ГОСТ IEC 62304-2022. Межгосударственный стандарт. Изделия медицинские. Программное обеспечение. Процессы жизненного цикла
5 ПРОЦЕСС разработки программного обеспечения
5.1* Планирование разработки программного обеспечения
5.1.1 План разработки программного обеспечения
ИЗГОТОВИТЕЛЬ должен создать план (или планы) разработки программного обеспечения с целью провести всю необходимую ДЕЯТЕЛЬНОСТЬ в отношении ПРОЦЕССА разработки программного обеспечения, соответствующий области, значимости и классу безопасности разрабатываемой ПРОГРАММНОЙ СИСТЕМЫ. МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ должна быть либо полностью определена, либо указана в плане (или в планах). План должен содержать:
a) ПРОЦЕССЫ, которые будут использоваться при разработке ПРОГРАММНОЙ СИСТЕМЫ (см. примечание 4);
b) ПОСТАВЛЯЕМЫЕ РЕЗУЛЬТАТЫ (включая документацию) ДЕЯТЕЛЬНОСТИ и ЗАДАЧ;
c) ПРОСЛЕЖИВАЕМОСТЬ между требованиями СИСТЕМЫ, требованиями программного обеспечения, испытанием ПРОГРАММНОЙ СИСТЕМЫ и мерами по УПРАВЛЕНИЮ РИСКОМ, включенными в программное обеспечение;
d) конфигурацию программного обеспечения и менеджмент изменений, включая СОСТАВНЫЕ ЧАСТИ КОНФИГУРАЦИИ ПОНП (программное обеспечение неизвестного происхождения), и программного обеспечения, используемого для поддержки разработки;
e) решение проблем с программным обеспечением для обработки проблем, обнаруженных в
ПРОГРАММНОМ ОБЕСПЕЧЕНИИ МЕДИЦИНСКОГО ИЗДЕЛИЯ, ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТАХ и |
ДЕЯТЕЛЬНОСТИ на каждой стадии жизненного цикла. [Классы A, B, C]
Примечание 1 - МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ может определять различные элементы (ПРОЦЕССЫ, ДЕЯТЕЛЬНОСТЬ, ЗАДАЧИ и ПОСТАВЛЯЕМЫЕ РЕЗУЛЬТАТЫ) для различных ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ в соответствии с классами безопасности программного обеспечения для каждой ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ ПРОГРАММНОЙ СИСТЕМЫ.
Примечание 2 - ДЕЯТЕЛЬНОСТЬ и ЗАДАЧИ могут перекрываться или взаимодействовать и могут выполняться итеративно или рекурсивно. Это не подразумевает того, что должна использоваться определенная модель жизненного цикла.
Примечание 3 - Другие ПРОЦЕССЫ описываются в настоящем стандарте отдельно от ПРОЦЕССА разработки. Это не подразумевает того, что они должны быть реализованы в виде отдельной ДЕЯТЕЛЬНОСТИ и ЗАДАЧ. ДЕЯТЕЛЬНОСТЬ и ЗАДАЧИ других ПРОЦЕССОВ могут быть включены в ПРОЦЕСС разработки.
Примечание 4 - План разработки программного обеспечения может ссылаться на существующие ПРОЦЕССЫ или определять новые.
Примечание 5 - План разработки программного обеспечения может быть включен в план разработки общей СИСТЕМЫ.
5.1.2 Поддержание плана разработки программного обеспечения в актуальном состоянии
ИЗГОТОВИТЕЛЬ должен обновлять план по мере того, как осуществляется разработка. [Классы A, B, C]
5.1.3 План разработки программного обеспечения относительно проектирования и разработки СИСТЕМЫ
a) ИЗГОТОВИТЕЛЬ должен указать требования СИСТЕМЫ в плане разработки программного обеспечения в качестве входных данных.
b) В план разработки программного обеспечения ИЗГОТОВИТЕЛЬ должен включать или ссылаться на процедуры по координации разработки программного обеспечения с разработкой системы, необходимой для выполнения требований 4.1 (например, системная интеграция, верификация и валидация). [Классы A, B, C] |
Примечание - Может не существовать различий между требованиями ПРОГРАММНОЙ СИСТЕМЫ и требованиями СИСТЕМЫ, если ПРОГРАММНАЯ СИСТЕМА является отдельной СИСТЕМОЙ (например, если программное обеспечение само по себе является изделием).
5.1.4 Стандарты, методы и инструменты планирования разработки программного обеспечения
В план разработки программного обеспечения ИЗГОТОВИТЕЛЬ должен включать или ссылаться:
a) на стандарты;
b) методы;
c) инструменты,
связанные с разработкой ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ класса C. [Класс C]
5.1.5 Программная интеграция и планирование тестирования интеграции
ИЗГОТОВИТЕЛЬ должен включить в план разработки программного обеспечения план интеграции ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ (включая ПОНП) или сослаться на него, а также выполнить тестирование во время интеграции. [Классы B, C]
Примечание 1 - Допускается объединение тестирования интеграции и тестирования ПРОГРАММНОЙ СИСТЕМЫ в единые план и совокупность ДЕЯТЕЛЬНОСТИ. Примечание 2 - См. 5.6. |
5.1.6 Планирование ВЕРИФИКАЦИИ программного обеспечения
В план разработки программного обеспечения ИЗГОТОВИТЕЛЬ должен включить или сослаться на следующую информацию по ВЕРИФИКАЦИИ:
a) ПОСТАВЛЯЕМЫЕ РЕЗУЛЬТАТЫ, требующие ВЕРИФИКАЦИИ;
b) требуемые ВЕРИФИКАЦИОННЫЕ ЗАДАЧИ для каждой ДЕЯТЕЛЬНОСТИ в жизненном цикле;
c) контрольные точки, на которых ВЕРИФИЦИРУЮТСЯ ПОСТАВЛЯЕМЫЕ РЕЗУЛЬТАТЫ;
d) критерии приемки для ВЕРИФИКАЦИИ ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ. [Классы A, B, C]
5.1.7 Планирование МЕНЕДЖМЕНТА РИСКА программного обеспечения
В план разработки программного обеспечения ИЗГОТОВИТЕЛЬ должен включать или ссылаться на план осуществления ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА программного обеспечения в отношении ДЕЯТЕЛЬНОСТИ и ЗАДАЧ, включая МЕНЕДЖМЕНТ РИСКА, применяющийся к ПОНП. [Классы A, B, C]
5.1.8 Документация по планированию
В план разработки программного обеспечения ИЗГОТОВИТЕЛЬ должен включать, или ссылаться на информацию о документации, которая будет создана во время жизненного цикла разработки программного обеспечения. Каждому идентифицированному документу или типу документа должна быть присвоена (или содержаться непосредственно) следующая информация:
a) титульный лист, наименование или обозначение;
b) цель;
c) процедуры и ответственность за разработку, анализ, одобрение и модификацию. [Классы A, B, C] |
Примечание - Информация для рассмотрения менеджмента конфигурации документации приведена в разделе 8. |
5.1.9 Планирование менеджмента конфигурации программного обеспечения
В план разработки программного обеспечения ИЗГОТОВИТЕЛЬ должен включать или ссылаться на информацию о менеджменте конфигурации программного обеспечения. Эта информация должна содержать или ссылаться:
a) на классы, типы, категории или списки элементов, подлежащих управлению;
b) ДЕЯТЕЛЬНОСТЬ и ЗАДАЧИ по менеджменту конфигурации программного обеспечения;
c) структуру (структуры), отвечающую(ие) за ДЕЯТЕЛЬНОСТЬ по менеджменту конфигурации программного обеспечения;
d) их взаимосвязь с другими структурами, такими как разработка или техническая поддержка программного обеспечения;
e) случаи, когда элементы должны находиться под управлением конфигурации;
f) случаи, когда следует использовать ПРОЦЕСС решения проблем. [Классы A, B, C]
Примечание - См. раздел 8. |
5.1.10 Поддержка элементов, подлежащих управлению
Элементы, подлежащие управлению, должны включать инструменты, элементы или настройки, использующиеся для разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, которые могут воздействовать на ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ. [Классы B, C]
Примечание 1 - Примеры подобных элементов включают компиляторные/ассемблерные версии, созданные файлы, командные файлы и специфичные настройки окружения. Примечание 2 - См. раздел 8. |
5.1.11 Управление СОСТАВНЫМИ ЧАСТЯМИ КОНФИГУРАЦИИ программного обеспечения до ВЕРИФИКАЦИИ
ИЗГОТОВИТЕЛЬ должен запланировать размещение СОСТАВНОЙ ЧАСТИ КОНФИГУРАЦИИ под |
управление менеджмента конфигурации прежде, чем они будут ВЕРИФИЦИРОВАНЫ. [Классы B, C]
5.1.12 Идентификация и предотвращение распространенных дефектов программного обеспечения ИЗГОТОВИТЕЛЬ должен включить или указать в плане разработки программного обеспечения процедуру: а) для определения категорий дефектов, которые могут быть введены на основе выбранной технологии программирования и имеют отношение к их ПРОГРАММНОЙ СИСТЕМЕ; б) документирования свидетельств, демонстрирующих неспособность этих дефектов приводить к недопустимому РИСКУ. Примечание - Примеры категорий дефектов или причин, способствующих возникновению ОПАСНЫХ СИТУАЦИЙ, см. в приложении B из IEC/TR 80002-1:2009.
[Классы B, C] |
5.2* Анализ требований к программному обеспечению
5.2.1 Отделение и документирование требований к программному обеспечению на основе требований СИСТЕМЫ
Для каждой ПРОГРАММНОЙ СИСТЕМЫ МЕДИЦИНСКОГО ИЗДЕЛИЯ ИЗГОТОВИТЕЛЬ должен определить и документировать требования к ПРОГРАММНОЙ СИСТЕМЕ исходя из требований уровня СИСТЕМЫ. [Классы A, B, C]
Примечание - Может не существовать различий между требованиями ПРОГРАММНОЙ СИСТЕМЫ и требованиями СИСТЕМЫ, если ПРОГРАММНАЯ СИСТЕМА является отдельной СИСТЕМОЙ (например, если программное обеспечение само по себе является изделием).
5.2.2 Содержание требований к программному обеспечению
Как применимые и подходящие в отношении ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКИХ ИЗДЕЛИЙ, ИЗГОТОВИТЕЛЬ должен включать в требования к программному обеспечению:
a) требования к потенциальным возможностям и функциональности.
Примечание 1 - Примеры включают:
- характеристики, связанные с выполнением (например, цели/назначение программного обеспечения, требования по синхронизации);
- физические характеристики (например, язык машинного кода, платформу, операционную СИСТЕМУ);
- компьютерное окружение (например, аппаратные средства, размер памяти, процессор, часовой пояс, инфраструктуру сети);
- необходимость совместимости с модернизациями или многими ПОНП или другими версиями изделий;
b) входные и выходные данные ПРОГРАММНОЙ СИСТЕМЫ.
Примечание 2 - Например:
- характеристики данных (например, цифровые, буквенно-цифровые, формат);
- диапазоны;
- пределы;
- значения по умолчанию;
c) интерфейсы между ПРОГРАММНОЙ СИСТЕМОЙ и другими СИСТЕМАМИ;
d) программные средства управления сигналами тревоги, предупреждениями и оповещением оператора;
e) требования к ЗАЩИЩЕННОСТИ.
Примечание 3 - Например:
- связанные с компромиссом относительно конфиденциальной информации;
- идентификация;
- авторизация;
- системный журнал;
- непрерывность связи;
- система безопасности/защита от взлома;
f) требования пользовательского интерфейса, реализованные в программном обеспечении. |
Примечание 4 - Примеры в этой области связаны:
- с поддержкой операций, выполняемых вручную;
- взаимодействием между человеком и оборудованием;
- ограничениями в отношении персонала;
- областями, где требуется пристальное человеческое внимание.
Примечание 5 - Информацию относительно требований к разработке удобства и простоты использования
(эксплуатационной пригодности) можно найти в IEC 62366-1 [21] среди прочих стандартов (например, IEC 60601-1-6 [3]); |
g) определение данных и требований к базе данных.
Примечание 6 - Например:
- форма;
- размерность;
- функция;
h) требования по инсталляции и приемке поставляемого ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКИХ ИЗДЕЛИЙ для разработки и технической поддержки сайта или сайтов;
i) требования, относящиеся к методам разработки и технической поддержки;
j) требования, связанные с аспектами информационных сетей.
Примечание 9 - Примеры включают аспекты, которые связаны:
- с сетевыми сигналами тревоги, предупреждения и сообщения оператора;
- сетевыми протоколами;
- обработкой недоступности сетевых услуг;
k) требования к поддержке пользователей;
l) регулирующие требования.
Примечание 10 - Требования с a) до l) могут пересекаться. |
[Классы A, B, C]
Примечание 11 - Все эти требования могут не иметься в наличии на момент начала разработки.
Примечание 12 - Среди прочих, ISO/IEC 25010 [12] приводит информацию о качественных характеристиках, |
которая может быть полезна при определении требований к программному обеспечению.
5.2.3 Включение мер УПРАВЛЕНИЯ РИСКОМ в требования к программному обеспечению
ИЗГОТОВИТЕЛЬ должен включать меры по УПРАВЛЕНИЮ РИСКОМ, реализованные в программном |
обеспечении в требования, соответствующие ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ МЕДИЦИНСКИХ ИЗДЕЛИЙ. [Классы B, C]
Примечание - Эти требования могут быть недоступны в начале процесса разработки и изменяться по мере того, как создается программное обеспечение и устанавливаются дальнейшие меры по УПРАВЛЕНИЮ РИСКОМ.
5.2.4 ПЕРЕОЦЕНИВАНИЕ АНАЛИЗА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ
ИЗГОТОВИТЕЛЬ должен осуществить ПЕРЕОЦЕНИВАНИЕ АНАЛИЗА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ, когда требования к программному обеспечению установлены, и, соответственно, обновить эти требования по результатам переоценки. [Классы A, B, C]
5.2.5 Обновление требований |
ИЗГОТОВИТЕЛЬ должен удостовериться, что существующие требования, включая требования к СИСТЕМЕ, ПЕРЕОЦЕНЕНЫ и обновлены, в соответствии с результатами ДЕЯТЕЛЬНОСТИ по анализу требований к программному обеспечению. [Классы A, B, C]
5.2.6 Верификация требований к программному обеспечению
ИЗГОТОВИТЕЛЬ должен верифицировать и документировать, что требования к программному обеспечению:
a) включают требования к СИСТЕМЕ, в том числе относящиеся к УПРАВЛЕНИЮ РИСКОМ;
b) не противоречат друг другу;
c) выражены в терминах, которые избегают двусмысленности;
d) формулируются в терминах, которые позволяют установить критерии тестирования и осуществить тестирование; |
e) могут быть идентифицированы уникальным образом;
f) являются прослеживаемыми в отношении требований к СИСТЕМЕ или к другому источнику.
[Классы A, B, C]
Примечание - Настоящий стандарт не требует использования формально установленного языка.
5.3 Проектирование АРХИТЕКТУРЫ программного обеспечения
5.3.1 Преобразование требований к программному обеспечению в АРХИТЕКТУРУ
ИЗГОТОВИТЕЛЬ должен преобразовать требования к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ МЕДИЦИНСКОГО ИЗДЕЛИЯ в документированную АРХИТЕКТУРУ, которая описывает структуру программного обеспечения и идентифицирует ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ. [Классы B, C]
5.3.2 Разработка АРХИТЕКТУРЫ для интерфейсов ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ
ИЗГОТОВИТЕЛЬ должен разработать и документировать АРХИТЕКТУРУ для интерфейсов между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ и компонентами, внешними по отношению к ПРОГРАММНЫМ СОСТАВНЫМ ЧАСТЯМ (как для программной, так и для аппаратной части), а также между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ. [Классы B, C]
5.3.3 Определение требований к функциональным и эксплуатационным характеристикам элементов ПОНП
Если ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ идентифицирован как ПОНП, ИЗГОТОВИТЕЛЬ должен определить требования к функциональным и эксплуатационным характеристикам элементов ПОНП, которые необходимы для их использования согласно предусмотренному назначению. [Классы B, C]
5.3.4 Определение требований к аппаратным и программным средствам СИСТЕМЫ, требуемых элементами ПОНП
Если ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ определяется как ПОНП, ИЗГОТОВИТЕЛЬ должен определить аппаратные и программные средства СИСТЕМЫ, необходимые для поддержания правильной работы элемента ПОНП. [Классы B, C]
Примечание - Примеры включают тип и скорость процессора, тип и размер памяти, тип программного обеспечения СИСТЕМЫ, коммуникационные и дисплейные требования.
5.3.5 Идентификация обособленности, необходимой для УПРАВЛЕНИЯ РИСКОМ
ИЗГОТОВИТЕЛЬ должен идентифицировать любую обособленность ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ, которая необходима для УПРАВЛЕНИЯ РИСКОМ, и указать, как обеспечить результативность |
созданной обособленности. [Класс C]
Примечание - В качестве примера создания обособленности можно привести ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ, выполняемые на разных процессорах. Результативность обособленности может быть обеспечена |
за счет отсутствия общих ресурсов у разных процессоров. Другие способы создания обособленности могут
применяться, когда результативность может быть обеспечена посредством разработки АРХИТЕКТУРЫ программного обеспечения (см. B.4.3). |
5.3.6 Верификация АРХИТЕКТУРЫ программного обеспечения
ИЗГОТОВИТЕЛЬ должен верифицировать и документировать, что:
a) АРХИТЕКТУРА программного обеспечения реализует требования к СИСТЕМЕ и к программному обеспечению, включая относящиеся к УПРАВЛЕНИЮ РИСКОМ;
b) АРХИТЕКТУРА программного обеспечения способна поддерживать взаимодействие между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ, а также между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ и аппаратными средствами;
c) АРХИТЕКТУРА МЕДИЦИНСКОГО ИЗДЕЛИЯ поддерживает правильную работу любых элементов ПОНП. [Классы B, C]
Примечание - Для выполнения требования a) может быть использован анализ ПРОСЛЕЖИВАЕМОСТИ АРХИТЕКТУРЫ к требованиям по программному обеспечению. |
5.4* Разработка детального дизайна программного обеспечения
5.4.1 Дробление программного обеспечения на ПРОГРАММНЫЕ БЛОКИ ИЗГОТОВИТЕЛЬ должен дробить программное обеспечение, пока оно не будет представлено в виде ПРОГРАММНЫХ БЛОКОВ. [Классы B, C] Примечание - Некоторые ПРОГРАММНЫЕ СИСТЕМЫ далее не могут быть раздроблены. |
5.4.2 Разработка детального дизайна для каждого ПРОГРАММНОГО БЛОКА
ИЗГОТОВИТЕЛЬ должен документировать дизайн с достаточной степенью детализации, с целью обеспечения правильной реализации каждого ПРОГРАММНОГО БЛОКА. [Класс C] |
5.4.3 Разработка детального дизайна для интерфейсов
ИЗГОТОВИТЕЛЬ должен документировать дизайн любых интерфейсов между ПРОГРАММНЫМ БЛОКОМ и внешними компонентами (аппаратными или программными средствами), а также любых интерфейсов между ПРОГРАММНЫМИ БЛОКАМИ, который должен быть достаточно подробным для правильной реализации каждого ПРОГРАММНОГО БЛОКА и его интерфейсов. [Класс C] |
5.4.4 ВЕРИФИКАЦИЯ детального дизайна
ИЗГОТОВИТЕЛЬ должен верифицировать и документировать, что детальный дизайн программного обеспечения:
a) реализует АРХИТЕКТУРУ программного обеспечения;
b) не вступает в противоречия с АРХИТЕКТУРОЙ программного обеспечения. [Класс C] Примечание - Для выполнения требования a) может быть использован анализ ПРОСЛЕЖИВАЕМОСТИ АРХИТЕКТУРЫ к детальному дизайну программного обеспечения. |
5.5* Имплементация ПРОГРАММНЫХ БЛОКОВ |
5.5.1 Имплементация каждого ПРОГРАММНОГО БЛОКА
ИЗГОТОВИТЕЛЬ должен имплементировать каждый ПРОГРАММНЫЙ БЛОК. [Классы A, B, C]
5.5.2 Установление ПРОЦЕССА ВЕРИФИКАЦИИ ПРОГРАММНОГО БЛОКА
ИЗГОТОВИТЕЛЬ должен установить стратегии, методы и процедуры для верификации ПРОГРАММНЫХ БЛОКОВ. Там, где ВЕРИФИКАЦИЯ осуществляется посредством тестирования, правильность процедур проведения тестирования должна быть ОЦЕНЕНА на адекватность. [Классы B, C] |
Примечание - Допускается объединение интеграционного тестирования и тестирование ПРОГРАММНОЙ СИСТЕМЫ в единый план и совокупность ДЕЯТЕЛЬНОСТИ.
5.5.3 Критерии приемки ПРОГРАММНЫХ БЛОКОВ
ИЗГОТОВИТЕЛЬ должен установить критерии приемки для ПРОГРАММНЫХ БЛОКОВ до их интеграции в более крупные ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ и удостовериться, что ПРОГРАММНЫЕ БЛОКИ соответствуют критериям приемки. [Классы B, C]
Примечание - Примеры критериев приемки:
- Имплементированы ли требования в программном коде, включая меры по УПРАВЛЕНИЮ РИСКОМ?
- Нет ли в программном коде противоречий с проектом (дизайном) интерфейса ПРОГРАММНЫХ БЛОКОВ? |
- Соответствует ли программный код процедурам программирования или стандартам кодирования?
5.5.4 Дополнительные критерии приемки ПРОГРАММНЫХ БЛОКОВ
Если детальный дизайн разработан, ИЗГОТОВИТЕЛЬ должен включить в дизайн дополнительные критерии приемки, предназначенные:
- для правильной (соответствующей) последовательности событий;
- потока данных и управления;
- планируемого распределения ресурсов;
- работы с ошибками (определение ошибки, локализация и восстановление);
- инициализации переменных;
- самодиагностики;
- управления памятью и переполнений памяти;
- граничных условий.
[Класс C]
5.5.5 ВЕРИФИКАЦИЯ ПРОГРАММНЫХ БЛОКОВ
ИЗГОТОВИТЕЛЬ должен выполнять ВЕРИФИКАЦИЮ ПРОГРАММНЫХ БЛОКОВ и документировать результаты. [Классы B, C]
5.6 Интеграция программного обеспечения и тестирование интеграции
5.6.1 Интеграция ПРОГРАММНЫХ БЛОКОВ
ИЗГОТОВИТЕЛЬ должен интегрировать ПРОГРАММНЫЕ БЛОКИ согласно плану интеграции (см. 5.1.5). [Классы B, C]
5.6.2 Верификация интеграции программного обеспечения
ИЗГОТОВИТЕЛЬ должен верифицировать, что ПРОГРАММНЫЕ БЛОКИ были интегрированы в ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ и/или ПРОГРАММНУЮ СИСТЕМУ в соответствии с планом интеграции (см. 5.1.5), а также сохранить записи, свидетельствующие о проведении такой верификации. [Классы B, C] Примечание - Данная верификация заключается только в проверке выполнения интеграции в соответствии с планом. Эта ВЕРИФИКАЦИЯ, скорее всего, осуществляется в форме какого-либо контрольного мероприятия. |
5.6.3 Интеграционное тестирование программного обеспечения |
ИЗГОТОВИТЕЛЬ должен тестировать интегрированные ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ в соответствии с планом интеграции (см. 5.1.5) и документировать полученные результаты. [Классы B, C]
5.6.4 Содержание тестирования интеграции программного обеспечения |
При тестировании интеграции программного обеспечения ИЗГОТОВИТЕЛЬ должен установить, что интегрированная ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ функционирует в соответствии с предусмотренным назначением. [Классы B, C]
Примечание 1 - Примерами могут служить:
- требуемая функциональность программного обеспечения;
- выполнение мер по УПРАВЛЕНИЮ РИСКОМ;
- определенная синхронизация и другие режимы работы;
- определенное функционирование внутренних и внешних интерфейсов;
- тестирование в ненормальных условиях, включая обоснованно прогнозируемое неправильное применение.
Примечание 2 - Возможно объединять тестирование интеграции и тестирование ПРОГРАММНОЙ СИСТЕМЫ в единый план и совокупность ДЕЯТЕЛЬНОСТИ.
5.6.5 Оценивание процедур тестирования интеграции программного обеспечения ИЗГОТОВИТЕЛЬ должен ОЦЕНИВАТЬ процедуры тестирования интеграции на адекватность. [Классы B, C] |
5.6.6 Проведение регрессионного тестирования
По завершении интеграции программных составных частей, ИЗГОТОВИТЕЛЬ должен провести РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ, подходящее для демонстрации того, что в ранее интегрированном программном обеспечении не были обнаружены дефекты. [Классы B, C]
5.6.7 Содержание записей в отношении регрессионного тестирования
ИЗГОТОВИТЕЛЬ должен:
a) документировать результаты тестирования (соответствует, не соответствует и перечень АНОМАЛИЙ);
b) сохранить существенные записи с целью сделать возможным повторное тестирование;
c) указать лицо, которое проводило тестирование.
[Классы B, C]
Примечание - Требование b) может быть выполнено путем сохранения, например:
- спецификаций тестового примера, показывающих требуемые действия и ожидаемые результаты;
- записей об оборудовании;
- записей о тестовом окружении (включая программные инструменты), используемом при проведении тестирования.
5.6.8 Использование ПРОЦЕССА решения проблем с программным обеспечением
ИЗГОТОВИТЕЛЬ должен вводить АНОМАЛИИ, обнаруженные во время интеграции программного обеспечения и тестирования интеграции, в ПРОЦЕСС решения проблем с программным обеспечением. [Классы B, C]
Примечание - см. раздел 9.
5.7 Тестирование ПРОГРАММНОЙ СИСТЕМЫ
5.7.1 Установление тестирования в отношении требований к программному обеспечению
a) Для проведения тестирования ПРОГРАММНОЙ СИСТЕМЫ ИЗГОТОВИТЕЛЬ должен установить |
и выполнить перечень тестов, выраженных как входные данные, ожидаемые результаты, критерии приемки и процедуры, с целью учета и охвата тестированием всех требований к программному обеспечению. [Классы A, B, C]
Примечание 1 - Допускается объединять тестирование интеграции и тестирование ПРОГРАММНОЙ СИСТЕМЫ в единый план и совокупность ДЕЯТЕЛЬНОСТИ. Также допустимо тестировать программное обеспечение на более ранних стадиях.
Примечание 2 - Могут проводиться не только тестирования отдельных требований, но и тестирования комбинаций требований, особенно если между требованиями существуют зависимости.
b) ИЗГОТОВИТЕЛЬ должен ОЦЕНИТЬ адекватность стратегий проведения ВЕРИФИКАЦИИ и тестовых процедур. |
5.7.2 Применение ПРОЦЕССА решения проблем с программным обеспечением
ИЗГОТОВИТЕЛЬ должен ввести АНОМАЛИИ, обнаруженные во время испытаний ПРОГРАММНОЙ
СИСТЕМЫ, в ПРОЦЕСС решения проблем с программным обеспечением. [Классы A, B, C] |
5.7.3 Повторное тестирование после внесения изменений
При внесении изменений в ходе тестирования ПРОГРАММНОЙ СИСТЕМЫ ИЗГОТОВИТЕЛЬ должен:
a) повторить тестирование, выполнить модифицированные тесты или дополнительные тесты, если применимо, с целью проверки результативности вносимых изменений для исправления проблем;
b) провести соответствующее тестирование, необходимое для демонстрации отсутствия возникновения непреднамеренных побочных эффектов;
c) выполнить соответствующую ДЕЯТЕЛЬНОСТЬ по МЕНЕДЖМЕНТУ РИСКА, как установлено в 7.4.
[Классы A, B, C]
5.7.4 Оценивание тестирования ПРОГРАММНОЙ СИСТЕМЫ ИЗГОТОВИТЕЛЬ должен ОЦЕНИТЬ целесообразность стратегий ВЕРИФИКАЦИИ и процедур тестирования. |
ИЗГОТОВИТЕЛЬ должен проверить, что:
a) все требования к программному обеспечению были протестированы или иным образом ВЕРИФИЦИРОВАНЫ; b) ведутся записи по ПРОСЛЕЖИВАЕМОСТИ между требованиями к программному обеспечению и тестами или другой ВЕРИФИКАЦИЕЙ; c) результаты тестирования соответствуют требуемым критериям приемки. [Классы A, B, C] |
5.7.5 Содержание отчета по тестированию ПРОГРАММНОЙ СИСТЕМЫ
Для обеспечения повторяемости тестов ИЗГОТОВИТЕЛЬ должен документировать: a) ссылки на конкретные процедуры тестирования с указанием требуемых действий и ожидаемых результатов; b) результаты тестирования (соответствует, не соответствует и список АНОМАЛИЙ); c) версию тестируемого программного обеспечения; d) соответствующие конфигурации тестируемого аппаратного и программного обеспечения; e) соответствующие средства тестирования; f) дату выполненного тестирования; g) идентификацию лица, ответственного за проведение тестирования и запись его результатов. [Классы A, B, C] 5.8* Выпуск программного обеспечения на системном уровне |
5.8.1 Обеспечение завершенности ВЕРИФИКАЦИИ программного обеспечения
ИЗГОТОВИТЕЛЬ до выпуска ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в обращение должен обеспечить, чтобы ДЕЯТЕЛЬНОСТЬ по ВЕРИФИКАЦИИ всего программного обеспечения была полностью завершена, а результаты были ОЦЕНЕНЫ. [Классы A, B, C] |
5.8.2 Документирование известных остаточных АНОМАЛИЙ
ИЗГОТОВИТЕЛЬ должен задокументировать все известные остаточные АНОМАЛИИ. [Классы A, B, C] |
5.8.3 ОЦЕНИВАНИЕ известных остаточных АНОМАЛИЙ
ИЗГОТОВИТЕЛЬ должен обеспечить, чтобы все известные остаточные АНОМАЛИИ были ОЦЕНЕНЫ, с целью обеспечения отсутствия их способности содействовать возникновению недопустимых РИСКОВ. [Классы B, C]
5.8.4 Документирование выпущенных ВЕРСИЙ
ИЗГОТОВИТЕЛЬ должен документировать ВЕРСИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, которая будет выпускаться. [Классы A, B, C] |
5.8.5 Документирование создания выпущенного программного обеспечения
ИЗГОТОВИТЕЛЬ должен документировать процедуру и окружение (среду), используемые для создания выпущенного программного обеспечения. [Классы B, C]
5.8.6 Обеспечение полного завершения деятельности и задач
ИЗГОТОВИТЕЛЬ должен обеспечить выполнение всей ДЕЯТЕЛЬНОСТИ и всех ЗАДАЧ, входящих в состав плана разработки (или плана технической поддержки) программного обеспечения, наряду со связанной с ними документацией. [Классы B, C] Примечание - См. 5.1.3.b). |
5.8.7 Архивирование программного обеспечения
Изготовитель должен хранить в архиве:
a) ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ и СОСТАВНОЙ ЧАСТИ КОНФИГУРАЦИИ; |
b) документацию
в течение как минимум срока службы ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ, установленного ИЗГОТОВИТЕЛЕМ, или в течение срока, установленного соответствующими регулирующими требованиями. |
[Классы A, B, C] 5.8.8 Обеспечение надежной поставки выпущенного программного обеспечения ИЗГОТОВИТЕЛЬ должен установить процедуры, обеспечивающие, чтобы выпущенное ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ было поставлено пользователю (к месту его применения) без искажения или несанкционированного изменения. Эти процедуры должны распространяться на производство и обращение со средствами, содержащими ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ, и включать, если применимо: |
- создание копии;
- средства маркировки;
- упаковку;
- защиту;
- хранение;
- поставку.
[Классы A, B, C] |
