ГОСТ Р МЭК 62304—2013
ПО. Он должен быть достаточно полным, чтобы программисту не требовалось принимать специальных проект
ных решений.
ПРОГРАММНЫЕ ЭЛЕМЕНТЫ могут быть разложены на уровни так. что только немногие из новых ПРО
ГРАММНЫХ ЭЛЕМЕНТОВ выполняют связанные с БЕЗОПАСНОСТЬЮ требования оригинального ПРОГРАМ
МНОГО ЭЛЕМЕНТА. Оставшиеся ПРОГРАММНЫЕ ЭЛЕМЕНТЫ не осуществляют связанных с БЕЗОПАСНОСТЬЮ
функций и могут быть повторно классифицированы с присвоением более низкого класса БЕЗОПАСНОСТИ ПО.
Однако принятие такого решения само по себе является частью ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА и докумен
тируется в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
Поскольку реализация зависит отдетализированного проекта, необходимо верифицировать детализирован
ный проект до завершения деятельности. ВЕРИФИКАЦИЮ детализированного проекта, как правило, осуществля
ют путем технического ОЦЕНИВАНИЯ. 5.4.4 требует от ИЗГОТОВИТЕЛЯ ВЕРИФИЦИРОВАТЬ выходные данные
деятельности по детализированному проектированию. Проект определяет, какие требования должны быть реали
зованы. Если проект будет содержатьдефекты, то код не будет правильно осуществлять требования.
Если это имеет место в проекте. ИЗГОТОВИТЕЛЬ должен проверить характеристики проекта, которые счи
тает важными для БЕЗОПАСНОСТИ. Примеры таких характеристик включают:
- осуществление намеченных событий, входных и выходных данных, интерфейсов, логической схемы, рас
пределения ресурсов процессора, распределения ресурсов памяти, ошибок и исключений изоляции и устранения
ошибок;
- определение состояния по умолчанию, в котором все отказы, могущие привести к возникновению опасной
ситуации, охвачены, включая события и переходы;
- инициализация переменных, управление памятью; и
- «холодная» и «теплая» перезагрузки, режим ожидания и другие изменения состояния, которые могут ока
зать влияние на меры по УПРАВЛЕНИЮ РИСКОМ.
В.5.5 Реализация и ВЕРИФИКАЦИЯ ПРОГРАММНОГО МОДУЛЯ
Эта деятельность требует от ИЗГОТОВИТЕЛЯ записать и проверить код для ПРОГРАММНЫХ МОДУЛЕЙ.
Детализированный проект преобразовывается в исходный код. Кодирование представляет собой момент, в
который заканчивается декомпозиция спецификаций и начинается составление реализуемого ПО. Чтобы последо
вательно достигать желаемых характеристик кода, должны использоваться стандарты кодирования для определе
ния предпочитаемого стиля кодирования. Примеры стандартов кодирования включают требования к понятности,
правила использования языка или ограничений и сложность управления. Код для каждого модуля ВЕРИФИЦИРУ
ЕТСЯ. чтобы убедиться, что он функционирует, как определено вдетализированном проекте, и что он соответству ет
указанным стандартам кодирования.
В 5.5.5 от ИЗГОТОВИТЕЛЯ требуется проверять код. Если код не реализует проект правильно. ПО МЕДИ
ЦИНСКОГО ИЗДЕЛИЯ не будет работать так. как предполагалось.
В.5.6 Программная интеграция и тестирование интеграции
Эта деятельность требует от ИЗГОТОВИТЕЛЯ планировать и реализовывать интеграцию ПРОГРАММНЫХ
МОДУЛЕЙ в составные ПРОГРАММНЫЕ ЭЛЕМЕНТЫ так же. как и интеграцию ПРОГРАММНЫХ ЭЛЕМЕНТОВ в
более сложносоставные ПРОГРАММНЫЕ ЭЛЕМЕНТЫ, и проверять, что полученный в результате ПРОГРАММНЫЙ
ЭЛЕМЕНТ функционирует так. как предназначено.
Подход к интеграции может колебаться от непошаговой интеграции до любой формы пошаговой интеграции.
Свойства собираемого ПРОГРАММНОГО ЭЛЕМЕНТАдиктуют выбираемый метод интеграции.
Тестирование интеграции ПО направлено на передачу данных и управление всего ПРОГРАММНОГО ЭЛЕ
МЕНТА через внешние и внутренние интерфейсы. Внешние интерфейсы — те. которые имеют другое ПО. включая
работающее системное ПО и аппаратные средства МЕДИЦИНСКОГО ИЗДЕЛИЯ.
Точность тестирования интеграции и уровень детализации документации, связанной с тестированием инте
грации. должны быть соизмеримы с РИСКОМ, связанным с изделием, с зависимостью изделия от ПО для потен
циально опасных функций и с ролью определенных ПРОГРАММНЫХ ЭЛЕМЕНТОВ в функциях изделия с большей
степенью РИСКА. Например, несмотря на то. что все ПРОГРАММНЫЕ ЭЛЕМЕНТЫ должны быть протестированы,
элементы, которые влияют на БЕЗОПАСНОСТЬ, следует подвергать более точным, тщательным и подробным
тестам.
В соответствующих случаях тестирование интеграции демонстрирует поведение программы на границах ев
входных и выходных доменов (областей) и подтверждает ПРОГРАММНЫЕ реакции на недействительные, неожи
данные и специальные входные данные. Действия программы обнаруживаются при введении комбинации вход
ных данных, неожиданной последовательности входных данных или когда нарушены определенные требования
синхронизации. Требования тестирования в плане должны включать, соответственно, типы тестирования методом
«белого ящика», чтобы быть выполненными как часть интеграционного тестирования.
Тестирование методом «белого ящика», также известное как тестирование стеклянного ящика, структур
ное. прозрачного ящика и открытого ящика, — это техника тестирования, в которой используется точное знание
внутренней работы ТЕСТИРУЕМОГО ЭЛЕМЕНТА, чтобы выбирать данные тестирования. Тестирование «белого
ящика» использует определенные знания о ПРОГРАММНОМ ЭЛЕМЕНТЕ, чтобы проверять выходные данные.
Это тестирование является точным только в том случае, если тестер «знает», что ПРОГРАММНЫЙ ЭЛЕМЕНТ
должен делать. Тогда тестер может видеть, когда ПРОГРАММНЫЙ ЭЛЕМЕНТ отклоняется от его
намеченной
29