Что такое методология Waterfall: как работает водопадная модель, где используется, отличия от Agile

Ecommerce-маркетолог
Стаж 8 лет

Вода течет строго сверху вниз, это закон физики. На этом основана методология разработки программного обеспечения Waterfall: все этапы идут строго последовательно, без возвратов на предыдущие ступени.

В статье мы рассказываем, что это за метод, как устроен, когда оправдан и чем отличается от Agile и других, более гибких подходов к разработке ПО.

Что такое методология Waterfall

Waterfall, или каскадная, «водопадная» модель разработки ПО — это одна из методологий, которую применяют при управлении проектами.

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

Каскадная модель основана на последовательном выполнении этапов разработки. При этом не возврат на предыдущие этапы, не перескакивание с этапа на этап не допускаются.

В стандартном случае (и в подходе, описанном У. Ройсом) этапов семь:

  1. Формулировка требований к задаче.
  2. Проектирование.
  3. Реализация. Обычно это непосредственно программирование и написание кода.
  4. Воплощение — объединение различных частей продукта в одно целое.
  5. Тестирование.
  6. Установка.
  7. Поддержка.
Одна из вариаций структуры каскадной модели из «Википедии>» из пяти этапов
Одна из вариаций структуры каскадной модели из «Википедии>» из пяти этапов

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

Особенности водопадной модели разработки

Главная, в отличие от других методологий, особенность Waterfall — в ней отсутствует какая-либо гибкость. У тех же Agile или Scrum этапы могут идти параллельно, возможны почти любые изменение и возвраты на предыдущие ступени. Например, устанавливаться и тестироваться могут части продукта задолго до того, как начнет вырисовываться общая картина. ПО может «допиливаться» и переделываться по ходу.

Гибкие методологии выигрывают потому, что работа делится на участки, работа над которыми идет автономно. Если кто-то зафакапил, переделывается один участок, что дешевле и быстрее. При глобальных ошибках проектирования по Waterfall приходится переделывать весь продукт.

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

Это как построить самолет: если конструктор с проектировщиком неправильно рассчитали прочность фюзеляжа, это выяснится только на испытаниях, когда борт взлетит и развалится в воздухе, если говорить предельно утрированно.

Именно поэтому Waterfall не применяют при проектировании самолетов и ограниченно используют при разработке ПО
Именно поэтому Waterfall не применяют при проектировании самолетов и ограниченно используют при разработке ПО

Как работает Waterfall

Расскажу подробно, как устроены этапы работы в каскадной модели разработки, на примере компьютерной игры.

  1. Определение требований. Технических (по сути — составление ТЗ для программистов), финансовых (определение бюджета) временных (сроки реализации проекта) и т. д. Грубо говоря, это должна быть такая-то игра, герой бегает и стреляет во врагов, бюджет миллион долларов, срок 24 месяца. Только более подробно.
  2. Проектирование. На этом этапе все требования упаковываются в документацию. Для программистов это будет логика игры, дизайн героев и многое другое. Проектирование — один из самых длительных этапов разработки по каскадной модели. О цене ошибки мы уже говорили.
  3. Реализация. Собственно, написание кода по документации, разработанной на предыдущих этапах.
  4. Воплощение — соединение частей программы в единое целое.
  5. Тестирование: проверка готовой игры на предмет ошибок. Правильнее было бы назвать этот этап пуско-наладочным: все выявленные баги устраняются либо тестировщиками, либо программистами отдела тестирования. Никто ничего не отправляет на доработку: помним, что возврат на предыдущие этапы не предусмотрен.
  6. Установка. В широком смысле — выпуск продукта на рынок и его инсталляция на устройства конечных пользователей (если речь о коробочной версии) либо доступ к облаку (если речь о предоставлении ПО по SaaS-модели).
  7. Техническая поддержка. Сопровождение продукта в эксплуатации: выпуск обновлений, устранение ошибок и т. д.

Еще одна возможная структура
Еще одна возможная структура

Преимущества и недостатки водопадной модели

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

  • Самый главный минус — невозможность ничего изменить, когда процесс разработки запущен. Если заказчик на полпути опомнился и решил добавить в ПО новый функционал, придется все далеть заново. Гибкости ноль.
  • Это долго и дорого, если сравнивать с гибкими методологиями.
  • Один продукт — один проект. Разработки нельзя распространить на другое ПО. Никакой универсальности или возможность использовать проект в качестве шаблона. Отсюда…
  • …долго и дорого. Простой пример: по одному проекту дома можно построить любое количество домов. А здесь так не выйдет: одна программа — один проект, поэтому дороже и дольше.
  • Нужно много персонала: разработчики, проектировщики, аналитики, программисты, тестировщики и так далее.
  • Критическая зависимость успеха всего проекта от качества проектирования и разработки документации.
  • Тестирование проводится в конце. Если выявлены фатальные ошибки, переделывается все с самого начала.
  • Излишняя бюрократизация процесса разработки. Часто на первый план, вместо качества ПО и удовлетворенности заказчика, выходят такие параметры, как трудозатраты, трудоемкость и другие вещи, не имеющие отношения к качеству продукта.
  • Нет места для импровизации. Если у кого-то из исполнителей возникла идея по улучшению продукта, реализовать ее не удастся.

Тем не менее, у подхода есть и сильные стороны:

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

Отличие методологии Waterfall от Agile

