Требования к аппаратному и программному обеспечению являются требованиями предъявляемыми к чему
Требования к аппаратному и программному обеспечению являются требованиями предъявляемыми к чему
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ
Общие требования к разработке и документированию
Embedded system software.
General requirements for development and documentation
Дата введения 2003-07-01
1 РАЗРАБОТАН Государственным научно-исследовательским институтом авиационных систем с участием Научно-исследовательского института стандартизации и унификации
ВНЕСЕН Научно-исследовательским институтом стандартизации и унификации
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 июня 2002 г. N 247-ст
3 Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» с целью учета специфики разработки и документирования программного обеспечения встроенных систем реального времени
5 ПЕРЕИЗДАНИЕ. Октябрь 2005 г.
1 Область применения
Настоящий стандарт распространяется на процессы разработки и документирования программного обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все действия, имеющие отношение к разработке программного обеспечения.
Настоящий стандарт применяют полностью ко всему поставляемому программному обеспечению, включая среду разработки, если контрактом не предусмотрено использование специальных стандартов для определенных заказчиком типов ПО. Стандарт неприменим для аппаратных элементов программно-аппаратного обеспечения.
2 Нормативные ссылки
В настоящем стандарте использована ссылка на следующий стандарт:
3 Определения и сокращения
В настоящем стандарте применяют термины с соответствующими определениями по ГОСТ Р ИСО/МЭК 12207, а также приведенные ниже:
3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий для выполнения конкретной задачи.
3.2 анализ полноты покрытия: Определения степени, до которой работы процесса верификации ПО удовлетворяют поставленной цели.
3.3 аномальное поведение: Поведение, которое не соответствует заданным требованиям.
3.4 аппаратные средства: Материальная часть вычислительной системы, включающая в себя электрические и электронные элементы (например, приборы и схемы), электромеханические элементы (например, дисководы) и механические элементы (например, стойки).
3.5 архитектура: Организационная структура системы или ЭКПО, в которой идентифицированы компоненты, их интерфейсы и концепция взаимодействия между ними.
3.6 аттестация инструментальных средств: Процесс получения сертификационного доверия к программному инструментальному средству применительно к конкретной встроенной системе.
3.7 база данных: Совокупность взаимосвязанных данных, сохраненных в одном или более компьютерных файлах в виде, позволяющем обращаться к ним пользователям или компьютерным программам с помощью системы управления базой данных.
3.8 библиотека разработки ПО: Контролируемая совокупность документов, промежуточных и конечных программных продуктов, а также инструментальных средств и процедур, используемых для управления текущей разработкой и последующей поддержкой ПО.
3.9 верификация: Оценка результатов процесса с целью гарантии корректности и непротиворечивости в отношении входов и стандартов, существующих для данного процесса.
3.10 заплата: Исправление, вносимое непосредственно в объектную программу, а не в текст, на языке программирования.
3.11 изменение ПО: Модификация исходного кода, исполняемого объектного кода или сопутствующих документов относительно их базовой линии.
3.12 имитатор: Устройство, компьютерная программа или система, используемая при верификации ПО, которая принимает те же входные данные и производит те же выходные данные, что и объектная система.
3.13 интегральный процесс: Процесс разработки ПО, который остается активным на протяжении жизненного цикла ПО.
3.14 интеграция аппаратуры и ПО: Процесс объединения ПО с объектным компьютером.
3.15 интеграция ПО: Процесс объединения компонентов кода.
3.16 интерфейс: Взаимосвязь между двумя или более объектами (типа ЭКПО/ЭКПО, ЭКПО/ЭКА, ЭКПО/пользователь или между модулями ПО), которые совместно используют и обеспечивают данные или обмениваются ими.
3.17 инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
3.18 инструментальный компьютер: Компьютер, на котором разрабатывают ПО.
3.19 исходный код: Код, написанный на исходном языке программирования, таком как язык ассемблера и/или язык высокого уровня, в машинно-читаемой форме, пригодной для ввода в ассемблер или компилятор.
3.20 квалификационное тестирование: Тестирование, выполняемое с целью убедить заказчика, что ПО соответствует заданным требованиям.
3.21 класс эквивалентности: Такое разбиение входной области программы, при котором тестирование для представительного значения класса эквивалентно тестированию для любого другого значения из этого класса.
3.22 код: Реализация конкретных данных или конкретной компьютерной программы в символьной форме, такой, например, как исходный код, объектный код или машинный код.
3.23 коммерчески доступное ПО: Коммерчески доступное программное средство, продаваемое производителем по официальным каталогам. Коммерчески доступное ПО не предназначено для переделки или усовершенствования. ПО, разработанное по специальным контрактам для специализированных приложений, не является коммерчески доступным ПО.
3.24 компонент: Замкнутая часть, комбинация частей или элемент, которые выполняют в системе отдельную функцию.
3.25 контракт: Соглашение о разработке ПО, установленное между заказчиком и разработчиком.
3.26 критерии перехода: Минимальные условия, определенные процессом планирования ПО, которые должны быть выполнены для входа в процесс.
3.27 мертвый код: Исполняемый объектный код (или данные), который в результате ошибки проектирования не может быть выполнен (код) или использован (данные) в функциональной конфигурации среды объектного компьютера и не может быть прослежен в системных или программных требованиях. Исключение составляют встроенные идентификаторы.
3.28 многоверсионное неидентичное ПО: Множество из двух или более программ, разработанных отдельно по одним и тем же функциональным требованиям. Ошибки одной версии обнаруживают путем сравнения выходных результатов разных программ.
3.29 модифицированное покрытие условий/решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении программы должно быть выполнено со всеми возможными результатами хотя бы один раз; все результаты каждого решения должны быть выполнены хотя бы один раз, и для каждого условия в решении должно быть показано его независимое влияние на результат решения. Независимость влияния условия на результат решения демонстрируют путем рассмотрения всех возможных комбинаций условий.
3.30 непоставляемое программное средство: Программное средство, которое в соответствии с контрактом не требуется поставлять заказчику или другому обозначенному получателю.
3.31 объектный код: Представление компьютерной программы на низком уровне, обычно не в форме, непосредственно пригодной для объектного компьютера, а в форме, включающей в себя, помимо информации о процессорных командах, информацию о размещении программы.
3.32 объектный компьютер: Компьютер, на котором эксплуатируют ПО.
3.33 отказоустойчивость: Свойство системы продолжать правильное выполнение функций при наличии ограниченного числа аппаратных или программных дефектов.
3.34 отключенный код: Исполняемый объектный код (или данные), который согласно проекту предназначен для выполнения (код) или использования (данные) только при определенных условиях.
3.35 оценка безопасности системы: Систематическая, всесторонняя оценка предлагаемой системы с целью показать, что она удовлетворяет требованиям, предъявленным к обеспечению безопасности.
3.36 ошибка: Неправильность в требованиях, проекте или коде.
3.37 передача ПО: Последовательность действий, определяющих ответственность за передачу разработанного ПО организацией, имеющей право на эти действия (обычно организацией, которая выполняет разработку ПО), в организацию, осуществляющую поддержку ПО.
3.38 перепроектирование: Процесс исследования и изменения существующей системы для преобразования ее в новую форму.
3.39 поддержка ПО: Набор действий, гарантирующий, что установленное для эксплуатационного использования ПО продолжает выполнять все функции в соответствии с предназначением системы. Поддержка ПО включает в себя сопровождение ПО, помощь пользователям и связанные с этим действия.
3.40 покрытие операторов: Такое выполнение программы при тестировании, при котором каждый оператор в программе должен быть выполнен хотя бы один раз.
3.41 покрытие решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении должно быть выполнено с каждым возможным результатом хотя бы один раз.
3.42 покрытие условий/решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении программы должно быть выполнено со всеми возможными результатами хотя бы один раз; все результаты каждого решения должны быть выполнены хотя бы один раз.
3.43 поставляемое программное средство: Программное средство, требуемое по контракту, которое будет поставлено заказчику или другому обозначенному получателю.
3.44 построение: Версия ПО, отвечающая определенному подмножеству требований, которые должны быть обеспечены в конечном ПО.
3.45 прерывание: Приостановка задачи, например выполнения компьютерной программы, вызванная событием, внешним для этой задачи. Прерывание позволяет обработать возникшее событие и вернуться к прерванной задаче.
3.46 программная система: Система, состоящая из ПО и, возможно, компьютерного оборудования для его выполнения.
3.47 программное обеспечение (ПО): Совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих программ.
3.48 программное средство: ПО и связанные с ним документы, вновь созданные, модифицированные или сгруппированные для удовлетворения требованиям контракта.
3.49 программное средство многократного использования: Программное средство, разработанное для конкретного применения, но с возможностью другого применения, или разработанное специально для многократного использования в различных проектах или для многофункционального использования в одном проекте.
3.50 производные требования: Дополнительные требования, появившиеся в результате выполнения процессов разработки ПО, которые не являются непосредственно связанными с требованиями верхнего уровня.
3.51 процедура тестирования: Детальные инструкции для того, чтобы генерировать и выполнить множество тестовых наборов и оценить результаты их выполнения.
3.52 разработка ПО: Набор действий, результатом выполнения которых являются программные средства. Разработка ПО может включать в себя новую разработку, модификацию, многократное использование, перепроектирование или любое другое действие, требуемое для создания программных средств.
3.54 связность по данным: Зависимость программного компонента от данных, которые используются не только исключительно в этом компоненте.
3.55 связность по управлению: Степень влияния одного программного компонента на выполнение другого программного компонента.
3.56 сертификационное доверие: Принятие сертифицирующей организацией того факта, что процесс или средство удовлетворяет сертификационным требованиям.
3.57 система: Набор аппаратных и программных компонентов, созданный для выполнения определенной функции или множества функций.
3.58 словарь данных: Детальное описание данных, параметров, переменных и констант, используемых в системе.
3.59 совместный просмотр: Совещание с участием представителей и заказчика и разработчика, в процессе которого проверяют и обсуждают состояние проекта, программные средства и/или проблемы проекта.
3.60 соискатель: Человек или организация, претендующая на получение утверждения от сертифицирующей организации.
3.61 соисполнитель разработки: Организация, которая не является ни главным подрядчиком, ни субподрядчиком данной разработки, но которая принимает участие в разработке системы или проекта.
3.62 среда разработки ПО: Интегрированная система, включающая в себя аппаратные средства, ПО, программно-аппаратные средства, процедуры и документы, необходимые для разработки ПО.
3.63 среда верификации/тестирования ПО: Интегрированная система, включающая в себя аппаратные средства, ПО, программно-аппаратные средства, процедуры и документы, необходимые для выполнения верификации/тестирования ПО. Элементами данной среды могут являться имитаторы, статические анализаторы, генераторы тестовых данных, анализаторы путей и т.п., а также элементы, используемые в среде разработки ПО.
Требования к аппаратному и программному обеспечению являются требованиями предъявляемыми к чему
Минимальные аппаратные требования:
Для развертывания в облачных окружениях требования к Серверу администрирования и серверу базы данных такие же, как и к физическому Серверу администрирования (в зависимости от того, каким количеством устройств вы хотите управлять).
Сервер баз данных (может быть установлен на другой машине):
Рекомендуется использовать версию MariaDB 10.3.22; если вы используете более раннюю версию, задача обновления Windows может выполнятся более одного дня.
Поддерживаются следующие платформы виртуализации:
Поддерживаются следующие SIEM-системы:
Kaspersky Security Center 12 Web Console
Сервер Kaspersky Security Center 12 Web Console
Минимальные аппаратные требования:
Клиентскому устройству для работы с Kaspersky Security Center 12 Web Console требуется только браузер.
Требования к аппаратному и программному обеспечению устройства соответствуют требованиям браузера, который используется для работы с Kaspersky Security Center 12 Web Console.
Сервер мобильных устройств iOS™ Mobile Device Management (iOS MDM)
Операционная система Microsoft Windows (версия поддерживаемой операционной системы определяется требованиями Сервера администрирования).
Сервер мобильных устройств Exchange ActiveSync
Программные и аппаратные требования для Сервера мобильных устройств Exchange ActiveSync полностью включены в требования для сервера Microsoft Exchange Server.
Поддерживается работа с Microsoft Exchange Server 2007, Microsoft Exchange Server 2010 и Microsoft Exchange Server 2013.
Минимальные аппаратные требования:
Поддерживаются следующие платформы виртуализации:
На устройствах под управлением Windows 10 версии RS4 или RS5 Kaspersky Security Center может не обнаруживать некоторые уязвимости в папках, в которых включен учет регистра.
Агент администрирования для Linux и Агент администрирования для macOS предоставляются вместе с программами безопасности «Лаборатории Касперского» для этих операционных систем.
Требования к ПО на пальцах
Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.
Если коротко, то основные этапы разработки требований — это:
Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.
Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.
В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.
Так что же такое требования и почему важно уметь их разрабатывать?
Итак, обратимся к истокам:
То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.
С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.
1. Зачем?
Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.
Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.
Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.
Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.
Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.
Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.
Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.
Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.
И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.
2. Что?
Цель достигается разными путями. И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели.
Чтобы сократить процесс согласования счетов, мы можем:
А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.
Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.
В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.
Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.
У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.
3. Как?
Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.
Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.
На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.
Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил.
Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
4. Когда?
В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.
Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.
Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту.
Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.
В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).
А дальше можно уже раскидывать по спринтам/этапам разработки и внедрения. Ну и повторять эти упраженения в рамках каждой итерации. И будет вам счастье — никаких переделок, довольный заказчик, счастливая команда, работающий и приносящий пользу продукт, эльфы играют на арфе на фоне радуги.
Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.
Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.
Спасибо за внимание и удачного проектирования.
Требования к аппаратному и программному обеспечению являются требованиями предъявляемыми к чему
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Государственная система обеспечения единства измерений
ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ СРЕДСТВ ИЗМЕРЕНИЙ
State system for ensuring the uniformity of measurements. Requirements for software of measuring instruments. Main principles
Дата введения 2016-03-01
Предисловие
1 РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт метрологической службы» (ФГУП «ВНИИМС»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 53 «Основные нормы и правила по обеспечению единства измерений»
5 ПЕРЕИЗДАНИЕ. Март 2019 г.
Введение
Настоящий стандарт разработан в развитие пункта 1 статьи 9 Федерального закона Российской Федерации от 26 июня 2008 г. N 102-ФЗ «Об обеспечении единства измерений», в соответствии с которым в состав обязательных требований, предъявляемых к средствам измерений, применяемым в сфере государственного регулирования обеспечения единства измерений, в необходимых случаях включают требования к программному обеспечению средств измерений.
Стандарт предназначен для использования разработчиками, изготовителями и заявителями испытаний программного обеспечения средств измерений, а также организациями, проводящими испытания средств измерений или осуществляющими подтверждение соответствия программного обеспечения средств измерений в соответствии с действующим законодательством Российской Федерации.
1 Область применения
Настоящий стандарт устанавливает обязательные требования к программному обеспечению (ПО) средств измерений (СИ), применяемых в сфере государственного регулирования обеспечения единства измерений, обусловленные необходимостью защиты ПО и измерительной информации от непреднамеренных и преднамеренных изменений, его идентификации и оценки влияния на метрологические характеристики СИ.
— на ПО СИ, в том числе измерительных и информационно-измерительных систем;
— ПО автоматизированных систем, функционирующих с использованием СИ или компонентов измерительных систем;
— ПО контроллеров и вычислительных блоков, не входящих в состав измерительных систем, а также технических систем и устройств с измерительными функциями, осуществляющих обработку и представление измерительной информации.
Стандарт также может быть использован при испытаниях ПО СИ, не входящих в сферу государственного регулирования обеспечения единства измерений.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ Р 8.596 Государственная система обеспечения единства измерений. Метрологическое обеспечение измерительных систем. Основные положения
ГОСТ Р 8.839-2013/OIML D 31:2008 Государственная система обеспечения единства измерений. Общие требования к измерительным приборам с программным управлением
ГОСТ Р ИСО 9127 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов
ГОСТ ИСО/МЭК 17025 Общие требования к компетентности испытательных и калибровочных лабораторий
ГОСТ Р ИСО/МЭК 12119 Информационная технология. Пакеты программ. Требования к качеству и тестирование
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 алгоритм хеширования (hash algorithm): Алгоритм, который сжимает содержимое блока данных в число определенной длины (хеш-сумма), такое, что изменение любого бита блока данных приводит к другой хеш-сумме [1]*.
3.2 данные: Информация, представленная в виде, пригодном для передачи, интерпретации или обработки.
3.3 защищенный интерфейс: Интерфейс, через который может быть передан или изменен только определенный набор данных и параметров. Через защищенный интерфейс невозможно ввести в ПО данные, которые могут быть ошибочно приняты за результат измерения, а также команды, которые могут быть использованы для искажения отображаемых, обработанных и сохраненных результатов измерения или других данных либо для несанкционированного изменения настроек ПО.
3.4 идентификационные данные (признаки) ПО: Однозначно связанная с конкретным ПО последовательность символов (букв, цифр и т.п.), например контрольная сумма.
3.5 идентификация ПО: Проверка и подтверждение подлинности и целостности ПО, выраженное в символах (буквах, цифрах), однозначно соответствующих ПО (например, контрольная сумма).
3.6 интерфейс (interface): Общая граница между двумя блоками (функциональными единицами), характеризующимися различными функциями, физическими соединениями и обменом сигналами [2].
3.7 интерфейс пользователя (user interface): Интерфейс, обеспечивающий прохождение обрабатываемой информации (данных) между пользователем и СИ либо между пользователем и аппаратными или программными компонентами СИ [2].
3.8 интерфейс связи (communication interface): Электронное, оптическое, радио- или другое техническое устройство, позволяющее обрабатываемой информации (данным) автоматически проходить между компонентами СИ [2].
3.9 исполняемый код (executable code): Файл, установленный в вычислительном компоненте СИ, электронном устройстве или его части [постоянное запоминающее устройство (ПЗУ), жесткий диск и т.д.]. Микропроцессор интерпретирует содержимое файла (код) и преобразует его в определенные логические, арифметические, декодирующие операции или операции передачи данных [2].
3.10 контрольная сумма: Число, рассчитанное путем проведения определенных операций над входными данными (например, хеш-сумма, электронная подпись), обычно используемое для проверки правильности передачи данных по каналам связи.
3.11 метрологически значимая часть ПО: Программы и программные модули, выполняющие обработку измерительной информации и реализующие функции по идентификации и защите ПО СИ.
3.12 непреднамеренные изменения ПО: Непредумышленные, случайные воздействия на ПО и измерительную информацию, вызванные ошибками в проектировании СИ, в программировании, а также действиями персонала и воздействиями случайных физических факторов.
3.13 подлинность (аутентичность) ПО и данных: Состояние ПО и данных, характеризующееся их идентичностью приписанным признакам (характеристикам).
3.14 подтверждение соответствия (сертификация) ПО СИ: Документальное удостоверение соответствия ПО положениям настоящего стандарта и/или других нормативных документов.
3.15 преднамеренные изменения ПО: Сознательные воздействия на ПО и измерительную информацию с целью их искажения.
3.16 проверка защиты ПО: Исследование ПО с целью подтверждения идентификационных данных (признаков) и оценки уровня его защиты в соответствии с требованиями законодательства в области обеспечения единства измерений.
3.17 ПО СИ: Программы (совокупность программ), предназначенные для использования в СИ и реализующие в том числе сбор, передачу, обработку, хранение и представление измерительной информации, а также программные модули и компоненты, необходимые для функционирования этих программ.
3.18 программное разделение (software separation): Выделение в ПО метрологически значимой и незначимой частей [2].
3.19 утвержденное ПО: ПО, прошедшее процедуру подтверждения соответствия.
3.20 целостность ПО и данных (integrity of data and software): Состояние ПО и данных, характеризующееся отсутствием изменений преднамеренного или случайного характера [1].
3.21 электронная подпись (electronic signature): Последовательность чисел, однозначно закрепленная за ПО или данными для доказательства их целостности и подлинности [1].
4 Требования к программному обеспечению средств измерений
4.1 Общие положения
Настоящий стандарт предназначен для использования при испытаниях ПО СИ, а также для подтверждения соответствия ПО СИ согласно действующему законодательству Российской Федерации.
4.1.1 В соответствии с Федеральным законом [3] (статья 9, пункт 2) конструкция средств измерений должна обеспечивать ограничение доступа к определенным частям СИ (включая ПО) в целях предотвращения несанкционированных настройки и вмешательства, которые могут привести к искажениям результатов измерений. При этом к ПО СИ, в соответствии с международными документами [1] и [2], должны предъявляться общие требования и требования, обусловленные исполнением ПО в соответствии с функциями и особенностями, предусмотренными информационными технологиями.
4.1.2 Общие требования к ПО СИ включают в себя требования к документации, идентификации, структуре ПО, влиянию ПО на метрологические характеристики СИ и к защите ПО и данных.
4.1.3 Требования, обусловленные исполнением ПО в соответствии с функциями и особенностями, предусмотренными информационными технологиями, включают в себя требования к обновлению (загрузке) ПО, долговременному хранению данных и их передаче через сети коммуникации, а также к разделению ПО.
Указанные требования предъявляются к ПО в том случае, если перечисленные информационные технологии используют.
4.1.4 Все требования к ПО СИ, содержащиеся в настоящем разделе, соответствуют международным документам [1] и [2], а также ГОСТ Р 8.839, ГОСТ Р 8.596, ГОСТ Р ИСО/МЭК 17025*, ГОСТ Р ИСО/МЭК 12119, ГОСТ Р ИСО 9127.
4.2 Требования к документации
4.2.1 ПО СИ следует сопровождать документацией, соответствующей требованиям международных документов [1], [2], настоящего стандарта и других нормативных документов, относящихся к программной документации. Документация должна полно и однозначно описывать назначение, основные функции, структуру и другие необходимые параметры и характеристики ПО.
4.2.2 Документация, сопровождающая ПО СИ при подтверждении его соответствия, должна содержать:
— описание структуры ПО и выполняемых функций, в том числе последовательность обработки данных;
— описание метрологически значимых функций и параметров ПО;
— описание реализованных в ПО расчетных алгоритмов, а также их блок-схемы;
— описание модулей ПО;
— перечень интерфейсов и перечень команд для каждого интерфейса, в том числе для интерфейсов связи и пользователя, включая заявление об их полноте;
— список, значение и действие всех команд, получаемых от клавиатуры, мыши и других устройств ввода информации;
— описание реализованной методики идентификации ПО и самих идентификационных признаков;
— описание хранимых или передаваемых наборов данных;
— описание реализованных методов защиты ПО и данных;
— характеристики требуемых системных и аппаратных средств, если эта информация не приведена в руководстве пользователя.
Перечень и содержание документов, сопровождающих ПО при подтверждении соответствия, можно уточнить и скорректировать по согласованию между заявителем (разработчиком, изготовителем) и организацией, проводящей подтверждение соответствия (сертификацию) ПО СИ или аккредитованной на проведение испытаний СИ.
4.2.3 В отдельных случаях при необходимости документацию рекомендуется дополнять текстами программ или их фрагментами. При этом может быть заключен договор о соблюдении конфиденциальности.
4.2.4 Графическая и текстовая информация в технической документации ПО должна быть представлена таким образом, чтобы она была пригодна для полного и однозначного понимания.