Каскадная модель: различия между версиями

[отпатрулированная версия][непроверенная версия]
Содержимое удалено Содержимое добавлено
м r2.6.4) (робот добавил: et:Koskmudel
термин "каскадная модель" лучше отражает суть методологии, чем "водопад". В русскоязычных книгах применяется именно первый перевод
Строка 1:
{{Разработка программного обеспечения}}
'''МодельКаскадная водопадамодель''' ({{lang-en|waterfall model}}) — модель процесса [[разработка программного обеспечения|разработки программного обеспечения]], в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия «водопад» часто указывают статью, опубликованную У. У. Ройсом (''W. W. Royce'') в [[1970 год]]у; забавно, что сам Ройс использовал [[Итеративная разработка|итеративную модель разработки]] и даже не использовал термин «водопад».
 
== Содержание модели ==
 
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «моделькаскадная водопадамодель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.
 
В оригинальной модели водопада Ройса, следующие фазы шли в таком порядке:
Строка 15:
# Поддержка
 
Следуя моделикаскадной водопадамодели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.
 
Тем самым, моделькаскадная водопадамодель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.
 
Тем не менее, существуют модифицированные моделикаскадные водопадамодели (включая модель самого Ройса), имеющие небольшие или даже значительные вариации описанного процесса.
 
== Критика моделикаскадной Водопадамодели и гибридные методологические решения ==
 
Методику «ВодопадаКаскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству.<ref>[http://www.microsoftproject.ru/articles.phtml?aid=158#agile Критика известных экспертов PMI концепции «водопада» в PMBOK 3]</ref> Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие [[риск]]и проекта и сделать его более [[Прозрачность|прозрачным]]. Поэтому даже в [[PMBOK]] 3-ей версии формально была закреплена только методика «Водопадакаскадной модели» и не были предложены альтернативные варианты, известные как [[Итеративная разработка|итеративное ведение проектов]].
 
Начиная с [[PMBOK]] 4-ой версии удалось достичь компромисса между [[методолог]]ами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на [[Гибкая методология разработки|гибкие итеративные методы]].<ref>[http://www.microsoftproject.ru/articles.phtml?aid=158#cycle PMBOK 4 — Новая философия итеративного управления проектами (Project Life Cycle)]</ref> Таким образом, начиная с 2009 года, формально [[Институт по Управлению Проектами|Институтом Проектного Менеджмента (PMI)]] предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.