Структура ГОСТ 34

Введение: ГОСТ 34 как семейство стандартов

ГОСТ 34 — это не один стандарт, а целое семейство документов, объединённых общей системой обозначений. Все номера стандартов этого комплекса начинаются с цифр «34», за которыми следуют дополнительные коды; последние две цифры обозначают год принятия. Представленные в семействе годы — от 1980 до 1996 — показывают, что стандарт развивался и применялся достаточно долго.

Особое место занимает руководящий документ РД-50 (в его номере также присутствует «34»). Он не является стандартом в строгом смысле, а служит детализацией и пояснением ряда положений, которые в основных стандартах даны на верхнем уровне, своего рода «пунктиром».

Обзор ключевых стандартов

Не все документы семейства одинаково актуальны. Например, ГОСТ 34 «Термины и определения» (1990 г.) к настоящему времени устарел: изменились и терминология, и технологии. Однако три стандарта сохраняют практическую ценность примерно на 95%, несмотря на отдельные устаревшие детали:
• ГОСТ 34.601 — стадии создания автоматизированных систем;
• ГОСТ 34.201 — виды, комплектность и обозначение документов;
• ГОСТ 34.602 — техническое задание.

Стадии и этапы создания АС по ГОСТ 34.601

Термин АС (автоматизированная система) в то время был общепринятым обозначением информационных систем. ГОСТ 34.601 определяет восемь стадий создания АС, каждая из которых включает разное количество этапов:
1. Формирование требований к АС.
2. Разработка концепции.
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение.

Стандарт допускает небольшие отклонения: стадию «Эскизный проект» можно исключить, некоторые стадии — объединять, однако общая канва остаётся неизменной. Конкретный набор стадий и этапов фиксируется в договорах и техническом задании на основе данного стандарта.

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

Роли организаций-участников

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

Документо-центрическая природа: ГОСТ 34.201 и РД-50

ГОСТ 34.201 «Виды, комплектность и обозначение документов при создании автоматизированных систем» составляет основу всего подхода. В нём подробно и последовательно перечислены документы, которые должны появляться на выходе каждой стадии: техническое задание, эскизный проект, технический проект, рабочая документация. Приводится таблица, где точно определены названия документов и их содержание: пояснительные записки, описания системы и её частей, принципы действий, условия применения, сведения, подтверждающие целесообразность принятых решений.

Вся система ГОСТ 34 по своей сути является стандартом не столько на процесс создания системы, сколько на состав и содержание документов, которые при этом должны быть выпущены. Не код, не логические модели баз данных, не тесты, а именно документы. Детальные требования к содержанию этих документов собраны в уже упомянутом РД-50. Например, стадия формирования требований к АС должна завершаться отчётом и заявкой на разработку. В отчёте обязательно должны присутствовать: характеристика объекта автоматизации, описание существующей информационной системы, описание её недостатков и т.д.

Идея заключалась в том, чтобы максимально точно и детально расставить ориентиры, которым разработчик обязан неукоснительно следовать. Заказчик проверял не столько процесс создания (он описан кратко), сколько соответствие выпущенных документов этим требованиям.

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

Техническое задание — центральный документ (ГОСТ 34.602)

Центральным документом всего комплекса является техническое задание (ТЗ) , которое содержит девять разделов. Знание этих разделов и их содержания наизусть долгое время считалось признаком профессионализма даже в коммерческих организациях, формально не обязанных применять ГОСТ.

ТЗ выступает своего рода квинтэссенцией всех требований. Рассмотрим один из ключевых разделов — «Требования к системе». Он включает подразделы:
• требования к системе в целом;
• требования к функциям;
• требования к видам обеспечения.

Далее идёт детальная расшифровка. В подразделе «Требования к системе в целом» может быть перечислено до двадцати видов требований. В требованиях к структуре и функционированию — шесть пунктов. Прописываются требования к численности и квалификации персонала, показателям назначения, надёжности, безопасности, эргономике и технической эстетике, эксплуатации, техническому обслуживанию, ремонту и хранению. Причём детализация требовалась даже тогда, когда специфических требований к системе по этим аспектам не было. На практике это приводило к курьёзам: в требованиях по эргономике писали, что монитор должен быть цветным, обладать определённым разрешением и комплектоваться мышью — то есть фиксировали то, что и так обеспечивалось доступным на рынке оборудованием.

Требования к защите информации от несанкционированного доступа включают нормы, установленные в ведомстве заказчика, — подход, который в целом сохранился и сейчас, с той разницей, что сегодня многие заказчики ориентируются на общие отраслевые стандарты информационной безопасности. Встречаются и экзотические пункты, например требования к оснащению системы устройствами для обучения персонала (тренажёрами) и документацией на них.

Единственный формализованный процесс: согласование ТЗ

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

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

Краткие итоги

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

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

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