«Водопада» не существует

На прошлой неделе в нескольких «околоэлектронных» и «околопрограммистских» ЖЖ состоялся срачик по поводу ГОСТов в частности и стандартов вообще, а также про необходимость следовать им. Итоги подвел [info]hedgeov, заодно собравший ссылки на некоторые части дискуссии:

http://hedgeov.livejournal.com/337510.html

В этой записи я тоже хотел бы вспомнить про ГОСТы, конкретно — про серии 19 и 34, регламентирующие содержание документации на программы и автоматизированные системы соответственно. Их, разумеется, считают устаревшими — хотя из явных анахронизмов там можно назвать лишь необходимость распечатки текста программы (да и ее можно обойти). Более конструктивный аргумент — это то, что в ГОСТах 34 серии приведен список документов, которые сопровождают процесс разработки программы и якобы этот список вынуждает при разработке использовать «модель водопада».

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

Аргументация будет очень простой. Во-первых, и в так называемой «модели водопада», и в RUP-подобных итеративных процессах, и в ГОСТ выделяются четыре стадии разработки, только называются они по-разному. У буржуев это Inception, Elaboration, Construction и Transition, в ГОСТах названий не приводится и обычно «стадии» называют по получающимся в конце документам («артефактам», в терминологии RUP): техническое задание, технический проект, рабочая документация (одновременно с ней разрабатывается и сама ИС) и ввод в действие. Конечно, апологеты RUP утверждают, что стадии RUP и стадии «водопада» — это «две большие разницы», но их настойчивость в этом убеждает в обратном.

Перейдем ко второму пункту. Я не зря упомянул про титульный лист. Дело в том, что он убивает все противопоставления «водопада» итеративным процессам. Фанаты последних утверждают, что в случае «водопада» ТЗ, проект и вообще все «требования» «спускают сверху». Так вот, на титульном листе всегда есть подписи двух сторон — заказчика и исполнителя. Всякое согласование документов само по себе и порождает итерации — и в «идеальном» случае порождает из ГОСТовской модели что-то похожее на OpenUP.

Разумеется, я не зря упомянул об «идеальном случае». Дело в том, что основная часть всех «методологий» — это здравый смысл и прочие Best Practices. А если на здравый смысл положили с большим прибором — то «от дурака» не спасет ни ГОСТ, ни RUP.

PS Типичная (к сожалению) ситуация, когда ТЗ согласуется на уровне какого-нибудь недостижимого начальства, а в патологическом случае — этим же впадающим в маразм начальством и пишется — на уровне RUPовского здравого смысла называется «неправильным определением заинтересованных лиц» и к ГОСТам отношения не имеет.

PPS Кстати, применительно к фазам RUP, по-новому звучит шуточка «любое начинание делится на четыре части: запутывание, запугивание, наказание невиновных и награждение непричастных».

«Водопада» не существует: 5 комментариев

  1. Ой, раз уж ты так всё красиво рассказываешь — разложи например, как эти ГОСТы в вёб-разработке использовать, где у тебя «ввод в эксплуатацию» чуть ли не каждый раз по Ctrl-S. (Ну, не совсем так, но несколько раз на дню — вполне рабочая ситуация).

    1. — «Мммать, мать, мать» — привычно повторило эхо.

      Вы че, в работающую систему вносите изменения? Можете называть вашу «методологию разработки» Agile или Scrum, можете — «как получится», или еще более модным словом — Getting Real, только к серьезным людям не приставайте, ОК?

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

      Ну и напоследок — «современная веб-разработка», то есть вездесущее распиздяйство, очень плохо укладывается в хоть какие-то разумные методологии, вот и придумывают специально для нее всякое Getting Real. Это обычное «как получится», но в красивой обертке.

      1. Ну то есть, пофигу, что работает, приносит людям пользу и зарабатывает деньги — главное, что не «по-правильному», значит, распиздяйство. Так, что ли? Вот уж точно преобладание процесса над здравым смыслом. Окстись.

        1. Во-первых, я не призываю запрещать, убивать и отрезать полжопы. Как говорил товарищ Мао, «пусть расцветают сто цветов». Человечество в целом в разных областях уже пришло к выводу о необходимости стандартизации, в том числе — и стандартизации производственных процессов. В программировании же процветает чудовищная «кустарщина», и большое счастье, что сляпанный по принципу «как получится» продукт «работает, приносит людям пользу и зарабатывает деньги».

  2. Оформлял когда-то (почти 10 лет назад, будучи инженером-математиком ;-) ) всю документацию по ЕСПД. Несмотря на старые нормативы (80-е годы 20 века) все четко вписывалось в ТЗ, алгоритмы, тексты программ, описание программы, руководство программисту , формуляры…

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *