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

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

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

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

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

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

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

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

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

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

• Архитектурные и функциональные схемы. Структура системы, подсистемы, связи, размещение компонентов и точки интеграции.
• Постановки задач. Логика задач, входные и выходные данные, периодичность, сценарии взаимодействия и ограничения.
• Программа и методика испытаний. Что проверяется, какими сценариями, кто принимает результат и какие протоколы нужны.
• Организационные и эксплуатационные документы. Роли, регламенты, инструкции администратора и пользователя, порядок сопровождения.
• Документы по надежности и экономике. Расчеты, обоснования, риски, требования к отказоустойчивости и восстановлению.

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

• Есть границы системы. Понятно, что входит в проект, что остается внешней системой и где проходят интерфейсы.
• Архитектура связана с требованиями. Основные решения объясняют, как будут выполнены функции и ограничения из ТЗ.
• Есть traceability matrix. Требования связаны с проектными решениями, задачами разработки, испытаниями и приемкой.
• Есть risk register. Зафиксированы технические, организационные, интеграционные и эксплуатационные риски, а также способы их контроля.
• Описаны данные и обмены. Есть форматы, источники, получатели, периодичность, ошибки и ответственность за качество данных.
• Понятна проверка результата. Есть ПМИ или основание для нее, критерии приемки и список подтверждающих протоколов.

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

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

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

• согласовать общий состав документации на ПО;
• подготовить описание программы;
• проверить архитектурную рамку проектирования системы.