Приложение С (справочное). Взаимосвязь с другими стандартами

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

Взаимосвязь с другими стандартами

С.1 Общие положения

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

Стандарты по менеджменту МЕДИЦИНСКИХ ИЗДЕЛИЙ, такие как ИСО 13485 [7] (см, С.2 и приложение D) и ИСО 14971 обеспечивают менеджмент окружающей среды, что закладывает основу для организации разработки продукции. Стандарты БЕЗОПАСНОСТИ, такие как МЭК 60601-1 [1] (см. С.4) и МЭК 61010-1 [4] (см. С.5), дают определенное руководство по созданию безопасных МЕДИЦИНСКИХ ИЗДЕЛИЙ. Когда ПО является составной частью МЕДИЦИНСКИХ ИЗДЕЛИЙ, настоящий стандарт предлагает более детальное руководство относительно требований к разработке и поддержанию БЕЗОПАСНОСТИ ПО МЕДИЦИНСКИХ ИЗДЕЛИЙ. Многие другие стандарты, такие как ИСО/МЭК 12207 [9] (см. С.6), МЭК 61508-3 [3] (см. С.7) и ИСО/МЭК 90003 [11], могут рассматриваться как источники методов, инструментов и техник, которые могут быть использованы, чтобы осуществить требования настоящего стандарта. На рисунке С.1 показано отношение между этими стандартами.

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

Рисунок С.1 - Взаимосвязь ключевых стандартов на МЕДИЦИНСКИЕ ИЗДЕЛИЯ с настоящим стандартом

С.2 Взаимосвязь с ИСО 13485

Настоящий стандарт требует, чтобы ИЗГОТОВИТЕЛЬ использовал систему менеджмента качества. Когда ИЗГОТОВИТЕЛЬ использует ИСО 13485 [7], требования настоящего стандарта непосредственно связаны с требованиями ИСО 13485, как это показано в таблице С.1.

Таблица С.1 - Взаимосвязь с ИСО 13485:2003

Раздел/пункт настоящего стандарта	Соответствующий пункт ИСО 13485:2003
5.1 Планирование разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	7.3.1 Планирование проектирования и разработки
5.2 Анализ требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ	7.3.2 Входные данные для проектирования и разработки
5.3 Проектирование АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	-
5.4 Детализированная разработка ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	-
5.5 Исполнение и проверка ПРОГРАММНЫХ МОДУЛЕЙ	-
5.6 Программная интеграция и испытания в отношении интеграции	-
5.7 Испытания СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	7.3.3 Выходные данные проектирования и разработки 7.3.4 Анализ проекта и разработки
5.8 Выпуск ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	7.3.5 ВЕРИФИКАЦИЯ проекта и разработки 7.3.6 Валидация проекта и разработки
6.1 Установление плана технической поддержки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	7.3.7 Управление изменениями проекта и разработки
6.2 Анализ модификации и проблем	-
6.3 Осуществление модификации	7.3.5 Верификация проекта и разработки 7.3.6 Валидация проекта и разработки
7.1 Анализ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, способствующего возникновению опасных ситуаций	-
7.2 Меры по УПРАВЛЕНИЮ РИСКОМ	-
7.3 ВЕРИФИКАЦИЯ мер по УПРАВЛЕНИЮ РИСКОМ	-
7.4 МЕНЕДЖМЕНТ РИСКА в отношении изменений ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	-
8.1 Идентификация конфигурации	7.5.3 Идентификация и ПРОСЛЕЖИВАЕМОСТЬ
8.2 Управление изменениями	7.5.3 Идентификация и ПРОСЛЕЖИВАЕМОСТЬ
8.3 Учет статуса конфигурации	-
9 Программный ПРОЦЕСС решения проблем	-

С.3 Взаимосвязь с ИСО 14971

В таблице С.2 показаны области, где настоящий стандарт усиливает требования к ПРОЦЕССУ МЕНЕДЖМЕНТА РИСКА, требуемого ИСО 14971.

Таблица С.2 - Взаимосвязь с ИСО 14971:2007

Раздел/пункт ИСО 14971:2007	Соответствующий пункт настоящего стандарта
4.1 Процедура анализа РИСКА	-
4.2 Предусмотренное применение/предусмотренное назначение и определение характеристик, относящихся к БЕЗОПАСНОСТИ медицинского изделия	-
4.3 Идентификация известных или прогнозируемых ОПАСНОСТЕЙ	7.1 Анализ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, способствующего возникновению опасных ситуаций
4.4 Определение РИСКОВ для каждой опасной ситуации	4.3 Классификация ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в отношении БЕЗОПАСНОСТИ
5 ОЦЕНИВАНИЕ РИСКА	-
6.1 Уменьшение РИСКА	-
6.2 Анализ возможностей	7.2.1 Выбор мер по УПРАВЛЕНИЮ РИСКОМ
6.3 Выполнение мер по УПРАВЛЕНИЮ РИСКОМ	7.2.2 Меры по УПРАВЛЕНИЮ РИСКОМ, осуществляемые в ПРОГРАММНОМ ОБЕСПЕЧЕНИИ 7.3.1 Проверка мер по УПРАВЛЕНИЮ РИСКОМ
6.4 Оценивание остаточного РИСКА	-
6.5 Анализ соотношения риск/польза	-
6.6 Другие возможные опасности	7.3.2 Документирование любых новых последовательностей событий
6.7 Полнота оценивания РИСКА	-
7 ОЦЕНИВАНИЕ полного остаточного РИСКА	-
8 Отчет по МЕНЕДЖМЕНТУ РИСКА	7.3.3 Документирование ПРОСЛЕЖИВАЕМОСТИ
9 Постпроизводственная информация	7.4 МЕНЕДЖМЕНТ РИСКА в отношении изменений ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

С.4 Взаимосвязь ПЭМС с требованиями МЭК 60601-1:2005