Водопадную модель чаще всего сравнивают с другой методологией — Agile. Если не вдаваться в подробности, во главу угла в Agile ставится качество продукта и удовлетворенность заказчика, а также скорость реализации проекта.

Здесь работа делится на несколько участков (итераций). В каждой итерации свой микроводопад: проектирование, разработка и тестирование. В результате каждая часть работы заведомо работоспособна. После того как части собираются воедино, гарантия положительного результата выше. А переделать небольшой участок проще, быстрее и дешевле, чем весь продукт.

И таких итераций может быть несколько
И таких итераций может быть несколько

В результате метод отличается гибкостью: здесь нет жестких правил и последовательностей. К тому же этапы могут зависеть один от другого. Идеи по улучшению приветствуются, и если один участок получился лучше, это положительно сказывается на всем результате. А еще приветствуется участие заказчика на всех этапах разработки.

Если сравнивать методологии, то Waterfall — это жесткий и заранее известный результат. Он зависит от качества проектирования. Agile — гибкость при работе над каждым этапом, направленная на достижение наилучшего результата. А результат зависит от того, насколько эффективно работает команда.

Когда стоит применять модель Waterfall

Несмотря на критику и недостатки, есть случаи, когда применение Waterfall вполне оправдано. Например:

  • Сложные и нестандартные проекты, к которым невозможен шаблонный подход и всю техническую документацию нужно разрабатывать с нуля.
  • Условия проекта заведомо неизменны.
  • При выполнении проекта возможна смена подрядчика, выполнение этапов разными подрядчиками, участие разных специалистов. По вменяемой документации начать проект могут одни специалисты, а закончить другие.
  • К результату проекта предъявляются четкие требования
  • Любые другие случаи, когда гибкие подходы наподобие Scrum или Agile не работают либо не устраивают заказчика.
Еще одна гибкая методология — Scrum, которую часто противопоставляют каскадной
Еще одна гибкая методология — Scrum, которую часто противопоставляют каскадной

Примеры использования каскадной методологии

Сразу оговорюсь: «водопад» совсем не обязательно используется в чистом и неизменном виде. Очень часто при разработке используется сборная солянка из методологий и их сочетаний.

Простой пример: итерации Agile могут представлять собой «микроводопады» со своей документацией, жесткой структурой и т. д.

Вообще в конце прошлого века каскадная модель применялась широко: ее использовали IBM, Microsoft, Toyota и другие гиганты. Даже сейчас в таких отраслях, как медицина, банковский сектор, не говоря уже о госзаказах, Waterfall распространен широко. Причина проста: сферы консервативны, к тому же заказчику нужно точно знать сроки, точно известен бюджет. Agile и другие гибкие технологии часто не подходят чисто по этим формальным требованиям.

Коротко о главном

  • Каскадная модель разработки ПО — такой подход, при котором этапы идут строго последовательно. Возврат на предыдущие этапы не допускается, равно как и пропуск одного из них.
  • Плюсы методологии: заранее известен бюджет и сроки, минимальное участие заказчика, высокое качество, прозрачность работы.
  • Минусы: отсутствует гибкость, высокие риски: тестируется уже готовый продукт и из-за критических ошибок придется переделывать всю работу.
  • Применение технологии оправдано там, где есть четкие и неизменные требования к результату, минимальное участие заказчика, а также для сложных нестандартных проектов.
  • Водопадная модель редко используется в чистом виде: обычно ее сочетают с более гибкими подходами Agile и Scrum.

Оценить статью
13 ответов

Комментарии

Написать комментарий
Популярные статьи автора
Узнайте стоимость продвижения сейчас
Выберите удобный способ связи:
Выберите удобный способ связи:
Введите Ваш номер телефона:
Введите адрес Вашего сайта:
Введите Ваше имя:
Нажимая кнопку «Получить предложение» вы соглашаетесь с Политикой конфиденциальности.
Введите Ваш Email:
Введите адрес Вашего сайта:
Введите Ваше имя:
Нажимая кнопку «Получить предложение» вы соглашаетесь с Политикой конфиденциальности.
Оперативно отвечаем в рабочее время: с 10:00 до 19:00
Оперативно отвечаем в рабочее время: с 10:00 до 19:00
Вы уже проголосовали
Возьмем ТОП вместе?
Нажимая кнопку «Оставить заявку» вы соглашаетесь с Политикой конфиденциальности.
Цена лидов в различных нишах
Тематика Стоимость лида (Москва/Россия)
Отдых 500
Мебель 350
Оборудование 500
Бансковские услуги 500
Безопасность 500
Организация мероприятий, концерты, праздники 500
Недвижимость 500
Строительство и отделка 500
Грузоперевозки 500
Доставка еды 350
Юридические услуги 500
Бухгалтерские услуги 500
Пластиковые окна 500
Детские товары 350
Автозапчасти 350
Образование 500
Возьмем ТОП вместе?
Нажимая кнопку «Оставить заявку» вы соглашаетесь с Политикой конфиденциальности.
Оставить заявку сейчас
Выберите интересующую услугу *
Нажимая кнопку «Оставить заявку» вы соглашаетесь с Политикой конфиденциальности.
Подпишитесь на рассылку
Не пропустите самое интересное из мира SEO и Digital. Только актуальные и самые крутые статьи.
Заявка успешно отправлена!
Наши сотрудники уже приступили к анализу Вашего сайта. Наш менеджер свяжется с вами в течение дня, спасибо!