Waterfall методология разработки

Waterfall

Каскадная модель (англ. waterfall model, иногда переводят, как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

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

Waterfall
Waterfall

Для классической модели разработки программного обеспечения выделяют следующие этапы:

  1. Анализ требований проекта. Определяются программные требования для информационной предметной области системы.
  2. Проектирование. Разрабатывается и формулируется логически последовательная техническая характеристика программной системы. Детализация системы.
  3. Реализация ПО. Воплощение полноценного проекта.
  4. Тестирование продукта. Тестовая эксплуатация продукта
  5. Интеграция системы. Включает установку и официальную приёмку продукта.
  6. Поддержка. Предоставление технической помощи по продукту после запуска а коммерческую эксплуатацию.

Эта модель подразумевает строго последовательное и однократное выполнение каждой фазы проекта. Переход от одной фазы к другой возможен только после успешного завершения предыдущего этапа. Каждый этап подразумевает детальное планирование и полную корректность результата этапа.

Такие жёсткие ограничения последовательности позволяет построить процесс разработки, который максимально прозрачен и удобен для Заказчика.

ПРОЕКТ И ДОКУМЕНТАЦИЯ

Обратная сторона «медали» данного метода, это необходимость поддержки и постоянной актуализации документации разработки продукта. Любое изменение необходимо обязательно согласовывать с Заказчиком. А не достаточный уровень проработки требований несёт за собой увеличение бюджета и сроков проекта, которые довольно сложно оценить.

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

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

Мета информация

  • Количество процессов — 6
  • Команда — десятки человек

Минусы

  • Watrefall проект должен постоянно иметь актуальную документацию. Обязательная актуализация проектной документации. Избыточная документация
  • Очень не гибкая методологии
  • Может создать ошибочное впечатление о работе над проектом (например фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта)
  • У Заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы
  • У Пользователя нет возможности привыкать к продукту постепенно
  • Все требования должны быть известны в начале жизненного цикла проекта
  • Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выйдет из графиков
  • Отсутствует возможность учесть переделку, весь проект делается за один раз

Плюсы

  • Высокая прозрачность разработки и фаз проекта
  • Чёткая последовательность
  • Стабильность требований
  • Строгий контроль менеджмента проекта
  • Облегчает работу по составлению плана проекта и сбора команды проекта
  • Хорошо определяет процедуру по контроля качества

Применение

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

Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.

Читать про все методологии разработки

I believe in QA, все о тестировании