Waterfall – методология управления проектами, которая заточена на каскадную разработку продуктов. Данная методология появилась полвека назад. Этот подход был описан американским ученым в области информатики Уинстоном Уокером Ройсом в 1970 году. Подход предполагает, что работа над проектом ведется последовательно, в несколько этапов, которые следуют друг за другом. Количество этих этапов может варьироваться, но суть всегда остается одна. Такое название модель получила из-за схожести схемы работы потока воды в водопаде.
Методология строится на 8 главных принципов:
- Документирование необходимо – все этапы работы должны быть зафиксированы;
- Каждый этап последователен – следующий этап начинается после начала предыдущего;
- Нельзя пропускать этапы плана;
- Если требования к функционалу в процессе разработке поменялись, вносим их в ТЗ (техническое задание);
- Возврат на прошлый этап невозможен, ничего менять нельзя;
- Разработка происходит в рамках одного процесса. Итераций нет;
- Работа над ошибками происходит после окончания разработки;
- Участие клиента ограничивается этапом разработки ТЗ
Схема работы по каскадной модели состоит из 5 этапов, которые отражена на представленном ниже рисунке.
Сбор требований
Команда собирает и анализирует требования к проекту. Результаты проведенного анализа собирают во входной документации, в которой описывается что команда должна в итоге сделать. Создается обобщенная версия технического задания.
Проектирование
Команда приступает к разработке детализированного технического задания. На этом этапе:
- Обсуждают и согласуют с клиентом логику работы системы, детали готового продукта;
- Создают описание функционала;
- Готовят прототип и макеты дизайна;
- Согласуют бюджет, планируют штат команды разработки
Реализация
Этот этап занимает большую часть времени проекта. Сначала решается вопрос – как будет проходить разработка, какие инструменты будет использовать команда, какие языки программирования, оборудование использовать. Потом строго следуя ТЗ разработчики пишут код, дизайнеры рисуют дизайн т.д.
Проверка – тестирование
После того, как продукт готов, начинается проверка его работоспособности. На этом этапе могут обнаружиться критические ошибки в коде, а значит функционал нужно исправлять. На это уходит много времени. В этом и заключается главный минус Waterfall. Ведь если бы использовалась гибкая методология, тогда критические ошибки были бы найдены раньше. Соответственно, время разработки и ресурсы команды сократились.
Развертывание
Работа продукта протестирована и отлажена. Проект можно передавать заказчику и вводить в эксплуатацию. Некоторое время команда следит за проектом во избежание каких-либо проблем. По договоренности с клиентом собирается команда техподдержки и постпроектного обслуживания.