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