В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата предыдущей фазы. Однако из-за неточности какого-либо требования мы попадаем в ситуацию, когда приходится возвращаться к ранней фазе проекта. При этом требуемые изменения могут быть катастрофическими для проекта. Запретить вносить изменения в требования? Отличная идея, но неосуществима на нашей планете. Требования меняются всегда, как и меняется весь мир. Впрочем, об этом позже…

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

Короче говоря, модель водопада при всей ее красоте и очевидности применима для рытья траншеи, но не для разработки программного обеспечения. Эта модель не способна гарантировать сколько-нибудь приемлемую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности заинтересованных лиц. И таких примеров проблем, порождаемых самой природой модели, можно привести достаточно много. Достаточно много для того, чтобы не использовать эту модель. Никогда. И увольняться из тех мест, где программное обеспечение разрабатывается, опираясь на эту модель. Увольняться, пока вас не обвинили в провале проекта.

Впрочем, изменения требований или ошибки в архитектуре системы – это даже не причины неадекватности каскадной модели. Это следствия. Причина еще глубже – в невозможности вовремя получить обратную связь от мира (от заинтересованных лиц или из фактических результатов измерений производительности – не важно) и среагировать на нее. Именно слишком позднее появление обратной связи делает каскадную модель неадекватной. И именно эту проблему, проблему обратной связи, решает итеративная или, как ее еще называют, инкрементальная модель жизненного цикла.