Каскадная модель разработки ПО 🌊 «Waterfall» — этапы и особенности «Водопадной» модели

Что такое каскадная модель

В 1970 году Уинстон Ройс выпустил статью с концепцией новой модели разработки. Она стала известна под названием каскадной или водопадной модели. В ней процесс разработки представлен как поток, состоящий из нескольких фаз:

• Анализ проекта
• Анализ требований
• Проектирование продукта
• Разработка продукта
• Тестирование
• Поддержка

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

Краткая история «водопадной» модели Waterfall

Часто считается, что в каскадной модели перейти на предыдущий этап невозможно. Однако это не так. В оригинальной работе «MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS», включены циклы обратной связи. Обязательно откройте и просмотрите оригинальный документ, до последней страницы 😃

Если вы знакомы с Agile или Scrum то увидите что практически те же принципы включены в модель: циклы обратной связи и бережливая разработка прототипов.

Причина по которой модель не прижилась: циклы подразумевались от 2-3 месяцев на один этап. В Agile — полный цикл разработки команда проходит за 1–2 недели.

То есть, еще раз, единственное отличие «водопада» от «гибких» подходов — заключается только в длине итерации.

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

Содержание каскадной модели

Анализ проекта

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

Анализ требований

На этом этапе разработчики создают документацию со всеми требованиями заказчика. Полная документация важна, потому что:

• Разработчики в полной мере поймут цель и придумают пути решения.
• Легкая ориентация в работе. Можно точно определить, сколько работы сделано. Также, это облегчит взаимопонимание между программистами. Если возникнет ошибка, разработчик сразу покажет, в каком фрагменте проекта.
• Точное разграничение ответственности между участниками. Распределение работников известно с начала. Не возникнет ситуации, когда один человек работает за всю команду.

Проектирование продукта

На этом этапе на основе документации составляется структура ПО, устанавливаются масштабы и границы проекта. Также, сюда входят:

• Выбор языка программирования. Заранее известно, на чем и с помощью чего разработчики создадут продукт.
• Мокапы и скетчи пользовательского интерфейса программы. С ними вы увидите результат до начала работы. Также, с скетчами легко разработать первый концепт продукта. Легче показать заказчику скетч, чем объяснять по документации.
• Подробно описываются все требования к ПО и пути их реализации. Чем понятнее описать – тем легче разработчикам реализовать.
• Описание поддержки проекта после выпуска. Известно, сколько лет проект будет улучшаться после релиза.

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

Разработка продукта

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

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

Тестирование

После завершения разработки продукт проходит тщательное тестирование, состоящие из трёх последовательных частей:

• Альфа–тестирование. В нем участвуют разработчики ПО, тестирование проходит на наборе подготовленных тестов. Внимание уделяют работоспособности и соответствию требованиям заказчика.
• Бета–тестирование. Проводится командой добровольцев, тестируется почти финальный продукт. Здесь выявляются и устраняются ошибки, возникающие при использовании ПО в предполагаемых сценариях.
• Приемочное тестирование. Продукт тестируется заказчиком на тестовых сценариях, построенных на требованиях к ПО. Заказчик либо принимает проект, либо возвращает на доработку.

Поддержка

После релиза продукта наступает этап поддержки. Здесь команда разработчиков:

• Устраняет ошибки, обнаруженные при использовании ПО настоящими пользователями.
• Добавляет дополнительные функции в ПО.
• Переносит продукт на другую среду: компьютерную платформу либо операционную систему.

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

Водопадная модель разработки обладает преимуществами перед другими моделями. Вот часть её достоинств:

• Легкая структура и понятный метод. Принцип создания проекта понятен интуитивно, изучение не занимает много времени.
• Четкое определение каждого этапа работы, сопровождаемое документированием. Это помогает разработчикам, ведь точная цель известна до начала работы.
• Точное описание требований к ПО, которые не меняются по ходу работы. Заказчик не придумает новых требований и не придется с ним спорить.
• Объем нужного времени и денег известен заранее. Не возникнет ситуации, когда проект готов наполовину, а денег уже нет.
• Легкость контроля разработки. Ход выполнения проекта прослеживается согласно срокам в документации.

Недостатки каскадной модели

Разработчики критикуют каскадную модель. У неё есть недостатки:

• Из–за концепции водопада отсутствует механизм исправления ошибок. Предполагается, что разработчики не ошибаются. Для исправления ошибки цепочка этапов запускается заново, а это затраты денег и времени.
• Трудно вносить изменения. Модель предполагает полное определение требований клиента в начале проекта. Вносить изменения затратно.
• Нет перекрытия между фазами. Перейти на следующий этап можно только если завершить предыдущий, что в проектах разработки ПО сложно.
• Много времени уходит на подробную документацию.
• Необходимость жесткого управления и контроля. При недостаточном контроле сроки будут сорваны.
• Недостаточная роль заказчика. Он участвует только в начале создания проекта и на последнем этапе тестирования.
• Позднее тестирование. Ошибки и конструктивные недостатки выявляются на последних этапах разработки. Ошибки не получится решить фундаментально, помогут заплатки или работа сначала.
• Недостаточная связь с пользователями. Они могут оценить качество продукта только в конце разработки.

Примеры применения каскадной модели

Водопадную модель лучше применять в следующих случаях:

• Когда известны четкие, неизменяемые требования с понятными путями решения.
• Если разработчиками ранее создавалась система подобного типа. Если программисты уже делали систему автоматического начисления зарплаты, создать подобный продукт будет легче.
• При переносе проекта на другую платформу. Если возникла потребность сделать версию ПО для MAC OS или LINUX, водопадная модель подойдет.
• При реализации больших проектов, в которых задействовано несколько команд разработчиков.
• Для реализации относительно небольших проектов.
• Проект длится от нескольких недель до 2-3 месяцев. Требования к проекту не успевают устареть.

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

Заключение

Чтобы применять каскадную модель правильно, стоит придерживаться следующего:

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