С.4.1 Общие положения

Требования к ПО - это подмножество требований к программируемой электрической медицинской системе (ПЭМС). Настоящий стандарт определяет требования к ПО, которые являются дополнительными, но не являются несовместимыми с требованиями МЭК 60601-1[1] для ПЭМС. Поскольку ПЭМС включают в себя элементы, не являющиеся ПО, не все требования МЭК 60601-1 для ПЭМС изложены в настоящем стандарте.

С.4.2 Взаимосвязь ПО с разработкой ПЭМС

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

Рисунок С.2 - ПО как часть V-модели

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

Соответствие ПРОЦЕССУ разработки ПО в настоящем стандарте (раздел 5) требует, чтобы план разработки ПО был определен и соблюдался, а также включал определенные виды деятельности и имел определенные признаки, однако это не означает, чтобы использовалась некая определенная модель жизненного цикла. Эти требования соотносятся с требованиями ПЭМС в МЭК 60601 к разработке жизненного цикла, спецификации требований, АРХИТЕКТУРЕ, проектированию и осуществлению, а также ВЕРИФИКАЦИИ. Требования в настоящем стандарте более детальны в области разработки ПО, чем требования МЭК 60601-1.

С.4.4 ПРОЦЕСС технического обслуживания

Соответствие ПРОЦЕССУ технического обслуживания ПО в настоящем стандарте (раздел 6) требует, чтобы процедуры были установлены и соблюдались, когда в ПО вносятся изменения. Эти требования соответствуют требованиям МЭК 60601-1 для модификации ПЭМС. Требования настоящего стандарта относительно технического обслуживания ПО предоставляют более подробную информацию о том, что должно быть сделано для технической поддержки ПО, чем требования для модификации ПЭМС в МЭК 60601-1.

С.4.5 Прочие ПРОЦЕССЫ

Прочие ПРОЦЕССЫ в настоящем стандарте определяют дополнительные требования к ПО, сверх подобных требований для ПЭМС в МЭК 60601-1. В большинстве случаев существует общее требование для ПЭМС в МЭК 60601-1, которое расширяет ПРОЦЕССЫ, указанные в настоящем стандарте.

ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА ПО в настоящем стандарте соответствует дополнительным требованиям МЕНЕДЖМЕНТА РИСКА, определенными для ПЭМС в МЭК 60601-1.

ПРОЦЕСС решения проблем ПО в настоящем стандарте соответствует требованию к решению проблем для ПЭМС в МЭК 60601-1.

ПРОЦЕСС менеджмента конфигурации ПО в настоящем стандарте определяет дополнительные требования, которые не представлены для ПЭМС в МЭК 60601-1, за исключением документации.

С.4.6 Охват требований к ПЭМС в МЭК 60601-1

В таблице С.3 приведены требования к ПЭМС в МЭК 60601-1 и соответствующие им требования в настоящем стандарте.

Таблица С.3 - Взаимосвязь с МЭК 60601-1

