Вам знакома эта картинка?

Ну конечно, это визуализация всем известной каскадной методологии разработки ПО, иначе именуемой «водопадом» (en: Waterfall). Той самой, которую так принято критиковать последние лет 20 и изобретать взамен модные итеративные и агильные методологии. А вы знаете, откуда взялся этот водопад?

История

Традиционно ссылаются на статью Уинстона Ройса (Winston Royce) Managing the Development of Large Software (Управление разработкой больших компьютерных систем). Но мало кто читал эту статью. А если её прочитать, то выяснится, что Ройс и не обосновывал водопад, и не рекомендовал его и даже не придумал его. Вышеприведённая картинка у Ройса просто иллюстрирует естественную последовательность шагов при реализации компьютерной системы — требования, анализ, дизайн, кодирование, тестирование — ну, как положено.А дальше Ройс пишет, что нельзя строить проект буквально как на картинке, последовательно выполняя фазы, и не переходя к следующей фазе, пока не завершится предыдущая. Более того, всю статью Ройс посвятил потому, чтобы показать, как надо видоизменить модель разработки, чтоб, пользуясь ею, реально можно было выполнять большие проекты.

Перевод

Мне так понравилось, что я решил сделать перевод на русский язык, который с удовольствием представляю вашему вниманию:

Уинстон Ройс, Управление разработкой больших компьютерных систем, 1970 год

Комментарий

Теперь от себя, что я увидел у Ройса. Он предлагает пять шагов по усовершенстованию процесса, и приходи в конце вот к такой картинке:

Шаг 1: Прототип

Между требованиями и анализом рекомендуется уже разработать предварительный дизайн, с риском наделать ошибок, но с целью собрать реальный опыт, который можно учесть при разработке настоящего дизайна. Если учесть уровень языков программирования в 1970 году, то тогдашний «дизайн» вполне сопостовим с сегодняшним программированием, а значит то, что Ройс предлагает — это в сущности разработка прототипа для устранения главных технических рисков.

Шаг 2: Документация

Ройс требует жесткого документирования и обещает, что это окупится на фазах тестирования и дальше. К примеру, для проекта в 5 миллионов долларов (на деньги 1970 года) он оценивает объём документации в 1500 страниц. Чтобы адекватно оценить, почему Ройс так говорит, надо представить себе пропасть между доступными ему средствами в 1970 году (например, Фортран, программирование ручкой на бумаге и машины третьего поколения с их дефицитными ресурсами, когда на машинное время нужно было записываться в специальный журнал) и сложностью решаемых задач (управление миссией космических полётов). Ройс хотел сохранить контроль над происходящим в проекте. В переводе на сегодняшний инструментарий объём письменной документации будет в разы меньше. Хотя, может быть и не будет, если учесть сегодняшние параметры сложности. Это не столько вычислительные алгоритмы, сколько количество взаимодействующих заинтересованных сторон и скорость изменений.

Шаг 3: Итерации

Для разработки с нуля рекомендуется поставлять заказчику не первую версию, а как минимум вторую. Это значит, что весь цикл разработки нужно прокрутить два раза. Ройс говорит о пилоте, делаемом в начале и занимаемом приблизительно треть всего времени. Это ни что иное как начало итеративного подхода. Ройс стоял у истоков не водопада, а итеративной разработки!

Шаг 4: Планирование тестирования

Многие советы здесь по-прежнему актуальны, к примеру о том, что фазу тестирования надо планировать, что нужно иметь критерии завершения тестирования, что тестировать должны другие люди, не те что разрабатывали программу, что есть разные виды тестирования, находящие разные виды ошибок.Но многое и устарело в связи с улучшенным инструментарием, к примеру:

Не используйте компьютер для нахождения таких дефектов – это слишком дорого.

Жаль, что у Ройса не было современных сред разработки.

Шаг 5: Вовлечение заказчика

Тут хочется процитировать целиком:

По каким-то причинам то, что именно программа должна делать, остаётся предметом широкой интерпретации даже после предварительного согласования. Важно вовлечь заказчика формальным способом, с тем чтобы он подтвердил своё согласие на ранних фазах, до финальной поставки. Давать подрядчику полную свободу между формулировкой требований и вводом в эксплуатацию – это запрограммированные неприятности. Рис. 9 показывает три точки после формулировки требований, где проницательность, суждения и поддержка заказчика может поддержать проект разработки.

Три точки взаимодействия с заказчиком, предлагаемые Ройсом — это:

• Preliminary Software Review (PSR)
• Critical Software Review (CSR)
• Final Software Acceptance Review (FSAR)

Это огромный шаг вперёд по сравнению с исходной ситуацией — никакого вовлечения заказчика между заморозкой требований и поставкой готовой системы. Я думаю, Ройс не мог себе представить насколько много и часто, увы, деструктивно заказчик может влиять на разработку сегодня.

Забавный факт — в договоре на разработку в моём сегодняшнем проекте зафиксированы именно эти три ревью по Ройсу как контрольные точки, практически с такими же названиями. И даже частичные платежи по контракту привязаны именно к этим точкам. Вот только реальное развитие проекта проходит не по Ройсу.

А где же водопад?

Ройс не предлагал использовать водопад, и даже не произносил такого слова. Его неправильно поняли. Не дочитали статью до конца. Сначала американские военные, а потом и все остальные. У американских военных водопад был стандартизирован в 1985 году под обозначением DOD-STD-2167. Отечественный аналог — ГОСТ 34601-90.

Однако остаётся неясным, работал ли кто-нибудь по классическому водопаду, или же его всегда использовали как красивую модель, которую можно повесить на стенку (раньше) или же критиковать как пережитки старины (сейчас)?

Ссылки:

• Managing the Development of Large Software, Winston Royce, 1970 (локальная копия, на всякий случай)
• Why Waterfall was a big misunderstanding from the beginning – reading the original paper — статья, очень похожая на мою, но по-английски и 2014 года
• The Rise And Fall of Waterfall — отличный 5-минутный мультик Максима Дорофеева, 2010 года
• Традиционное управление разработкой ПО — в п. 1.1.1 подробно обсуждается статья Ройса, причём это перевод из книги сына Уинстона Ройса — Волкера Ройса (Walker Royce) — Software Project Management: A Unified Framework, 1998.
• There’s no such thing as the Waterfall Approach! (and there never was)

 

 

• Software