ГОСТ 34 - развенчиваем типичные мифы и заблуждения

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

Давайте же разберем очевидные мифы вокруг стандарта и обратим внимание на факты.

Миф 1. В ГОСТ 34 «зашит водопад» и он не подразумевает итеративную разработку

• ГОСТ 34 не регламентирует модель жизненного цикла проектирования и разработки системы и никак не ограничивает её выбор. Этот выбор определяется условиями конкретного проекта. Поэтому модель "водопада" никакого отношения к стандарту не имеет.
• Процесс проектирования — это творческий и итерационный процесс. Его итерационность заложена в особенностях мышления человека. Поэтому любая методология проектирования априори итерационна.
• Если внимательно прочитать ГОСТ 34.602-89 и особенно Приложение 1, то нетрудно увидеть итерационный характер процессов создания как самого ТЗ  на АС, так и системы в целом.

Миф 2. В отличие от стека Agile в ГОСТ  34 не подразумевается вовлечение заказчика и исполнителя в совместную работу.

• Рекомендации о необходимости вовлечения заказчика и исполнителя в совместные работы по созданию системы  явно закреплены в ГОСТ 34.601-90, Приложение 2,  в  ГОСТ 34.602-89 Приложения 1 и разделы 2.7-2.9 и отражены в РД 50.34.609-90.

Миф 3.  В отличие от Agile в ГОСТ 34 не подразумевается создание общего словаря заказчика и разработчика 

• Согласно документу РД 50.34.609-90 развёрнутое описание всех информационных сущностей, задействованных в проектировании,  должно быть отражено в информационной модели системы, которая является неотъемлемой частью информационного обеспечения системы, разрабатываемого  в соответствии с ГОСТ 34.602-89.
  Каждая информационная сущность должна быть поименована и описана в ТЗ. Это и есть словарь заказчика и разработчика. По стандарту его можно оставить в разделе «Требования к информационному обеспечению» или вынести в отдельный подраздел или приложение к ТЗ.

Миф 4.  ГОСТ 34 навязывает избыточную документацию

• ГОСТ 34, как и большинство стандартов РФ, имеет только рекомендательную, а необязательную силу. Это позволяет при  разработке технического задания по ГОСТ34.602-89 в разделах 2.7 и 2.10 приводить только минимально необходимый набор документов, без которых система не может быть создана и принята в эксплуатацию. При этом конкретный состав документов согласовывается с заказчиком при подписании контракта исходя из условий проекта и здравого смысла.

Миф 5. ГОСТы 34-ой и 19-ой серии устарели, т.к. были созданые еще в советское время и с тех пор не обновлялись 

• Учитывая последние запросы системной инженерии,  в ГОСТ 34 заложена  актуальная методология по созданию качественных автоматизированных систем любой сложности. Чего нельзя сказать о стандартах ISO/IEC/IEEE, предназначение которых быть основой для создания внутренних корпоративных стандартов, где прописываются методологии создания продуктов.  Наглядный тому пример доступные стандарты NASA и DoD.
• Важно, что  ГОСТ 34 не ограничивает ни кого в применении любых современных терминов. Его основной стандарт ГОСТ 34.602-89 базируется  на определении автоматизированной системы, которое за это время не претерпело ни каких изменений.
• ГОСТ 19  — та же история. Архаичными выглядит некоторые слова, а не суть стандарта. Отметим также, что такое требование ГОСТ 19, как создание блок-схем алгоритмов программ на структурном языке диаграмм (SDL) существенно повышает качество кода при весьма скромных затратах на обучение и применение. Кстати, SDL входит в UML — для тех, кому это слово ближе.

Миф 6. Коммерческий сектор не пользуется ГОСТ 34

• Коммерческий сектор, коммерческому сектору рознь. Есть очень продвинутые в этом деле заказчики. Из личного примера проектирования скажу, что компетентные коммерческие заказчики обращают внимание на качество технической документации не хуже чем государственные структуры или НИИ.
• Поэтому вероятнее всего коммерческий сектор (массово) не пользуется ими не по причине бессмысленности, а из-за отсутствия специалистов, которые могли мы его грамотно применять.

Миф 7. ГОСТ 34 не дает быстрой обратной связи 

• Обратной связи не дает не какой-то ГОСТ, обратной связи не дают конкретные люди. От того, что в методологии или даже стандарте прописано об обязательности быстрой обратной связи ничего само собой не получится. Как говорит восточная мудрость: «Сколько не кричи «Халва!» — во рту сладко не будет». На любом проекте нужны немалые усилия для создания условий для получения обратной связи как от заказчика к исполнителю, так и от исполнителя к заказчику.

Миф 8. В ГОСТ 34 нет слова agile

• Это не миф. Его действительно там нет. Как нет и не может быть таких слов как: V-model, SCRUM, ХР, Model-Driven Development, DSDM (Dynamic Systems Development Method) и т.д.
• Это связано с тем,  что, во-первых, ГОСТ 34 сосредоточен на рекомендациях по созданию автоматизированных систем в целом, в то время как любая из Agile методологий сосредоточена на рекомендациях по созданию всего одной части автоматизированной системы — программного обеспечения.  Во-вторых, ГОСТ 34 был спроектирован как стандарт, который не зависит от какой-то конкретной методологии проектирования и разработки.