Модель водопада

Разработка программного обеспечения

Процесс разработки ПО
Шаги процесса
Анализ | Проектирование | Реализация | Тестирование | Внедрение | Сопровождение
Модели / Методы
Agile | Cleanroom | Итеративная | RAD | Scrum | RUP | OpenUP | MSF | Спиральная | Водопад | XP
Сопутствующие дисциплины
Конфигурационное управление | Документирование | Управление проектами

Модель водопада (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия «водопад» часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки и даже не использовал термин «водопад».

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

В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «модель водопада», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.

В оригинальной модели водопада Ройса, следующие фазы шли в таком порядке:

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

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

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

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

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

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

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

См. также

• Гибкая методология разработки
• Итеративная разработка
• Спиральная модель

Ссылки

• Royce, Winston (1970), Managing the Development of Large Software Systems (англ.)