Статус документа
Статус документа

ГОСТ Р МЭК 62304-2013 Изделия медицинские. Программное обеспечение. Процессы жизненного цикла

Приложение В
 (справочное)

Руководство по положениям настоящего стандарта

В.1 Обзор
     


    В.1.1 Цель

Цель настоящего стандарта состоит в том, чтобы обеспечить ПРОЦЕСС разработки, который соответственно производит высококачественное, безопасное ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ. Чтобы достигнуть этого, настоящий стандарт определяет минимально необходимые деятельность и ЗАДАЧИ, которые следует осуществить, чтобы быть уверенным в том, что ПО разработано до той степени, которая обеспечивает производство надежного и безопасного ПРОГРАММНОГО ПРОДУКТА.

Настоящее приложение обеспечивает руководство для дополнительных требований стандарта. Оно не дополняет или не изменяет требования настоящего стандарта. Настоящее приложение может быть использовано для лучшего понимания требований стандарта.

Следует отметить, что в настоящем стандарте деятельность является подпунктами, вызываемыми ПРОЦЕССАМИ, а ЗАДАЧИ определены внутри деятельности. Например, деятельность, определенная для ПРОЦЕССА разработки ПО, - это планирование разработки ПО, анализ требований ПО, проектирование АРХИТЕКТУРЫ ПО, детализированное проектирование ПО, реализация ПРОГРАММНЫХ МОДУЛЕЙ и их ВЕРИФИКАЦИЯ, интеграция ПО и тестирование интеграции, тестирование ПРОГРАММНОЙ СИСТЕМЫ и выпуск ПО. Деятельность внутри этих ЗАДАЧ определяется индивидуальными требованиями.

Настоящий стандарт не требует использования определенной МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПО.

Однако соответствие настоящему стандарту подразумевает наличие зависимости между ПРОЦЕССАМИ, поскольку входные данные для одного ПРОЦЕССА генерируются другим ПРОЦЕССОМ. Например, классификация БЕЗОПАСНОСТИ ПО для ПРОГРАММНОЙ СИСТЕМЫ должна быть завершена после того, как ПРОЦЕСС АНАЛИЗА РИСКОВ установит, какой ВРЕД приносит отказ ПРОГРАММНОЙ СИСТЕМЫ.

Из-за таких логических зависимостей между процессами, легче всего описывать ПРОЦЕССЫ в этом стандарте в последовательности, подразумевающей модель жизненного цикла "водопад" (прямоточная). Однако также могут быть использованы и другие жизненные циклы. Некоторые стратегии разработки (модели), как определено в ИСО/МЭК 12207 [9], включают в себя (см. также таблицу В.1):

- "Водопад" - прямоточная стратегия, также называемая "водопад", состоит в выполнении ПРОЦЕССА разработки один раз. Проще говоря, следует определить нужды заказчика, определить требования, спроектировать СИСТЕМУ, исполнить ее, протестировать, установить и поставить заказчику.

- "Пошаговая" - это стратегия определяет нужды заказчика и определяет требования СИСТЕМЫ, затем осуществляет остаток разработки в виде последовательной сборки. Первая сборка реализует часть запланированных возможностей, следующая - добавляет еще часть возможностей и так далее, до тех пор, пока СИСТЕМА не будет завершена.

- "Эволюционная" - это стратегия также развивает СИСТЕМУ в сборке, но в отличие от пошаговой стратегии признает, что нужды потребителя до конца не изучены и все требования не могут быть определены заранее. В этой стратегии нужды заказчика и системные требования определяются заранее, а затем актуализируются при каждой последующей сборке.


Таблица В.1 - Разработка стратегий (моделей), как это определено в ИСО/МЭК 12207

Стратегия разработки

С самого начала определяет все требования?

Многократные циклы разработки?

Поставляет временное программное обеспечение?

"Водопад" (прямоточная)

Да

Нет

Нет

Пошаговая (предварительно запланированное улучшение продукции)

Да

Да

Возможно

Эволюционная

Нет

Да

Да

          

