Где истоки водопада? Читаем статью «Управление разработкой больших компьютерных систем»

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

WaterfallClassic

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

История

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

Перевод

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

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

Комментарий

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

WaterfallAdvanced

Шаг 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.

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

Ссылки:

 

 

Реклама

3 thoughts on “Где истоки водопада? Читаем статью «Управление разработкой больших компьютерных систем»

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s