ГОСТ Р МЭК 61508-3—2012
Практически методы, использующиеся при разработке спецификации требований к программному обеспе
чению системы безопасности, выбирают с учетом ряда практических ограничений (см. 7.1.2.7) в дополнение к
собственным возможностям методов. Такие ограничения могут включать в себя:
- непротиворечивость и втаимодоиашяюишй характер выбранных методов, языков и инструментов для всего
цикла разработки;
- полностью ли понимают разработчики используемые ими методы, языки и инструменты;
- насколько хорошо адаптированы методы, языки и инструменты к конкретным проблемам, для разработки
которых они используются.
Таблица С.1 гложет использоваться для сравнения относительной эффективности конкретных методов по та
блице А.1 в достижении требуемых свойств на стадии жизненного цикла «спецификация требований к программно му
обеспечению системы безопасности» и в то же времядля факторизации практических ограничений конкретного
разрабатываемого проекта.
Например, для верификации и подтверждения соответствия использование формального метода (R3) более
обосновано, чем полуформального метода (R2). однако другие ограничения проекта (например, доступность слож
ных компьютерных инструментов поддержки или узкоспециализированное представление формальной нотации)
могут повлиять на выбор полуформального подхода.
Таким образом, требуемые свойства таблицы С.1 могут служить основанием для аргументированного и прак
тического сравнения альтернативных методов, которые рекомендованы в таблице А.1 и предназначены для раз
работки спецификации требований к программному обеспечению системы безопасности. Или (в общем случае)
при рассмотрении требуемых свойств, перечисленных в соответствующей таблице приложения С для конкретной
стадии жизненного цикла, может быть сделан аргументированный выбор метода из нескольких альтернативных,
рекомендуемых приложением А.
Но особо следует обратить внимание на то. что вследствие систематической природы поведения, свойства
приложения С. возможно, не будут достигнуты или строго доказаны. Скорее свойства являются целью, к которой
необходимо стремиться. Достижение этих целей может даже потребовать компромиссов между различными свой
ствами. например, между проектом защиты и его простотой.
Наконец, вдополнение к определению критериев R1/R2i’R3 полезно в качестве рекомендации сформировать
неформальную связь между ростом уровня строгости от R1 к R3 и ростом уверенности в корректности программ
ного обеспечения. Так как рекомендация является общей и неформальной, необходимо стремиться к следующим
минимальным уровням строгости, когда приложение А требует соответствующий ему УПБ;
УПБСтрогость R
V2R1
3R2 (если возможно)
4Наиболее высокая возможная строгость
С.1.3 Метод использования — 2
Хотя приложение А рекомендует конкретные методы, разрешено также применятьдругие методы и средства,
если они соответствуют требованиям и целям стадии жизненного цикла.
Уже было отмечено, что на стойкость к систематическим отказам программного обеспечения влияет много
факторов, и невозможно создать алгоритм для выбора и объединения методов, гарантирующий достижение тре
буемых свойств для любого заданного применения.
Может существовать несколько эффективных способов обеспечить требуемые свойства и следует признать,
что разработчики системы могут быть в состоянии представить альтернативные доказательства. Информация в
таблицах настоящего приложения может использоваться в качестве основы для весомого аргумента, чтобы обо
сновать выбор методов, отсутствующих в таблицах приложения А.
С.2 Свойства для систематической полноты безопасности
Руководящие указания, представленные в настоящем стандарте и [5]. определяют конкретные методы обе
спечения свойств систематической полноты безопасности и формирования убедительных доказательств. Если
метод не способствует достижению свойства, то в таблицах настоящего приложения это показано как «—». Если
метод гложет отрицательно влиять на некоторые свойства и положительно — на другие, то приводится пояснение в
примечании к соответствующей таблице.
54