Требования к ПЭМС в МЭК 60601-1:2005	Требования настоящего стандарта, связанные с программным обеспечением подсистемы ПЭМС
14* Программируемые электрические медицинские СИСТЕМЫ (ПЭМС) 14.1* Общие положения Требования данного пункта должны применяться к ПЭМС, за исключением случаев, когда: - программируемая электронная подсистема (ПЭСС) не задействована в обеспечении ОСНОВНОЙ БЕЗОПАСНОСТИ или ОСНОВНЫХ ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК, или - применение ИСО 14971:2007 показывает, что отказ ПЭСС не приводит к возникновению недопустимого РИСКА	4.3 Классификация ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в отношении безопасности Требования к ПЭМС, установленные в МЭК 60601-1, применимы только к программному обеспечению классов безопасности В и С. Настоящий стандарт содержит некоторые требования в отношении программного обеспечения класса безопасности А
14.2* Документирование В дополнение к ЗАПИСЯМ и документам, требуемым ИСО 14971:2007, разработанные при применении раздела 14 документы должны сохраняться в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА, составляя его часть	4.2 МЕНЕДЖМЕНТ РИСКА
Документы, требуемые в соответствии с разделом 14, должны рассматриваться, утверждаться, выпускаться и изменяться в соответствии с документированной процедурой управления документацией	5.1 Планирование разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В дополнение к определенным требованиям в отношении ДЕЯТЕЛЬНОСТИ по планированию разработки программного обеспечения, документы, которые являются частью ФАЙЛА МЕНЕДЖМЕНТА РИСКА, должны поддерживаться в соответствии с ИСО 14971:2007. Кроме того, в соответствии с ИСО 13485:2003, требуется управление в отношении документации системы качества
14.3* План МЕНЕДЖМЕНТА РИСКА План МЕНЕДЖМЕНТА РИСКА, требуемый согласно ИСО 14971:2007, пункт 3.5, должен также включать ссылку на план ПРОВЕРКИ СООТВЕТСТВИЯ ПЭМС (см. 14.11)	Специальные требования отсутствуют. Не существует никакого определенного плана валидации программного обеспечения. План валидации ПЭМС относится к уровню СИСТЕМЫ и, таким образом, находится вне области применения настоящего стандарта на программное обеспечение. Настоящий стандарт требует ПРОСЛЕЖИВАЕМОСТИ от ОПАСНОСТИ до определения причин возникновения опасности, связанных с программным обеспечением, мер по УПРАВЛЕНИЮ РИСКОМ и до ВЕРИФИКАЦИИ мер по УПРАВЛЕНИЮ РИСКОМ (см. 7.3)
14.4* ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС должен быть документально оформлен	5.1 Планирование разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 5.1.1 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Пункты, на которые ссылается план разработки программного обеспечения, составляют разработку жизненного цикла программного обеспечения
ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС должен состоять из набора определенных этапов	-
На каждом этапе должны быть определены работы, которые должны быть завершены, а также методы ВЕРИФИКАЦИИ, которые должны применяться в отношении этих работ	5.1.6 Планирование ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Должны быть запланированы ЗАДАЧИ ВЕРИФИКАЦИИ, этапы и критерии приемки
Каждая работа должна быть определена с указанием входных и выходных характеристик	5.1.1 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Вся ДЕЯТЕЛЬНОСТЬ определена в настоящем стандарте. Документация, которая должна быть разработана, определена для каждого вида ДЕЯТЕЛЬНОСТИ
На каждом этапе должны быть определены работы по менеджменту риска, которые необходимо завершить перед этим этапом	5.1.1 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В соответствии с настоящим стандартом разработка жизненного цикла ПО должна быть документирована в плане разработки. Это означает, что план разработки должен содержать разработку конкретного жизненного цикла
ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС должен быть составлен для каждой разработки путем создания планов, в которых уточняются работы, этапы и графики их выполнения	-
ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС должен также включать требования к документации	5.1.1 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 5.1.8 Документация планирования
14.5* Решение проблем Когда это целесообразно, должна разрабатываться и поддерживаться зарегистрированная система решения проблем, возникающих на каждом этапе (и между ними) ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПЭМС	9 Программный ПРОЦЕСС решения проблем
В зависимости от типа изделия система решения проблем может: - регистрироваться как часть ЖИЗНЕННОГО ЦИКЛА РАЗ РАБОТКИ ПЭМС; - позволять уведомлять о потенциальных или возникающих проблемах, затрагивающих ОСНОВНУЮ БЕЗОПАСНОСТЬ или ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ХАРАКТЕРИСТИКИ ПЭМС; - включать оценку каждой проблемы с точки зрения связанных с ней РИСКОВ; - определять критерии завершения решения проблем; - определять работы, которые должны выполняться для решения каждой проблемы	5.1.1 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 9.1 Подготовка ОТЧЕТОВ О ПРОБЛЕМАХ
14.6 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА	7 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
14.6.1* Идентификация известных и прогнозируемых ОПАСНОСТЕЙ При составлении перечня известных или прогнозируемых ОПАСНОСТЕЙ ИЗГОТОВИТЕЛЬ должен учитывать те из них, которые связаны с программным обеспечением и особенностями аппаратных средств ПЭМС, включая связанные с СЕТЕВЫМИ/ИНФОРМАЦИОННЫМИ СРЕДСТВАМИ СВЯЗИ, компонентами сторонних изготовителей и стандартными подсистемами	7.1 Анализ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, способствующего возникновению опасных ситуаций Настоящий стандарт не дает ссылки на конкретное сопряжение сети и данных
14.6.2* УПРАВЛЕНИЕ РИСКОМ Нижеследующие требования к ПЭМС дополняют требования, содержащиеся в ИСО 14971:2007, подраздел 6.1. Для выполнения каждого мероприятия по УПРАВЛЕНИЮ РИСКОМ должны быть выбраны и идентифицированы соответствующим образом обоснованные методы и ПРОЦЕДУРЫ. Эти методы и ПРОЦЕДУРЫ должны быть пригодны для гарантии того, что каждое мероприятие по УПРАВЛЕНИЮ РИСКОМ уменьшает идентифицированные РИСКИ в достаточной степени	5.1.4 Стандарты, методы и инструменты планирования разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Настоящий стандарт требует идентификации определенных инструментов и методов, которые используются как общепринятые при разработке, но не в отношении каждой меры по УПРАВЛЕНИЮ РИСКОМ
14.7* Перечень требований Для любой ПЭМС и каждой из ее подсистем должен быть разработан и задокументирован перечень требований	5.2 Анализ требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ Настоящий стандарт применим только в отношении подсистем программного обеспечения ПЭМС
Перечень требований к системе или подсистеме должен включать и характеризовать все основные функциональные характеристики и все мероприятия по управлению риском, реализуемые в этой системе или подсистеме	5.2.1 Определение и документирование требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ в зависимости от требований СИСТЕМЫ 5.2.2 Содержание требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ 5.2.3 Включение мер УПРАВЛЕНИЯ РИСКОМ в требования к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ Настоящий стандарт не устанавливает, чтобы требования, связанные с эксплуатационными характеристиками и мерами по УПРАВЛЕНИЮ РИСКОМ были отличными от других требований, однако устанавливает, чтобы все требования были идентифицированы уникальным образом
14.8* АРХИТЕКТУРА Для любой ПЭМС и каждой из ее подсистем должна быть определена АРХИТЕКТУРА, удовлетворяющая перечню требований	5.3 Проектирование АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Когда это целесообразно для снижения риска до приемлемого уровня, в требованиях к структуре ПЭМС должны использоваться: a) компоненты с высокой степенью интеграции; b) устойчивые к отказам функции; c) избыточность; d) диверсификация; e) разделение функций; f) защищенная структура, служащая, например, для ограничения представляющих потенциальную опасность эффектов путем ограничения допускаемой выходной мощности или введения устройств, ограничивающих свободный ход исполнительных устройств	5.3.5 Идентификация обособленности, необходимой для УПРАВЛЕНИЯ РИСКОМ Разделение является единственным идентифицированным способом, и это только идентификация, потому что требование состоит в точном определении того, что целостность разделения обеспечена
Структура ПЭМС должна также учитывать: a) распределение мероприятий по управлению риском в подсистемах и компонентах ПЭМС; b) режимы (состояния) отказов компонентов и их последствия; c) неспецифические отказы; d) систематические отказы; e) период проведения тестирования или диагностики; f) ремонтопригодность; g) защиту от прогнозируемых ошибок в применении; h) если применимо, требования к сетевым/информационным системам связи	Не включено в настоящий стандарт
14.9* Проектирование и реализация ПЭМС Когда это целесообразно, проектирование следует проводить для отдельных подсистем, каждая из которых должна иметь собственные требования к разработке и требования к испытаниям	5.4 Детализированная разработка ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 5.4.2 Разработка детализированного проекта для каждого ПРОГРАММНОГО МОДУЛЯ
Пояснения относительно условий проектирования должны включаться в ФАЙЛ МЕНЕДЖМЕНТА РИСКА	5.4.2 Разработка детализированного проекта для каждого ПРОГРАММНОГО МОДУЛЯ
14.10* ВЕРИФИКАЦИЯ ВЕРИФИКАЦИЯ требуется для всех функций, которые обеспечивают ОСНОВНУЮ БЕЗОПАСНОСТЬ, ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ХАРАКТЕРИСТИКИ ИЛИ УПРАВЛЕНИЕ РИСКОМ	5.1.6 Планирование ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ВЕРИФИКАЦИЯ требуется в отношении любого вида ДЕЯТЕЛЬНОСТИ
План ВЕРИФИКАЦИИ должен формироваться для указания способов проверки этих функций и включать: - указания о том, на каком этапе (этапах) каждая функция должна проходить ВЕРИФИКАЦИЮ; - выбор и документирование принципов, мероприятий, методов и соответствующего уровня независимости персонала, выполняющего ВЕРИФИКАЦИЮ; - выбор и использование методов ВЕРИФИКАЦИИ; - критерии ВЕРИФИКАЦИИ	5.1.6 Планирование ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Требование в отношении независимости персонала не включено в настоящий стандарт. Это требование считается установленным в ИСО 13485
ВЕРИФИКАЦИЯ должна выполняться в соответствии с планом верификации, а ее результаты должны документироваться	Требования ВЕРИФИКАЦИИ установлены к большинству видов ДЕЯТЕЛЬНОСТИ
14.11* ПРОВЕРКА СООТВЕТСТВИЯ (ВАЛИДАЦИЯ) ПЭМС План ПРОВЕРКИ СООТВЕТСТВИЯ (ВАЛИДАЦИИ) ПЭМС должен включать проверку ОСНОВНОЙ БЕЗОПАСНОСТИ И ОСНОВНЫХ ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК, а также проверки на непредусмотренное функционирование ПЭМС	Настоящий стандарт не распространяется на валидацию программного обеспечения. ВАЛИДАЦИЯ ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта
ПРОВЕРКА СООТВЕТСТВИЯ (ВАЛИДАЦИЯ) ПЭМС должна выполняться в соответствии с планом ВАЛИДАЦИИ, а ее РЕЗУЛЬТАТЫ должны документироваться	Настоящий стандарт не распространяется на валидацию программного обеспечения. ВАЛИДАЦИЯ ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта
Лицо, несущее основную ответственность за ПРОВЕРКУ СООТВЕТСТВИЯ (ВАЛИДАЦИЮ) ПЭМС, должно быть независимым от коллектива разработчиков ПЭМС. ИЗГОТОВИТЕЛЬ должен задокументировать обоснование уровня его независимости	Настоящий стандарт не распространяется на валидацию программного обеспечения. ВАЛИДАЦИЯ ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта
Ни один из членов коллектива разработчиков ПЭМС не должен нести ответственность за процесс ПРОВЕРКИ СООТВЕТСТВИЯ (ВАЛИДАЦИИ) ПЭМС их собственного проекта	Настоящий стандарт не распространяется на валидацию программного обеспечения. ВАЛИДАЦИЯ ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта
Все профессиональные взаимодействия между членами коллектива, выполняющего работы по ПРОВЕРКЕ СООТВЕТСТВИЯ (ВАЛИДАЦИИ) ПЭМС, и членами коллектива разработчиков ПЭМС должны быть зарегистрированы в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА	Настоящий стандарт не распространяется на валидацию программного обеспечения. ВАЛИДАЦИЯ ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта
Ссылка на методы и РЕЗУЛЬТАТЫ ПРОВЕРКИ СООТВЕТСТВИЯ (ВАЛИДАЦИИ) ПЭМС должна быть включена в ФАЙЛ МЕНЕДЖМЕНТА РИСКА	Настоящий стандарт не распространяется на валидацию программного обеспечения. Валидация ПЭМС является ДЕЯТЕЛЬНОСТЬЮ на уровне СИСТЕМЫ и находится вне области применения настоящего стандарта
14.12* Модификация Если часть или весь существующий проект является модификацией более раннего проекта, то к нему следует либо применять требования всего настоящего пункта так, как если бы эта модификация была новым проектом, либо с помощью задокументированной ПРОЦЕДУРЫ модификации в ПРОЦЕССЕ внесения изменений ОЦЕНИВАТЬ возможность дальнейшего использования предыдущей проектной документации	6 ПРОЦЕСС технической поддержки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Настоящий стандарт устанавливает, что обслуживание программного обеспечения должно быть запланировано, а реализация модификаций должна использовать ПРОЦЕСС разработки программного обеспечения или установленный ПРОЦЕСС обслуживания программного обеспечения
14.13* Соединение ПЭМС с другим изделием с помощью СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ Если ПЭМС предназначена для соединения с помощью СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ с другим изделием, которое не может контролироваться изготовителем ПЭМС, то в техническом описании: a) должны быть указаны характеристики СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ, необходимые для предусмотренного применения ПЭМС; b) должен содержаться перечень ОПАСНЫХ СИТУАЦИЙ, возникающих из-за отказов СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ, связанных с обеспечением их установленных характеристик; с) должны содержаться указания ОТВЕТСТВЕННОЙ ОРГАНИЗАЦИИ относительно того, что: 1) соединение ПЭМС с СЕТЕВЫМИ/ИНФОРМАЦИОННЫМИ СРЕДСТВАМИ СВЯЗИ, которое осуществляется с использованием другого оборудования, может приводить к ранее непредусмотренным РИСКАМ ДЛЯ ПАЦИЕНТОВ, ОПЕРАТОРОВ или третьих лиц; 2) ОТВЕТСТВЕННАЯ ОРГАНИЗАЦИЯ должна идентифицировать, анализировать, ОЦЕНИВАТЬ эти РИСКИ и управлять ими; 3) последующие изменения СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ могут приводить к появлению новых РИСКОВ и требовать дополнительного анализа; 4) последующие изменения СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ могут включать: 1) изменения в их конфигурации; 2) подсоединение к ним дополнительных элементов; 3) отсоединение от них отдельных элементов; 4) модификацию соединенного с ними изделия; 5) модернизацию соединенного с ними изделия	Требования в отношении сопряжения сети и данных не включены в настоящий стандарт

