Приложение В (справочное). Руководство по положениям настоящего стандарта

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

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

В.1 Обзор

В.1.1 Цель

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

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

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

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

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

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

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

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

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

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

Стратегия разработки	С самого начала определяет все требования?	Многократные циклы разработки?	Поставляет временное программное обеспечение?
"Водопад" (прямоточная)	Да	Нет	Нет
Пошаговая (предварительно запланированное улучшение продукции)	Да	Да	Возможно
Эволюционная	Нет	Да	Да

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

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

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

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

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

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

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

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

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

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

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

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

B.3 Термины и определения

Там, где это возможно, к терминам даны определения из международных стандартов.

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

В.4 Общие требования

Не существует метода, чтобы обеспечить 100% БЕЗОПАСНОСТЬ для ПО любого класса.

Существует три главных принципа, которые способствуют БЕЗОПАСНОСТИ ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ:

- МЕНЕДЖМЕНТ РИСКА;

- менеджмент качества;

- проектирование ПО.

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

B.4.1 Система менеджмента качества

Дисциплинированная и эффективная совокупность ПРОЦЕССОВ ПО включает в себя организационные ПРОЦЕССЫ, такие как управление, инфраструктура, улучшение и подготовка. Чтобы избежать дублирования и сфокусировать настоящий стандарт на проектировании, в настоящем стандарте эти ПРОЦЕССЫ не указаны.

Эти ПРОЦЕССЫ описаны в СИСТЕМЕ менеджмента качества ИСО 13485 [7] - это международный стандарт, который специально предназначен для применения понятий менеджмента качества к МЕДИЦИНСКИМ ИЗДЕЛИЯМ. Соответствие требованиям системы менеджмента качества ИСО 13485 не означает автоматического соответствия национальным или местным нормативным требованиями. На ответственности ИЗГОТОВИТЕЛЯ остается идентификация и установление соблюдения соответствующим нормативным актам.

B.4.2 МЕНЕДЖМЕНТ РИСКА

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

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

B.4.3 Классификация БЕЗОПАСНОСТИ ПО

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

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

Если ПРОГРАММНАЯ СИСТЕМА делится на ПРОГРАММНЫЕ ЭЛЕМЕНТЫ, тогда каждый ПРОГРАММНЫЙ ЭЛЕМЕНТ может иметь свой собственный класс БЕЗОПАСНОСТИ ПО. Можно определить РИСК, связанный с отказом ПРОГРАММНОГО ЭЛЕМЕНТА, только:

- если СИСТЕМНАЯ АРХИТЕКТУРА и АРХИТЕКТУРА ПО определяют роль ПРОГРАММНОГО ЭЛЕМЕНТА с точки зрения его цели и взаимодействия с другими программными и аппаратными элементами;

- если изменения в СИСТЕМЕ контролируются;

- после того, как был выполнен АНАЛИЗ РИСКОВ для данной АРХИТЕКТУРЫ, и определены меры по УПРАВЛЕНИЮ РИСКОМ.

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

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

Эта точка соответствует точке, где по ИСО 14971 начинается УПРАВЛЕНИЕ РИСКОМ.

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

Ожидается, что ИЗГОТОВИТЕЛЬ посчитает полезным классифицировать ПО до данной точки, например, чтобы сфокусировать внимание на областях, которые нужно исследовать, но такая классификация должна считаться предварительной и не должна использоваться для обоснования пропуска ПРОЦЕССОВ,

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

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

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

Как установлено в В.3, настоящий стандарт выбирает для применения три термина, чтобы описывать декомпозицию ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ (верхний уровень).

На рисунке В.1 проиллюстрировано возможное разделение ПРОГРАММНЫХ ЭЛЕМЕНТОВ внутри ПРОГРАММНОЙ СИСТЕМЫ и как классы БЕЗОПАСНОСТИ ПО могут быть применены к группе ПРОГРАММНЫХ ЭЛЕМЕНТОВ в декомпозиции.

Рисунок В.1 - Пример разделения ПРОГРАММНЫХ ЭЛЕМЕНТОВ

