Приложение В (справочное). Свойства стойкости к систематическим отказам программного обеспечения

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

Свойства стойкости к систематическим отказам программного обеспечения

В.1 Введение

Учитывая большое число факторов, влияющих на стойкость к систематическим отказам ПО, невозможно создать алгоритм, включающий в себя методы и средства и обеспечивающий необходимый результат для любого заданного применения. Целями настоящего приложения являются:

- предоставление руководства по выбору конкретных методов из приложений А и Б для обеспечения на систематической основе возможностей ПО;

- оказание помощи в обосновании использования методов, которые не перечислены в приложениях А и Б.

Настоящее приложение является дополнением к приложениям А и Б.

В.1.1 Структура приложения В, связанная с приложениями А и Б

Выходные данные каждой стадии ЖЦ СБ ПО определены в таблице А.1 приложения А. Например, рассмотрена спецификация требований к безопасности ПО.

В таблице А.1 приложения А рекомендованы конкретные методы разработки спецификации требований к СБ ПО:

Метод/средство *	Структурный элемент ГОСТ 34332.5-2021	УПБ 1	УПБ 2	УПБ 3	УПБ 4
1 Альтернативные методы
1а Полуформальные методы	Таблица Б.7	Р	Р	ОР	ОР
1б Формальные методы	Б.2.2, В.2.4	- -	Р	Р	ОР
2 Прямая прослеживаемость между требованиями к системе безопасности и требованиями к ПО системы безопасности	В.2.11	Р	Р	ОР	ОР
3 Обратная прослеживаемость между требованиями к системе безопасности и предполагаемыми потребностями безопасности	В.2.11	Р	Р	ОР	ОР
4 Компьютерные средства разработки спецификаций для поддержки перечисленных выше соответствующих методов/средств	Б.2.4	Р	Р	ОР	ОР

В таблице В.1 отмечено, что спецификация требований к безопасности ПО характеризуется свойствами, приведенными в ГОСТ 34332.5-2021 (приложение Е) и представленными ниже.

В.1.2 Свойства

В.1.2.1 Полнота охвата ПО потребностей безопасности.

В.1.2.2 Корректность охвата ПО потребностей безопасности.

В.1.2.3 Отсутствие ошибок в спецификации, включая отсутствие неоднозначности.

В.1.2.4 Четкость требований к системе безопасности.

В.1.2.5 Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, и функций безопасности, реализуемых ПО Э/Э/ПЭ СБЗС системы.

В.1.2.6 Способность обеспечения проведения оценки и подтверждения соответствия.

В таблице В.1 также ранжированы неформальные шкалы эффективности R1/R2/R3 конкретных методов для достижения вышеперечисленных свойств.

По методу/средству 1а "Полуформальные методы" учитывают свойства следующим образом:

- В.1.2.1 - R1 "Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в проблемной области";

- В.1.2.2 - R1 "Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в проблемной области"; R2 "Верификация спецификации согласно критериям охвата";

- В.1.2.3 - R1 "Метод и нотация, которые помогают предотвратить или обнаружить внутреннюю несогласованность, неверное поведение или математически несовместимые выражения"; R2 "Проверка спецификации согласно критериям охвата"; R3 "Проверка спецификации, основанная на систематическом анализе и/или систематическом предотвращении определенных типов отказов внутри спецификации";

- В.1.2.4 - R1 "Определяемая нотация, ограничивающая возможность для непонимания"; R2 "Применение пределов сложности в спецификации";

- В.1.2.5 - "- -";

- В.1.2.6 - R1 "Определяемая нотация, снижающая неоднозначность в спецификации".

При ранжировании по шкалам R1-R3, а также по методу "- -" учитывают следующие свойства:

R1 - без объективных критериев приемки или с ограниченными объективными критериями приемки, например: тестирование методом "черного ящика", основанное на профессиональном суждении; полевые испытания;

R2 - с объективными критериями приемки, гарантирующими с высокой долей вероятности, что необходимое свойство достигнуто (исключения должны быть определены и обоснованы), например: тест или аналитические методы с метриками охвата, охват таблицами контрольных проверок;

R3 - с объективным систематическим обоснованием того, что необходимое свойство достигнуто, например: формальное доказательство, демонстрирующее соблюдение архитектурных ограничений, которые гарантируют свойство;

- - - данный метод не относится к этому свойству

То, что можно связать со свойствами спецификации требований к ПО Э/Э/ПЭ СБЗС системы (как основание для обеспечения безопасности ПО), зависит от строгости методов, с помощью которых были достигнуты необходимые свойства спецификации требований к ПО системы. Строгость метода неформально ранжируется по шкалам R1, R2, R3, причем R1 - наименее строгий метод и R3 - наиболее строгий метод.

Для каждого метода, обеспечивающего конкретное свойство, определяют одно из ранжированных значений R1/R2/R3 в зависимости от уровня строгости этого метода.

Пример - Метод 1а "Полуформальные методы" определяют по шкалам R1 "Определяемая нотация, ограничивающая возможность для непонимания"; R2 "Применение пределов сложности в спецификации".

В данном примере применение полуформального метода со строгостью R1 обеспечивает ограниченную нотацию, которая улучшает точность выражений, и увеличение строгости до R2, дополнительно ограничивая сложность спецификации, что в противном случае могло бы привести к путанице.

Метод/средство	Свойства
	1	2	3	4	5	6
1а Полуформальные методы				R1 Определяемая нотация, ограничивающая возможность для непонимания. R2 Применение пределов сложности в спецификации

В.1.3 Используемый метод 1

Общие рекомендации

Если можно убедительно продемонстрировать, что необходимые свойства достигнуты при разработке спецификации требований к безопасности СБ ПО, то есть основания полагать, что спецификация требований к безопасности СБ ПО является адекватной основой для разработки ПО с достаточным уровнем систематической полноты безопасности.

Каждый из методов, представленных в таблице А.1 приложения А, в той или иной степени обеспечивает выполнение одного или большего числа вышеупомянутых свойств по таблице В.1, которые относятся к спецификации требований к СБ ПО.

Несмотря на то что в таблице А.1 приложения А рекомендованы конкретные методы, эти рекомендации не являются нормативными. Фактически из положений приложения А ясно следует, что "учитывая большое число факторов, влияющих на стойкость к систематическим отказам ПО, невозможно создать алгоритм, включающий методы и средства и обеспечивающий необходимый результат для любого заданного применения".

Выбор методов, используемых при разработке спецификации требований к ПО Э/Э/ПЭ СБЗС систем, обусловлен рядом практических ограничений (см. 7.1.2.7) в дополнение к возможностям методов. Такие ограничения могут включать в себя:

- непротиворечивость и взаимодополняющий характер выбранных методов, языков и инструментов для всего цикла разработки;

- неполное понимание разработчиками используемых ими методов, языков и инструментов;

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

Таблица В.1 может быть использована для сравнения относительной эффективности конкретных методов, представленных в таблице А.1 приложения А, с целью достижения требуемых свойств на стадиях (этапах) ЖЦ ПО СБЗС системы с учетом практических ограничений для конкретного разрабатываемого проекта.

Например, для верификации и подтверждения соответствия использование формального метода (R3) более обосновано, чем полуформального метода (R2), однако другие ограничения проекта (например, доступность сложных компьютерных инструментов поддержки или узкоспециализированное представление формальной нотации) могут повлиять на выбор полуформального подхода.

Таким образом, требуемые свойства, представленные в таблице В.1, могут служить основанием для аргументированного и практического сравнения альтернативных методов, которые рекомендованы в таблице А.1 приложения А и предназначены для разработки спецификации требований к ПО системы безопасности. В общем случае при рассмотрении требуемых свойств, перечисленных в таблице В, для конкретной стадии ЖЦ может быть сделан аргументированный выбор применения нескольких альтернативных методов, рекомендованных в приложении В.

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

Наконец, в дополнение к определению критериев R1/R2/R3 полезно в качестве рекомендации сформировать неформальную связь между ростом уровня строгости от R1 к R3 и ростом уверенности в корректности ПО. Так как рекомендация является общей и неформальной, необходимо стремиться к следующим минимальным уровням строгости, когда согласно условиям приложения А требуется соответствующий ему УПБ:

- УПБ 1/2 - R1;

- УПБ 3 - R2 (если возможно);

- УПБ 4 - наиболее высокая возможная строгость.

В.1.4 Используемый метод 2

Несмотря на то что в приложении А рекомендованы конкретные методы, также допускается применять другие методы и средства при условии соблюдения требований и целей стадии (этапа) ЖЦ.

Ранее отмечено, что на систематическую способность ПО влияют многие факторы, и невозможно представить такой алгоритм для выбора и комбинирования методов, который гарантирует в любом конкретном приложении достижение определенных свойств.

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

В.2 Свойства для систематической полноты безопасности

В соответствии с руководящими указаниями, представленными в настоящем стандарте и ГОСТ 34332.2, определяют конкретные методы обеспечения выполнения свойств систематической полноты безопасности и формирования убедительных доказательств. Если метод не способствует достижению свойства, то в таблицах настоящего приложения это показано как "- -". Влияние метода как отрицательное, так и положительное на свойства. Альтернативные методы обозначены буквами "а" и "б", следующими за порядковым номером данного метода в левой колонке таблиц.

Таблица В.1 - Свойства для обеспечения систематической полноты безопасности. Спецификация требований к СБ ПО (см. 7.2 и таблицу А.1 приложения А)

Метод/средство	Свойство
	Полнота охвата потребностей безопасности программным обеспечением	Корректность охвата потребностей безопасности программным обеспечением	Отсутствие ошибок в спецификации, включая отсутствие неоднозначности	Четкость требований к системе безопасности	Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, и функций безопасности, реализуемых ПО системы безопасности	Способность обеспечения проведения оценки и подтверждения соответствия
1а Полуформальные методы	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в проблемной области	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в предметной области. R2 Верификация спецификации согласно критерию охвата	R1 Метод и нотация, которые помогают предотвратить или обнаружить внутреннюю несогласованность, отсутствующее поведение или математически несовместимые выражения. R2 Проверка спецификации согласно критериям охвата. R3 Проверка спецификации, основанная на систематическом анализе и/или систематическом предотвращении определенных типов отказов внутри спецификации	R1 Определяемая нотация, ограничивающая возможность для непонимания. R2 Применение пределов сложности в спецификации	- -	R2 Определяемая нотация, уменьшающая неоднозначность в спецификации
1б Формальные методы	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в предметной области	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в предметной области. R2 Верификация спецификации согласно критерию охвата. R3 Гарантия правильности на ограниченных аспектах поведения	R1 Метод и нотация, которые помогают предотвратить или обнаружить внутреннюю несогласованность, неверное поведение или математически несовместимые выражения. R2 Проверка спецификации согласно критериям охвата. R3 Проверка спецификации, основанная на систематическом анализе и/или систематическом предотвращении определенных типов отказов внутри спецификации	- - Примечание - Может усложнить достижение этого свойства, если метод не является дружественным для приложения или не зависящим от предметной области	- -	R1 Уменьшение неоднозначности в спецификации
2 Прямая прослеживаемость между спецификацией требований к безопасности системы и требованиями к безопасности ПО	R1 Уверенность в том, что спецификация требований к безопасности программного обеспечения получает системные требования к безопасности	- -	- -	- -	- -	- -
3 Обратная прослеживаемость между требованиями к системе безопасности и предполагаемыми потребностями в безопасности	- -	R1 Уверенность в том, что спецификация требований к ПО Э/Э/ПЭ СБЗС системы не содержит ненужной сложности	- -	R1 Прослеживаемость потребностей безопасности УО способствует его доступности	- -	- -
4 Компьютерные средства разработки спецификаций для поддержки соответствующих перечисленных выше методов/средств	R1 Инкапсуляция знаний в предметной области УО и программной среды. R2 Если перечень вопросов, которые необходимо учесть в таблице контрольных проверок, определен, обоснован и охватывает проблему	R1 Методы функционального моделирования. R2 Функциональное моделирование в соответствии с определенными и обоснованными критериями охвата	R2 Синтаксическая и семантическая проверки, чтобы убедиться в том, что соответствующие правила выполнены	R1 Анимация или просмотр спецификации	R1 Идентификация связанных и не связанных с безопасностью функций	R1 Помощь в прослеживаемости и в охвате. R2 Измерение прослеживаемости и охвата

