Вода течет строго сверху вниз, это закон физики. На этом основана методология разработки программного обеспечения Waterfall: все этапы идут строго последовательно, без возвратов на предыдущие ступени.
В статье мы рассказываем, что это за метод, как устроен, когда оправдан и чем отличается от Agile и других, более гибких подходов к разработке ПО.
Что такое методология Waterfall
Waterfall, или каскадная, «водопадная» модель разработки ПО — это одна из методологий, которую применяют при управлении проектами.
На самом деле такой подход применяется не только при разработке программного обеспечения, но и при проектировании в любой другой сфере, от медицины до строительства. Первые упоминания о методологии относятся к 1970 году, а автором подхода считают американского программиста Уинстона Ройса. Но это не точно.
Каскадная модель основана на последовательном выполнении этапов разработки. При этом не возврат на предыдущие этапы, не перескакивание с этапа на этап не допускаются.
В стандартном случае (и в подходе, описанном У. Ройсом) этапов семь:
- Формулировка требований к задаче.
- Проектирование.
- Реализация. Обычно это непосредственно программирование и написание кода.
- Воплощение — объединение различных частей продукта в одно целое.
- Тестирование.
- Установка.
- Поддержка.
В других версиях методологии этапов может быть больше или меньше. Например, первым может идти формирование идеи продукта и только за тем — формулировка требований к нему. А после тестирования почти всегда идет устранение выявленных недочетов. И так далее, но самое важное — следующий этап начинается только тогда, когда успешно закончен предыдущий.
.jpg)
Особенности водопадной модели разработки
Главная, в отличие от других методологий, особенность Waterfall — в ней отсутствует какая-либо гибкость. У тех же Agile или Scrum этапы могут идти параллельно, возможны почти любые изменение и возвраты на предыдущие ступени. Например, устанавливаться и тестироваться могут части продукта задолго до того, как начнет вырисовываться общая картина. ПО может «допиливаться» и переделываться по ходу.
Гибкие методологии выигрывают потому, что работа делится на участки, работа над которыми идет автономно. Если кто-то зафакапил, переделывается один участок, что дешевле и быстрее. При глобальных ошибках проектирования по Waterfall приходится переделывать весь продукт.
Именно поэтому в каскадной модели одну из главных ролей занимает проектирование. При проектировании нужно учесть все возможные сценарии и исключить ошибки. Одна закрывающаяся ошибка способна пустить под откос весь проект: промежуточных тестирований не предусмотрено, проверяется готовый продукт.
Это как построить самолет: если конструктор с проектировщиком неправильно рассчитали прочность фюзеляжа, это выяснится только на испытаниях, когда борт взлетит и развалится в воздухе, если говорить предельно утрированно.
Как работает Waterfall
Расскажу подробно, как устроены этапы работы в каскадной модели разработки, на примере компьютерной игры.
- Определение требований. Технических (по сути — составление ТЗ для программистов), финансовых (определение бюджета) временных (сроки реализации проекта) и т. д. Грубо говоря, это должна быть такая-то игра, герой бегает и стреляет во врагов, бюджет миллион долларов, срок 24 месяца. Только более подробно.
- Проектирование. На этом этапе все требования упаковываются в документацию. Для программистов это будет логика игры, дизайн героев и многое другое. Проектирование — один из самых длительных этапов разработки по каскадной модели. О цене ошибки мы уже говорили.
- Реализация. Собственно, написание кода по документации, разработанной на предыдущих этапах.
- Воплощение — соединение частей программы в единое целое.
- Тестирование: проверка готовой игры на предмет ошибок. Правильнее было бы назвать этот этап пуско-наладочным: все выявленные баги устраняются либо тестировщиками, либо программистами отдела тестирования. Никто ничего не отправляет на доработку: помним, что возврат на предыдущие этапы не предусмотрен.
- Установка. В широком смысле — выпуск продукта на рынок и его инсталляция на устройства конечных пользователей (если речь о коробочной версии) либо доступ к облаку (если речь о предоставлении ПО по SaaS-модели).
- Техническая поддержка. Сопровождение продукта в эксплуатации: выпуск обновлений, устранение ошибок и т. д.
.jpg)
Преимущества и недостатки водопадной модели
Все беды и недостатки каскадной методологии вытекают из того, что этапы разработки идут последовательно. Начну с того, за что подход критикуют и применяют ограничено.
- Самый главный минус — невозможность ничего изменить, когда процесс разработки запущен. Если заказчик на полпути опомнился и решил добавить в ПО новый функционал, придется все далеть заново. Гибкости ноль.
- Это долго и дорого, если сравнивать с гибкими методологиями.
- Один продукт — один проект. Разработки нельзя распространить на другое ПО. Никакой универсальности или возможность использовать проект в качестве шаблона. Отсюда…
- …долго и дорого. Простой пример: по одному проекту дома можно построить любое количество домов. А здесь так не выйдет: одна программа — один проект, поэтому дороже и дольше.
- Нужно много персонала: разработчики, проектировщики, аналитики, программисты, тестировщики и так далее.
- Критическая зависимость успеха всего проекта от качества проектирования и разработки документации.
- Тестирование проводится в конце. Если выявлены фатальные ошибки, переделывается все с самого начала.
- Излишняя бюрократизация процесса разработки. Часто на первый план, вместо качества ПО и удовлетворенности заказчика, выходят такие параметры, как трудозатраты, трудоемкость и другие вещи, не имеющие отношения к качеству продукта.
- Нет места для импровизации. Если у кого-то из исполнителей возникла идея по улучшению продукта, реализовать ее не удастся.
.jpg)
Тем не менее, у подхода есть и сильные стороны:
- Команда и отдельные специалисты всегда знают, что делать. Вся работа детально и пошагово расписана.
- Всегда известны сроки и бюджет проекта.
- Прозрачность работы и полное понимание со стороны заказчика.
- Взаимозаменяемость специалистов. Благодаря подробной документации можно реализовать проект силами любой компетентной команды.
Отличие методологии Waterfall от Agile
Водопадную модель чаще всего сравнивают с другой методологией — Agile. Если не вдаваться в подробности, во главу угла в Agile ставится качество продукта и удовлетворенность заказчика, а также скорость реализации проекта.
Здесь работа делится на несколько участков (итераций). В каждой итерации свой микроводопад: проектирование, разработка и тестирование. В результате каждая часть работы заведомо работоспособна. После того как части собираются воедино, гарантия положительного результата выше. А переделать небольшой участок проще, быстрее и дешевле, чем весь продукт.
В результате метод отличается гибкостью: здесь нет жестких правил и последовательностей. К тому же этапы могут зависеть один от другого. Идеи по улучшению приветствуются, и если один участок получился лучше, это положительно сказывается на всем результате. А еще приветствуется участие заказчика на всех этапах разработки.
Если сравнивать методологии, то Waterfall — это жесткий и заранее известный результат. Он зависит от качества проектирования. Agile — гибкость при работе над каждым этапом, направленная на достижение наилучшего результата. А результат зависит от того, насколько эффективно работает команда.
Когда стоит применять модель Waterfall
Несмотря на критику и недостатки, есть случаи, когда применение Waterfall вполне оправдано. Например:
- Сложные и нестандартные проекты, к которым невозможен шаблонный подход и всю техническую документацию нужно разрабатывать с нуля.
- Условия проекта заведомо неизменны.
- При выполнении проекта возможна смена подрядчика, выполнение этапов разными подрядчиками, участие разных специалистов. По вменяемой документации начать проект могут одни специалисты, а закончить другие.
- К результату проекта предъявляются четкие требования
- Любые другие случаи, когда гибкие подходы наподобие Scrum или Agile не работают либо не устраивают заказчика.
.jpg)
Примеры использования каскадной методологии
Сразу оговорюсь: «водопад» совсем не обязательно используется в чистом и неизменном виде. Очень часто при разработке используется сборная солянка из методологий и их сочетаний.
Простой пример: итерации Agile могут представлять собой «микроводопады» со своей документацией, жесткой структурой и т. д.
Вообще в конце прошлого века каскадная модель применялась широко: ее использовали IBM, Microsoft, Toyota и другие гиганты. Даже сейчас в таких отраслях, как медицина, банковский сектор, не говоря уже о госзаказах, Waterfall распространен широко. Причина проста: сферы консервативны, к тому же заказчику нужно точно знать сроки, точно известен бюджет. Agile и другие гибкие технологии часто не подходят чисто по этим формальным требованиям.
Коротко о главном
- Каскадная модель разработки ПО — такой подход, при котором этапы идут строго последовательно. Возврат на предыдущие этапы не допускается, равно как и пропуск одного из них.
- Плюсы методологии: заранее известен бюджет и сроки, минимальное участие заказчика, высокое качество, прозрачность работы.
- Минусы: отсутствует гибкость, высокие риски: тестируется уже готовый продукт и из-за критических ошибок придется переделывать всю работу.
- Применение технологии оправдано там, где есть четкие и неизменные требования к результату, минимальное участие заказчика, а также для сложных нестандартных проектов.
- Водопадная модель редко используется в чистом виде: обычно ее сочетают с более гибкими подходами Agile и Scrum.
.png)
.png)
.png)
Комментарии