ГОСТ IEC 62304—2022
ШЕГО ПО, и сравнить ее с 5.2, 5.3, 5.7 и разделом 7. Типичные шаги для выполнения данного анализа разрывов
(пробелов) включают:
а) идентификацию УСТАРЕВШЕГО ПО, включая ВЕРСИЮ, редакцию и любые другие средства, необходи
мые для четкой идентификации:
б) ОЦЕНКУ существующих ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ, соответствующих результатам, требуемым
5.2, 5.3, 5.7 и разделом 7;
c) ОЦЕНКУ имеющихся объективных свидетельств, документирование ранее применявшейся модели жиз
ненного цикла разработки программного обеспечения (при необходимости):
d) ОЦЕНКУ адекватности существующей документации по МЕНЕДЖМЕНТУ РИСКА с учетом ISO 14971.
Принимая во внимание проведенный анализ разрывов (пробелов), ИЗГОТОВИТЕЛЬ оценит потенциальное
снижение РИСКА в результате создания недостающих ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ и связанной с ними ДЕЯ
ТЕЛЬНОСТИ, а также разработает план выполнения ДЕЯТЕЛЬНОСТИ и создания недостающих пока ПОСТАВЛЯ
ЕМЫХ РЕЗУЛЬТАТОВ для закрытия этих разрывов.
Снижение РИСКА должно уравновешивать преимущества применения процесса разработки программного
обеспечения в соответствии с разделом 5 с возможностью того, что модификация УСТАРЕВШЕГО ПО без полного
знания истории его разработки может привести к появлению новых дефектов, которые увеличивают риск. Некото
рые элементы раздела 5 могут быть оценены как имеющие незначительное влияние или полностью не влияющие на
снижение РИСКА, когда это делается постфактум. Например, детальное проектирование и верификация моду ля
снижают РИСК в первую очередь в процессе разработки нового программного обеспечения или рефакторинга
существующего программного обеспечения. Если эти цели не запланированы, изолированное выполнение ДЕЯ
ТЕЛЬНОСТИ может привести к созданию документации, но не приведет к снижению РИСКА.
Как минимум, план устранения разрывов (пробелов) касается отсутствующих записей тестирования ПРО
ГРАММНЫХ СИСТЕМ. Если они отсутствуют или не подходятдля обоснования продолжения использования УСТА
РЕВШЕГО ПО, план устранения разрывов должен включать создание требований к ПРОГРАММНОЙ СИСТЕМЕ на
функциональном уровне в соответствии с 5.2 и тестирование в соответствии с 5.7.
Документированное обоснование дальнейшего использования УСТАРЕВШЕГО ПО основывается на имею
щихся объективных свидетельствах и результатах анализа, полученных в ходе оценки РИСКА и разработки плана
устранения разрывов, соответствующих контексту повторного использования УСТАРЕВШЕГО ПО.
Обоснование дает положительный аргумент в пользу безопасной и надежной работы УСТАРЕВШЕГО ПО
в контексте планируемого повторного использования, принимая во внимание как записи о постпроизводстве, до
ступные для УСТАРЕВШЕГО ПО, так и МЕРЫ ПО УПРАВЛЕНИЮ РИСКОМ, связанные с заполнением пробелов в
процессе.
После повторного использования УСТАРЕВШЕГО ПО в соответствии с 4.4 те части УСТАРЕВШЕГО ПО, для
которых сохраняются разрывы (пробелы) в ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТАХ, продолжают оставаться УСТАРЕВ
ШИМ ПО и могут быть рассмотрены для дальнейшего повторного использования в соответствии с 4.4. Когда раз
рывы (пробелы) в результатах устраняются путем изменения УСТАРЕВШЕГО ПО, изменения должны выполняться в
соответствии с разделами 4—9 настоящего стандарта.
В.5 ПРОЦЕСС разработки ПО
В.5.1 Планирование разработки ПО
Целью данной деятельности является планирование ЗАДАЧ разработки ПО для уменьшения РИСКОВ, вы
зываемых программным обеспечением, сообщение задач и целей участникам группы разработки, а также обеспе
чение выполнения требований к качеству СИСТЕМЫ для ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ.
ДЕЯТЕЛЬНОСТЬ по планированию разработки ПО может документировать ЗАДАЧИ в едином плане или в
различных планах. Некоторые ИЗГОТОВИТЕЛИ могут устанавливать политики и процедуры, которые применя
ются к разработке всего ПО для своих МЕДИЦИНСКИХ ИЗДЕЛИЙ. В этом случае план может просто ссылаться на
существующие политики и процедуры. Некоторые ИЗГОТОВИТЕЛИ могут подготовить план или набор планов для
разработки каждого ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ, которые влекут за собой детально установленные виды
ДЕЯТЕЛЬНОСТИ и ссылаются на общие процедуры. Другая возможность состоит в том, что план или набор пла
нов приспособлен для разработки каждого ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ. Планирование следует определять на
уровне детализации, необходимой для осуществления ПРОЦЕССА разработки, и он должен быть пропорционален
РИСКУ. Например, СИСТЕМЫ или элементы с более высокой степенью РИСКА должны подчиняться ПРОЦЕССУ
разработки с более строгими требованиями, а ЗАДАЧИ следует излагать более детально.
Планирование является итеративной ДЕЯТЕЛЬНОСТЬЮ, которую следует пересматривать и обновлять по
мере развития разработки. План может развиваться, чтобы включать большую и лучшую информацию, по мере
того как больше узнают о СИСТЕМЕ и уровне усилий, необходимых для развития СИСТЕМЫ. Например,
началь ная классификация безопасности ПО СИСТЕМЫ может измениться в результате осуществления
ПРОЦЕССА МЕ НЕДЖМЕНТА РИСКА и развития АРХИТЕКТУРЫ программного обеспечения. В некоторых
случаях может быть принято решение о включении ПОНП в СИСТЕМУ. Важно, чтобы планы обновлялись с целью
отразить в них теку щие знания о СИСТЕМЕ и уровне усилий, необходимом для СИСТЕМЫ или ее элементов,
чтобы обеспечить над лежащее управление ПРОЦЕССОМ разработки.
33