Технический проект по ГОСТ 34: что входит и как проверить состав

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

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

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

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

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

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

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

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

Пояснительная записка

Что входит кроме пояснительной записки

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

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

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

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

Рабочая связка выглядит так: ТЗ задает требования и критерии приемки → технический проект выбирает решение → описание программы раскрывает состав и поведение ПО → испытания проверяют результат → эксплуатационные документы помогают сопровождать систему после запуска. Если эти роли смешать, комплект становится объемным, но плохо проверяемым.

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

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