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

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

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

В.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 Тестирование ПО СИСТЕМЫ

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

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