С.4.7 Взаимосвязь с МЭК 60601-1-4

МЭК 60601-1-4 будет продолжать использоваться до тех пор, пока переходный период для МЭК 60601-1 не будет завершен.

Таблица С.4 показывает требования МЭК 60601-1-4 [2] и соответствующие требования в настоящем стандарте. Это не свидетельствует о том, что соответствующие требования в настоящем стандарте полностью охватывают требования в МЭК 60601-1-4. Многие части требований МЭК 60601-1-4 охватываются путем соблюдения требований стандарта ИСО 14971. Некоторые требования МЭК 60601-1-4 не относятся к настоящему стандарту.

Таблица С.4 - Взаимосвязь с МЭК 60601-1-4.

Требования МЭК 60601-1-4:1996 к ПЭМС, включая поправки 1:1999	Соответствующие требования настоящего стандарта
6.8 Сопроводительная документация	-
6.8.201	4.2 и 4.3, перечисление с)
52.201 Документация	-
52.201.1	4.1
52.201.2	4.1 и 4.2
52.201.3	4.2
52.202 ПЛАН МЕНЕДЖМЕНТА РИСКА	-
52.202.1	4.2
52.202.2	5.1.1, 5.1.5
52.202.3	4.1, 5.1.2
52.203 Жизненный цикл разработки	-
52.203.1	5.1.1
52.203.2	5.1.1
52.203.3	-
52.203.4	5.1.7
52.203.5	Раздел 7
52.204 ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА	-
52.204.1	4.2
52.204.2	4.2, раздел 7
52.204.3	-
52.204.3.1	-
52.204.3.1.1	4.2, 7.1
52.204.3.1.2	4.2, 7.1.2
52.204.3.1.3	4.2
52.204.3.1.4	4.2, 7.1.2, перечисление е)
52.204.3.1.5	4.2, 7.1.2
52.204.3.1.6	4.2, 7.1
52.204.3.1.7	4.2
52.204.3.1.8	4.2
52.204.3.1.9	4.2
52.204.3.1.10	4.2
52.204.3.2	-
52.204.3.2.1	4.2
52.204.3.2.2	4.2, 4.3
52.204.3.2.3	-
52.204.3.2.4	-
52.204.3.2.5	4.2
52.204.4	-
52.204.4.1	4.2
52.204.4.2	4.2
52.204.4.3	4.2
52.204.4.4	4.2
52.204.4.5	-
52.204.4.6	4.2
52.205 Квалификация персонала	4.1
52.206 Требования спецификации	-
52.206.1	5.2
52.206.2	7.2.2
52.206.3	-
52.207 АРХИТЕКТУРА	-
52.207.1	5.3.1
52.207.2	5.3
52.207.3	-
52.207.4	-
52.207.5	-
52.208 Проектирование и реализация	-
52.208.1	Раздел 5
52.208.2	-
52.209 ВЕРИФИКАЦИЯ	-
52.209.1	5.7.1
52.209.2	5.1.5, 5.1.6
52.209.3	5.2.6, 5.3.6, 5.4.4, 5.5.5, 5.6, 5.7
52.209.4	-
52.210 ВАЛИДАЦИЯ	-
52.210.1	4.1
52.210.2	4.1
52.210.3	4.1
52.210.4	-
52.210.5	-
52.210.6	-
52.210.7	-
52.211 Модификация	-
52.211.1	Раздел 6
52.211.2	4.1, раздел 6
52.212 ОЦЕНКА	-
52.212.1	4.1

