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

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

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

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

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

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

1. Важно, чтобы все этапы работы были задокументированы.

2. Следующий этап не начинается до того, как будет завершен предыдущий.

3. Пропуск этапов исключен.

4. Если в процессе разработки требования к продукту поменялись, необходимо внести изменения в ТЗ.

5. Нельзя откатиться на прошлый этап, чтобы что-то изменить.

6. Разработка происходит в рамках одного общего процесса создания продукта, итераций нет.

7. Выявление и исправление ошибок происходит только после окончания разработки на этапе тестирования.

8. Клиент не может участвовать в создании продукта, кроме этапа разработки ТЗ.

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

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

1. Анализ и определение требований проекта

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

2. Проектирование

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

3. Реализация

После завершения проектирования, программистами выполняется воплощение полноценного проекта. На этом этапе разработчики пишут код продукта согласно утвержденному плану, макетам и требованиям, работая четко по ТЗ.

4. Тестирование продукта

Когда код готов, начинается тестирование и отладка ПО. На этой стадии устраняют все недочеты, которые появлялись на предыдущих стадиях разработки.

5. Эксплуатация и поддержка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Клиента устраивает полное ведение проекта подрядчиком. Заказчик не собирается принимать участие в разработке, контролировать и давать обратную связь исполнителям, а желает сразу увидеть результат.

- Клиент заранее определился со сроками и знает, какой результат будет на каждой стадии разработки.

- Команде заранее известно, какими инструментами и подходами ее участники будут пользоваться, у них имеются типовые решения, на основе которых они будут работать над продуктом.

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

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