ГОСТ Р 55544—201З
Л
ЕСП-R80002-1:2009
Вдополнение кпредотвращению ВРЕДА следует уделять внимание информированию пользователя
об обнаруженном состоянии. При отсутствии такого информирования существует возможность причинения
ВРЕДА, если последует отказ меры по УПРАВ
Л
ЕНИЮ РИСКОМ.
Следует также уделить внимание частоте, с которой будут выполняться меры по управлению
РИСКОМ. Программные меры по УПРАВ
Л
ЕНИЮ РИСКОМ должны выполняться достаточно часто для
обнаружения состояния, которое может привести к ВРЕДУ, прежде чем этот ВРЕД произойдет.
6.2.2.5 Меры по УПРАВ
Л
ЕНИЮ РИСКОМ для АНОМА
Л
ИЙ программного обеспечения
Программное обеспечение представляет особую трудность: некоторые события в последовательнос
ти. приводящей к ОПАСНОЙ СИТУАЦИИ, могут возникнуть в результате необнаруженных АНОМА
Л
ИЙ
программного обеспечения, и трудно предсказать, где такие АНОМА
Л
ИИ могут произойти или какие
последствия вызвать.
Меры по УПРАВ
Л
ЕНИЮ РИСКОМ могут снижать вероятность ВРЕДА, происходящего от програм
мныхАНОМА
Л
ИЙ. Обычно вАРХИТЕКТУРЕ программного обеспечения будут присутствовать области, где
меры по УПРАВ
Л
ЕНИЮ РИСКОМ могут уменьшить вероятность ВРЕДА вне зависимости от природы
предыдущих событий. Если это сделано тщательно, то нет необходимости выяснять точный характер
программных АНОМА
Л
ИЙ для предотвращения ВРЕДА, который может от них произойти.
В тех случаях, когда этот подход неприменим, например, если предупреждающая мера осуществле
на в программном обеспечении, должны использоваться методы, обеспечивающие целостность програм
много обеспечения (см. 6.2.2.6).
6.2.2.6 ПРОЦЕСС — как мера по УПРАВ
Л
ЕНИЮ РИСКОМ
Если АНОМА
Л
ИИ программного обеспечения могут способствовать последовательности событий,
приводящей к ОПАСНОЙ СИТУАЦИИ, может оказаться невозможным разработать меры поУПРАВ
Л
ЕНИЮ
РИСКОМ для предотвращения ВРЕДА от их возникновения. Наилучшим решением в таком случае будет
конструктивно обусловленная БЕЗОПАСНОСТЬ, чтобы АНОМА
Л
ИИ программного обеспечения не могли
создать ОПАСНУЮ СИТУАЦИЮ.
Когдаэто неосуществимо, то с целью уменьшения вероятности возникновения АНОМА
Л
ИЙ програм
много обеспечения может использоваться эффективный ПРОЦЕСС разработки программного обеспече
ния. Существует мнение, что меры по УПРАВ
Л
ЕНИЮ РИСКОМ ПРОЦЕССА выгодны, когда используются в
сочетании с другими видами мер по УПРАВ
Л
ЕНИЮ РИСКОМ, если они определены в деталях.
Если установлено, что высока уверенность в том. что программное обеспечение будет выполнять
свою предусмотренную функцию надежно, а также в том. что в программном обеспечении отсутствуют
ошибки, то программное обеспечение можно рассматривать как компонент высокой целостности. Чтобы
достичь этого высокого уровня надежности. ИЗГОТОВИТЕ
Л
Ь должен продемонстрировать, что ПРОЦЕСС
разработки программного обеспечения может создать высоконадежное, безотказное программное обеспе
чение. Использование такого ПРОЦЕССА может быть востребовано для уменьшения вероятности возник
новения АНОМА
Л
ИЙ программного обеспечения.
Установлено, что увеличение тщательности ПРОЦЕССА разработки программного обеспечения мо
жет сократить количество АНОМА
Л
ИЙ программного обеспечения. Следует отметить, что. хотя испытания
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ могут сократить количество АНОМА
Л
ИЙ
программного обеспечения, нельзя утверждать, что. когда программное обеспечение проходит все запла
нированные тесты, в нем не остается никаких АНОМА
Л
ИЙ. Это происходит, поскольку при клиническом
использовании входные данные программного обеспечения будут включать последовательности, которые
не входили в запланированный объем испытаний. Поскольку ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ является слишком сложным для проведения полномасштабных испытаний,
то тщательный выбор и проведение конкретных испытаний может рассматриваться только как метод
снижения возникновения вероятности ОПАСНЫХ СИТУАЦИЙ. Испытаний самих по себе недостаточнодля
обеспечения уверенности в том. что программное обеспечение можно рассматривать как компонент
высокой целостности.
Отправной точкой для обеспечения тщательного ПРОЦЕССА разработки программного обеспечения
может быть включение деятельности и ЗАДАЧ, определенных в МЭК 62304. в ПРОЦЕСС разработки
программного обеспечения. Дополнительные элементы, которые следует учесть при рассмотрении
тщательного ПРОЦЕССА разработки программного обеспечения,должны включать:
- компетентность персонала — навыки, квалификация, опыт иобучение (кто разрабатывает программ
ное обеспечение?);
- методы — пригодность спецификации, проектирования, кодирования и методов испытаний (каков
ПРОЦЕСС разработки?);
27