Методология «ВОДОПАД» (WATERFALL)

We use cookies. Read the Privacy and Cookie Policy

«ВОДОПАД» (WATERFALL) – Традиционная, классическая методология управления проектом. Она также носит название «каскадной» или «поточной» модели, вследствие того, что предлагаемая ею последовательность фаз напоминает водопад. Наиболее очевидный способ сделать свой проект более управляемым – это разбить его процессы реализации на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. Данный подход не предполагает возврата к предыдущим этапам по их завершению и принятию, или внесение изменений в требования проекта. Данная методология управления проектами предполагает разбиение проекта на ряд последовательных задач, с четким определением целей и сроков. Члены проекта выполняют задания в установленном порядке, завершая каждое задание перед тем, как преступать к последующему. В «водопадной» модели, в применении к ИТ проектам разработки программного обеспечения, стадии идут в следующем порядке:

•Определение требований

•Проектирование

•Конструирование («реализация» или «кодирование»)

•Интеграция

•Тестирование и отладка («верификация»)

•Инсталляция

•Поддержка

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

Сильные стороны классического проектного менеджмента – является то, что он требует от заказчика или руководства компании определить, что же они хотят получить, уже на первом этапе проекта. Раннее включение привносит определённую стабильность в работу проекта, а планирование позволяет упорядочить реализацию проекта. Кроме того, этот подход подразумевает мониторинг показателей и тестирование, что совершенно необходимо для реальных проектов. Потенциально, классический подход позволяет избежать стрессов ввиду наличия запасного времени на каждом этапе, заложенного на случай каких-либо осложнений и реализации рисков. Кроме того, с правильно проведённым этапом планирования, руководитель проектов всегда знает, какими ресурсами он обладает, даже если эта оценка не всегда точная. Основные преимущества: возможность заранее посчитать стоимость реализации решения и контроль состояния на всех этапах жизненного цикла управления проектом.

Слабые стороны классического проектного менеджмента – не толерантность к изменениям. Если в вашем проекте ресурсы и время не являются ключевыми ограничениями, а содержание проекта подвержено изменениям – возможно вам стоит присмотреться к другим системам управления проектами. Кроме этого, в реальных ИТ проектах довольно сложно на начальном этапе сформулировать детальные требования к конечному проекту.

Данный текст является ознакомительным фрагментом.