Разработка автоматизированных систем (АС), автоматизированных систем управления (АСУ), автоматизированных информационных систем (АИС) или программного обеспечения (ПО) регламентируется в первую очередь комплексом межгосударственных стандартов семейства ГОСТ 34.ххх. Они регулируют создание, документацию и жизненный цикл автоматизированных систем (АС) и АСУ ТП. ГОСТы устанавливают стадии создания, виды документов (ТЗ, проект) и требования к ним, особенно при госзакупках.

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

Основные стандарты включают:

• ГОСТ 34.601-90 — стадии и этапы жизненного цикла АС.
• ГОСТ 34.201-2020 — виды, комплектность и обозначение документов.
• ГОСТ 34.602-2020 — техническое задание (ТЗ) на создание.

Основные положения и этапы по ГОСТ 34:

• Применение: Обязателен для государственных и крупных корпоративных информационных систем.
• Стадии создания: Включает обследование объекта, разработку ТЗ, эскизный/технический проект, рабочую документацию, ввод в эксплуатацию.
• Документация: Строго регламентирует состав документации, обеспечивая стандартизацию проектирования.
• Ключевые отличия: ГОСТ 34 ориентирован на системы (включая персонал, процессы), в отличие от ГОСТ 19 (Единая система программной документации — ЕСПД), который сфокусирован на программном обеспечении.

ГОСТ был разработан в 80-е годы прошлого столетия, однако широко применяется до сих пор и активно обновляется в соответствии с современными реалиями. В частности, пять из девяти стандартов, упоминающихся в данной статье, были обновлены в течение последних 5–6 лет. Основные изменения коснулись замены/исключения устаревших терминов и ссылок, произошла корректировка требований. Например, для технического задания (ТЗ) появились новые требования о порядке обучения персонала и пользователей. Для текстовых документов — об использовании шрифтов со свободной лицензией. И, кстати, теперь нет никаких АСУ и АИС, есть только АС.

В принципе, следование ГОСТ дело добровольное, за исключением случаев, когда этого требуют нормы законодательства. Однако на практике требование следовать ГОСТу в разработке ПО и оформлении документации исходит по большей части от государственных учреждений и предприятий с государственным участием. Потому что соответствие стандарту гарантирует, что заказчик получит систему (и не менее важно – документацию) с предсказуемыми характеристиками. Разработчик в свою очередь извлекает выгоду от соответствия ГОСТу — прозрачные критерии приемки и четкие границы ответственности. Для коммерческой организации следование ГОСТу облегчает создание документации, так как имеется общепринятая структура и рекомендации по содержанию разделов документа, что помогает логически правильно организовать подачу материала, а использование легитимизированных терминов позволяет избежать недопонимания с клиентом. 

ГОСТ 34.601—90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания»

В данном стандарте устанавливаются следующие стадии и этапы жизненного цикла АС.

1. Формирование требований
2. Обследование объекта;
3. Формулировка требований пользователя;
4. Оформление отчета.
5. Разработка концепции
6. Изучение объекта;
7. Проведение НИР;
8. Выбор варианта концепции;
9. Оформление отчета.
10. Техническое задание
11. Разработка и утверждение ТЗ.
12. Эскизный проект
13. Разработка предварительных решений;
14. Разработка документации.
15. Технический проект
16. Проектные решения;
17. Документация;
18. Документация на комплектующие;
19. Задания на проектирование.
20. Рабочая документация
21. Разработка рабочей документации;
22. Адаптация программ.
23. Ввод в действие
24. Подготовка, монтаж, пусконаладочные работы;
25. Предварительные испытания;
26. Опытная эксплуатация;
27. Приемочные испытания.
28. Сопровождение
29. Гарантийное обслуживание;
30. Послегарантийное обслуживание.

Существующая практика позволяет опускать или объединять некоторые этапы разработки. Так, например, этапы «Формирование требований» и «Разработка концепции», часто никак не фигурируют в документации, хотя их результаты, такие как схемы бизнес-процессов, «пользовательские истории» и т. п. ложатся в основу ТЗ. Практикуется также объединение этапов «Эскизный проект», «Технический проект» и «Рабочая документация» под общим названием: «Технорабочее проектирование». Вполне допускается параллельное выполнение этапов, что приближает каскадную модель разработки к гибким методологиям Agile, но с сохранением четких точек контроля.

ГОСТ 34.602—2020 «Информационные технологии.
Комплекс стандартов на автоматизированные системы. Техническое задание на создание
автоматизированной системы»

В данном стандарте определяются состав, содержание и правила оформления ТЗ, указывается, какие обязательные разделы должно включать ТЗ по ГОСТу:

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

Далее подробно расписывается, какие именно данные содержатся в каждом из разделов.

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

ГОСТ 34.201—2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»

Регламентирует порядок разработки автоматизированных систем, устанавливает требования к видам, наименованию, комплектности и обозначению документов, разрабатываемых на стадиях создания АС. В п. 4.1 указывается, что перечень наименований разрабатываемых документов и их комплектность определяется в техническом задании на создание АС, либо на начальных этапах ее создания, что делает весь регламент опциональным. К данному стандарту очень близок по содержанию ГОСТ 19.101—2024 «Единая система программной документации. Виды программ и программных документов», описывающий основные требования к документам, сопровождающим процесс разработки ПО на каждом этапе.

