В качестве источника названия часто указывают статью, опубликованную У. Ройсом (W. W. Royce) в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки. Ройсом в 1970 году; при том, что сам Ройс использовал итеративную модель разработки. Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО.
Команда детализирует техническое задание и обсуждает с клиентом логику работы. На этом этапе формируется бэклог, создаются макеты, устанавливается количество участников и часов, необходимых для создания продукта. https://deveducation.com/ Если необходима гибкость во внесении в продукт изменений, постоянное взаимодействие с заказчиком, а также возможность видеть прогресс на каждой стадии разработки, предпочтительнее использовать методологию Agile.
Истории
Данный недостаток каскадной модели в общем-то является одним из проявлений предыдущего. Поэтапная и последовательная работа над проектом может быть следствием то го, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на последующих стадиях работы над проектом. Поэтому, после того как ошибки проявятся, проект возвращается на предыдущий этап, перерабатывается и снова передается каскадная модель на последующую стадию. Это может служить причиной срыва графика работ и усложнения взаимоотношений между группами разработчиков, выполняющих отдельные этапы работы. Самым же неприятным является то, что недоработки предыдущего уровня могут обнаруживаться не сразу на последующем уровне, а позднее (например, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной области).
Например, при строительстве дома не получится переделать фундамент, если в нем нашли проблемы на стадии возведения стен и крыши. Поэтому этот подход сравнивают с каскадом и иногда называют водопадной моделью или waterfall-методологией. Чем отличается работа по гибкой методологии и почему сейчас Agile популярнее каскадной модели?
Жизненный цикл программного обеспечения ИС
Многие ошибки анализа, проектирования и реализации могут быть выявлены только на последующих этапах или только в ходе эксплуатации. Устранение таких ошибок представляет трудоемкую задачу, связанную с дополнительными неоправданными издержками. Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ИС зафиксированы в виде технического задания на все время ее создания.
После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой
Недостатки и преимущества waterfall. Гибридные методологии
функциональности и устранение ошибок. Тем не менее, существуют модифицированные каскадные модели (включая модель самого Ройса), имеющие небольшие или даже значительные вариации описанного процесса. Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK 3-ей версии формально была закреплена только методика «каскадной модели» и не были предложены
альтернативные варианты, известные как итеративное ведение проектов.
Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал вид, представленный на рис. Каскадный подход хорошо зарекомендовал себя при построении относительно простых ИС, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем.
Крупных функциональных элементов, и включают хронологию, по которой можно понять, когда та или иная возможность станет доступной. Дорожную карту можно изменять по ходу работы и при получении командой новой информации (допускаются незначительные и масштабные изменения). Дорожная карта должна учитывать как текущие условия, которые влияют на проект, так и долгосрочные цели, чтобы команда могла эффективно работать с заинтересованными сторонами и реагировать на конкурентную среду.
Команда составляет документацию, рассчитывает бюджет и сроки выполнения задания, оценивает вероятные риски. Планирование заканчивается подготовкой инструкций, где прописаны характеристика программы и стратегия действий. Каскадная модель создания программного обеспечения является негибкой. В процесс невозможно вносить изменения, каким будет результат, известно заранее. Команда должна строго следовать инструкции и выполнять утвержденное задание. Agile-процессы не будут работать, если между участниками команды нет полного доверия.
- Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени.
- В проработку технического задания входят пожелания заказчика, планирование графика работ, учет потенциальных рисков и другое.
- Такой подход к процессу разработки помог оптимизировать работу многих компаний-разработчиков программного обеспечения.
- После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований.
При этом все участники соглашаются с тем, что изначальные требования должны оставаться неизменными в соответствии с договором. Всего один упущенный срок или изменение области работ при каскадном подходе к проекту могут оказать несоразмерное влияние на будущие релизы. Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков.