ГОСТР 53195.5—2010
Методы выбираются таким образом, что ошибки могли быть устранены и влияние отказов могло быть
минимизировано для получения требуемой полноты безопасности.
П р и м е ч а н и е — Должны быть учтены предупреждения об исправлении ошибочных данных, приведен
ные в В.3.2. и об отрицательных рекомендациях применения этого метода, приведенные в ГОСТ Р 53195.4
(таблицаА.2. пункт 5).
Более подробное описание данного метода’средства приведено в [169).
В.3.13 Динамическая реконфигурация
П р и м е ч а н и е — На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обеспечение функционирования системы, несмотря на внутренний сбой.
Описание: логическая архитектура системы должна быть такой, чтобы ев можно было отобразить в под
множестве доступных ресурсов системы. Архитектура должна быть способна к обнаружению отказа на физичес
ком уровне и далее к повторному преобразованию логической архитектуры в ограниченные функционирующие
ресурсы. Несмотря на то что эта концепция, в основном, традиционно ограничена только восстановлением неис
правных модулей АС. она применима также к сбоям в ПО при наличии достаточной «избыточности времени
прогона» для повторного выполнения программы или наличии достаточных избыточных данных, которые обес
печивают незначительное влияние отдельного и изолированного отказа.
Этот метод должен рассматриваться на первом этапе проектирования системы.
Более подробное описание данного мвгода/средства приведено в [169].
В.4 Инструменты разработки и языки программирования
В.4.1 Строготипизированныеязыки программирования
П р и м е ч а н и е — Ссыпка на данные методы^средства приведена в ГОСТ Р 53195.4 (таблица А.З).
Цель: снижение вероятности ошибок путем использования языка, который обеспечивает высокий уровень
проверки компилятором.
Описание: если скомпилирован строго типизированный язык программирования, то проводится много
проверок по использованию типов переменных, например в вызовах процедур и доступе к внешним данным.
Компиляция может оказаться безуспешной, и будет выдано сообщение об ошибке при любом использовании
типа переменных, которое не соответствует заранее установленным правилам.
Подобные языки обычно позволяют определять установленные пользователем типы данных на основе
типовданных базового языка (например, целое число, реальное число). Затем эти типы могут быть использованы
также, как и базовый тип. Вводятся строгие проверки для гарантирования использования правильного типа. Эти
проверки проводятся для всей программы, даже если она построена из отдельных скомпилированных модулей.
Данные проверки гарантируют также, что число и тип аргументов конкретной процедуры соответствуют числу и
типу аргументов при ее вызове, даже если к ней обращаются из отдельно скомпилированных программных
модулей.
Строго типизированные языки обычно обеспечивают другие аспекты проверенной на практике техники
проектирования ПО, например легко анализируемые структуры управления («if», «then»», «else», «do», «while»
и т. n.). которые приводят к четко структурированным программам.
Типичными примерами строго типизированных языков являются С ++. Delphi. Java. ML. Pascal. ADA.
Modula 2.
Более подробное описание данного метода/средства приведено в [170—173].
В.4.2 Подмножество языка
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.З).
Цель: снижение вероятности внесения программных ошибок и повышение вероятности обнаружения ос
тавшихся ошибок.
Описание: проводится исследование языка для определения программных конструкций, подверженных
ошибкам либо сложных для анализа, например при использовании методов статического анализа. После этого
определяется языковое подмножество, которое исключает такие конструкции.
Более подробное описание данного метода/средства приведено в [173].
£3.4.3Сертифицированные средства
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.З).
Цель: предоставление разработчику на различных этапах разработки ПО необходимых сертифицирован
ных инструментальных средств для обеспечения конкретной степени уверенности в корректности результатов.
Описание: сертификацию инструментальных средств в общем случав допускается проводить независимо,
как правило, в национальных органах по сертификации по независимому набору критериев, установленных обыч
но в национальных или международных стандартах. В идеальном случае инструментальные средства, применя
емые на всех стадиях разработки (спецификация, проектирование, кодирование, тестирование и оценка соответ
ствия). а также используемые а управлении конфигурацией, должны быть сертифицированы.
53