ГОСТ 22360-77 — это фундаментальный государственный стандарт, разработанный в СССР и действовавший на территории стран СНГ, который регламентирует стадии создания автоматизированных систем (АС). Он входит в систему стандартов ЕСПД (Единая система программной документации) и серии стандартов по автоматизированным системам (серия 19xxxx и смежные).

Несмотря на то, что стандарт был утвержден в 1977 году, его методологические принципы (жизненный цикл, поэтапность, документационное обеспечение) до сих пор лежат в основе современных стандартов разработки ПО и системной инженерии (например, ГОСТ Р ИСО/МЭК 12207, ГОСТ Р 54872-2011/ISO/IEC 15288).

Область применения и назначение

Стандарт устанавливает:

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

Важно: ГОСТ 22360-77 применяется к автоматизированным системам любого класса и назначения (управления производством, проектирования, расчетно-аналитических, банковских, военных и др.), создаваемых в рамках инвестиционных проектов или НИОКР.

Стадии создания автоматизированной системы

Стандарт выделяет 7 основных стадий (плюс стадия эксплуатации, которая часто рассматривается отдельно в ГОСТ 19.101-77). Ниже приведено подробное описание каждой.

Стадия 1. Техническое задание (ТЗ)

Цель: Определение требований к системе, обоснование целесообразности ее создания.

• Сбор и анализ исходных данных.
• Формулировка целей создания АС.
• Разработка и утверждение Технического задания (основной документ стадии).
• Согласование ТЗ с заказчиком и разработчиком.

Стадия 2. Техническое предложение (ТП)

Цель: Разработка концепции системы, выбор оптимального варианта решения.

• Анализ альтернативных вариантов архитектуры, аппаратного и программного обеспечения.
• Оценка технико-экономических показателей (ТЭП).
• Разработка Технического предложения.
• Защита ТП заказчиком/экспертиза.

Стадия 3. Технический проект (ТПР)

Цель: Проектирование архитектуры системы, определение состава подсистем, алгоритмов и структуры БД.

• Разработка функциональной структуры АС.
• Проектирование информационной базы (логическая модель данных).
• Разработка алгоритмов решения задач.
• Выбор ЭВМ, СВТ, средств связи, СУБД, ОС.
• Составление Пояснительной записки к техническому проекту, схем, диаграмм.

Стадия 4. Рабочая документация (РД)

Цель: Детальная проработка всех компонентов для последующей разработки и изготовления.

• Разработка рабочих проектов программ (описание модулей, структур данных, интерфейсов).
• Разработка документации на аппаратное обеспечение (схемы монтажа, кабельные журналы).
• Разработка документации на информационную базу (физическая модель БД).
• Подготовка комплекта Рабочей документации для производства (кодирования, закупки, монтажа).

Стадия 5. Изготовление (Внедрение/Реализация)

Цель: Физическое создание системы: кодирование ПО, закупка/сборка железа, монтаж, наладка.

• Программирование (кодирование) и отладка модулей.
• Поставка и монтаж технических средств.
• Установка системного и прикладного ПО.
• Наполнение информационной базы справочными данными.
• Проведение предварительных испытаний (внутренних разработчиком).

Стадия 6. Испытания и приемка (ППИ, ПСИ, ГСИ)

Цель: Подтверждение соответствия системы ТЗ и рабочей документации.

• Предварительные испытания (ППИ): Внутренние у разработчика.
• Приемо-сдаточные испытания (ПСИ): Совместные с заказчиком на стенде разработчика или на месте эксплуатации.
• Государственные испытания (ГСИ): Для гостайны/военных систем (по решению госзаказчика).
• Оформление Актов испытаний и Акта приема-передачи.

Стадия 7. Ввод в действие (Эксплуатация)

Цель: Перевод системы в промышленную эксплуатацию.

• Пилотная/промышленная эксплуатация.
• Обучение персонала.
• Доработка выявленных недочетов (гарантийное обслуживание).
• Передача в штатное сопровождение (поддержка).

Документационное обеспечение (Ключевой аспект)

ГОСТ 22360-77 неразрывно связан с ГОСТ 19.xxx (ЕСПД). На каждой стадии формируется строго определенный комплект документов. Нарушение состава документов ведет к невозможности согласования и приемки работ.

