Состав программных средств: что описывать в документации

Состав программных средств нужен, чтобы показать, какие программные компоненты входят в систему, что является собственной разработкой, какие внешние продукты используются и какая среда нужна для работы. Это помогает не смешивать поставку, инфраструктуру и зависимости.

Страница нужна при подготовке технического проекта, комплекта по ГОСТ 34, передачи системы в эксплуатацию, аудита состава поставки или оценки влияния стороннего ПО. Она особенно полезна, когда в проекте есть несколько сервисов, библиотек, интеграций и окружений.

Если система состоит из одного небольшого приложения и пары стандартных зависимостей, можно ограничиться коротким перечнем компонентов, версий и среды запуска. Но даже такой перечень должен отличать собственный код от сторонних средств и инфраструктуры.

• список собственных программных компонентов;
• перечень стороннего ПО, библиотек и платформ;
• версии и ограничения лицензий, если они важны;
• среды выполнения и инфраструктурные зависимости;
• ответственных за обновления и сопровождение;
• границы поставки: что передается, а что остается внешней зависимостью.

В собственные компоненты включают приложения, сервисы, модули, скрипты, обработчики, интеграционные адаптеры и другие части, которые команда разрабатывает или передает как результат проекта. Для каждого компонента полезно указать назначение, репозиторий, версию и связь с требованиями.

Стороннее ПО лучше выносить отдельно: базы данных, брокеры сообщений, серверы приложений, библиотеки, фреймворки, инструменты мониторинга и внешние сервисы. Это помогает увидеть лицензионные, инфраструктурные и эксплуатационные ограничения.

Среда эксплуатации не равна составу собственных программных средств. Ее нужно описывать как условия работы: операционная система, контейнерная платформа, сеть, доступы, переменные окружения, внешние endpoints и требования к ресурсам.

• включать в один список собственные модули, библиотеки, серверы и ручные процедуры;
• не указывать версии и владельцев компонентов;
• считать внешнюю платформу частью поставки без проверки договора;
• забывать инструменты миграции, настройки и служебные скрипты;
• не связывать состав с репозиториями и инструкциями запуска.

Готовый документ должен отвечать на вопрос: из чего состоит программная часть системы, что передается заказчику, от каких внешних средств зависит работа и что нужно поддерживать после запуска.