Плюсы и минусы водопадной разработки программного обеспечения

Что такое водопадная модель?

Водопадная модель существует уже более 50 лет. Впервые она была описана в 1970 г. (Dr. Winston W Royce) как одна из самых первых формальных моделей процесса разработки программного обеспечения.

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

Оригинальная модель Waterfall состояла из пяти этапов:

• Требования
• Проектирование
• Реализация
• Верификация
• Сопровождение

Существует несколько общепризнанных водопадных методологий. Одна из них - PRINCE2, которая была создана правительством Великобритании и до сих пор пользуется большим уважением в государственном секторе.

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

Каковы плюсы и минусы водопадной разработки?

Плюсы:

• Все быстро входят в курс дела. Поскольку техническая документация является необходимой частью начального этапа разработки требований, это означает, что все понимают цели. Новые разработчики могут быстро войти в курс дела - даже на этапе сопровождения.
• Соблюдение временных рамок. Поэтапный цикл разработки обеспечивает дисциплину. Каждый этап имеет четко определенную начальную и конечную точку, что позволяет легко контролировать ход работ. Это позволяет сократить "отставание" проекта от согласованных сроков.
• Отсутствие финансовых сюрпризов. После определения требований можно с достаточно высокой степенью точности оценить затраты.
• Тестирование упрощается. Тестовые сценарии уже подробно описаны в функциональной спецификации на этапе разработки требований, что делает процесс тестирования более простым и прозрачным.
• Результат кристально ясен. Еще до начала разработки программного обеспечения детально прорабатывается дизайн, что делает потребности и результат понятными для всех.
• Решение проблем на этапе разработки. Потенциальные проблемы разработки могут быть изучены и решены на этапе проектирования, а альтернативные решения запланированы до начала программирования.
• Что планируешь, то и получаешь. Многие организации ценят внимание к документации на начальном этапе, поскольку это означает, что конечный продукт не преподнесет никаких сюрпризов.

Минусы:

• Потребности могут быть трудноопределимыми. Клиентам может быть сложно сформулировать свои потребности в виде функциональной спецификации на этапе разработки требований. Это означает, что после ознакомления с конечным продуктом они могут изменить свое мнение, что трудно устранить, если приложение придется перепроектировать в значительной степени.
• Потенциальное отсутствие гибкости. Могут возникнуть проблемы с гибкостью модели для учета новых разработок или изменений требований, которые могут произойти после первоначальной консультации. Изменения, связанные с бизнес-планами или влиянием рынка, могут быть не учтены при предварительном планировании.
• Более длительный срок реализации. По сравнению с использованием итеративной методологии, такой как Agile, реализация проектов может занять больше времени.

Для каких проектов лучше всего подходит водопадная разработка

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

Во многих случаях подлинное двустороннее взаимодействие между разработчиками и заказчиками начинается только после того, как заказчик сможет увидеть модель в действии. (Для сравнения, Agile-разработка позволяет заказчику видеть фрагменты рабочего кода, который разрабатывается и демонстрируется на протяжении всего процесса).

Исходя из этих плюсов и минусов, водопадная разработка обычно рекомендуется для проектов, в которых не ожидается изменений или необходимости в новых разработках в течение жизненного цикла проекта.