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