Как описывать программы по ГОСТ 19.402 и архитектурным подходам
Описание программы по ГОСТ 19.402–78 — это структурированный документ, необходимый для формализации архитектуры программного обеспечения. В статье приведён пример оформления описания по ЕСПД, показано, как использовать подходы архитектурной декомпозиции и зачем это нужно бизнесу, разработке и сопровождению.
Назначение описания программы
Документ “Описание программы” по ГОСТ 19.402–78 используется для фиксации состава, структуры и взаимодействий компонентов системы. Он необходим для:
- оформления архитектурного описания в составе технического проекта (в т.ч. по ГОСТ 34);
- включения в регламентированную документацию ЕСПД;
- подготовки к сертификации, передаче на сопровождение или масштабированию системы.
Описание программы — это документ, фиксирующий иерархию, состав и внутренние связи программных компонентов. Он играет важную роль на стыке концептуального проектирования и начала реализации:
- формализует архитектурную декомпозицию;
- описывает взаимодействие между модулями и подсистемами;
- создаёт основу для декомпозиции задач, тестирования, сопровождения и передачи проекта.
Он особенно полезен в средах, где важна нормативная фиксация: от внутренних стандартов до включения в состав технического проекта, РД или сертификационных документов.
Когда и зачем писать
Документ составляется после проектирования архитектуры (HLD) и перед началом низкоуровневой разработки (LLD). Он расшифровывает техническое задание (ТЗ) или SRS, связывает смысловые цели с конкретной структурой программных модулей и формирует основу для:
- планирования задач;
- проектирования интерфейсов;
- подготовки отчётных и приёмочных материалов.
Что включает описание
В соответствии с ГОСТ 19.402–78 структура документа “Описание программы” включает следующие разделы:
Введение
Общие сведения — фиксируются наименование программы, обозначение документа и разработчика, а также формулировать назначение самого документа. Он уточняет, что описание предназначено для проектирования, сопровождения, экспертизы и разработки ПО, и включает иерархию компонентов, архитектурные связи и термины. Раздел не должен дублировать «Назначение программы» или «Область применения», а служит вводной точкой для понимания состава документа и его роли в жизненном цикле ПО.
Область применения — уточняется, в каком контексте и для каких целей применяется программа: в каких системах, кем используется, какие задачи решает. Это позволяет задать границы ответственности и понять, для чего предназначен программный продукт — и для чего не предназначен.
Основание для разработки — указываются документы и решения, послужившие формальной основой для начала разработки: техническое задание, договор, приказ или внутреннее распоряжение.
Такое введение помогает систематизировать понимание роли программы в составе более широкого решения, установить контекст для анализа архитектуры и обеспечить юридическую и техническую прослеживаемость разработки.
Назначение программы как элемента автоматизированной системы или как самостоятельного программного средства
Уточнение задач, решаемых программой
При наличии — место программы в составе программного комплекса
Структура программы
В разделе описывается состав программы, включая подсистемы, модули и компоненты (подпрограммы, процедуры и т. д.). Приводится иерархическая структура с указанием подчинённости и связей между элементами.
В оригинале по ГОСТу – "описание логической структуры".
Назначение и функции компонентов
Для каждого модуля и его составных частей приводятся:
Наименование
Назначение — какую задачу решает
Реализуемые функции — какие операции выполняет
Взаимодействия и зависимости (связи) — с какими другими модулями взаимодействует
Форма представления: таблицы, структурированные описания.
Допускается включение особенностей реализации:
используемые языки программирования
сторонние библиотеки и зависимости
специфика компиляции и сборки
шаблоны проектирования и архитектурные приёмы
Приложения: Диаграммы и визуализация
- Архитектурные схемы описывают используемые технические средства, DFD (Data Flow Diagrams), UML-диаграммы;
- API и внешние интерфейсы;
- Примеры кода, шаблоны, словари;
- Состав компонентов (SBOM).
Используются для ясности, особенно при передаче проекта внешним командам.
Приложения: Дополнительные элементы (опционально)
Сведения о связи с внешними системами, API.
Перечень сторонних компонентов, лицензий (SBOM).
Дополнительные схемы, словари, фрагменты кода.
Связь с другими документами
Описание структуры:
- Не дублирует BRD/Vision —, а конкретизирует архитектуру, формируя мост между ТЗ (ГОСТ 34.602), SRS (IEEE 830) и LLD.
- Конкретизирует ТЗ (ГОСТ 34.602) — в части архитектурных требований.
- Уточняет SRS (System Requirements Specification) — добавляя детализацию архитектуры.
- Может быть частью Технического проекта (ТП) — оформляется в разделе архитектуры.
- Является основой для LLD и РД — даёт структуру, на основе которой пишется реализация.
Также оно может использоваться как ориентир при планировании задач в таск-трекерах: блоки задач мапятся на модули из документа, что повышает покрытие и снижает риски забытых компонентов.
Что это даёт бизнесу
• Управляемость: декомпозированные блоки упрощают планирование и ответственность.
• Прозрачность: удобно для внешней экспертизы, аудита, техподдержки.
• Повторяемость: шаблон можно использовать повторно в новых проектах.
• Готовность к сертификации: соответствует ГОСТ, ISO, требованиям ИТ-госконтрактов.
Что дальше
Хотите внедрить описание программного обеспечения по ГОСТ 19.402–78 или подготовить документацию для сертификации и сопровождения?
Мы предоставим шаблоны, проверим структуру, оформим пример, соответствующий стандарту ЕСПД.
Свяжитесь с нами — мы поможем сделать документацию источником устойчивости, а не формальностью.
08.05.2025 (обн. 27.05.2025)