Обзор водопадной модели разработки, ее особенностей, преимуществ и недостатков для проектов по созданию программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

• Поддержка

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

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

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

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

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

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

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

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

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

• Разработчики в полной мере поймут цель и придумают пути решения.

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

• Точное разграничение ответственности между участниками. Распределение работников известно с начала. Не возникнет ситуации, когда один человек работает за всю команду.

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

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

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

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

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

• Описание поддержки проекта после выпуска. Известно, сколько лет проект будет улучшаться после релиза.

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

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

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

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

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

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

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

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

• Приемочное тестирование. Продукт тестируется заказчиком на тестовых сценариях, построенных на требованиях к ПО. Заказчик либо принимает проект, либо возвращает на доработку.

Поддержка

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

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

• Добавляет дополнительные функции в ПО.

• Переносит продукт на другую среду: компьютерную платформу либо операционную систему.

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

• Легкая структура и понятный метод. Принцип создания проекта понятен интуитивно, изучение не занимает много времени.

• Четкое определение каждого этапа работы, сопровождаемое документированием. Это помогает разработчикам, ведь точная цель известна до начала работы.

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

• Объем нужного времени и денег известен заранее. Не возникнет ситуации, когда проект готов наполовину, а денег уже нет.

• Легкость контроля разработки. Ход выполнения проекта прослеживается согласно срокам в документации.

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

• Из–за концепции водопада отсутствует механизм исправления ошибок. Предполагается, что разработчики не ошибаются. Для исправления ошибки цепочка этапов запускается заново, а это затраты денег и времени.

• Трудно вносить изменения. Модель предполагает полное определение требований клиента в начале проекта. Вносить изменения затратно.

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

• Много времени уходит на подробную документацию.

• Необходимость жесткого управления и контроля. При недостаточном контроле сроки будут сорваны.

• Недостаточная роль заказчика. Он участвует только в начале создания проекта и на последнем этапе тестирования.

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

• Недостаточная связь с пользователями. Они могут оценить качество продукта только в конце разработки.

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

• Когда известны четкие, неизменяемые требования с понятными путями решения.

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

• При переносе проекта на другую платформу. Если возникла потребность сделать версию ПО для MAC OS или LINUX, водопадная модель подойдет.

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

• Для реализации относительно небольших проектов.

• Проект длится от нескольких недель до 2-3 месяцев. Требования к проекту не успевают устареть.

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

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

• Следите за настроением в коллективе и быстро решайте конфликты. Не допускайте напряженности в команде, ведь это повлияет на скорость и качество разработки.

• Не выполняйте работы параллельно. Это приведет к ошибкам и тратам времени и денег.

• Тщательно контролируйте расходы и процесс работы над проектом. В этом поможет подробная документация.

• Соблюдайте документацию и указанные сроки.