ГОСТ Р МЭК 61508-7—2012
Приложение С
(справочное)
Анализ методов и средств достижения полноты безопасности программного обеспечения
(см. МЭК 61508-3)
С.1 Общие положения
Анализ методов, содержащийся в настоящем приложении, не следует рассматривать как полный или ис
черпывающий.
С.2 Требования и детальное проектирование
П р и м е ч а н и е — Соответствующие методы и средства приведены в В.2.
С.2.1 Структурные методы
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы А.2 иА.4).
С.2.1.1 Общие положения
Цель. Основная цель методов анализа структуры (структурных методов) состоит в обеспечении качества
разработки программного обеспечения. Данные методы в основном используются на ранних стадиях жизненного
цикла создаваемой системы. Структурные методы используют как точные, так и интуитивные процедуры и нотации
(поддерживаемые компьютерами), а также определяют и позволяют документально оформлять требования и воз
можности реализации в логической последовательности и структурированным способом.
Описание. Существует достаточно много структурных методов. Некоторые из них созданы для выполнения
традиционных функций обработки данных и транзакций, другие в большей степени ориентированы на процессы
управления и задачи реального времени (для систем, реализующих такие задачи, характеристика безопасности
является более критичной, чем для других систем). UML (см. С.3.12) содержит много примеров структурирован
ных нотаций.
Структурные методы можно считать «интеллектуальными инструментами», предназначенными для обоб
щенного восприятия и структуризации конкретной проблемы или системы. К их основным свойствам относятся:
- использование логики в рассуждениях и выводах, декомпозиция сложной проблемы на управляемые стадии;
- анализ и документирование всей системы, включая окружающую среду, а также разрабатываемую систему;
- декомпозиция данных и функций в разрабатываемой системе;
- использование контрольных таблиц, то есть списков типов объектов, нуждающихся в анализе;
- малая интеллектуальная перегрузка — простота, интуитивность и практичность при представлении про
блемы или системы:
- акцентирование на разработке структурной модели создаваемой системы с поддержкой CASE средств
для полноты метода.
Нотации, используемые для анализа и документирования проблем и объектов системы (например на основе
процессов и потоков данных), ориентированы на строгость, однако нотации для выражения функций обработки,
выполняемых этими обьектами, являются более неформальными. В то же время некоторые методы частично
используют формальные нотации (например регулярные выражения или конечные состояния автоматов). Увели
чение точности нотации не только повышает уровень понимания, но и обеспечивает возможность автоматизиро
ванной обработки.
Другим преимуществом структурных нотаций является их наглядность, которая позволяет пользователю ин
туитивно проверять возможности спецификации или проекта при неполной информации.
Данный краткий обзор описывает несколько структурных методов более подробно.
Литература:
Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education. 2003, ISBN 0201596202,
9780201596205.
Software Design. D. Budgen. Pearson Education, 2003, ISBN 0201722194. 9780201722192.
C.2.1.2 Управляемое представление требований (CORE)
Цель. Обеспечение требований, определений и формулировок.
Описание. Данный метод должен устранить пробел между потребителем/конечным пользователем и ана
литиком. Он не основан на математически строгой теории, а является средством коммуникации. Метод CORE
создандля представления требований, а не для спецификаций. Данный метод является структурированным, все его
представления проходят через различные уровни уточнений. Метод CORE используется для широкого круга
проблем, учитывает сведения об окружающей среде, в которой система функционирует, а также различные точ ки
зрения разных типов пользователей. Метод CORE содержит руководящие материалы и тактические подходы для
того, чтобы упростить сложный проект. Такое упрощение может быть скорректировано либо явным образом
идентифицировано и документально оформлено. Таким образом, спецификации могут быть неполными, однако
выявленные нерешенные проблемы и области высокого риска должны быть рассмотрены при последующем
проектировании.
34