ГОСТ Р МЭК 61508-7—2007
- совокупности подпрограмм должны строиться так. чтобы обеспечивать несколько уровней программных
модулей;
- размеры подпрограмм следует ограничить некоторыми конкретными значениями, обычно от двух до че
тырех размеров экрана.
- подпрограммы должны иметь только один вход и один выход;
- программные модули должны взаимодействовать с другими программными модулями через свои интер
фейсы. где используются глобальные или общие переменные, которые должны быть хорошо структурированы,
доступ к ним должен находиться под контролем, и их использование в каждом конкретном случав должно быть
обосновано;
- все интерфейсы программных модулей должны быть полностью документированы;
- все интерфейсы программных модулей должны содержать только необходимые для их функционирова
ния параметры.
Литература:
Structured Design — Fundamentals of a Discipline of Computer Program and Systems Design. E. Yourdon. L. L.
Constantine, Prentice-Hall. 1979. ISBN 0-13-854471-9.
C.2.10 Использование доверительных/проверенных программных модулей и их компонентов
П р и м е ч а н и я
1 Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.4).
2 Математический аппарат, обеспечивающий числовые оценки данного метода, приведен в приложении D.
Аналогичный метод и статистический подход изложены также в В.5.4.
Цель: исключение такого проектирования компонентов программных модулей и аппаратных средств, кото
рое вызывало бы необходимость их интенсивных повторных проверок или перепроектирования для каждого
нового применения. Использование преимущества проектов, которые не были формально или строго провере
ны. но для которых имеется продолжительный опыт эксплуатации.
Описание: данный метод проверяет наличие в программных модулях и компонентах систематических оши
бок проектирования и/или эксплуатационных отказов. Только в редких случаях использование доверительных
программных модулей и компонентов (то есть проверенных в эксплуатации) достаточно в качестве единственного
средства, гарантирующего достижение необходимого уровеня полноты безопасности. Для сложных компонентов
со многими возможными функциями (например операционной системы) важно установить, какая из функций
достаточно проверена при ее использовании. Например, в случаях использования процедуры
самотестирования для обнаружения сбоев аппаратных средств, если в период эксплуатации не появилось
отказов аппаратных средств, процедуру самотестирования на обнаружение сбоев нельзя рассматривать как
проверенную на практи ке.
Конкретный компонент или программный модуль может быть достаточно доверительным, если он уже
испытан на конкретный уровень полноты безопасности или соответствует следующим критериям:
- спецификация на программный модуль или компонент не менялась;
- программные модули или компоненты эксплуатировались в различных областях применения:
- продолжительность срока эксплуатации — не менее года;
- продолжительность эксплуатации соответствует уровню полноты безопасности или соответствующему чис
лу запросов; демонстрируется частота отказов, не связанная с безопасностью, менее.
1СН на один запрос (в год) с 95 %-ным уровнем доверия, при необходимости 300 эксплуатационных про
хождений (в год):
10~5 на один запрос (в год) с 99.9 %-ным уровнем доверия, при необходимости 690000 эксплуатационных
прохождений (в год);
- весь опыт эксплуатации соотнесен с известным профилем запросов функций программного модуля для
гарантии того, что увеличивающийся опыт эксплуатации действительно приводит к увеличению знаний о поведе
нии программного модуля, связанного с соответствующим профилем запроса.
- отказы, не связанные с безопасностью.
П р и м е ч а н и е — Отказ, некритичный для безопасности в одном контексте, может быть критичен для
безопасности вдругом контексте, и наоборот.
Для проверки соответствия критерию компонента или программного модуля должны быть задокументиро
ваны:
- точная идентификация каждой системы и ев компонент, включая номера версий (как для программных,
так идля аппаратных средств);
- идентификация пользователей и продолжительность их работы;
- продолжительность эксплуатации системы;
- процедура выбора систем, применяемых пользователями, и случаев ее применения:
- процедуры обнаружения и регистрации отказов и устранения сбоев.
42