ГОСТ Р МЭК 61508-3-2012 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению
Приложение С
(справочное)
Свойства стойкости к систематическим отказам программного обеспечения
С.1 Введение
Учитывая большое число факторов, влияющих на стойкость к систематическим отказам программного обеспечения, невозможно создать алгоритм, включающий методы и средства, который обеспечит необходимый результат для любого заданного применения. Целью настоящего приложения является:
- привести указания по выбору конкретных методов из приложений А и В, чтобы обеспечить стойкость к систематическим отказам программного обеспечения;
- помочь в обосновании использования методов, которые не перечислены явно в приложениях А и В.
Настоящее приложение является дополнением к приложениям А и В.
С.1.1 Структура приложения С, связанная с приложениями А и В
Выходные данные каждой стадии жизненного цикла программного обеспечения системы безопасности определены в таблице 1. Например, рассмотрена спецификация требований к программному обеспечению системы безопасности.
Таблица А.1 ("Спецификация требований к программному обеспечению системы безопасности") приложения А рекомендует конкретные методы разработки спецификации требований к программному обеспечению системы безопасности:
Метод/средство | Ссылка | УПБ1 | УПБ2 | УПБ3 | УПБ4 |
1а Полуформальные методы | Таблица В.7 | R | R | HR | HR |
1b Формальные методы | В.2.2, С.2.4 | - | R | R | HR |
2 Прямая прослеживаемость между требованиями к системе безопасности и требованиями к программному обеспечению системы безопасности | С.2.11 | R | R | HR | HR |
3 Обратная прослеживаемость между требованиями к системе безопасности и предполагаемыми потребностями безопасности | С.2.11 | R | R | HR | HR |
4 Компьютерные средства разработки спецификаций для поддержки, перечисленных выше, подходящих методов/средств | В.2.4 | R | R | HR | HR |
Таблица С.1 ("Свойства систематической полноты безопасности - спецификация требований к программному обеспечению системы безопасности") устанавливает, что спецификация требований к программному обеспечению системы безопасности характеризуется следующими требуемыми свойствами (которые неформально определены в [5], приложение F):
Свойства | |||||
Полнота охвата потребностей безопасности программным обеспечением | Корректность охвата потребностей безопасности программным обеспечением | Отсутствие ошибок в самой спецификации, включая отсутствие неоднозначности | Ясность требований к системе безопасности | Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, и функций безопасности, реализуемых программным обеспечением системы безопасности | Способность обеспечения проведения оценки и подтверждения соответствия |
Таблица С.1 с помощью неформальной шкалы R1/R2/R3 также ранжирует эффективность конкретных методов в достижении этих требуемых свойств:
Методы/ средства | Свойства | |||||
Полнота охвата потребностей безопасности програм- | Корректность охвата потребностей безопасности программным обеспечением | Отсутствие ошибок в самой спецификации, включая отсутствие неодно- | Ясность требований к системе безопасности | Отсутствие неблаго- | Способность обеспечения проведения оценки и подтверж- | |
1а Полуфор- | R1 Дружест- | R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в проблемной области. R2 Верификация спецификации согласно критерию охвата | R1 Метод и нотация, которые помогают предотвратить или обнаружить внутреннюю несогла- R2 Проверка спецификации согласно критериям охвата. R3 Проверка спецификации, основанная на система- | R1 Определяемая нотация, ограни- R2 Применение пределов сложности в спецификации | - | R1 Опреде- |
Уверенность, которую можно связать со свойствами спецификации требований к программному обеспечению системы безопасности, как основание для обеспечения безопасности программного обеспечения, зависит от строгости методов, с помощью которых были достигнуты требуемые свойства спецификации требований к программному обеспечению системы безопасности. Строгость метода неформально ранжируется по шкале от R1 до R3, где R1 - наименее строгий и R3 - самый строгий метод.
R1 | Без объективных критериев приемки или с ограниченными объективными критериями приемки. Например, тестирование методом "черного ящика", основанное на профессиональном суждении, полевые испытания |
R2 | С объективными критериями приемки, которые могут дать высокий уровень уверенности в том, что необходимое свойство достигнуто (исключения должны быть определены и обоснованы); например, тест или аналитические методы с метриками охвата, охват таблицами контрольных проверок |
R3 | С объективным систематическим рассуждением о том, что необходимое свойство достигнуто. Например, формальное доказательство, демонстрирующее соблюдение архитектурных ограничений, которые гарантируют свойство |
- | Данный метод не относится к этому свойству |
Для каждого метода, обеспечивающего конкретное свойство, определяется одно из ранжированных значений R1/R2/R3 в зависимости от уровня строгости этого метода.