Каскадная модель основана на последовательном выполнении этапов разработки. При этом не возврат на предыдущие этапы, не перескакивание с этапа на этап не допускаются. Заказчик не всегда готов сказать, чего он хочет — не всегда он это знает. На случай большой неопределенности и придумали гибкие https://deveducation.com/ методологии.
Особенности водопадной модели разработки
Как будто водопадный подход придумал не разработчик программного обеспечения, а государство и крупные корпорации. Водопадную модель чаще всего сравнивают с другой методологией — Agile. Если не вдаваться в подробности, во главу угла в Agile ставится качество продукта и удовлетворенность заказчика, а также скорость реализации проекта. Первые упоминания о методологии относятся к 1970 году, а автором подхода считают американского Язык программирования программиста Уинстона Ройса.
Модель водопада: как работает методология Waterfall
Каждый этап подразумевает детальное планирование и полную корректность результата этапа. За недостаточную гибкость, за громоздкость, waterfall это за обязательную формализацию управления проектом в ущерб срокам, бюджету и даже качеству. Но для больших проектов как раз в формализации и есть большая ценность — она помогает минимизировать многие риски и делает работу над продуктом прозрачной. А с 2009 года в PMBOK внесен гибридный вариант, который сочетает преимущества каскадного подхода и итеративных методологий.
Чем «водопадный» подход отличается от аджайла
Не могу утверждать, что Ройс первопроходец. Появление каскадной модели стало скорее ошибкой. Ученый написал статью, в которой обсуждал недостатки каскадного подхода и предлагал его доработать — сам он использовал итеративную методологию. Это принципы работы и положения манифеста. Никакой бюрократии, люди важнее документов, заказчик важнее ТЗ, изменения важнее плана… Тьфу, сопли. Каскадный метод — это хардкор, формальность и жесткие контрактные ограничения.
Waterfall методология разработки
Чтобы исключить дальнейшие проблемы, кое-какое время команда продолжает следить за продуктом — чтобы все работало. По договоренности с клиентом собирается команда техподдержки и построектного обслуживания. Вообще в разных источниках можно встретить с десяток разных вариаций и гибридных представлений к каскадного подхода.
На это уходит много времени, иногда этап проверки длится неделями. Такие жёсткие ограничения последовательности позволяет построить процесс разработки, который максимально прозрачен и удобен для Заказчика. Строгий менеджмент, четкая последовательность работ, жесткие требования регламентов. Это исключает расхлябанность членов команды даже при отсутствии полной вовлеченности. У каждого есть инструкция, за невыполнение которой можно получить по голове. Вопрос реализации по прежнему пока не затрагивается.
- Обычно на этом этапе начинаются проблемы — вылазят косяки.
- И так далее, но самое важное — следующий этап начинается только тогда, когда успешно закончен предыдущий.
- Каждый этап подразумевает детальное планирование и полную корректность результата этапа.
- Тестирование всегда намечено на конец разработки.
Массовый потребитель на выходе может получить продукт, который не отвечает его требованиям. Работа продукта протестирована и отлажена, косяки исправлены. Проект можно передавать заказчику и вводить в эксплуатацию.
На сегодняшний день водопадная модель разработки ПО практически не используется из-за малой гибкости модели. Однако её продолжают использовать из-за высокой прозрачности разработки. Благодаря высокому уровню формализации, управлять таким проектом значительно проще. Принято считать, что каскадная модель разработки снижает риски и вносит ясность в процесс разработки, когда над проектом работает несколько десятком человек. Эта модель подразумевает строго последовательное и однократное выполнение каждой фазы проекта. Переход от одной фазы к другой возможен только после успешного завершения предыдущего этапа.
Каскадная модель подходит при разработки сложных и больших проектов и систем со строго определённой функциональностью. Использовать при разработке больших гос.заказов или научных разработках. Использовать данную методология для разработки бизнес-приложений крайне не желательно.
Поэтому предлагаю изложить схему работы по каскадной модели вот так. Подход предполагает, что работа над проектом ведется последовательно, в несколько этапов, следующих друг за другом. Количество этих этапов, их содержание, а иногда и последовательность могут меняться, но суть всегда остается одна.
Сегодня по ней мало кто работает, но без этой модели не придумали бы agile. Если сравнивать методологии, то Waterfall — это жесткий и заранее известный результат. Agile — гибкость при работе над каждым этапом, направленная на достижение наилучшего результата. А результат зависит от того, насколько эффективно работает команда. Пока дело не дошло до разработки, изменения вполне допустимы.
А после тестирования почти всегда идет устранение выявленных недочетов. И так далее, но самое важное — следующий этап начинается только тогда, когда успешно закончен предыдущий. Как помните, аджайл — это итеративный подход. Работа ведется короткими фиксированными итерациям. Скажем, команда создает какой-то функционал в течение 2 недель, а потом смотрит на него и корректирует общий план.
Тестирование всегда намечено на конец разработки. Если разработкой занимаются профаны и просто бездари, руководство узнает об этом, когда будет слишком поздно. Если будут просто косяки, команде проще закрыть их заплатками, чем начинать разработку с нуля. Результат — плачевные последствия, плохой продукт и недовольный заказчик. Ее нужно постоянно держать в актуальном состоянии, из-за чего работа над проектом превращается в сплошную бюрократию. Пока не согласовать детали со всеми участниками процесса, не формализовать это в виде документа, проект не сдвинется с мертвой точки.
Команда собирает и анализирует требования к проекту. Проект-менеджер изучает хотелки заказчика, формализует системные требования, потребности аудитории в функционале. Создается первая, обобщенная версия технического задания. В описанной Ройсом модели можно было возвращаться на прошлые этапы работы над проектом — для корректировки.
Основа, собранная на двух прошлых этапах, обрастает деталями, появляется целостный облик готового продукта. Руководство заранее знает, что, кто и на каком этапе будет делать. Поэтому планировать расходы, собирать команду и прогнозировать сроки гораздо проще. Продукт готов, начинается проверка его работоспособности. Обычно на этом этапе начинаются проблемы — вылазят косяки. Если вылазят критические ошибки в коде, функционал нужно исправлять.
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.
Но подготовительный этап в самом разгаре.