Методологические принципы

1. Принцип поэтапности: Переход к следующей стадии возможен только после полного завершения и согласования результатов предыдущей (водопадная модель).
2. Принцип обратной связи: На стадиях ТПР и РД допускается уточнение решений, принятых на ранних стадиях (с оформлением изменений в ТЗ/ТП).
3. Единообразие документации: Использование унифицированных форм (ЕСПД) обеспечивает читаемость и переносимость проекта между организациями.
4. Управление конфигурацией: Базируется на версионировании документации (регистрация изменений, уведомления).

Актуальность и современный контекст

На данный момент ГОСТ 22360-77 формально не отменен (находится в статусе «Действует» в реестрах Росстандарта/Госстандарта РФ), однако на практике:

• В госзаказе (44-ФЗ, 223-ФЗ): Часто требуется соблюдение этапности, но документация оформляется по ГОСТ 19.xxx в сочетании с ГОСТ Р ИСО/МЭК 12207-2010 (Процессы жизненного цикла ПО) и ГОСТ Р 54872-2011 (Системная инженерия).
• В Agile/DevOps: Жесткая водопадная модель ГОСТ 22360 адаптируется через итерационное прохождение стадий внутри спринтов или разделение на «Техническое задание на этап» и «Рабочую документацию на релиз».
• Цифровые платформы: Современные СУПР (Системы управления требованиями, PLM, ALM — Jira, Confluence, Polarion, DOORS, отечественные аналоги) автоматизируют прослеживаемость (Traceability) между стадиями, которую ГОСТ 22360 требует обеспечить вручную.

Частые ошибки и риски

1. Пропуск стадии Технического предложения (ТП). Часто заказчик требует сразу ТЗ -> ТПР. Это ведет к риску выбора неоптимальной архитектуры, который обнаруживается на стадии РД или испытаний (стоимость исправления в 10-100 раз выше).
2. Неполная Рабочая документация. Передача в кодирование только «Пояснительной записки ТПР» без детального описания модулей (ГОСТ 19.401) приводит к «кодированию на коленке» и нетестируемому коду.
3. Игнорирование документации на ИБ (Информационную базу). Отсутствие физической модели БД, скриптов миграции и наполнения справочников — частая причина провала ПСИ.
4. Формальное проведение ПСИ. Испытания по «галочке» без реалистичных нагрузок и сценариев отказа оборудования.

ГОСТ 22360-77 — это «классика жанра» системной инженерии в постсоветском пространстве. Он зафиксировал дисциплинированный подход к созданию сложных ИТ-систем: от идеи (ТЗ) до утилизации. Знание структуры стадий и требуемой документации по этому стандарту обязательно для:

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

Грамотное применение стандарта (в связке с современными ISO/IEC) позволяет строить предсказуемые, управляемые и аудируемые процессы разработки, минимизируя риски срыва сроков и бюджета.

Нормативные ссылки (для глубокого изучения)

• ГОСТ 22360-77, Автоматизированные системы. Стадии создания (базовый стандарт);
• ГОСТ 19.000-80 — ЕСПД. Общие положения.
• ГОСТ 19.101-77 — ЕСПД. Виды и обозначения документов.
• ГОСТ 19.201-78, ТЗ. Требования к составу и параметрам.
• ГОСТ 19.202-78 — ТП. Требования к составу и параметрам.
• ГОСТ 19.301-79 — Программа и методика испытаний.
• ГОСТ 19.401-78 — Описание программы.
• ГОСТ Р ИСО/МЭК 12207-2010 — Технологии информации. Процессы жизненного цикла программного обеспечения.
• ГОСТ Р 54872-2011 — Системная инженерия. Процессы жизненного цикла системы.

Примечание: Если под «22360 часть» вы имели в виду конкретный номер детали (spare part) для автомобиля, станка или прибора (например, каталог запчастей КАМАЗ, УАЗ, тракторов МТЗ и т.д.), пожалуйста, уточните контекст (марка техники, узел, наименование), так как номер 22360 встречается в десятках каталогов как артикул конкретной детали (шайба, болт, датчик, панель и т.п.). Данная статья посвящена именно Государственному стандарту.