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

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

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

B.1 Область применения

B.1.1 Цель

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

Данное приложение содержит рекомендации по применению, которые не дополняют и не изменяют требования настоящего стандарта. Данное приложение может использоваться для лучшего понимания требований настоящего стандарта.

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

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

Из-за указанных логических зависимостей между процессами в настоящем стандарте целесообразней описывать процессы в последовательности, подразумевающей "водопадную" или "сквозную" модель жизненного цикла. Однако можно использовать и другие модели. Некоторые стратегии разработки (модели) определены в стандарте ISO/IEC 12207 [9] и включают (см. также таблицу B.1):

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

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

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

Таблица B.1 - Разработка стратегий (моделей), как это определено в ISO/IEC 12207

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

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

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

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

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

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

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

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

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

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

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

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

ISO/IEC 90003 [11] предоставляет руководство для применения систем менеджмента качества к разработке ПО. Использование этого руководства не требуется настоящим стандартом, но рекомендуется.

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

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

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

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

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

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

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

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

- разработка ПО.

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

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

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

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

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

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

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

B.4.3 Классификация безопасности ПО

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

РИСК рассматривается как комбинация тяжести ВРЕДА и вероятности его возникновения. Не существует общепризнанного метода количественного определения вероятности возникновения отказа программного обеспечения. Если ПО задействовано в последовательности или комбинации событий, приводящих к ОПАСНОЙ СИТУАЦИИ, то вероятность возникновения отказа программного обеспечения не может быть учтена при определении РИСКА от ОПАСНОЙ СИТУАЦИИ. В таких ситуациях целесообразно рассмотреть вероятность наихудшего случая и установить вероятность возникновения отказа ПО равной 1. Если есть возможность определить вероятность для остальных событий в последовательности (что возможно, если они не являются программными), то эта вероятность может быть использована для определения вероятности возникновения ОПАСНОЙ СИТУАЦИИ (Р1 на рисунке B.2).

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

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

Примечание

P ₁ - вероятность возникновения опасной ситуации;

P ₂ - вероятность возникновения опасной ситуации, приводящей к причинению вреда.

Рисунок B.2 - Наглядное представление взаимосвязи ОПАСНОСТИ, последовательности событий, ОПАСНОЙ СИТУАЦИИ и ВРЕДА - заимствовано из ISO 14971:2007, приложение E

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

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

- если изменения в СИСТЕМЕ находятся под управлением;

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

Настоящий стандарт требует минимального количества ДЕЯТЕЛЬНОСТИ, направленной на выполнение вышеуказанных условий для всех классов ПО.

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

Данный этап соответствует точке, с которой в ISO 14971 начинается УПРАВЛЕНИЕ РИСКОМ.

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

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

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

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

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

Как установлено в B.3, настоящий стандарт использует три термина для описания декомпозиции ПРОГРАММНОЙ СИСТЕМЫ (высший уровень).

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

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

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

B.4.4 Устаревшее/наследуемое ПО

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

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

- необходимая ДЕЯТЕЛЬНОСТЬ и итоговая документация должны основываться на существующей документации и использовать ее, где это возможно,

- ИЗГОТОВИТЕЛЬ должен использовать ресурсы для максимально результативного снижения РИСКА.

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

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

В 4.4 требуется всесторонняя оценка имеющихся постпроизводственных данных, полученных для УСТАРЕВШЕГО ПО за время его производства и применения. Типичные источники данных на стадии постпроизводства включают:

- неблагоприятные события, связанные с изделием,

- отзывы, полученные от пользователей изделия, и

- АНОМАЛИИ, обнаруженные ИЗГОТОВИТЕЛЕМ.

Хотя не существует единого мнения в отношении метода перспективного количественного определения вероятности возникновения отказа программного обеспечения, для УСТАРЕВШЕГО ПО может быть доступна уместная информация по постпроизводству. Если в таких случаях возможно количественно определить вероятность событий в последовательности, то количественное значение может быть использовано для выражения вероятности возникновения всей последовательности событий. Если данная количественная оценка невозможна, целесообразно учитывать вероятность наихудшего случая и принять вероятность возникновения сбоя программного обеспечения равной 1.

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

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

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

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

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

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

Согласно 4.4 ИЗГОТОВИТЕЛЬ проводит анализ разрывов (пробелов), чтобы определить доступную документацию, включая объективные свидетельства выполненных ЗАДАЧ, созданную во время разработки УСТАРЕВШЕГО ПО, и сравнить ее с 5.2, 5.3, 5.7 и разделом 7. Типичные шаги для выполнения данного анализа разрывов (пробелов) включают:

a) идентификацию УСТАРЕВШЕГО ПО, включая ВЕРСИЮ, редакцию и любые другие средства, необходимые для четкой идентификации;

б) ОЦЕНКУ существующих ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ, соответствующих результатам, требуемым 5.2, 5.3, 5.7 и разделом 7;

c) ОЦЕНКУ имеющихся объективных свидетельств, документирование ранее применявшейся модели жизненного цикла разработки программного обеспечения (при необходимости);

d) ОЦЕНКУ адекватности существующей документации по МЕНЕДЖМЕНТУ РИСКА с учетом ISO 14971.

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

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

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

Документированное обоснование дальнейшего использования УСТАРЕВШЕГО ПО основывается на имеющихся объективных свидетельствах и результатах анализа, полученных в ходе оценки РИСКА и разработки плана устранения разрывов, соответствующих контексту повторного использования УСТАРЕВШЕГО ПО.

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

После повторного использования УСТАРЕВШЕГО ПО в соответствии с 4.4 те части УСТАРЕВШЕГО ПО, для которых сохраняются разрывы (пробелы) в ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТАХ, продолжают оставаться УСТАРЕВШИМ ПО и могут быть рассмотрены для дальнейшего повторного использования в соответствии с 4.4. Когда разрывы (пробелы) в результатах устраняются путем изменения УСТАРЕВШЕГО ПО, изменения должны выполняться в соответствии с разделами 4-9 настоящего стандарта.

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

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

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

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

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

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

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

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

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

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

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

ПРОЦЕСС сбора и анализа СИСТЕМНЫХ и программных требований может быть итеративным.

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

B.5.3 АРХИТЕКТУРА программного обеспечения

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

Данная ДЕЯТЕЛЬНОСТЬ требует от ИЗГОТОВИТЕЛЯ проверить функциональность программного обеспечения путем проверки того, что требования к программному обеспечению были успешно реализованы.

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

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

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

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

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

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

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

B.5.8 Выпуск ПО

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

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

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

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

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

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

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

Подраздел 6.1 требует, чтобы эти ПРОЦЕССЫ были установлены в плане технической поддержки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B.7 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА программного обеспечения

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

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

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

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

B.7.1 Анализ программного обеспечения, способствующего опасным ситуациям

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B.9 ПРОЦЕСС решения проблем программного обеспечения

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

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

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