С.5 Взаимосвязь с МЭК 61010-1

Сфера действия МЭК 61010-1 [4] охватывает измерительное оборудование и оборудование для электрических испытаний, оборудование электрического контроля и электрооборудование лаборатории. Только часть лабораторного электрооборудования используется в медицинской среде или в качестве оборудования для in vitro диагностики.

Из-за правовых норм или нормативных ссылок, оборудование для in vitro диагностики выделяется из МЕДИЦИНСКИХ ИЗДЕЛИЙ, однако, не попадая в сферу действия МЭК 60601-1 [1]. Это связано не только с тем, что инструменты для in vitro диагностики не являются МЕДИЦИНСКИМИ ИЗДЕЛИЯМИ, которые прямо контактируют с пациентами, но и с тем, что такую продукцию изготавливают для разных целей различных лабораторий. Использование в качестве инструментов для in vitro диагностики или принадлежностей к инструментам для in vitro диагностики встречается редко.

Если лабораторное оборудование используется в качестве оборудования для in vitro диагностики, полученные измеренные РЕЗУЛЬТАТЫ должны быть ОЦЕНЕНЫ в соответствии с медицинскими критериями. Применение ИСО 14971 требуется для МЕНЕДЖМЕНТА РИСКА. Если подобная продукция также содержит ПО, которое может привести к возникновению ОПАСНОСТИ, например отказу, вызванному ПО, что приводит к нежелательному изменению медицинских данных (измеряемых РЕЗУЛЬТАТОВ), следует учитывать требования МЭК 62302.

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

Рисунок С.3 - Применение настоящего стандарта совместно с МЭК 61010-1