Например, ИЗГОТОВИТЕЛЬ знает благодаря типу разрабатываемого ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ, что по предварительной классификации БЕЗОПАСНОСТЬ ПО для ПРОГРАММНОЙ СИСТЕМЫ относится к классу С по БЕЗОПАСНОСТИ ПО. Во время проектирования программной АРХИТЕКТУРЫ изготовитель решает разделить СИСТЕМУ, как это показано, на три программных уровня - X, W и Z. ИЗГОТОВИТЕЛЬ может выделить все вклады ПРОГРАММНОЙ СИСТЕМЫ в ОПАСНОСТИ, которые могут привести к смерти или СЕРЬЕЗНОМУ УЩЕРБУ, в программный уровень Z, а все оставшиеся вклады ПРОГРАММНОЙ СИСТЕМЫ в ОПАСНОСТИ, которые приводят к НЕСЕРЬЕЗНОМУ УЩЕРБУ, в программный уровень W. Программный уровень W получает класс БЕЗОПАСНОСТИ ПО B, программный уровень Z - класс БЕЗОПАСНОСТИ ПО С. Программный уровень Y, следовательно, должен быть отнесен к классу С, по 4.3, перечисление g). В соответствии с этим требованием ПРОГРАММНАЯ СИСТЕМА также получает программный класс БЕЗОПАСНОСТИ С. Программный уровень Х относится к программному классу БЕЗОПАСНОСТИ А. ИЗГОТОВИТЕЛЬ может документально подтвердить разумное объяснение для разделения программных уровней X и Y так же, как и для программных уровней W и Z, чтобы обеспечить целостность разделения. Если разделение не является возможным, программные уровни X и Y должны быть отнесены к программному классу БЕЗОПАСНОСТИ С.

В.5 ПРОЦЕСС разработки ПО

B.5.1 Планирование разработки ПО

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

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

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

B.5.2 Анализ требований к ПО

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

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

Традиционно программные требования, функциональные спецификации и спецификации проекта записаны как набор из одного и более документов. В настоящее время возможно рассматривать эту информацию как элементы данных внутри общей базы данных. Каждый элемент может иметь один или более признаков, которые определяют его цель и его соединение с другими элементами в базе данных. Этот подход допускает представление и печать различных видов информации, которая лучше всего подходит для каждой группы предполагаемых пользователей (например, продавцов, изготовителей, тестеров, аудиторов) и поддерживает ПРОСЛЕЖИВАЕМОСТЬ, чтобы демонстрировать соответствующее выполнение тестовых заданий проверяемым требованиям до установленной степени. Инструменты, поддерживающие этот подход, могут быть такими же простыми, как гипертекстовый документ, использующий гиперссылки HTML или столь же сложными, как CASE (computer aided software engineering - разработка компьютерного ПО).

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

Чтобы гарантировать целостность СИСТЕМЫ, ИЗГОТОВИТЕЛЬ должен обеспечить механизм для ведения переговоров об изменениях и уточнения требований СИСТЕМЫ, чтобы исправлять непрактичность, несоответствия или двусмысленности в требованиях любой родительской СИСТЕМЫ или в программных требованиях.

Процесс охвата и анализа СИСТЕМЫ и требований ПО может быть итеративным.

Настоящий стандарт не требует, чтобы ПРОЦЕССЫ были строго разделены на два слоя. На практике СИСТЕМНАЯ АРХИТЕКТУРА и АРХИТЕКТУРА ПО часто обрисовываются в общих чертах одновременно, и СИСТЕМНЫЕ и программные требования впоследствии документируются в форме слоев.

B.5.3 Проектирование АРХИТЕКТУРЫ ПО

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

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

Множество последующих событий может сделать классификацию недействительной. Они включают в себя, например:

- изменения спецификации СИСТЕМЫ, программной спецификации или АРХИТЕКТУРЫ;

- обнаружения ошибок в АНАЛИЗЕ РИСКОВ, особенно непредвиденных ОПАСНОСТЕЙ и

- обнаружение неосуществимости требований, особенно мер по УПРАВЛЕНИЮ РИСКОМ.

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

B.5.4 Детализация проекта ПО

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

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

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

Если это имеет место в проекте, ИЗГОТОВИТЕЛЬ должен проверить характеристики проекта, которые считает важными для БЕЗОПАСНОСТИ. Примеры таких характеристик включают:

- осуществление намеченных событий, входных и выходных данных, интерфейсов, логической схемы, распределения ресурсов процессора, распределения ресурсов памяти, ошибок и исключений изоляции и устранения ошибок;

- определение состояния по умолчанию, в котором все отказы, могущие привести к возникновению опасной ситуации, охвачены, включая события и переходы;

- инициализация переменных, управление памятью; и

- "холодная" и "теплая" перезагрузки, режим ожидания и другие изменения состояния, которые могут оказать влияние на меры по УПРАВЛЕНИЮ РИСКОМ.

B.5.5 Реализация и ВЕРИФИКАЦИЯ ПРОГРАММНОГО МОДУЛЯ

Эта деятельность требует от ИЗГОТОВИТЕЛЯ записать и проверить код для ПРОГРАММНЫХ МОДУЛЕЙ.

