Методология Waterfall

Waterfall – методология управления проектами, которая заточена на каскадную разработку продуктов. Данная методология появилась полвека назад. Этот подход был описан американским ученым в области информатики Уинстоном Уокером Ройсом в 1970 году. Подход предполагает, что работа над проектом ведется последовательно, в несколько этапов, которые следуют друг за другом. Количество этих этапов может варьироваться, но суть всегда остается одна. Такое название модель получила из-за схожести схемы работы потока воды в водопаде.

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

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

Схема работы по каскадной модели состоит из 5 этапов, которые отражена на представленном ниже рисунке.

Сбор требований

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

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

Команда приступает к разработке детализированного технического задания. На этом этапе:

  1. Обсуждают и согласуют с клиентом логику работы системы, детали готового продукта;
  2. Создают описание функционала;
  3. Готовят прототип и макеты дизайна;
  4. Согласуют бюджет, планируют штат команды разработки

Реализация

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

Проверка – тестирование

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

Развертывание

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

 

 

 

 

 

 

 

 

Spread the love