Получите все материалы с наших курсов — бесплатно
Каскадная «Водопадная» 🌊 Модель Разработки Waterfall
Каскадная «Водопадная» 🌊 Модель Разработки Waterfall
Каскадная «Водопадная» 🌊 Модель Разработки Waterfall
Ответим в течение 30 минут — contact@leadstartup.ru
+7 495 150 42 63 — с 8:00 до 21:00 МСК

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

Каскадная модель – базовая модель создания программного обеспечения и разработка проходит последовательно от первой до последней фазы.

46 отзывов, в среднем 5 из 5

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

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

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

Каскадная модель обрела популярность в середине 90-х, сейчас её используют реже. Причина: циклы от 2-3 месяцев на один этап. Водопадную модель применяют при разработке сложных продуктов, когда реализуют проекты, где все детали известны заранее и не добавляются по ходу проекта.

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

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

Модель «Waterfall»

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

Чтобы грамотно организовать процесс создания ПО, нужно знать хотя бы одну модель разработки. Каскадная модель – базовая модель создания программного обеспечения.

Получите доступ к нашему Google–диску
Скачать модель

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

Каскадная модель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

  • Следите за настроением в коллективе и быстро решайте конфликты. Не допускайте напряженности в команде, ведь это повлияет на скорость и качество разработки.
  • Не выполняйте работы параллельно. Это приведет к ошибкам и тратам времени и денег.
  • Тщательно контролируйте расходы и процесс работы над проектом. В этом поможет подробная документация.
  • Соблюдайте документацию и указанные сроки.
Ближайшие тренинги
Онлайн
Практика в Miro
Q&A сесия
с 18:00 до 20:00 по Москве
Онлайн
Тестирование гипотез в цикличном формате, одна за одной, непрерывно, анализируя данные и принимая решения на их основе.
с 18:00 до 20:00 по Москве
Онлайн
Множество метрик и формулы на уровне математики 5-7 класса, позволяющие спрогнозировать все, что будет происходить с продуктом в процессе запуска и роста.
Курсы
Онлайн
Поддержка менторов
Доступ в чат и видео–ответы
Обучение с ПК, Android или IPhone — в удобном приложении