ГОСТРМЭК 62304—2013
Какой бы жизненный цикл не был выбран, необходимо поддерживать логические зависимости между выход
ными данными ПРОЦЕССОВ, такими как спецификации, проектные документы и ПО. Модель жизненного цикла
«водопад» достигает этого, откладывая старт ПРОЦЕССА до тех пор. пока входные данные для этого процесса не
будут определены и одобрены.
Другие жизненные циклы, особенно эволюционные жизненные циклы, разрешают ПРОЦЕССУ вырабаты
вать выходные данные до того, как будут доступны все входные данные для этого процесса. Например, новый
ПРОГРАММНЫЙ ЭЛЕМЕНТ может быть определен, классифицирован, исполнен и ВЕРИФИЦИРОВАН до того,
как будет закончена программная АРХИТЕКТУРА вцелом. Такие жизненные циклы несут в себе РИСК того, что
изменение или разработка выходных данных одного процесса сделает недействительными выходные данные
другого ПРОЦЕССА. При этом все жизненные циклы используют комплексную систему управления
конфигу рацией. чтобы убедиться, что выходные данные всех ПРОЦЕССОВ доведены до согласованного
состояния, и поддерживаются все необходимые зависимости.
Следующие принципы важны вне зависимости от того, какой жизненный цикл разработки ПО используется:
- все выходные данные ПРОЦЕССАдолжны поддерживаться в согласованном состоянии: каждый раз. когда
выходные данные ПРОЦЕССА создаются или меняются, все выходные данные всех связанных с ними ПРОЦЕС
СОВ должны быстро обновляться, чтобы поддерживать их согласованность друг с другом и поддерживать все за
висимости. явные или подразумевающиеся, требуемые настоящим стандартом:
- все выходные данные ПРОЦЕССА должны быть доступны в случае необходимости в качестве входных
данных для дальнейшей работы над ПО;
- перед тем. как любое ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ будет выпущено, все выходные данные ПРОЦЕССА
должны быть приведены в соответствие друг с другом, и должны соблюдаться все зависимости между ПРОЦЕС
САМИ, явные или подразумевающиеся, требуемые настоящим стандартом.
В.1.2 Область применения
Настоящий стандарт применяетсядля разработки и технической поддержки ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ,
а так же для разработки и технической поддержхи МЕДИЦИНСКИХ ИЗДЕЛИЙ, которые содержат ПОНП.
Использование настоящего стандарта требует от изготовителя выполнять МЕНЕДЖМЕНТ РИСКА МЕ
ДИЦИНСКИХ ИЗДЕЛИЙ, как это указано в ИСО 14971. Следовательно, когда АРХИТЕКТУРА СИСТЕМЫ
МЕДИЦИНСКИХ ИЗДЕЛИЙ включает в себя приобретенный компонент (это может быть закупленный ком
понент или компонент неизвестного происхождения), такой как принтер/плоттер. который содержит ПОНП, этот
приобретенный компонент становится ответственностью ИЗГОТОВИТЕЛЯ и должен быть включен в
МЕНЕДЖМЕНТ РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ. Считается, что посредством надлежащего исполнения
МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ ИЗГОТОВИТЕЛЬ идентифицирует этот компонент и
признает, что он содержит ПОНП. ИЗГОТОВИТЕЛЬ, использующий настоящий стандарт, должен ввести
ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА ПО как часть ПРОЦЕССА МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКОГО
ИЗДЕЛИЯ.
Техническая поддержка выпущенного ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ относится к постпроизводствен-
ному опыту работы с ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ. Техническая поддержка ПО включает в себя сочетание
всех технических и управленческих средств, в т. ч. действия контроля, чтобы реагировать на ОТЧЕТ О ПРО
БЛЕМАХ. сохраняя элемент или восстанавливая его до состояния, в котором он может осуществлять требуе
мые функции, а так же запросы на модификацию, относящуюся к выпущенному ПРОГРАММНОМУ ПРОДУКТУ
(ПРОДУКТАМ). Например, это включает исправление проблемы, регламентированную отчетность, повторные
проверки и профилактические действия. См. ИСО/МЭК 14764 [10].
В.2 Нормативные ссылки
ИСО/МЭК 90003 [11) представляет собой руководство для применения систем менеджмента качества к раз
работке ПО. Это руководство не требуется настоящим стандартом, но рекомендуется.
В.З Термины и определения
Там. где это возможно, к терминам даны определения из международных стандартов.
Настоящий стандарт выбирает для использования три термина, чтобы описывать декомпозицию ПРО
ГРАММНОЙ СИСТЕМЫ (верхний уровень). ПРОГРАММНАЯ СИСТЕМА может быть разделена на подсистемы
МЕДИЦИНСКОГО ИЗДЕЛИЯ (см. [2)) или МЕДИЦИНСКОЕ ИЗДЕЛИЕ само по себе. Самый нижний уровень,
ниже которого дальнейшее разложение на составные части не осуществляется, для цепей тестирования или
управления конфигурацией ПО — это ПРОГРАММНЫЙ МОДУЛЬ. Все уровни композиции, включая верхний и
нижний уровни, могут быть названы ПРОГРАММНЫМИ ЭЛЕМЕНТАМИ. ПРОГРАММНАЯ СИСТЕМА состоит из
одного или более ПРОГРАММНЫХ ЭЛЕМЕНТОВ, и каждый ПРОГРАММНЫЙ ЭЛЕМЕНТ состоит из ПРО
ГРАММНЫХ МОДУЛЕЙ или разложимых ПРОГРАММНЫХ ЭЛЕМЕНТОВ. Ответственность за обеспечение
определения и степени детализации ПРОГРАММНЫХ ЭЛЕМЕНТОВ и ПРОГРАММНЫХ МОДУЛЕЙ возложена
на ИЗГОТОВИТЕЛЯ. То. что эти термины остаются неопределенными, допускает их применение ко многим
разным методам разработки и типам ПО. используемым в МЕДИЦИНСКИХ ИЗДЕЛИЯХ.
24