Таблица В.2 - Свойства систематической полноты безопасности. Проектирование и разработка ПО. Разработка архитектуры ПО (см. 7.4.3, структурный элемент, приведенный в таблице А.2 приложения А)

Метод/средство	Свойство
	Полнота спецификации требований к безопасности ПО	Корректность спецификации требований к ПО Э/Э/ПЭ СБЗС системы	Отсутствие ошибок проекта	Простота и понятность	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость	Защита от отказов по общей причине, вызванной одним событием
1 Обнаружение ошибок	- -	- -	- -	- - Может быть осложнено достижение этого свойства	R1 Мониторинг потока логических программ обеспечивает предсказуемость	- -	R1 (R2, если цели покрытия определены, обоснованы и выполнены	R1 или - -
2 Коды обнаружения ошибок	- -	- -	- -	- - Достижение этого свойства может быть сложным	R1 Достижение этого свойства может быть сложным	- -	R1 (R2, если цели покрытия определены, обоснованы и выполнены). Эффективен для конкретных областей применения, например для передачи данных	R1 Эффективность для конкретных областей применения, например для передачи данных
3а Программирование с проверкой ошибок	- -	R2 Проверка соответствия с помощью постусловий детальным требованиям	- -	R2 Ограничения входного пространства с помощью предусловий	R2 Проверка выходов, которые должны быть ожидаемыми либо приемлемыми, с помощью постусловий	R2 Ограничение входного пространства и необходимого тестируемого пространства с помощью предусловий	R3 Эффективность для конкретных отказов	R3 Эффективность для конкретных отказов
3б Разнообразные методы мониторинга (с независимостью между монитором и контролируемой функцией на одном компьютере)	- -	- -	R2 Реализация минимальных требований безопасности посредством независимого контроля	R2 Неявное разнообразие благодаря независимому контролю	R2 Реализация минимальных требований безопасности с использованием простого способа независимого контроля	R2 Реализация минимальных требований безопасности с использованием простого способа независимого контроля	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 (R2, если цели охвата определены, обоснованы и выполнены)
3в Разнообразные методы мониторинга (с разделением между монитором и контролируемым компьютером)	- -	- -	R2 Реализация минимальных требований безопасности посредством независимого контроля	R2 Неявное разнообразие, обеспечиваемое независимым контролем	R2 Реализация минимальных требований безопасности посредством простого способа независимого контроля	R2 Реализация минимальных требований безопасности посредством независимого контроля	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 (R2, если цели охвата определены, обоснованы и выполнены)
3г Разнообразная избыточность, реализующая те же требования к спецификации требований к безопасности ПО	- -	- -	- -	- - Примечание - Может осложнить достижение этого свойства, если оно выполнено в одном и том же исполняемом ПО	- -	- -	R1, если отказ одной программы не оказывает негативного влияния на другие. R2, если цели охвата определены, обоснованы и выполнены. Отсутствие защиты от ошибок в спецификации требований	R1 Если отказ одной программы не оказывает негативного влияния на другие. R2 Если цели охвата определены, обоснованы и выполнены. Не защищает от ошибок в спецификации требований
3д Функционально разнообразная избыточность, реализующая различные требования к безопасности ПО (обычно с применением датчиков, работающих на разных физических принципах)	- -	- -	R1	- - Примечание - Достижение этого свойства может быть сложным, если реализуется в одной исполнимой программе	- -	- -	R1, если отказ одной программы не оказывает негативного влияния на другие	R1, если отказ одной программы не оказывает негативного влияния на другие. Защита от ошибок в спецификации требований
3е Восстановление предыдущего состояния	- -	- -	- - Примечание - Достижение этого свойства может быть сложным	- -	- - Примечание - Достижение этого свойства может быть сложным	- -	R2	R1 (R2, если цели охвата определены, обоснованы и выполнены)
3ж Проектирование ПО, не сохраняющего состояние (или проектирование ПО, сохраняющее ограниченное описание состояния)	R2, если несохранение или сохранение ограниченного описания состояния предусмотрено в требованиях к Э/Э/ПЭ СБЗС системе	R2, если несохранение или сохранение ограниченного описания состояния предусмотренно требованиями к Э/Э/ПЭ СБЗС системе	R2, если несохранение или сохранение ограниченного описания состояния предусмотрено в требованиях к Э/Э/ПЭ СБЗС системе	R1, R2, если определены, обоснованы и выполнены ограничения для определенного возможного числа состояний	R1, R2, если определены, обоснованы и выполнены ограничения для определенного возможного числа состояний	R1, R2, если определены, обоснованы и выполнены цели верификации/тестирования возможных состояний	R1, если это приводит к самовосстановлению проекта. R2, если определены, обоснованы и выполнены цели самовосстановления	R1, если это приводит к самовосстановлению проекта. R2, если определены, обоснованы и выполнены цели самовосстановления
4
4а Механизмы повторных попыток парирования сбоя	- -	- -	- -	- -	Достижение этого свойства может быть сложным	- -	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 (R2, если цели охвата определены, обоснованы и выполнены)
4б Постепенное отклонение функций	- -	- -	- - Примечание - Достижение этого свойства может быть сложным	- -	- -	- -	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 (R2, если цели охвата определены, обоснованы и выполнены)
5 Исправление ошибок методами искусственного интеллекта	- -	- - Примечание - Достижение этого свойства может быть сложным	- - Примечание - Достижение этого свойства может быть сложным	- - Примечание - Достижение этого свойства может быть сложным	- - Примечание - Достижение этого свойства может быть сложным	- - Примечание - Достижение этого свойства может быть сложным	- -	- -
6 Динамическая реконструкция	- -	- - Примечание - Достижение этого свойства может быть сложным	- - Примечание - Достижение этого свойства может быть сложным	- - Примечание - Достижение этого свойства может быть сложным	- - Примечание - Достижение этого свойства может быть сложным	- - Примечание - Достижение этого свойства может быть сложным	- -	- -
7 Модульный подход	- -	R1 [R2, если цели декомпозиции (модульности) определены, обоснованы и выполнены]. В противном случае только R1	R1, если отсутствие конкретных типов ошибок в проекте может быть верифицировано независимо для каждого модуля. R3, если отсутствие конкретных типов ошибок в проекте может быть строго обосновано при проектировании модуля	R1 (R2, если цели декомпозиции определены, обоснованы и выполнены)	R1, (R2, если цели декомпозиции определены, обоснованы и выполнены)	R1, (R2, если цели декомпозиции определены, обоснованы и выполнены)	R1 Если модули, на которые не влияет отказ модуля, способствуют смягчению отказа/восстановлению отказавшего модуля. R3 Если допущение появления конкретных отказов может быть строго обосновано	R1, если модули, на которые могут влиять внешние события и которые могут одновременно повлиять на несколько каналов, выявлены и полностью проверены. R3, если появление конкретных внешних событий может быть строго обосновано
8 Использование доверительных/проверенных элементов ПО (при наличии)	- -	R1, R2, R3, если элемент вносит существенный вклад в выполнение требований к системе безопасности и правильно используется	R1, R2, R3 Повторное использование проверенных на практике элементов. Такая возможность должна быть оправдана для элемента	R1 Модульный подход декомпозирует полную сложность на четко понятные блоки	R1, R2, R3 Элементы, проверенные на практике	- -	R1, R2 (R2, если возможности отказоустойчивости легко обеспечиваются элементом и правильно используются или вокруг элемента создается слой защиты)	R1, R2 (R2, если защита от внешних событий, которая может повлиять на одновременное использование нескольких каналов, легко обеспечивается элементом и правильно используется или если вокруг элемента создается слой защиты)
9 Прямая прослеживаемость между спецификацией требований безопасности ПО и архитектурой ПО	R1 Архитектура соответствует требованиям безопасности ПО	- -	- -	- -	- -	- -	- -	- -
10 Обратная прослеживаемость между архитектурой ПО и спецификацией требований к ПО Э/Э/ПЭ СБЗС системы	- -	R1 Уверенность в том, что архитектура излишне не усложнена	- -	- -	- -	- -	- -	- -
11а Методы структурных диаграмм	- -	R1	- -	R1 (графические описания легче понять)	- -	R1 (структурируемые проекты легче верифицировать и тестировать)	- -	- -
11б Полуформальные методы	R1 Дружественные или зависящие от предметной области метод спецификации и нотация	R1 Дружественные или зависящие от предметной области метод спецификации и нотация	R2 Может выявить внутреннюю несогласованность, или неверное поведение, или математически некорректные выражения	- -	R2 (предоставление свидетельств по предсказуемости)	R2 (предоставление свидетельств по внутренней согласованности модели проекта)	- -	- -
11в Методы формального проектирования и усовершенствования	R1 Дружественные и зависящие от предметной области методы спецификации и нотация	R1 Точное определение ограниченных аспектов поведения, которые должны соответствовать предметной области	R3 Возможность выявления внутренней несогласованности, или неверного поведения, или математически некорректных выражений	- - Примечание - Достижение этого свойства может быть сложным	R2 Предоставление доказательства по предсказуемости	R2	- -	- -
11г Автоматическая генерация ПО	R1, если исполняемое ПО автоматически генерируется из спецификации требований или из конструкции, которая была показана как полная. R2, если показано, что инструменты генерации имеют соответствующую предысторию	R1, если исполняемое ПО автоматически генерируется из спецификации требований или из конструкции, которая была показана как полная. R2, если показана соответствующая предыстория инструментов	R1, если средства генерации гарантируют исключение определенных внутренних ошибок конструкции. R2, если показано, что инструменты генерации имеют соответствующую предысторию	- -	- -	- -	R1, R2, R3, если способность к отказоустойчивости генерируется автоматически	- -
12 Компьютерные средства разработки спецификаций и проектирования	R1 Инкапсуляция знаний в проблемной области УО и программной среды. R2, если определена, обоснована и охвачена таблица контрольных проверок, а также учтены ее проблемы	R1 Осуществление обратной прослеживаемости требований методов функционального моделирования. R2 Функциональное моделирование согласно определенным и обоснованным критериям охвата	R2 Семантические и синтаксические проверки для гарантирования того, что соответствующие правила выполнены	R1 Анимация и просмотр	- -	R2 Семантические и синтаксические проверки для гарантирования того, что соответствующие правила выполнены	- -	- -
13
13а Циклическое поведение с гарантированным максимальным временем цикла	- -	R1 Решение вопросов синхронизации в спецификации. R3, если максимальное время цикла определено	R1 Решение вопросов синхронизации в спецификации. R3, если максимальное время цикла определено	- -	R1 Решение вопросов синхронизации в спецификации. R3, если максимальное время цикла определено	R1 Решение вопросов синхронизации в спецификации. R3, если максимальное время цикла определено строгим выводом	- -	- -
13б Архитектура с временным распределением	R3 Полнота гарантируется распределением (только для временных характеристик)	R3 Корректность гарантируется распределением (только для временных характеристик)	R3 Строгая гарантия от внутренних временных сбоев синхронизации	R1 Определенная нотация значительно снижает недоразумение (предсказуемость как подход)	R3 Неблагоприятное влияние: полное разделение во времени, отсутствие интерференции	R3 Существенное снижение усилий, необходимых для тестирования и сертификации системы	R2 Прозрачная реализация отказоустойчивости	R3 Отсутствие помех внешних прерываний расписанию, которое уделяет приоритетное внимание критическим значениям для безопасности
13в Управление событиями с гарантированным максимальным временем отклика	- -	- -	- -	R1 Архитектуры, управляемые событиями, могут препятствовать пониманию	R1 Архитектуры, управляемые событиями, могут препятствовать пониманию	R1 Более предсказуемое тестирование	- -	- -
14 Статическое выделение ресурсов	R1	R1	R1	R1 Более понятное проектирование	R2 С архитектурой, определяющей использование ресурсов	R1 Более предсказуемое тестирование	- -	- -
15 Статическая синхронизация доступа к разделяемым ресурсам	- -	R1 Обеспечение предсказуемости при доступе к ресурсам	R1 (R3, если поддерживается строгими выводами, обезличивающими корректность синхронизации) м	R1 Более понятное проектирование	R1, если поддерживается строгими выводами, обезличивающими корректность синхронизации	- -	- -	- -

Таблица В.3 - Свойства систематической полноты безопасности. Проектирование и разработка ПО. Инструментальные средства поддержки и языки программирования (см. 7.4.4 и таблицу А.3 приложения А)

Метод/средство	Свойство
	Поддержка разработки с требуемыми свойствами	Четкость работы и функциональность инструментальных средств	Корректность и воспроизводимость результата
1 Выбор подходящего языка программирования	R2, если строгая типизация, ограниченное преобразование типов. R3, если определены семантики для формального вывода	- -	- -
2 Строго типизированные языки программирования	R2	- -	- -
3 Подмножество языка	R2 В зависимости от выбранного подмножества	R1	R2 В зависимости от выбранного подмножества
4а Сертифицированные средства и сертифицированные трансляторы	- -	R2	R2
4б Инструментальные средства, заслуживающие доверия на основании опыта использования	R1, если класс обнаруживаемых программных ошибок определяется систематически. R2, если существует объективное доказательство подтверждения соответствия эффективности инструментального средства	R1, если инструментальное средство поддержки не является специальным для данной предметной области. R2, если инструментальное средство поддержки создано специально для данной предметной области	R1, R2, если существует объективное доказательство подтверждения соответствия эффективности инструментального средства, например набор средств для подтверждения соответствия компиляторов

Таблица В.4 - Свойства систематической полноты безопасности. Проектирование и разработка программного обеспечения. Подробный проект (включает проектирование программной системы, проектирование программных модулей и кодирование) (см. 7.4.5 и 7.4.6)

Метод/средство	Свойство
	Полнота спецификации требований к ПО Э/Э/ПЭ СБЗС системы	Корректность спецификации требований к безопасности ПО	Отсутствие ошибок проекта	Простота и четкость	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость	Отсутствие отказов по общей причине
1в Формальный метод и методы доработки	- -	R3	R3	Примечание - Может усложнить достижение этого свойства	R3 Предоставление доказательств предсказуемости	R2	- -	- -
2 Средства автоматизированного проектирования	R2 Автоматизированное средство разработки спецификации, применяющее семантические и синтаксические проверки и гарантирующее, что соответствующие правила удовлетворены	R1	R2 Автоматизированное средство разработки спецификации, применяющее семантические и синтаксические проверки и гарантирующее, что соответствующие правила удовлетворены	- -	- -	R2 Основанные на CASE-технологии средства поддержки тестового охвата и статической проверки	- -	- -
3 Программирование с защитой	- -	- -	- -	Примечание - Достижение этого свойства может быть сложным	Примечание - Достижение этого свойства может быть сложным	- -	R1, (R2, если цели охвата определены, обоснованы и выполнены)	R1, (R2, если цели охвата определены, обоснованы и выполнены)
4 Прямая прослеживаемость между спецификацией требований к ПО системы безопасности и проектом ПО	R1 Соответствие проекта требованиям к ПО системы безопасности	- -	- -	- -	- -	- -	- -	- -

Таблица В.5 - Свойства систематической полноты безопасности. Проектирование и разработка ПО. Тестирование и интеграция программных модулей (см. 7.4.7, 7.4.8 и таблицу А.5 приложения А)

Метод/средство	Свойство
	Полнота тестирования и интеграции в соответствии со спецификацией проекта программного обеспечения	Корректность тестирования и интеграции в соответствии со спецификацией проекта программного обеспечения (удовлетворительное выполнение)	Воспроизводимость	Точно определенная тестируемая конфигурация
1 Вероятностное тестирование	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
2 Динамический анализ и тестирование	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
3 Регистрация и анализ данных	- -	R1	R1 Способствует согласованности процедур тестирования	R2, если журналы записей об отказах/тестах включают в себя подробную информацию о серии базовых программ
4 Функциональное тестирование и тестирование методом "черного ящика"	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
5 Тестирование рабочих характеристик	- -	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
6 Тестирование, основанное на модели (МВТ)	R2 МВТ позволяет на ранних стадиях выявлять неоднозначности в спецификации и проекте. МВТ используют, начиная с требований. R3, если при моделировании использованы формальные выводы и генерация тестовых примеров (TCG)	R2 Оценка результатов и комплектов регрессионных тестов - ключевое преимущество МВТ. R3, если применять формальные модели, то можно получить объективные данные по охвату тестами	R3 МВТ (с TCG) направлено на автоматическое выполнение сгенерированных тестов	R2 МВТ работает автоматически, тестируемая конфигурация должна быть точно определена; выполнение сгенерированных тестов подобно тестированию методом "черного ящика" с возможностью измерения уровня охвата исходного кода
7 Тестирование интерфейса	- -	R1 (R2, если необходимые выходы определены, обоснованы и выполнены)	- -	- -
8 Управление тестированием и средства автоматизации	R1 (R2, если цели охвата тестами определены, обоснованы и выполнены)	- -	R1 Автоматизация, способствующая согласованности	R2 Обеспечение воспроизводимости тестирования
9 Прямая прослеживаемость между спецификацией проекта ПО и спецификациями тестирования модуля и интеграции	R1 Соответствие спецификации тестов требованиям к ПО системы безопасности	- -	- -	R2 Гарантия четкой основы тестируемых требований
10 Формальная верификация	R3, если для создания тестовых примеров используется формальный вывод для того, чтобы показать, что все аспекты проекта реализованы	R3 Предоставление объективных данных о выполнении всех требований к ПО системы безопасности	R1, если средства поддержки недоступны. R2, если инструмент поддерживается

Таблица В.6 - Свойства систематической полноты безопасности. Интеграция программируемых электронных устройств (ПО и АС) (см. 7.5 и таблицу А.6 приложения А)

Метод/средство	Свойство
	Полнота интеграции в соответствии со спецификацией проекта	Корректность интеграции в соответствии со спецификацией проекта (удовлетворительное выполнение)	Воспроизводимость	Точно определенная конфигурация интеграции
1 Функциональное тестирование и тестирование методом "черного ящика"	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
2 Тестирование выполнения	- -	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
3 Прямая прослеживаемость между требованиями проектирования системы и ПО к интеграции программных и аппаратных средств и спецификациями тестирования интеграции программных и аппаратных средств	R1 Соответствие спецификаций тестирования интеграции программных и аппаратных средств требованиям интеграции	- -	- -	R2 Гарантия четкой основы тестируемых требований

Таблица В.7 - Свойства систематической полноты безопасности. Программные аспекты подтверждения соответствия СБ ПО (см. 7.7 и таблицу А.7 приложения А)

Метод/средство	Свойство
	Полнота подтверждения соответствия согласно спецификации проекта программного обеспечения	Корректность подтверждения соответствия согласно спецификации проекта программного обеспечения (удовлетворительное выполнение)	Воспроизводимость	Подтверждение соответствия точно определенной конфигурации
1 Вероятностное тестирование	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
2 Моделирование процесса	R1	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	R2 Определение внешнего окружения
3 Функциональное тестирование и тестирование методом "черного ящика"	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
4 Прямая прослеживаемость между спецификацией требований к ПО системы безопасности и планом подтверждения соответствия ПО системы безопасности	R1 План подтверждения соответствия ПО системы безопасности охватывает требования к ПО системы безопасности	- -	- -	R2 Гарантия четкой основы тестируемых требований
5 Обратная прослеживаемость между планом подтверждения соответствия ПО системы безопасности и спецификацией требований к ПО системы безопасности	- -	R1 Отсутствие излишней сложности в плане подтверждения соответствия ПО системы безопасности	- -	R2 Гарантия четкой основы тестируемых требований

Таблица В.8 - Свойства систематической полноты безопасности. Верификация ПО (см. 7.9 и таблицу А.9 приложения А)

Метод/средство	Свойство
	Полнота верификации в соответствии с предыдущей стадией	Корректность верификации в соответствии с предыдущей стадией (удовлетворительное выполнение)	Воспроизводимость	Верификация точно определенной конфигурации
1 Формальное доказательство	- -	R3	- -	- -
2 Анимация спецификации и тестирования	R1	R1	- -	- -
3 Статический анализ	- -	R1/R2/R3 (строгость может меняться от возможностей подмножества языка до формального анализа)	- -	- -
4 Динамический анализ и тестирование	R1 (R2, если цели охвата структурированием определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	- -	- -
5 Прямая прослеживаемость между спецификацией проекта ПО и планом верификации (включающим в себя верификацию данных) ПО	R1 Соответствие плана верификации ПО (включающего в себя верификацию данных) требованиям к ПО системы безопасности	- -	- -	R2 Гарантия четкой основы тестируемых требований
6 Обратная прослеживаемость между планом верификации (включающим верификацию данных) ПО и спецификацией проекта ПО	- -	R1 Отсутствие излишней сложности в плане верификации ПО (включающем в себя верификацию данных)	- -	R2 Гарантия четкой основы тестируемых требований
7 Численный анализ в автономном режиме	- -	R1 Высокая степень в ожидаемости точности вычислений. (R2 при объективных критериях приемки. R3, если используется совместно с объективным систематическим доказательством, обосновывающим критерии приемки)	- -	- -

Таблица В.9 - Свойства систематической полноты безопасности. Оценка функциональной безопасности (см. раздел 8 и таблицу А.10 приложения А)

Метод/средство	Свойство
	Полнота оценки функциональной безопасности в соответствии с требованиями настоящего стандарта	Корректность оценки функциональной безопасности в соответствии с проектными спецификациями (удовлетворительное выполнение)	Доступное для анализа решение всех выявленных проблем	Возможность модификации оценки функциональной безопасности после изменения проекта без необходимости проведения тщательной переработки оценки	Воспроизводимость	Своевременность	Точно определенная конфигурация
1 Таблица контрольных проверок	R1	R1	R1	- -	R1	- -	- -
2 Таблицы решений (таблицы истинности)	R1	R2	- -	- -	R2	- -	- -
3 Анализ отказов	R2	R2	R1 (анализ отказов основан на согласованных списках отказов)	- -	R1 (анализ отказов основан на согласованных списках отказов)	- -	- -
4 Анализ отказов по общей причине различного ПО (если различное ПО используется)	R2	R2	R1 (анализ отказов по общей причине основан на согласованных списках источников общих причин)	- -	R1 (анализ отказов по общей причине основан на согласованных списках источников общих причин)	- -	- -
5 Структурные схемы надежности	R1	R1	- -	- -	- -	- -	- -
6 Прямая прослеживаемость между требованиями раздела 8 и планом оценки функциональной безопасности ПО	R1 Соответствие плана оценки функциональной безопасности ПО требованиям раздела 8	- -	- -	- -	- -	- -	- -

Таблица В.10 - Подробные свойства. Стандарты проектирования и кодирования (см. таблицу В.1)

Метод/средство	Свойство
	Полнота спецификации требований к программному обеспечению системы безопасности	Корректность спецификации требований к программному обеспечению системы безопасности	Отсутствие ошибок проекта	Простота и четкость	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость/обнаружение отказов	Отсутствие отказов по общей причине
1 Использование стандартов кодирования для сокращения вероятности ошибок	- -	- -	R1	R1 Запрет отдельных конструкций языка	R1	R1	- -	- -
2 Неиспользование динамических объектов	- -	- -	R1/R2/R3, в зависимости от используемого языка	- -	R1/R2, в зависимости от используемого языка	R1/R2, в зависимости от используемого языка	- -	- -
3а Неиспользование динамических переменных	- -	- -	R1/R2/R3, в зависимости от используемого языка	- -	R1/R2, в зависимости от используемого языка	R1/R2, в зависимости от используемого языка	- -	- -
3б Проверка создания динамических переменных при выполнении программы	- -	- -	R1/R2/R3, в зависимости от используемого языка	- -	R1/R2, в зависимости от используемого языка	R1/R2, в зависимости от используемого языка	- -	- -
4 Ограниченное использование прерываний	- -	- -	R1/R2, в зависимости от используемого языка	R1 Повышение четкости логики и последовательностей событий	R1/R2, в зависимости от используемого языка	R/R2, в зависимости от используемого языка	- -	- -
5 Ограниченное использование указателей	- -	- -	R1/R2, в зависимости от используемого языка	R1 Повышение четкости логики	R1/R2, в зависимости от используемого языка	R1/R2, в зависимости от используемого языка	- -	- -
6 Ограниченное использование рекурсий	- -	- -	R1/R2, в зависимости от используемого языка	- -	R1/R2, в зависимости от используемого языка	R1/R2, в зависимости от используемого языка	- -	- -
7 Неиспользование неструктурированного управления в программах, написанных на языках высокого уровня	- -	- -	R1/R2, в зависимости от используемого языка	R1 Повышение четкости логики	R1/R2, в зависимости от используемого языка	R1/R2, в зависимости от используемого языка	- -	- -
8 Неиспользование автоматического преобразования типов	- -	R2 Предотвращение погрешностей округления	R2 Предотвращение погрешностей округления	R1	R1	- -	- -	- -

Таблица В.11 - Подробные свойства. Динамический анализ и тестирование (см. таблицу Б.2 приложения Б)

Метод/средство	Свойство
	Полнота тестирования и верификации в соответствии со спецификацией проекта программного обеспечения	Корректность тестирования и верификации в соответствии со спецификацией проекта программного обеспечения (удовлетворительное выполнение)	Воспроизводимость	Точно определенная тестируемая и верифицируемая конфигурация
1 Выполнение тестового примера, связанного с анализом граничных значений	- -	R1 (R2, если заданы объективные критерии для граничных значений)	- -	- -
2 Выполнение тестового примера, связанного с предполагаемой ошибкой	- -	R1	- -	- -
3 Выполнение тестового примера, связанного с введением ошибки	- -	R1	- -	- -
4 Выполнение тестового примера, сгенерированного на основе модели	R2 Использование МВТ начиная с требований и выявление на ранних стадиях ошибок при проектировании и разработке ПО. R3, если при моделировании использованы формальные выводы и генерация тестовых примеров (TCG)	R2 Оценка результатов и комплектов регрессионных тестов - ключевое преимущество МВТ, что облегчает понимание последствий указанных требований. R3, если применены формальные модели, то можно получить объективные данные по охвату тестами	R3 Использование МВТ (с TCG) направлено на автоматическое выполнение сгенерированных тестов	R2 Работа МВТ в автоматическом режиме; тестируемая конфигурация должна быть точно определена; выполнение сгенерированных тестов подобно тестированию методом "черного ящика" с возможностью измерения уровня охвата исходного кода
5 Моделирование реализации	- -	R1 (R2, если цель - требования к производительности)	- -	- -
6 Разделение входных данных на классы эквивалентности	R1, если профиль входных данных четко определен и прост в управлении своей структурой	R1, если разбиения, вероятнее всего, не содержат нелинейности, т.е. все члены класса являются действительно эквивалентными	- -	- -
7 Структурное тестирование	- -	R1, (R2, если цель - требования к производительности)	- -	- -

Таблица В.12 - Подробные свойства. Функциональное тестирование и проверка методом "черного ящика" (см. таблицу В.3)

Метод/средство	Свойство
	Полнота тестирования, интеграции и подтверждения соответствия согласно спецификациям проекта	Корректность тестирования интеграции и подтверждения соответствия согласно спецификациям проекта (удовлетворительное выполнение)	Воспроизводимость	Точно определенная конфигурация для тестирования, интеграции и подтверждения соответствия
1 Выполнение тестового примера на основе причинно-следственных диаграмм	R1	R1	- -	- -
2 Выполнение тестового примера, сгенерированного на основе модели (МВТ)	R2 Тестирование, основанное на модели и обеспечивающее автоматическую генерацию эффективных контрольных примеров/процедур, путем использования модели системных требований и заданной функциональности. МВТ способствует раннему выявлению ошибок и пониманию последствий указанных требований. R3, если при моделировании использованы формальные выводы и генерация тестовых примеров (TCG)	R2 МВТ основано на моделях (в основном функциональных/поведенческих), формируемых на основании требований. R3, если применены формальные модели, то можно получить объективные данные по охвату тестами	R3 Использование МВТ (с TCG) направлено на автоматическое выполнение сгенерированных тестов	R2 Работа МВТ в автоматическом режиме, тестируемая конфигурация должна быть точно определена
3 Макетирование/анимация	- -	R1	- -	- -
4 Разделение входных данных на классы эквивалентности, включая анализ граничных значений	R1, если профиль входных данных четко определен и прост в управлении своей структурой	R1, если разбиения, как правило, не содержат нелинейности, т.е. все члены класса являются действительно эквивалентными	- -	- -
5 Моделирование процесса	- -	R1	- -	R2 Определение внешнего окружения

Таблица В.13 - Подробные свойства. Анализ отказов (см. таблицу В.4)

Метод/средство	Свойство
	Полнота оценки функциональной безопасности в соответствии с требованиями настоящего стандарта	Корректность оценки функциональной безопасности в соответствии с проектными спецификациями (удовлетворительное выполнение)	Доступное для анализа решение всех выявленных проблем	Возможность модификации оценки функциональной безопасности после изменения проекта без необходимости проведения тщательной переработки оценки	Воспроизводимость	Своевременность	Точно определенная конфигурация
1а Причинно-следственные диаграммы	R2	R2	- -	- -	- -	- -	- -
1в Анализ методом дерева событий	R2	R2	- -	- -	- -	- -	- -
2 Анализ методом дерева отказов	R2	R2	- -	- -	- -	- -	- -
3 Анализ функциональных отказов ПО	R2	R2	- -	- -	- -	- -	- -

Таблица В.14 - Подробные свойства. Моделирование (см. таблицу В.5)

Метод/средство	Свойство
	Полнота подтверждения соответствия согласно спецификации проекта программного обеспечения	Корректность подтверждения соответствия согласно спецификации проекта программного обеспечения (удовлетворительное выполнение)	Воспроизводимость	Точно определенная конфигурация подтверждения соответствия
1 Диаграммы потоков данных	- -	R1	- -	- -
2а Метод конечных автоматов	R3	R3	- -	- -
2б Формальные методы	R3	R3	- -	- -
2в Моделирование во времени сетями Петри	- -	R1	- -	- -
3 Моделирование реализации	- -	R1	- -	- -
4 Макетирование/анимация	- -	R1	- -	- -
5 Структурные диаграммы	- -	R1	- -	- -

Таблица В.15 - Подробные свойства. Тестирование характеристик реализации (см. таблицу В.6)

Метод/средство	Свойство
	Полнота подтверждения соответствия согласно спецификации проекта программного обеспечения	Корректность подтверждения соответствия согласно спецификации проекта программного обеспечения (удовлетворительное выполнение)	Воспроизводимость	Точно определенная конфигурация подтверждения соответствия
1 Проверка на критические нагрузки и стресс-тестирование	- -	R1 (R2, если установлены объективные цели)	- -	- -
2 Ограничения на время ответа и объем памяти	- -	R1 (R2, если установлены объективные цели)	- -	- -
3 Требования к реализации	- -	R1 (R2, если установлены объективные цели)	- -	- -

Таблица В.16 - Подробные свойства. Полуформальные методы (см. таблицу В.7)

Метод/средство	Свойство
	Полнота спецификации требований к ПО Э/Э/ПЭ СБЗС системы	Корректность спецификации требований к ПО Э/Э/ПЭ СБЗС системы	Отсутствие ошибок в проекте	Четкость требований к системе безопасности	Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, с СБЗС системой, реализуемой ПО	Простота и четкость	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость/обнаружение отказов	Отсутствие отказов по общей причине от внешних событий
1 Логические диаграммы/диаграммы функциональных блоков	R2	R2	R2	- -	- -	R1	R2	- -	- -	R1
2 Диаграммы последовательности	R2	R2	R2	- -	- -	R1	R2	- -	- -	R2
3 Диаграммы потоков данных	R1	R1	R1	- -	- -	R1 Использование при обработке транзакций	- -	- -	- -	R1
4а Конечные автоматы/диаграммы переходов	R2	R2	R2	- -	- -	R1 Математически полная спецификация последовательности событий	R2	- -	- -	R2
4б Моделирование во времени сетями Петри	R2	R2	R2	- -	- -	R1 Определение взаимодействия в реальном времени	R2	- -	- -	R2
5 Модели данных "сущность-связь-атрибут"	R1	R1	R^	- -	- -	R1	- -	- -	- -	R1
6 Диаграммы последовательности сообщений	R2	R2	R2	- -	- -	R1	R2	- -	- -	R2
7 Таблицы решений и таблицы истинности	R2	R2	R2	- -	- -	R1 (для комбинационной логики)	R2	- -	- -	R2

Таблица В.17 - Свойства для систематической полноты безопасности. Статический анализ (см. таблицу В.8)

Метод/средство	Свойство
	Полнота верификации в соответствии с предыдущей стадией	Корректность верификации в соответствии с предыдущей стадией (удовлетворительное выполнение)	Воспроизводимость	Точно определенная верифицируемая конфигурация
1 Анализ граничных значений	- -	R1 (R2, если заданы объективные критерии для граничных значений)	- -	- -
2 Таблица контрольных проверок	- -	R1	- -	R1
3 Анализ потоков управления	- -	R1	- -	- -
4 Анализ потоков данных	- -	R1	- -	- -
5 Предположение ошибок	- -	R1	- -	- -
6
6а Формальные проверки, включая конкретные критерии	R2	R2	- -	R2
6б Сквозной контроль (программного обеспечения)	R1	R1	- -	R1
7 Тестирование на символьном уровне	- -	R2 (R3, если применяется для формально определенных предусловий и постусловий и выполняется инструментальным средством, использующим математически строгий алгоритм)	- -	- -
8 Анализ проекта	R2	R1 [R2 (с объективными критериями)]	- -	R2
9 Статический анализ выполнения программы с ошибкой	- -	R1 (R3 для определенных классов ошибок, если выполняется инструментальным средством, использующим математически строгий алгоритм)	- -	- -
10 Временной анализ выполнения при наихудших условиях	R1	R3	- - - -	R2

Таблица В.18 - Подробные свойства. Модульный подход (см. таблицу В.8)

Метод/средство	Свойство
	Полнота спецификации требований к программному обеспечению системы безопасности	Корректность спецификации требований к программному обеспечению системы безопасности	Отсутствие ошибок проекта	Простота и четкость	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость/обнаружение отказов	Отсутствие отказов по общей причине
1 Ограничение размера программного модуля	- -	- -	R1	R1	R1	R1	- -	- -
2 Управление сложностью ПО	- -	- -	R1	R1	R1	R1	- -	- -
3 Ограничение доступа/инкапсуляция информации	- -	- -	R1	R1	R1	R1	- -	- -
4 Ограниченное число параметров/фиксированное число параметров подпрограммы	- -	- -	R1	R1	R1	R1	- -	- -
5 Одна точка входа и одна точка выхода в каждой подпрограмме и функции	- -	- -	R1	R1	R1	R1	- -	- -
6 Полностью определенный интерфейс	- -	- -	R2	R1	R1	R1	- -	- -