С.6 Взаимосвязь с ИСО/МЭК 12207

Настоящий стандарт был разработан исходя из подходов и концепций ИСО/МЭК 12207 [9], который определяет требования для ПРОЦЕССОВ жизненного цикла ПО в общих чертах, то есть не ограничиваясь МЕДИЦИНСКИМИ ИЗДЕЛИЯМИ.

Настоящий стандарт отличается от ИСО/МЭК 12207 главным образом следующим:

- исключены аспекты СИСТЕМЫ, такие как системные требования, АРХИТЕКТУРА СИСТЕМЫ и валидация;

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

- добавлены ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА (БЕЗОПАСНОСТЬ) и ПРОЦЕСС выпуска ПО;

- включены документирование и ВЕРИФИКАЦИЯ поддерживающих ПРОЦЕССОВ в ПРОЦЕССЫ разработки и технической поддержки;

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

- классифицированы требования с учетом нужд БЕЗОПАСНОСТИ; и

ПРОЦЕССЫ явно не классифицированы на первостепенные или поддерживающие, и не сгруппированы ПРОЦЕССЫ, как это сделано в ИСО/МЭК 12207.

Большинство этих изменений были внесены из-за желания приспособить стандарт к нуждам сферы МЕДИЦИНСКИХ ИЗДЕЛИЙ:

- фокусируясь на аспектах БЕЗОПАСНОСТИ и МЕНЕДЖМЕНТА РИСКА МЕДИЦИНСКИХ ИЗДЕЛИЙ ИС014971;

- отбирая подходящие ПРОЦЕССЫ, полезные в регулируемой внешней среде;

- принимая во внимание, что разработка ПО включена в систему качества (которая охватывает некоторые ПРОЦЕССЫ и требования ИСО/МЭК 12207), и

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

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

В таблице С.5, которая была подготовлена подкомитетом 7 ИСО/МЭК, показана взаимосвязь между настоящим стандартом и ИСО/МЭК 12207.

Таблица С.5 - Взаимосвязь с ИСО/МЭК 12207

Процессы настоящего стандарта		Процессы ИСО/МЭК 12207
Деятельность	Задача	Деятельность	Задача
5 ПРОЦЕСС разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.3 Процесс разработки 6.1 Процесс документирования 6.2 Процесс управления конфигурацией 6.4 Процесс верификации 6.5 Процесс валидации 6.8 Процесс решения проблем 7.1 Процесс менеджмента
5.1 Планирование разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.3.1 Подготовка процесса 5.3.3 Проектирование системной архитектуры 5.3.7 Программирование и тестирование программных средств 5.3.8 Сборка программных средств 5.3.9 Квалификационные испытания программных средств 5.3.10 Сборка системы 6.1.1 Подготовка процесса 6.2.1 Подготовка процесса 6.2.2 Определение конфигурации 6.4.1 Подготовка процесса 6.5.1 Подготовка процесса 6.8.1 Подготовка процесса 7.1.2 Планирование 7.1.3 Выполнение и контроль 7.2.2 Создание инфраструктуры 7.2.3 Сопровождение инфраструктуры
	5.1.1 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	5.3.1 Подготовка процесса 7.1.2 Планирование	5.3.1.1 5.3.1.3 5.3.1.4 7.1.2.1
	5.1.2 Поддержание плана разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в актуальном состоянии	7.1.3 Выполнение и контроль	7.1.3.3
	5.1.3 План разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ относительно проектирования и разработки СИСТЕМЫ	5.3.3 Проектирование системной архитектуры 5.3.10 Сборка системы 6.5.1 Подготовка процесса	5.3.3.1 5.3.10.1 6.5.1.4
	5.1.4 Стандарты, методы и инструменты планирования разработки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	5.3.1 Подготовка процесса	5.3.1.3 5.3.1.4
	5.1.5 Программная интеграция и планирование тестирования интеграции	5.3.8. Сборка программных средств	5.3.8.1
	5.1.6 Планирование ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	6.4.1 Подготовка процесса 5.3.7 Программирование и тестирование программных средств 5.3.8 Сборка программных средств 5.3.9 Квалификационные испытания программных средств	6.4.1.4 6.4.1.5 5.3.7.5 5.3.8.5 5.3.9.3
	5.1.7 Планирование МЕНЕДЖМЕНТА РИСКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	Процесс менеджмента риска
	5.1.8 Документация планирования	6.1.1 Подготовка процесса	6.1.1.1
	5.1.9 Планирование менеджмента конфигурации ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	6.2.1 Подготовка процесса 6.8.1 Подготовка процесса	6.2.1.1 6.8.1.1
	5.1.10 Поддержка элементов, подлежащих управлению	7.2.2 Создание инфраструктуры 7.2.3 Сопровождение инфраструктуры	7.2.2.1
			7.2.3.1
	5.1.11 Управление ЭЛЕМЕНТАМИ КОНФИГУРАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ до ВЕРИФИКАЦИИ	6.2.2 Определение конфигурации	6.2.2.1
5.2 Анализ требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ		5.3.3 Проектирование систем ной архитектуры 5.3.4 Анализ требований к программным средствам 6.4.2 Верификация
	5.2.1 Определение и документирование требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ в зависимости от требований СИСТЕМЫ	5.3.3 Проектирование системной архитектуры	5.3.3.1
	5.2.2 Содержание требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ	5.3.4 Анализ требований к программным средствам	5.3.4.1
	5.2.3 Включение мер УПРАВЛЕНИЯ РИСКОМ в требования к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
	5.2.4 ПЕРЕОЦЕНИВАНИЕ АНАЛИЗА РИСКА МЕДИЦИНСКОГО ИЗДЕЛИЯ
	5.2.5 Обновление требований к СИСТЕМЕ	5.3.4 Анализ требований к программным средствам	Перечисления а) и b)
	5.2.6 Проверка требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ	5.3.4 Анализ требований к программным средствам 6.4.2 Верификация	5.3.4.2 6.4.2.3
