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

Методология разработки 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.

Комментарии
Всем привет. Недавно открыл для себя интересный факт, что товарищ Винстон Ройс (Dr. Winston D. Royce), анонсируя свой знаменитый Waterfall говорил об итеративной модели разработки.

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

Изображение не загружено

Ознакомившись с выдержкой из трудов Ройса, оказалось, что он предусматривал обратные связи между этапами на одном уровне (к примеру, дизайн-кодирование, кодирование-тестирование и т.д.).

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

К примеру, если рассмотреть параллельные работы по 2 последовательным фазам — Coding и Testing, становится очевидным, что часть программы выдается в тестирование, в то время как другая часть все еще находится на стадии разработки.
Т.е. получается, что речь действительно идет об итеративной методологии разработки ПО.

В таком случае остается вопросом, почему методология в широких кругах разработчиков и тестировщиков воспринимается ошибочно, как отображено на первом рисунке…
Водопад не любят не из-за того, что не понимают, его не любят из-за того, что он плохо подходит для сложных программных систем. Причин 2:
1. В современных условиях заказчик сам не знает и не может объяснить, чего же он в итоге хочет («чтоб было круто» — это не желание, это ощущение);
2. из-за п.1 бегать вверх-вниз по ступенькам водопада можно до бесконечности, как только проект переваливает определенную сложность (у нас в команде буквально за неделю аж 3 таких проекта появилось, притом так, что мы даже пока не знаем, в каких сроки и стоимость это получится уложить)

То, что вы озвучили в конце — это не разновидность водопада, это скорее спираль
Вам может быть интересно
Когда дело доходит до разработки программного обеспечения и приложений, облачные технологии стали обычным явлением в обиходе многих команд. Когда люди изучают мир облачных технологий, они часто приход...
DST Platform - система управления содержимым (CMS), используемая также как карка...
Инструменты контейнеризацииКонтейнеризация —...
Базы данных (БД) — способ хранения и организ...
Тестировать приложения можно двумя способами: вруч...
В этой статье мы поговорим о несомненных плюсах ис...
Нишевый маркетплейс — это маркетплейс, ассор...
Frontend- и backend-разработка тесно связаны между...
Потеря всех данных сайта – страшный сон предприним...
Сайты-агрегаторы услуг и товаров (маркетплейсы) ст...
Команда Битрикс24 провела масштабное нагрузочное т...
Перейти вверх