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