️ YouTube
Telegram–канал
Водопадная модель разработки ПО
Начинающему разработчику Ивану поручили создание маленькой программы. Начальство выделило команду программистов, определило требования и сроки. Иван ничего не знал о моделях разработки ПО и не смог организовать процесс создания программы. Команда сорвала сроки и превысила бюджет. Иван работал по ночам целую неделю до сдачи проекта. Он не успел доделать продукт и его чуть не уволили. А всего этого можно было избежать.
Чтобы грамотно организовать процесс создания ПО, нужно знать хотя бы одну модель разработки. Каскадная модель – базовая модель создания программного обеспечения.
Что такое каскадная модель
В 1970 году Уинстон Ройс выпустил статью с концепцией новой модели разработки. Она стала известна под названием каскадной или водопадной модели. В ней процесс разработки представлен как поток, состоящий из нескольких фаз:
- Анализ проекта
- Анализ требований
- Проектирование продукта
- Разработка продукта
- Тестирование
- Поддержка
Согласно этой модели, разработка проходит последовательно от первой до последней фазы. Пока разработчики не завершили работу над предыдущей фазой, к следующей перейти нельзя. Результаты каждого этапа проекта согласовываются и документируются.
Краткая история «водопадной» модели Waterfall
Часто считается, что в каскадной модели перейти на предыдущий этап невозможно. Однако это не так. В оригинальной работе «MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS», включены циклы обратной связи. Обязательно откройте и просмотрите оригинальный документ, до последней страницы 😃
Если вы знакомы с Agile или Scrum то увидите что практически те же принципы включены в модель: циклы обратной связи и бережливая разработка прототипов.
Причина по которой модель не прижилась: циклы подразумевались от 2-3 месяцев на один этап. В Agile — полный цикл разработки команда проходит за 1–2 недели.
То есть, еще раз, единственное отличие «водопада» от «гибких» подходов — заключается только в длине итерации.
Каскадная модель обрела популярность среди разработчиков в середине 90-х, но сейчас её используют реже. Большие компании применяют водопадную модель при разработке сложных продуктов, когда реализуют проекты, где все детали известны заранее и не добавляются по ходу проекта.
Содержание каскадной модели
Анализ проекта
На этом этапе определяется, можно ли разработать ПО. При этом, рассматриваются как технические, так и финансовые возможности компании. Разработчики определяют проблему и представляют стратегии её решения. Затем, на основе преимуществ и недостатков возможных решений выбирается подходящее. По этой стратегии и создают продукт.
Анализ требований
На этом этапе разработчики создают документацию со всеми требованиями заказчика. Полная документация важна, потому что:
- Разработчики в полной мере поймут цель и придумают пути решения.
- Легкая ориентация в работе. Можно точно определить, сколько работы сделано. Также, это облегчит взаимопонимание между программистами. Если возникнет ошибка, разработчик сразу покажет, в каком фрагменте проекта.
- Точное разграничение ответственности между участниками. Распределение работников известно с начала. Не возникнет ситуации, когда один человек работает за всю команду.
Проектирование продукта
На этом этапе на основе документации составляется структура ПО, устанавливаются масштабы и границы проекта. Также, сюда входят:
- Выбор языка программирования. Заранее известно, на чем и с помощью чего разработчики создадут продукт.
- Мокапы и скетчи пользовательского интерфейса программы. С ними вы увидите результат до начала работы. Также, с скетчами легко разработать первый концепт продукта. Легче показать заказчику скетч, чем объяснять по документации.
- Подробно описываются все требования к ПО и пути их реализации. Чем понятнее описать – тем легче разработчикам реализовать.
- Описание поддержки проекта после выпуска. Известно, сколько лет проект будет улучшаться после релиза.
Заказчик также участвует в обсуждении проекта. Возможно, у него появятся новые идеи относительно реализации. Правки в документацию вносятся до подписания договора о разработке.
Разработка продукта
Здесь разрабатываются стандарты документирования кода, наименований, инструкций для конечных пользователей. Если проект отдать другой команде программистов, им будет легче разобраться с подробной документацией, чем с спонтанными записями.
Затем, начинается разработка программного обеспечения. Программисты выполняют работу согласно проекту. Разработку делят на модули, каждый из которых создается и тестируется отдельно. Цель тестирований – определить, правильно ли работает каждая часть программы. Также, программисты находят и исправляют ошибки.
Тестирование
После завершения разработки продукт проходит тщательное тестирование, состоящие из трёх последовательных частей:
- Альфа–тестирование. В нем участвуют разработчики ПО, тестирование проходит на наборе подготовленных тестов. Внимание уделяют работоспособности и соответствию требованиям заказчика.
- Бета–тестирование. Проводится командой добровольцев, тестируется почти финальный продукт. Здесь выявляются и устраняются ошибки, возникающие при использовании ПО в предполагаемых сценариях.
- Приемочное тестирование. Продукт тестируется заказчиком на тестовых сценариях, построенных на требованиях к ПО. Заказчик либо принимает проект, либо возвращает на доработку.
Поддержка
После релиза продукта наступает этап поддержки. Здесь команда разработчиков:
- Устраняет ошибки, обнаруженные при использовании ПО настоящими пользователями.
- Добавляет дополнительные функции в ПО.
- Переносит продукт на другую среду: компьютерную платформу либо операционную систему.
Преимущества каскадной модели
Водопадная модель разработки обладает преимуществами перед другими моделями. Вот часть её достоинств:
- Легкая структура и понятный метод. Принцип создания проекта понятен интуитивно, изучение не занимает много времени.
- Четкое определение каждого этапа работы, сопровождаемое документированием. Это помогает разработчикам, ведь точная цель известна до начала работы.
- Точное описание требований к ПО, которые не меняются по ходу работы. Заказчик не придумает новых требований и не придется с ним спорить.
- Объем нужного времени и денег известен заранее. Не возникнет ситуации, когда проект готов наполовину, а денег уже нет.
- Легкость контроля разработки. Ход выполнения проекта прослеживается согласно срокам в документации.
Недостатки каскадной модели
Разработчики критикуют каскадную модель. У неё есть недостатки:
- Из–за концепции водопада отсутствует механизм исправления ошибок. Предполагается, что разработчики не ошибаются. Для исправления ошибки цепочка этапов запускается заново, а это затраты денег и времени.
- Трудно вносить изменения. Модель предполагает полное определение требований клиента в начале проекта. Вносить изменения затратно.
- Нет перекрытия между фазами. Перейти на следующий этап можно только если завершить предыдущий, что в проектах разработки ПО сложно.
- Много времени уходит на подробную документацию.
- Необходимость жесткого управления и контроля. При недостаточном контроле сроки будут сорваны.
- Недостаточная роль заказчика. Он участвует только в начале создания проекта и на последнем этапе тестирования.
- Позднее тестирование. Ошибки и конструктивные недостатки выявляются на последних этапах разработки. Ошибки не получится решить фундаментально, помогут заплатки или работа сначала.
- Недостаточная связь с пользователями. Они могут оценить качество продукта только в конце разработки.
Примеры применения каскадной модели
Водопадную модель лучше применять в следующих случаях:
- Когда известны четкие, неизменяемые требования с понятными путями решения.
- Если разработчиками ранее создавалась система подобного типа. Если программисты уже делали систему автоматического начисления зарплаты, создать подобный продукт будет легче.
- При переносе проекта на другую платформу. Если возникла потребность сделать версию ПО для MAC OS или LINUX, водопадная модель подойдет.
- При реализации больших проектов, в которых задействовано несколько команд разработчиков.
- Для реализации относительно небольших проектов.
- Проект длится от нескольких недель до 2-3 месяцев. Требования к проекту не успевают устареть.
В обязательном порядке каскадную модель разработки ПО используют при проектировании систем жизнеобеспечения. Также, по водопадной модели создаются системы контроля полета, системы подушек безопасности в авто. По каскадной модели разрабатывают ПО для научных вычислений и по госзаказам.
Заключение
Чтобы применять каскадную модель правильно, стоит придерживаться следующего:
- Следите за настроением в коллективе и быстро решайте конфликты. Не допускайте напряженности в команде, ведь это повлияет на скорость и качество разработки.
- Не выполняйте работы параллельно. Это приведет к ошибкам и тратам времени и денег.
- Тщательно контролируйте расходы и процесс работы над проектом. В этом поможет подробная документация.
- Соблюдайте документацию и указанные сроки.
