Waterfall — итеративная методология разработки

[@Regfor]

Не помешало бы добавить в конце ссылки которые подтверждают или на которые опирается написаное.

Например нагуглил для такую:

Royce, Winston (1970), «Managing the Development of Large Software Systems», Proceedings of IEEE WESCON 26 (August): 1–9

www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

[@retran]

Спасибо, кэп. Это есть во всех учебниках.

[@darkpashka]

«В таком случае остается вопросом, почему методология в широких кругах разработчиков и тестировщиков воспринимается ошибочно, как отображено на первом рисунке…»

Для меня больший вопрос почему вы считаете что в широких кругах разработчиков и тестировщиков waterfall воспринимается ошибочно??

А если выразить моё мнение, то я и вовсе не понимаю о чём статья, 2 скриншота вырванных из книги это всё равно что кровь из пальца высасывать. Даже в том отрывке что вы привели в качестве первоисточника, достаточно подробно описаны все нюансы и расписаны частично шаги.

[@astenix]

Ответ на главный вопрос уже есть — youtu.be/X1c2--sP3o0

[@serhiyko]

Ответа там нет.
Сложно представить что профессора просто «не услышали»… А он молчал в это время?

[@safright]

Водопад не любят не из-за того, что не понимают, его не любят из-за того, что он плохо подходит для сложных программных систем. Причин 2:
1. В современных условиях заказчик сам не знает и не может объяснить, чего же он в итоге хочет («чтоб было круто» — это не желание, это ощущение);
2. из-за п.1 бегать вверх-вниз по ступенькам водопада можно до бесконечности, как только проект переваливает определенную сложность (у нас в команде буквально за неделю аж 3 таких проекта появилось, притом так, что мы даже пока не знаем, в каких сроки и стоимость это получится уложить)

То, что вы озвучили в конце — это не разновидность водопада, это скорее спираль

[@xmagnusx]

Проблема каскадной модели второго типа в том, что если нам внезапно сообщили, что требования ошибочны, а мы уже на этапе тестирования, то необходимо будет вернуться назад к первому шагу, а затем снова бежать по водопаду вниз.

[@serhiyko]

а как иначе?
Смена требований ведь влияет на все последующие этапы…

Сменили/добавили требования — нужен анализ, нужны правки в дизайне, нужно кодирование, нужно тестирование…

[@rg_software]

Иначе — agile methods, при всех своих недостатках. В конце концов, все апологеты agile methods как раз отталкиваются в своих работах от недостатков водопада.

Одна фирма говорит: «ну а как иначе? сменили требования, дайте ещё год на работу».
А другая: «гм, ну что ж, мы были к этому готовы, дайте ещё месяц».

Подумайте, к кому заказчики пойдут :)

[@serhiyko]

По-этому нужно говорить не про то, что водопад — устаревшая утопия, а Agile — панацея, а о том, что эти методологии применимы для разных проектов.

При чем здесь мы говорим о размере проекта (Agile ведь говорит о проекта численостью 7+-2 человека), о его тематике (как подметил товарищ Greesha в своей статье, сложно представить проект по мед. или косм. программам бегущий на Agile) и конечно же желании/готовности кастомера (толи он хочет конкретный ф-л и у него есть требования, толи он подписывает контрак на год разработки и все время вам заказывает новые фичи).

[@Flammar]

сложно представить проект по мед. или косм. программам бегущий на Agile

Сложно представить проект по мед. или косм. программам, в котором "заказчик сам не знает и не может объяснить, чего же он в итоге хочет" ;-)…

[@Greesha]

В полку выбравших красную таблетку не ленящихся читать первоисточники прибыло. :)

Что интересно, когда я сделал для себя это открытие и решил поведать о нём миру, я вырезал из статьи те же самые картинки.