Модель водопада (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

Содержание модели

Модель водопада (waterfall model или последовательная разработка) – наверное, самый известный, исторически появившийся одним из первых процесс разработки. Он был описан в статье Ройса (W.W.Royce) в 1970 году (на самом деле, Ройс критиковал этот процесс, предлагая в качестве альтернативы итеративную разработку).

Основная идея заключается в том, что процесс разработки делится на четко определенные фазы, выполняемые строго последовательно. Название «водопад» появилось из-за внешнего вида диаграммы, изображающей процесс:

Оригинальная модель водопада Ройса, отражает фазы в таком порядке:

 1. Определение требований
 2. Проектирование
 3. Конструирование (также «реализация» либо «кодирование»)
 4. Интеграция
 5. Тестирование и отладка (также «верификация»)
 6. Инсталляция
 7. Поддержка

Следуя модели водопада, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.

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

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

Критика модели Водопада и гибридные методологические решения

Практика показала следующие недостатки этого процесса:

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

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

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

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

Модель водопада является разумным выбором для типовых, стандартных проектов или при наличии жестких требований к качеству (например, при создании mission critical-систем). Тем не менее, ее недостатки весьма существенны, и для разработки коммерческого ПО, как правило, существуют значительно более эффективные альтернативы.

При управлении большими проектами формализация часто являлась очень большой ценностью, т.к. могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK 3й версии формально была закреплена только методика \»Водопада\» и не были предложены альтернативные варианты известные как итеративное ведение проектов.

Начиная с PMBOK 4й версии удалось достичь компромисса между методологами приверженными формальному и поступательному управлению проектом с методологами делающими ставку на гибкие итеративные методы.

Таким образом, начиная с 2009 года (выход PMBOK 4), формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный вариант методологи управления проектами сочетающий в себе как плюсы от методики \»Водопада\», а также достижения итеративных методологов. Более подробно с критикой этой модели можно ознакомиться тут

По этой ссылке Вы можете ознакомиться с другими моделями и процессами разработки ПО.