ГОСТ Р МЭК 62304—2013
Например, ИЗГОТОВИТЕЛЬ знает благодаря типу разрабатываемого ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ, что
по предварительной классификации БЕЗОПАСНОСТЬ ПО для ПРОГРАММНОЙ СИСТЕМЫ относится к классу С
по БЕЗОПАСНОСТИ ПО. Во время проектирования программной АРХИТЕКТУРЫ изготовитель решает разделить
СИСТЕМУ, как это показано, на три программных уровня — X.
W
иZ. ИЗГОТОВИТЕЛЬ может выделить все
вклады ПРОГРАММНОЙ СИСТЕМЫ вОПАСНОСТИ, которые могут привести к смерти или СЕРЬЕЗНОМУ
УЩЕРБУ, в про граммный уровень Z, а все оставшиеся вклады ПРОГРАММНОЙ СИСТЕМЫ в ОПАСНОСТИ,
которые приводят к НЕСЕРЬЕЗНОМУ УЩЕРБУ, в программный уровень
W.
Программный уровень И/получает
класс БЕЗОПАСНОСТИ ПО
В.
программный уровень Z — класс БЕЗОПАСНОСТИ ПО С. Программный уровень У.
следовательно, должен быть отнесен к классу С. по 4.3. перечисление д). В соответствии с этим требованием
ПРОГРАММНАЯ СИСТЕМА так же получает программный класс БЕЗОПАСНОСТИ С. Программный уровень
X
относится кпрограммному клас су БЕЗОПАСНОСТИ
А.
ИЗГОТОВИТЕЛЬ гложетдокументально подтвердить
разумное обьяснение для разделения программных уровней X и Утак же. как и для программных уровней
WnZ.
чтобы обеспечить целостность разделе ния. Если разделение не является возможным, программные уровни X и
Удолжны быть отнесены к программному классу БЕЗОПАСНОСТИ С.
В.5 ПРОЦЕСС разработки ПО
В.5.1 Планирование разработки ПО
Целью этой деятельности является планирование ЗАДАЧ разработки ПО для уменьшения РИСКОВ, вы
зываемых программным обеспечением, сообщение задач и целей участникам группы разработки и обеспечение
выполнения требований к качеству СИСТЕМЫ для ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ.
Деятельность по планированию разработки ПО и задач может быть документирована в едином плане или в
различных планах. Некоторые ИЗГОТОВИТЕЛИ могут устанавливать политики и процедуры, которые применяются к
разработке всего их ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ. В этом случае план может просто ссылаться на существую щие
политики и процедуры. Некоторые ИЗГОТОВИТЕЛИ могут подготовить план или набор планов для разработки
каждого ПРОГРАММНОГО ПРОДУКТА МЕДИЦИНСКИХ ИЗДЕЛИЙ, который влечет за собой детально определен
ные действия и ссылается на общие процедуры. Другая возможность состоит в том. что план или набор планов
приспособлен для разработки каждого ПРОГРАММНОГО ПРОДУКТА МЕДИЦИНСКИХ ИЗДЕЛИЙ. Планирование
следуетопределять на уровне детализации, необходимойдля осуществления ПРОЦЕССАразработки, и онодолж
но быть пропорционально РИСКУ. Например. СИСТЕМЫ или элементы с более высокой степенью РИСКА должны
быть подчинены ПРОЦЕССУ разработки с более строгими требованиями, а задачи должны быть изложены более
детально.
Планирование является итеративной РАБОТОЙ, которую следует пересматривать и обновлять по мере
развития разработки. План может развиваться, чтобы включать большую и лучшую информацию, по мере того,
как больше узнают о СИСТЕМЕ и уровне усилий, необходимых для развития СИСТЕМЫ Например, начальная
классификация БЕЗОПАСНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ может измениться в результате
осуществления ПРОЦЕССА УПРАВЛЕНИЯ РИСКОМ и развития АРХИТЕКТУРЫ ПО. Также может быть принято
решение о включении ПОНП в СИСТЕМУ. Важно, чтобы план (планы) был обновлен, чтобы отражать текущие
знания о СИСТЕМЕ и уровне точности, необходимом для СИСТЕМЫ или элементов, и чтобы сделать возможным
надлежащий контроль над ПРОЦЕССОМ разработки.
В.5.2 Анализ требований к ПО
Эта деятельность требует от ИЗГОТОВИТЕЛЯ установить и верифицировать ПРОГРАММНЫЕ требования
для ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ. Установление верифицируемых требований существенно для определения
того, что должно быть создано, для определения, что ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ ведет себя приемлемым
образом, и для демонстрации, что завершенное ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ готово к использованию. Чтобы
продемонстрировать, что требования были осуществлены согласно замыслу, каждое требование должно быть
указано таким образом, чтобы можнобыло установить объективные критерии для проверки того, правильно ли оно
осуществлено. Если ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА изделия диктует требования к ПРОГРАММНОМУ ОБЕ
СПЕЧЕНИЮ для УПРАВЛЕНИЯ выявленными РИСКАМИ, эти требования должны быть идентифицированы в про
граммных требованиях таким образом, чтобы сделать возможным прослеживание мер по УПРАВЛЕНИЮ РИСКОМ
до программных требований. Все ПРОГРАММНЫЕ требования следует определять таким образом, чтобы сделать
возможной демонстрацию ПРОСЛЕЖИВАЕМОСТИ между требованием и тестированием ПРОГРАММНОГО ОБЕ
СПЕЧЕНИЯ СИСТЕМЫ. Если регулирующие требования некоторых стран требуют соответствия специальным
нормам или международным стандартам, это соответствие требованиям должно быть документировано в про
граммных требованиях. Поскольку ПРОГРАММНЫЕ требования устанавливают, что должно быть реализовано в
ПО. оценка требований требуетсядо завершения деятельности по анализу требований.
Областью частых недоразумений является различие между потребностями заказчика, входными данными
проектирования, программными требованиями, функциональными спецификациями ПО и спецификациями про
екта ПО. Входные данные проектирования являются преобразованием потребностей заказчика вофициально до
кументированные требования к МЕДИЦИНСКОМУ ИЗДЕЛИЮ. ПРОГРАММНЫЕ требования — это официально
документированные спецификации того, что ПО отвечает требованиям заказчика и входным данным проектиро
вания. Функциональные спецификации ПО часто включены в программные требования и определяют в деталях,
что ПО выполняет, чтобы соответствовать этим требованиям, даже если другие альтернативные варианты могут
27