Методология разработки Waterfall: как устроена каскадная модель

Термином Waterfall (в переводе с английского «водопад») называют каскадную модель управления проектами, при которой происходит последовательный переход с одного этапа на другой, при этом пропуск отдельного этапа и возврат на предыдущие стадии не предусмотрен. Переход от одной фазы разработки к другой осуществляется только после полного и успешного завершения предыдущей фазы.

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

В этом материале разберемся, как работает водопадная модель, и рассмотрим ее плюсы и минусы.

Принципы водопадной модели разработки

Методология разработки Waterfall строится на 8 главных принципах:

1. Важно, чтобы все этапы работы были задокументированы.
2. Следующий этап не начинается до того, как будет завершен предыдущий.
3. Пропуск этапов исключен.
4. Если в процессе разработки требования к продукту поменялись, необходимо внести изменения в ТЗ.
5. Нельзя откатиться на прошлый этап, чтобы что-то изменить.
6. Разработка происходит в рамках одного общего процесса создания продукта, итераций нет.
7. Выявление и исправление ошибок происходит только после окончания разработки на этапе тестирования.
8. Клиент не может участвовать в создании продукта, кроме этапа разработки ТЗ.

Как работает Waterfall

Процесс разработки при использовании каскадной водопадной модели выглядит как поток, последовательно проходящий следующие фазы:

⬇

⬇

⬇

⬇

Преимущества и недостатки каскадной модели

В последнее время водопадная модель разработки уступает позиции более гибким методологиям, таким как Agile, однако для крупных проектов и организаций она все еще актуальна по следующим причинам:

• Устойчивость к замене исполнителей. Разработчики могут приходить и уходить на протяжении всего жизненного цикла проекта, но благодаря подробному документированию изменение кадрового состава практически не влияет на процесс разработки, модель управления и сроки выполнения.
• Инструкции и правила по всему процессу разработки. Работа начинается с детального анализа требований заказчика и всех условий реализации проекта. Планы, стадии работы и процессы утверждают заранее, все данные фиксируются в документах, что в дальнейшем исключает возникновение вопросов. Исполнителям просто необходимо им следовать.
• Строгий менеджмент. Модель Waterfall заставляет разработчиков, участвующих в проекте, быть дисциплинированными, соблюдать четкую последовательность работ и жесткие требования регламентов, оставаясь в рамках намеченного плана.
• Гибкость на первых этапах работы. Изменения в первых фазах водопадного проекта могут быть произведены немедленно и с минимумом усилий, пока они не подкреплены кодом. За счет этого у заказчика и исполнителя есть значительный запас времени для кардинального изменения концепции работы программного обеспечения.
• Определенность в сроках и размере бюджета. Стоимость будущего ПО, а также сроки сдачи проекта бывают рассчитаны и утверждены в самом начале и не изменяются в процессе. Это делает работу над продуктом прозрачной и помогает руководству, заранее зная, что и кто на каком этапе будет делать, составлять план расходов, собирать команду и прогнозировать сроки исполнения.

Сегодня водопадная модель разработки ПО, которая впервые была описана в 1970 году – более чем полвека назад, из-за недостаточной гибкости и громоздкости используется нечасто.

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

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

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

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

Читайте также

Что такое Agile

Что такое скрам-доска

Отличие методологии Agile от Waterfall

Agile отличается гибким подходом к разработке программного обеспечения и хорошо подходит для применения в небольших командах.

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

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

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

Когда стоит применять модель Waterfall

Вышеназванные недостатки не мешают успешно применять методологию разработки «Водопад», если:

• Заказчик твердо знает и четко представляет, что он хочет получить. Если он заранее продумал концепцию, понимает, каким должен быть результат и не планирует вносить изменения.
• Клиента устраивает полное ведение проекта подрядчиком. Заказчик не собирается принимать участие в разработке, контролировать и давать обратную связь исполнителям, а желает сразу увидеть результат.
• Клиент заранее определился со сроками и знает, какой результат будет на каждой стадии разработки.
• Команде заранее известно, какими инструментами и подходами ее участники будут пользоваться, у них имеются типовые решения, на основе которых они будут работать над продуктом.

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

Если необходима гибкость во внесении в продукт изменений, постоянное взаимодействие с заказчиком, а также возможность видеть прогресс на каждой стадии разработки, предпочтительнее использовать методологию Agile.