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