Детализированный проект преобразовывается в исходный код. Кодирование представляет собой момент, в который заканчивается декомпозиция спецификаций и начинается составление реализуемого ПО. Чтобы последовательно достигать желаемых характеристик кода, должны использоваться стандарты кодирования для определения предпочитаемого стиля кодирования. Примеры стандартов кодирования включают требования к понятности, правила использования языка или ограничений и сложность управления. Код для каждого модуля ВЕРИФИЦИРУЕТСЯ, чтобы убедиться, что он функционирует, как определено в детализированном проекте, и что он соответствует указанным стандартам кодирования.

В 5.5.5 от ИЗГОТОВИТЕЛЯ требуется проверять код. Если код не реализует проект правильно, ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ не будет работать так, как предполагалось.

B.5.6 Программная интеграция и тестирование интеграции

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

Подход к интеграции может колебаться от непошаговой интеграции до любой формы пошаговой интеграции. Свойства собираемого ПРОГРАММНОГО ЭЛЕМЕНТА диктуют выбираемый метод интеграции.

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

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

В соответствующих случаях тестирование интеграции демонстрирует поведение программы на границах ее входных и выходных доменов (областей) и подтверждает ПРОГРАММНЫЕ реакции на недействительные, неожиданные и специальные входные данные. Действия программы обнаруживаются при введении комбинации входных данных, неожиданной последовательности входных данных или когда нарушены определенные требования синхронизации. Требования тестирования в плане должны включать, соответственно, типы тестирования методом "белого ящика", чтобы быть выполненными как часть интеграционного тестирования.

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

Планы и документация тестирования, определенные в 5.6 и 5.7, могут быть отдельными документами, привязанными к конкретным фазам разработки или эволюционным прототипам. Они также могут быть объединены в единый документ или набор документов, охватывающих требования множества подразделов. Все документы или часть документов могут быть включены в документы проекта более высокого уровня, такие как план обеспечения качества проекта или ПО, или план комплексного тестирования, который охватывает все аспекты тестирования аппаратных средств и ПО. В таких случаях следует создавать перекрестную ссылку, которая определяет, как различные документы проекта связаны с каждой из ЗАДАЧ интеграции ПО.

Тестирование интеграции ПО может быть осуществлено в моделируемой среде, на имеющемся оборудовании, или на полном МЕДИЦИНСКОМ ИЗДЕЛИИ.

В 5.6.2 от ИЗГОТОВИТЕЛЯ требуется ВЕРИФИЦИРОВАТЬ выходные данные деятельности по интеграции ПО. Выходные данные деятельности интеграции ПО - это интегрированные (встроенные) ПРОГРАММНЫЕ ЭЛЕМЕНТЫ.

Эти интегрированные ПРОГРАММНЫЕ ЭЛЕМЕНТЫ должны правильно функционировать для всего ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ, чтобы оно функционировало правильно и надежно.

B.5.7 Тестирование ПО СИСТЕМЫ

Эта РАБОТА требует от ИЗГОТОВИТЕЛЯ проверить функциональность ПО путем проверки того, что требования к ПО были успешно выполнены.

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

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

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

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

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

В 5.7.4 требуется, чтобы РЕЗУЛЬТАТЫ тестирования ПРОГРАММНОЙ СИСТЕМЫ были ОЦЕНЕНЫ для обеспечения получения ожидаемых РЕЗУЛЬТАТОВ.

B.5.8 Выпуск ПО

Эта деятельность требует от ИЗГОТОВИТЕЛЯ документировать ВЕРСИЮ выпускаемого ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ, указать, как оно было создано, и следовать необходимым для выпуска ПО процедурам.

ИЗГОТОВИТЕЛЬ должен быть способен продемонстрировать, что ПО, которое было разработано, с использованием ПРОЦЕССА разработки, - это то ПО, которое было выпущено. ИЗГОТОВИТЕЛЬ должен иметь возможность восстановить ПО и инструменты, использованные для его создания, в случае, если это будет необходимо в будущем, и хранить, упаковывать и доставлять ПО способом, минимизирующим возможность повреждения или неправильного применения. Должны быть установлены определенные процедуры, чтобы обеспечить выполнение ЗАДАЧ надлежащим образом и с последовательными результатами.

В.6 ПРОЦЕСС технической поддержки ПО

B.6.1 Установление плана технической поддержки ПО

ПРОЦЕСС технической поддержки ПО отличается от ПРОЦЕССА разработки ПО по двум следующим пунктам:

- ИЗГОТОВИТЕЛЮ разрешается использовать ПРОЦЕСС меньший, чем полный ПРОЦЕСС разработки ПО, чтобы осуществлять быстрые изменения в ответ на неотложные проблемы;