5.3 Проектирование АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.3.5 Проектирование программной архитектуры
	5.3.1 Преобразование требований к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ в АРХИТЕКТУРУ	5.3.5 Проектирование программной архитектуры	5.3.5.1
	5.3.2 Разработка АРХИТЕКТУРЫ для интерфейсов ПРОГРАММНЫХ ЭЛЕМЕНТОВ		5.3.5.2
	5.3.3 Определение требований к функциональным и эксплуатационным характеристикам элементов ПОНП
	5.3.4 Определение требований к аппаратным и программным средствам СИСТЕМЫ, требуемых элементами ПОНП
	5.3.5 Идентификация обособленности, необходимой для УПРАВЛЕНИЯ РИСКОМ
	5.3.6 Проверка АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	5.3.5 Проектирование программной архитектуры
5.4 Детализированная разработка ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.3.6 Техническое проектирование программных средств 6.4.2 Верификация
	5.4.1 Развитие АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в ПРОГРАММНЫЕ МОДУЛИ	5.3.6 Техническое проектирование программных средств	5.3.6.1
	5.4.2 Разработка детализированного проекта для каждого ПРОГРАММНОГО МОДУЛЯ
	5.4.3 Разработка детализированного проекта для интерфейсов		5.3.6.2
	5.4.4 Проверка детализированного проекта	6.4.2 Верификация	5.3.6.7
5.5 Исполнение и проверка ПРОГРАММНЫХ МОДУЛЕЙ		5.3.6 Техническое проектирование программных средств 5.3.7 Программирование и тестирование программных средств 6.4.2 Верификация
	5.5.1 Исполнение каждого ПРОГРАММНОГО МОДУЛЯ	5.3.7 Программирование и тестирование программных средств	5.3.7.1
	5.5.2 Установление ПРОЦЕССА ВЕРИФИКАЦИИ ПРОГРАММНОГО МОДУЛЯ	5.3.6 Техническое проектирование программных средств 5.3.7 Программирование и тестирование программных средств	5.3.6.5 5.3.7.5
	5.5.3 Критерии приемки ПРОГРАММНЫХ МОДУЛЕЙ	5.3.7 Программирование и тестирование программных средств	5 3 7.5
	5.5.4 Дополнительные критерии приемки ПРОГРАММНЫХ МОДУЛЕЙ	5.3.7 Программирование и тестирование программных средств 6.4.2 Верификация	5.3 7.5 6.4 2.5
	5.5.5 ВЕРИФИКАЦИЯ ПРОГРАММНЫХ МОДУЛЕЙ	5.3.7 Программирование и тестирование программных средств	5 3 7.2
5.6 Программная интеграция и испытания в отношении интеграции		5.3.8 Сборка программных средств 5.3.9 Квалификационные испытания программных средств 5.3.10 Сборка системы 6.4.1 Подготовка процесса 6.4.2 Верификация
	5.6.1 Интеграция ПРОГРАММНЫХ МОДУЛЕЙ	5.3.8 Сборка программных средств	5.3.8.2
	5.6.2 Проверка программной интеграции	5.3.8 Сборка программных средств 5.3.10 Сборка системы	5.3.8.2 5.3.10.1
	5.6.3 Испытания интегрированного ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	5.3.9 Квалификационные испытания программных средств	5.3.9.1
	5.6.4 Содержание испытаний в отношении интеграции		5.3.9.3
	5.6.5 Проверка процедур испытаний в отношении интеграции	6.4.2 Верификация	6.4.2.2
	5.6.6 Проведение регрессионных испытаний	5.3.8 Сборка программных средств	5.3.8.2
	5.6.7 Содержание записей в отношении регрессионных испытаний	5.3.8 Сборка программных средств	5.3.8.2
	5.6.8 Использование программного ПРОЦЕССА решения проблем	6.4.1 Подготовка процесса	6.4.1.6
5.7 Испытания СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.3.8 Сборка программных средств 5.3.9 Квалификационные испытания программных средств 6.4.1 Подготовка процесса 6.4.2 Верификация 6.8.1 Подготовка процесса
	5.7.1 Установление испытаний в отношении требований ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	5.3.8 Сборка программных средств 5.3.9 Квалификационные испытания программных средств	5.3.8.4 5.3.9.1
	5.7.2 Использование программного ПРОЦЕССА решения проблем	6.4.1 Подготовка процесса	6.4.1.6
	5.7.3 Повторные испытания после внесения изменений	6.8.1 Подготовка процесса	6.8.1.1
	5.7.4 ВЕРИФИКАЦИЯ испытаний СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	6.4.2 Верификация 5.3.9 Квалификационные испытания программных средств	6.4.2.2 5.3.9.3
	5.7.5 Содержание отчета по испытаниям СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	5.3.9 Квалификационные испытания программных средств	5.3.9.1
5.8 Выпуск ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.3.9 Квалификационные испытания программных средств 5.4.2 Эксплуатационные испытания 6.2.5 Оценка конфигурации 6.2.6 Управление выпуском и поставка
	5.8.1 Обеспечение полного завершения ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	5.4.2 Эксплуатационные испытания 6.2.6 Управление выпуском и поставка	5.4.2.1 5.4.2.2 6.2.6.1
	5.8.2 Документирование известных остаточных АНОМАЛИЙ	6.2.5 Оценка конфигурации 5.3.9 Квалификационные испытания программных средств	6.2.5.1 5.3.9.3
	5.8.3 ОЦЕНИВАНИЕ известных остаточных АНОМАЛИЙ
	5.8.4 Документирование выпущенных ВЕРСИЙ	6.2.6 Управление выпуском и поставка	6.2.6.1
	5.8.5 Документирование создания выпущенного ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
	5.8.6 Обеспечение полного завершения деятельности и задач
	5.8.7 Архивирование ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
	5.8.8 Обеспечение воспроизводимости выпуска ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