Какой бы жизненный цикл не был выбран, необходимо поддерживать логические зависимости между выходными данными ПРОЦЕССОВ, такими как спецификации, проектные документы и ПО. Модель жизненного цикла "водопад" достигает этого, откладывая старт ПРОЦЕССА до тех пор, пока входные данные для этого процесса не будут определены и одобрены.

Другие жизненные циклы, особенно эволюционные жизненные циклы, разрешают ПРОЦЕССУ вырабатывать выходные данные до того, как будут доступны все входные данные для этого процесса. Например, новый ПРОГРАММНЫЙ ЭЛЕМЕНТ может быть определен, классифицирован, исполнен и ВЕРИФИЦИРОВАН до того, как будет закончена программная АРХИТЕКТУРА в целом. Такие жизненные циклы несут в себе РИСК того, что изменение или разработка выходных данных одного процесса сделает недействительными выходные данные другого ПРОЦЕССА. При этом все жизненные циклы используют комплексную систему управления конфигурацией, чтобы убедиться, что выходные данные всех ПРОЦЕССОВ доведены до согласованного состояния, и поддерживаются все необходимые зависимости.

Следующие принципы важны вне зависимости от того, какой жизненный цикл разработки ПО используется:

- все выходные данные ПРОЦЕССА должны поддерживаться в согласованном состоянии; каждый раз, когда выходные данные ПРОЦЕССА создаются или меняются, все выходные данные всех связанных с ними ПРОЦЕССОВ должны быстро обновляться, чтобы поддерживать их согласованность друг с другом и поддерживать все зависимости, явные или подразумевающиеся, требуемые настоящим стандартом;

- все выходные данные ПРОЦЕССА должны быть доступны в случае необходимости в качестве входных данных для дальнейшей работы над ПО;

- перед тем, как любое ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ будет выпущено, все выходные данные ПРОЦЕССА должны быть приведены в соответствие друг с другом, и должны соблюдаться все зависимости между ПРОЦЕССАМИ, явные или подразумевающиеся, требуемые настоящим стандартом.

В.1.2 Область применения

Настоящий стандарт применяется для разработки и технической поддержки ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ, а также для разработки и технической поддержки МЕДИЦИНСКИХ ИЗДЕЛИЙ, которые содержат ПОНП.

Использование настоящего стандарта требует от изготовителя выполнять МЕНЕДЖМЕНТ РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ, как это указано в ИСО 14971. Следовательно, когда АРХИТЕКТУРА СИСТЕМЫ МЕДИЦИНСКИХ ИЗДЕЛИЙ включает в себя приобретенный компонент (это может быть закупленный компонент или компонент неизвестного происхождения), такой как принтер/плоттер, который содержит ПОНП, этот приобретенный компонент становится ответственностью ИЗГОТОВИТЕЛЯ и должен быть включен в МЕНЕДЖМЕНТ РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ. Считается, что посредством надлежащего исполнения МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ ИЗГОТОВИТЕЛЬ идентифицирует этот компонент и признает, что он содержит ПОНП. ИЗГОТОВИТЕЛЬ, использующий настоящий стандарт, должен ввести ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА ПО как часть ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ.

Техническая поддержка выпущенного ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ относится к постпроизводственному опыту работы с ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ. Техническая поддержка ПО включает в себя сочетание всех технических и управленческих средств, в т.ч. действия контроля, чтобы реагировать на ОТЧЕТ О ПРОБЛЕМАХ, сохраняя элемент или восстанавливая его до состояния, в котором он может осуществлять требуемые функции, а также запросы на модификацию, относящуюся к выпущенному ПРОГРАММНОМУ ПРОДУКТУ (ПРОДУКТАМ). Например, это включает исправление проблемы, регламентированную отчетность, повторные проверки и профилактические действия. См. ИСО/МЭК 14764 [10].

В.2 Нормативные ссылки

ИСО/МЭК 90003 [11] представляет собой руководство для применения систем менеджмента качества к разработке ПО. Это руководство не требуется настоящим стандартом, но рекомендуется.