Методология разработки Waterfall: как устроена каскадная модель
![Методология разработки Waterfall: как устроена каскадная модель Методология разработки Waterfall: как устроена каскадная модель](/upload/000/u1/6/e/razrabotki-waterfall-kak-ustroena-kaskadnaja-model-photo-normal..jpg)
Термином 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.
![](/templates/default/images/avatar_micro.png)
Наверняка, все, кто хоть как-то связаны с разработкой/тестированием ПО, знают о каскадной модели и об ее особенностях:
— высокий уровень формализации процессов;
— большое количество документации;
— и конечно же, жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап.
Изображение не загружено
Ознакомившись с выдержкой из трудов Ройса, оказалось, что он предусматривал обратные связи между этапами на одном уровне (к примеру, дизайн-кодирование, кодирование-тестирование и т.д.).
Насколько я понимаю разницу, во втором варианте, в отличии от первого, речь идет о параллельных работах по двум последовательным этапам, что дает возможность на более ранних стадиях выявить ошибки предыдущего этапа жизненного цикла и решает один из весомых недостатков «классического» водопада — невозможность возврата на предыдущий этап.
К примеру, если рассмотреть параллельные работы по 2 последовательным фазам — Coding и Testing, становится очевидным, что часть программы выдается в тестирование, в то время как другая часть все еще находится на стадии разработки.
Т.е. получается, что речь действительно идет об итеративной методологии разработки ПО.
В таком случае остается вопросом, почему методология в широких кругах разработчиков и тестировщиков воспринимается ошибочно, как отображено на первом рисунке…
1. В современных условиях заказчик сам не знает и не может объяснить, чего же он в итоге хочет («чтоб было круто» — это не желание, это ощущение);
2. из-за п.1 бегать вверх-вниз по ступенькам водопада можно до бесконечности, как только проект переваливает определенную сложность (у нас в команде буквально за неделю аж 3 таких проекта появилось, притом так, что мы даже пока не знаем, в каких сроки и стоимость это получится уложить)
То, что вы озвучили в конце — это не разновидность водопада, это скорее спираль