- в ответ на ПРОГРАММНЫЕ ОТЧЕТЫ О ПРОБЛЕМАХ, относящихся к выпущенному продукту, ИЗГОТОВИТЕЛЬ не только решает проблему, но еще и выполняет требования локальными регулирующими актами (обычно запуская активную схему наблюдения для сбора данных о проблеме и ее области и для общения с пользователями и регулирующими органами о проблеме).

B.1 требует, чтобы эти ПРОЦЕССЫ были установлены в плане обслуживания.

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

ИЗГОТОВИТЕЛЮ нужно планировать деятельность и ЗАДАЧИ ПРОЦЕССА технической поддержки.

B.6.2 Анализ проблем и модификаций

Данная деятельность требует от ИЗГОТОВИТЕЛЯ анализировать последствия обратной связи; проверять сообщения о проблемах и рассматривать, выбирать и одобрять подходящие для выполнения возможные варианты модификаций.

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

Важно различать техническую поддержку ПО (см. раздел 6) и решение проблем ПО (см. раздел 9).

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

- ОТЧЕТЫ О ПРОБЛЕМАХ, связанные с БЕЗОПАСНОСТЬЮ, адресуются регулирующим органам и заинтересованным потребителям и доводятся до них;

- ПРОГРАММНЫЕ ПРОДУКТЫ повторно одобряются и выпускаются после модификации и официального контроля, которые обеспечивают устранение проблемы и предотвращение дальнейших проблем;

- ИЗГОТОВИТЕЛЬ рассматривает, какие другие ПРОГРАММНЫЕ ПРОДУКТЫ могут быть затронуты, и предпринимает соответствующие действия.

Особое внимание при решении проблем ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ должно быть уделено функционированию комплексной СИСТЕМЫ управления, которая:

- анализирует ОТЧЕТЫ О ПРОБЛЕМАХ и идентифицирует все последствия этой проблемы;

- принимает решения по ряду изменений и определяет все их побочные эффекты;

- осуществляет изменения, сохраняя при этом согласованность ПРОГРАММНЫХ ЭЛЕМЕНТОВ КОНФИГУРАЦИИ, в том числе ФАЙЛА МЕНЕДЖМЕНТА РИСКА;

- ВЕРИФИЦИРУЕТ осуществление изменений.

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

B.6.3 Осуществление модификации

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

B.7 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА ПО

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

a) целевая аудитория настоящего стандарта должна осознавать минимальные требования для мер по УПРАВЛЕНИЮ РИСКОМ в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ, являющемся зоной их ответственности;

b) общий стандарт по МЕНЕДЖМЕНТУ РИСКА, ИСО 14971, приведенный в настоящем стандарте в качестве нормативной ссылки, не охватывает специально УПРАВЛЕНИЕ РИСКОМ ПО и место УПРАВЛЕНИЯ РИСКОМ в жизненном цикле разработки ПО.

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

В.7.1 Анализ ПО, способствующего возникновению опасных ситуаций

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

Однако вряд ли можно ожидать, что все опасные ситуации изделия могут быть определены до того, как будет подготовлена программная АРХИТЕКТУРА. В то же время известно, как функции ПО будут воплощены в программных компонентах и может быть ОЦЕНЕНА практичность мер по УПРАВЛЕНИЮ РИСКОМ, назначенных функциям ПО. Также следует пересмотреть анализ ОПАСНОСТИ изделия, чтобы включить:

- пересмотренные опасные ситуации;

- пересмотренные меры по УПРАВЛЕНИЮ РИСКОМ и требования к ПО;

- новые опасные ситуации, возникающие из-за ПО, например, опасные ситуации, связанные с человеческим фактором.

АРХИТЕКТУРА ПО должна включать в себя надежные стратегии для разделения компонентов ПО таким образом, чтобы минимизировать их опасное взаимодействие.

B.8 ПРОЦЕСС менеджмента конфигурации ПО

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

B.8.1 Идентификация конфигурации

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

B.8.2 Управление изменениями

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

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

В.8.3 Учет статуса конфигурации

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

В.9 ПРОЦЕСС решения проблем ПО

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

Данная деятельность требует от ИЗГОТОВИТЕЛЯ использовать ПРОЦЕСС решения проблем, когда определены проблема или несоответствие. Данная деятельность необходима для обеспечения уверенности в том, что обнаруженные проблемы проанализированы и ОЦЕНЕНЫ на возможное отношение их к БЕЗОПАСНОСТИ (как определено в ИСО 14971).

План (планы) или процедуры разработки ПО, как требуется в 5.1, состоят в том, как будут обработаны проблемы или несоответствия. Это включает в себя определение на каждой стадии жизненного цикла аспектов ПРОЦЕССА решения проблем ПО, которые будут надлежаще оформлены и зарегистрированы тогда, когда проблемы и несоответствия будут введены в ПРОЦЕСС решения проблем ПО.