Введение: что регламентирует ГОСТ 34
Стандарт ГОСТ 34 детально описывает промежуточные результаты создания автоматизированной системы: содержание, формат, структуру документов и даже правила их оформления. Если же посмотреть на стадии и этапы, заданные стандартом, становится видна их важнейшая особенность.
Каскадная модель жизненного цикла
Последовательность шагов, предусмотренная ГОСТ 34, линейна и не допускает никаких возвратов на предыдущие стадии. Проект движется только в одном направлении. Такая модель создания системы называется
каскадной (англ.
Waterfall — водопад). Как водопад не течёт вверх, так и проект не может вернуться назад ни с какого этапа.
Почему же появились столь жёсткие требования?
Истоки стандарта: аналогия с капитальным строительством
В тексте ГОСТ 34 встречаются понятия «сантехнические работы», «генпроектировщик объекта автоматизации». Разработчики стандарта, по-видимому, взяли за образец деятельность, наиболее похожую тогда на создание информационных систем, —
капитальное строительство.
Сходство действительно велико. И создание ИС, и капитальное строительство — проектная деятельность. В обоих случаях есть этап сбора требований, выявления ограничений и ожиданий заказчика: в строительстве изучаются особенности участка, в автоматизации — особенности объекта. Если стройка затрагивает существующие здания, генпроектировщики этих сооружений привлекаются к сбору требований, так как владеют полной информацией об объектах.
Эта строительная аналогия во многом рабочая. Для многих заказчиков подобный подход к созданию системы вполне приемлем.
Сильные и слабые стороны подхода
Стандарт регламентирует практически все технические, организационные и правовые вопросы через документы. Процесс описан лишь в части согласования и утверждения технического задания — других бизнес-процессов в ГОСТ 34 нет. Заказчик видит результат исключительно как набор документации.
Важное достоинство стандарта: для контроля не требуется специальных ИТ-знаний. Контролируется не сам процесс создания, а соответствие документов заданным шаблонам. Это упрощает работу заказчиков, чьи специалисты могут не разбираться в информационных технологиях. С другой стороны, документы могут формально соответствовать ГОСТ 34, но быть содержательно пустыми и не имеющими практической ценности.
Обязательность применения сегодня
ГОСТ 34 остаётся о
бязательным для всех государственных заказчиков: не только для органов власти, но и для госкорпораций, их дочерних структур, государственных банков — всех, кто заказывает корпоративные информационные системы. Ни одна государственная структура не примет техническое задание, если оно не оформлено по ГОСТ 34. Поэтому даже коммерческие организации, не обязанные соблюдать стандарт по закону о техническом регулировании, вынуждены это делать. Госзаказ в ИТ составляет львиную долю рынка, по оценкам — до 90% всех работ.
Хотя существуют более современные зарубежные стандарты, а сам ГОСТ 34 очевидно устарел и нуждается в пересмотре, он остаётся актуальным документом.
Когда каскадная модель хороша
Каскадная модель разумна и оправданна при одном ключевом допущении:
все требования к системе должны быть полностью собраны на начальной стадии, зафиксированы в техническом задании и никогда не меняться. Если это так, линейный подход вполне логичен. Возможные возвраты, вызванные ошибками исполнителя, заказчика не интересуют — это проблема исполнителя, неправильно интерпретировавшего чётко заданные требования.
Проблема изменяющихся требований
Ситуация меняется, когда создаётся уникальная система, автоматизирующая уникальные бизнес-процессы. Заказчик не может заранее точно описать все требования, поскольку никогда не видел подобных средств автоматизации и не пробовал выполнять процессы с их помощью. Ожидать, что он предвидит всё до начала разработки, наивно. Люди уточняют требования, пересматривают взгляды, отказываются от чего-то, увидев первые результаты или оценив трудоёмкость. По сути, анализ требований идёт на протяжении всего проекта, а не только на начальном этапе.
Лазейка: частное техническое задание
Государственные организации тоже сталкиваются с подобной неопределённостью. Для таких случаев в ГОСТ 34 существует механизм
частного технического задания. Изначально он задумывался как полезный инструмент, а на практике используется как лазейка. Сначала составляется общее техническое задание, из которого почти невозможно извлечь конкретные требования. Затем, по мере продвижения проекта, создаются частные технические задания, детализирующие положения общего и разнесённые по времени. Это немного смягчает жёсткость каскадной модели, хотя сам стандарт на такую гибкость не рассчитан.
Гибкость информационных систем против физических ограничений
Ещё одно важное соображение против каскадного жизненного цикла связано с природой материала. В капитальном строительстве невозможно начать с крыши, а затем перейти к окнам и ступенькам — физический объект диктует жёсткую последовательность.
Информационная система такими ограничениями не обладает. Информация как материал чрезвычайно гибка. Систему можно создавать отдельными, даже слабо связанными компонентами в практически любом порядке, сшивая их по мере готовности. Это фундаментальное свойство отличает ИТ-продукт от физического сооружения.
Заключение
Несмотря на директивный статус ГОСТ 34 и отдельные лазейки, его применение вызывает всё больше проблем. Каскадная модель, заложенная в стандарте, становится чересчур обременительной.
Краткие итоги
Стандарт ГОСТ 34 сформировался в период, когда единственной понятной эталонной проектной деятельностью для его авторов выступало капитальное строительство. Эта ментальная модель была без существенных адаптаций перенесена на создание информационных систем, что предопределило линейную, безальтернативную логику разработки — каскад (Waterfall). В этом подходе каждая стадия жёстко отделена, а возврат на предыдущую считается недопустимым и рассматривается исключительно как исправление ошибок исполнителя, а не как естественный процесс уточнения требований.
Такой перенос из строительной сферы привёл к тому, что контроль в стандарте сосредоточен не на инженерном качестве, а на полноте и соответствии документальных форм установленным шаблонам. В результате заказчику не требуется обладать ИТ-компетенциями — достаточно формальной проверки документации. Это стало одновременно и сильной стороной (низкий порог входа для заказчика), и фундаментальной уязвимостью: за безупречным с точки зрения ГОСТа комплектом бумаг может скрываться абсолютно непригодная к использованию система.
Особый статус стандарту придаёт его обязательность для всего спектра государственных организаций, что автоматически превращает ГОСТ 34 в де-факто рыночный стандарт для подавляющей доли ИТ-проектов в стране. Эта регуляторная реальность консервирует применение каскадной модели даже там, где она объективно вредна.
Попытка компенсировать жёсткость через инструмент частного технического задания не решает системной проблемы. По сути, это признание невозможности сразу определить полный объём требований, обёрнутое в форму, не нарушающую букву стандарта. Однако такая практика остаётся организационной лазейкой, а не органичной частью методологии.
Принципиальное противоречие между каскадной логикой и современной практикой создания программных продуктов коренится в различной материальной природе объектов. Если физические сооружения сопротивляются произвольному порядку возведения, то информационная система как гибкий, нематериальный продукт может развиваться инкрементально, итерационно и в любой удобной конфигурации компонентов. Жёсткая линейная последовательность, осмысленная для бетона и металла, становится неестественным ограничением для кода и данных. Именно это нарастающее несоответствие превращает ГОСТ 34 из рабочего инструмента во всё более обременительный, но пока неотменяемый административный барьер.
Стандарт ГОСТ 34 жёстко определяет не только стадии и этапы создания автоматизированной системы, но и содержание, формат и оформление документов. Его ключевая особенность — каскадная модель жизненного цикла (англ. Waterfall). Последовательность шагов в ней линейна и не допускает возвратов к предыдущим стадиям. Разработчики взяли за образец капитальное строительство, посчитав эту деятельность наиболее похожей на создание информационных систем. Отсюда в стандарте — отсылки к генпроектировщику и строительным работам.
Контроль в ГОСТ 34 ведётся не за процессом разработки, а за документами. Это сильная сторона: заказчику не требуется специальных ИТ-знаний, чтобы проверить формальное соответствие документов шаблонам. Но в этом же кроется и слабость — документы могут быть безупречны по форме и абсолютно пусты по содержанию.
Сегодня ГОСТ 34 обязателен для всех государственных заказчиков (органов власти, госкорпораций, госбанков). Поскольку госзаказ занимает до 90% ИТ-рынка, коммерческие компании де-факто вынуждены следовать стандарту, хотя по закону «О техническом регулировании» могут этого не делать.
Каскадная модель вполне разумна при одном условии: все требования полностью собираются на старте, фиксируются в техническом задании и никогда не меняются. Тогда любые возвраты — это ошибки исполнителя, которые заказчика не касаются.
Проблемы начинаются, когда создаётся уникальная система для уникальных бизнес-процессов. Заказчик не может заранее описать все требования, так как никогда не работал с подобной автоматизацией. Анализ требований фактически идёт весь проект. Для смягчения жёсткости в ГОСТ 34 есть механизм частного технического задания: сначала выпускают общее ТЗ без конкретики, а затем по ходу проекта разрабатывают частные, детализируя требования. Это лазейка, сам стандарт на непрерывную итеративность не рассчитан.
Главное противоречие — в природе материала. Капитальное строение физически невозможно возводить с крыши. Информационная система такой жёсткости не имеет: это гибкий «материал», который можно создавать отдельными компонентами в практически любом порядке, стыкуя их по мере готовности. Именно поэтому каскадная модель ГОСТ 34, перенесённая из строительства, сегодня всё чаще воспринимается как чрезмерно обременительная.
1. ГОСТ 34 задаёт единственно возможную каскадную модель жизненного цикла, исключающую возвраты к пройденным стадиям.
2. Структура и терминология стандарта заимствованы из области капитального строительства.
3. Контроль в рамках ГОСТ 34 нацелен на проверку документов, а не самого процесса создания ИС.
4. Применение стандарта не требует от заказчика специальных знаний в области информационных технологий.
5. Обязательность ГОСТ 34 для госзаказчиков делает его де-факто универсальным требованием на ИТ-рынке России.
6. Каскадная модель эффективна только при условии, что все требования полностью собраны и неизменны с самого начала.
7. Создание уникальных систем не позволяет зафиксировать полный набор требований на старте, так как заказчик уточняет их по мере реализации.
8. Частное техническое задание выступает легальной лазейкой, позволяющей детализировать требования на поздних этапах в обход жёсткой линейности.
9. Информация как материал чрезвычайно гибка и допускает создание системы отдельными компонентами в произвольном порядке.
10. Физические ограничения стройки (нельзя начать с крыши) неприменимы к информационным системам, что обессмысливает жёсткую каскадную последовательность.
11. Несмотря на формальное удобство контроля, документы по ГОСТ 34 могут не иметь практической ценности.
12. Каскадная модель, лежащая в основе стандарта, всё чаще воспринимается как обременительная и плохо совместимая с современными методами разработки.
1. Почему последовательность стадий в ГОСТ 34 названа каскадной?
2. Какая отрасль послужила прообразом для разработчиков ГОСТ 34 при создании стандарта?
3. В чём заключается основное достоинство стандарта для заказчика, не обладающего ИТ-компетенциями?
4. Какая опасность скрывается за формальным соответствием документации шаблонам ГОСТ 34?
5. Почему коммерческие ИТ-компании вынуждены следовать ГОСТ 34, даже если не обязаны делать это по закону?
6. При каком ключевом условии каскадная модель становится полностью обоснованной и эффективной?
7. Что делает невозможным полный сбор требований на старте в проектах по созданию уникальных информационных систем?
8. Как частное техническое задание помогает смягчить жёсткость каскадной модели?
9. Чем свойство информационных систем как материала принципиально отличается от свойств физических объектов строительства?
10. Почему аналогия с генпроектировщиком зданий и сооружений оказалась уместной для ранних редакций ГОСТ 34?
11. Какому единственному процессу, связанному с утверждением документа, уделено внимание в стандарте помимо стадий разработки?
12. Почему, несмотря на наличие более современных зарубежных стандартов, ГОСТ 34 сохраняет доминирующие позиции в России?