6 ПРОЦЕСС технической поддержки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.5 Процесс сопровождения 6.2 Процесс управления конфигурацией
6.1 Установление плана технической поддержки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.5.1 Подготовка процесса	5.5.1.1
6.2 Анализ модификации и проблем		5.5.1 Подготовка процесса 5.5.2 Анализ проблем и изменений 5.5.3 Внесение изменений 5.5.5 Перенос
	6.2.1 Документирование и ОЦЕНИВАНИЕ обратной связи
	6.2.1.1 Мониторинг обратной связи 6.2.1.2 Документирование и ОЦЕНИВАНИЕ обратной связи	5.5.1 Подготовка процесса	5.5.1.1 5.5.1.2
	6.2.1.3 ОЦЕНИВАНИЕ влияния ОТЧЕТА О ПРОБЛЕМАХ на БЕЗОПАСНОСТЬ	5.5.2 Анализ проблем и изменений	5.5.2.1 5.5.2.2 5.5.2.3 5.5.2.4
	6.2.2 Использование программного ПРОЦЕССА решения проблем	5.5.1 Подготовка процесса	5.5.1.2
	6.2.3 Анализ ЗАПРОСОВ НА ИЗМЕНЕНИЕ	5.5.2 Анализ проблем и изменений	5.5.2.1
	6.2.4 Одобрение ЗАПРОСА НА ИЗМЕНЕНИЕ	5.5.2 Анализ проблем и изменений	5.5.2.5
	6.2.5 Информирование пользователей и регулирующих органов	5.5.3 Внесение изменений 5.5.5 Перенос	5.5.3.1 5.5.3.3
6.3 Осуществление модификации		5.5.3 Внесение изменений 6.2.6 Управление выпуском и поставка
	6.3.1 Использование установленного ПРОЦЕССА осуществления модификации	5.5.3 Внесение изменений	5.5.3.2
	6.3.2 Повторный выпуск модифицированной ПРОГРАММНОЙ СИСТЕМЫ	6.2.6 Управление выпуском и поставка	6.2.6.1
7* ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА Процесс в настоящем стандарте адресован рискам/вопросам опасностей, которые не рассматриваются в ИСО/МЭК 12207. Существует некоторая общность (меры по управлению риском и т.д.), но направление анализа совершенно иное
8 ПРОЦЕСС менеджмента конфигурации ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		5.5 Процесс сопровождения 6.2 Процесс управления конфигурацией
8.1* Идентификация конфигурации		6.2.2 Определение конфигурации
	8.1.1 Установление средств для идентификации ЭЛЕМЕНТОВ КОНФИГУРАЦИИ	6.2.2 Определение конфигурации	6.2.2.1
	8.1.2 Идентификация ПОНП
	8.1.3 Идентификация документации конфигурации СИСТЕМЫ	6.2.2 Определение конфигурации	6.2.2.1
8.2* Управление изменениями		5.5.3 Внесение изменений 6.2.3 Контроль конфигурации
	8.2.1 Одобрение ЗАПРОСОВ НА ИЗМЕНЕНИЯ	6.2.3 Контроль конфигурации	6.2.3.1
	8.2.2 Осуществление изменений	5.5.3 Внесение изменений 6.2.3 Контроль конфигурации	5.5.3.2 6.2.3.1
	8.2.3 ВЕРИФИКАЦИЯ изменений	6.2.3 Контроль конфигурации	6.2.3.1
	8.2.4 Обеспечение средствами для ПРОСЛЕЖИВАЕМОСТИ изменений
8.3 Учет статуса конфигурации		6.2.4 Учет состояний конфигурации	6.2.4.1
9 Программный ПРОЦЕСС решения проблем		5.5 Процесс сопровождения 6.2 Процесс управления конфигурацией 6.8 Процесс решения проблем
9.1 Подготовка ОТЧЕТОВ О ПРОБЛЕМАХ		6.8.1 Подготовка процесса 6.8.2 Решение проблемы	6.8.1.1, перечисление b) 6.8.2.1
9.2 Исследование проблемы		6.8.2 Решение проблемы 6.8.1 Подготовка процесса	6.8.2.1 6.8.1.1, перечисление b)
9.3 Консультирование заинтересованных сторон		6.8.1 Подготовка процесса	6.8.1.1, перечисление а)
9.4 Использование процесса управления изменениями		6.2.3 Контроль конфигурации 5.5.3 Внесение изменений
9.5 Поддержание записей		6.8.1 Подготовка процесса	6.8.1.1, перечисление а)
9.6 Анализ проблем на предмет выявления тенденций		6.8.1 Подготовка процесса 6.8.2 Решение проблемы	6.8.1.1, перечисление b) 6.8.2.1
9.7 ВЕРИФИКАЦИЯ решения проблем ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ		6.8.1 Подготовка процесса	6.8.1.1, перечисление d)
9.8 Содержание документации по испытаниям			Все тестируемые задачи в ИСО/МЭК 12207 требуют документирования

С.7 Взаимосвязь с МЭК 61508

Поднимался вопрос о том, должен ли настоящий стандарт, имея дело с ПО, критичным к БЕЗОПАСНОСТИ следовать принципам МЭК 61508.

Позицию настоящего стандарта объясняет следующее.

МЭК 61508 охватывает три главных вопроса:

1) жизненный цикл МЕНЕДЖМЕНТА РИСКА и ПРОЦЕССЫ жизненного цикла;

2) определение уровней БЕЗОПАСНОСТИ эксплуатации оборудования;

3) рекомендуемые техники, инструменты и методы для разработки ПО и уровни независимости персонала ответственного за выполнение различных ЗАДАЧ.

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

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

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

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