ГОСТ 34.603—92 «Информационная технология. Виды испытаний автоматизированных систем»

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

1. Предварительные испытания. Проводятся с целью проверки работоспособности системы и готовности к опытной эксплуатации. Испытания проводятся на объекте заказчика после монтажа и пусконаладки. По результатам составляется Протокол испытаний и Акт о приемке в опытную эксплуатацию (если все прошло хорошо).
2. Опытная эксплуатация. Определяются реальные характеристики приложения, проводится проверка готовности персонала, в реальных условиях выявляются ошибки и несоответствия ТЗ. На данном этапе персонал заказчика ведет журнал, в котором фиксируются сбои, ошибки и замечания. По результатам составляется Акт о завершении опытной эксплуатации и допуске системы к приемочным испытаниям.
3. Приемочные испытания. Проводятся с целью окончательной проверки соответствия АС требованиям ТЗ, наличия и критичности ошибок. Испытания проводятся утвержденной комиссией с участием представителей заказчика и разработчика согласно критериям и в порядке, описанным в соответствующем разделе ТЗ. В результате подписывается Акт приемки в постоянную эксплуатацию. В случае недостатков составляется протокол с перечнем необходимых доработок.

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

ГОСТ Р 2 .105—2019 «Единая система конструкторской документации. Общие требования к текстовым документам»

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

Отдельно стоит упомянуть ГОСТ Р 59853—2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения». По сути — это словарь, на который следует ориентироваться при выборе терминов в процессе создания документации. Вообще при разработке технической документации рекомендуется в самом начале документа размещать раздел «Используемые термины, определения и сокращения» во избежание разночтений. И если в документации используются термины, входящие в перечень ГОСТ Р 59853—2021, — они должны быть употреблены исключительно в общепринятом значении.

В этом же контексте интересны ГОСТ 34.321—96 «Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными» и ГОСТ 34.320—96 «Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы». Сами стандарты регламентируют правила работы с данными и с базами данных, но устанавливают в том числе некоторые термины и определения, например сущности, экземпляры, классы, типы и т. д.

Техническое задание (ТЗ) на создание АС и ПО

В заключение — несколько основных советов по составлению технического задания по ГОСТ 34.

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

Качественно составленное техническое задание и корректно проведенные приемочные испытания являются ключевыми точками успеха в процессе разработки автоматизированных систем.

1. Содержание
   • По ГОСТ 34.602—2020 ТЗ должно содержать 9 обязательных разделов, плюс раздел «Термины и определения».
   • Зачем это нужно. Без раздела «Термины и определения» стороны могут по-разному трактовать такие понятия, как «инцидент», «отказоустойчивость» или «интерфейс», что приводит к различным недопониманиям и потенциальным конфликтам при приемке, что в свою очередь может замедлить процесс согласования и реализации проекта.
   • Совет. Ссылайтесь на общепринятые термины из самого ГОСТ 34.003—90, но специфические термины вашей системы фиксируйте отдельно, чтобы избежать путаницы и однозначно определить все ключевые аспекты, которые могут повлиять на выполнение проекта.
2. Форматирование
   • Оформление ТЗ должно соответствовать ГОСТ 2.105—2019 (Общие требования к текстовым документам).
   • Оформление ТЗ включает четкую иерархию (разделы, подразделы, пункты), правила нумерации страниц и таблиц, а также оформление титульного листа и листа утверждения.
   • Правильное оформление — это не бюрократия, а залог того, что документ пройдет официальное согласование в госорганах или крупных корпорациях.
3. Подробное описание функционала
   • Функциональные требования (раздел «Требования к функциям») — это ядро ТЗ.
   • Каждая функция должна быть описана по формуле: «Система должна обеспечивать [действие] для [роль пользователя] при [условие]».
   • Используйте однозначные слова (например, «должна», а не «может») и избегайте субъективных оценок вроде «быстрый» или «удобный» — заменяйте их конкретными цифрами (время отклика, количество кликов).
4. Поэтапная разработка и сроки
   • ГОСТ 34.601—90 четко определяет стадии создания АС.
   • В ТЗ укажите состав работ для каждого этапа (например, «Техническое проектирование», «Рабочее проектирование»), сроки их начала и окончания, а также ожидаемый результат (например, настроенная среда или программный код).
   • Это позволяет заказчику контролировать процесс, а исполнителю — получать оплату за промежуточные результаты.
5. Список документов
   • Необходимо зафиксировать перечень документов, которые будут переданы вместе с системой (согласно ГОСТ 34.201—2020).
   • Руководство пользователя, руководство администратора, ведомость эксплуатационных документов, программа и методика испытаний (ПМИ).
   • Удобнее всего составить таблицу, где для каждого этапа разработки указан свой пакет документации.
6. Порядок и критерии приемки
   • Раздел «Состав и содержание работ по вводу системы в эксплуатацию».
   • Виды испытаний (предварительные, приемочные), кто входит в комиссию, как оформляется протокол и акт.
   • Четко пропишите критерии успеха — что считается успешным прохождением теста (например, «отсутствие критических ошибок 1-го и 2-го уровней»). Это защитит вас от бесконечных правок «по вкусу».

В одной из следующих статей мы более подробно опишем пример ТЗ, подготовленного в соответствии с требованиями ГОСТ 34.602—2020.