Водопадная модель представляет собой разбиение деятельности по разработке на линейные последовательные этапы, то есть они передаются друг другу, где каждый этап зависит от результатов предыдущего и соответствует специализации задач. [1] Подход характерен для определенных областей инженерного проектирования . В разработке программного обеспечения [1] он , как правило, относится к числу менее итеративных и гибких подходов, поскольку прогресс протекает в основном в одном направлении («вниз», как водопад ) через фазы концепции, инициации, анализа , проектирования , конструирования , тестирования и т. д . развертывание и обслуживание . [2] [ нужен лучший источник ] Водопадная модель — это самый ранний подход SDLC , который использовался при разработке программного обеспечения. [ нужна цитата ]
Водопадная модель разработки зародилась в обрабатывающей и строительной отраслях, где высокоструктурированная физическая среда означала, что изменения в конструкции стали непомерно дорогими гораздо раньше в процессе разработки. [ нужна ссылка ] Когда этот метод впервые был принят для разработки программного обеспечения, не было признанных альтернатив творческой работе, основанной на знаниях. [3] [ нужен лучший источник ]
Первая известная презентация, описывающая использование таких этапов в разработке программного обеспечения, была проведена Гербертом Д. Бенингтоном на симпозиуме по передовым методам программирования для цифровых компьютеров 29 июня 1956 года. [4] Эта презентация была посвящена разработке программного обеспечения для SAGE . В 1983 году статья была переиздана с предисловием Бенингтона, в котором он объяснял, что этапы были намеренно организованы в соответствии со специализацией задач, и указывал, что процесс на самом деле не выполнялся строго сверху вниз, а зависел от прототипа. . [3]
Хотя термин «водопад» не используется в статье, первая формальная подробная диаграмма процесса, позже известная как «модель водопада», часто [ нужна ссылка ] цитируется как статья Уинстона Ройса 1970 года . [5] [6] [7] Однако он также считал, что у него есть серьезные недостатки, связанные с тем, что тестирование проводилось только в конце процесса, который он назвал «рискованным и влекущим за собой неудачу». [5] В оставшейся части его статьи представлены пять шагов, которые, по его мнению, были необходимы для «устранения большинства рисков развития», связанных с неизменным водопадным подходом. [5]
Пять дополнительных шагов Ройса (которые включали написание полной документации на различных этапах разработки) так и не получили широкого распространения, но его диаграмма того, что он считал ошибочным процессом, стала отправной точкой при описании «водопадного» подхода. [8] [ нужен лучший источник ]
Самое раннее использование термина «водопад», возможно, было в статье Белла и Тайера 1976 года. [9] [ нужен лучший источник ]
В 1985 году Министерство обороны США зафиксировало этот подход в DOD-STD-2167A [ нужна ссылка ] — своих стандартах работы с подрядчиками по разработке программного обеспечения, в которых говорилось, что «подрядчик должен реализовать цикл разработки программного обеспечения, включающий следующие шесть этапов: «Анализ требований к программному обеспечению, предварительное проектирование, детальное проектирование, кодирование и модульное тестирование, интеграция и тестирование». [10]
Хотя Ройс никогда не рекомендовал и не описывал водопадную модель , жесткое соблюдение следующих этапов подвергается его критике :
Таким образом, водопадная модель утверждает, что переходить к определенной фазе следует только после того, как предыдущая фаза рассмотрена и проверена.
Однако различные модифицированные каскадные модели (включая окончательную модель Ройса) могут включать небольшие или существенные вариации этого процесса. [5] Эти варианты включали возврат к предыдущему циклу после того, как дефекты были обнаружены на последующих этапах, или полный возврат к этапу проектирования, если последующие этапы считались недостаточными.
Время, потраченное на ранних стадиях цикла производства программного обеспечения, может снизить затраты на более поздних этапах. Например, проблему, обнаруженную на ранних стадиях (например, в спецификации требований), исправить дешевле, чем ту же ошибку, обнаруженную позже (в 50–200 раз). [11]
В обычной практике каскадные методологии приводят к составлению графика проекта, в котором 20–40 % времени уделяется первым двум этапам, 30–40 % времени — кодированию, а остальное — тестированию и внедрению. Фактическая организация проекта должна быть высокоструктурированной. Большинство средних и крупных проектов включают подробный набор процедур и средств контроля, которые регулируют каждый процесс проекта. [12] [ не удалось проверить ]
Еще одним аргументом в пользу каскадной модели является то, что она уделяет особое внимание документации (например, документам с требованиями и проектным документам), а также исходному коду . [ нужна ссылка ] В менее тщательно разработанных и документированных методологиях знания теряются, если члены команды уходят до завершения проекта, и проекту может быть трудно оправиться от потери. Если имеется полностью работающий проектный документ (как в случае с масштабным предварительным проектированием и каскадной моделью), новые члены команды или даже совершенно новые команды должны иметь возможность ознакомиться с документами. [13]
Водопадная модель обеспечивает структурированный подход; сама модель развивается линейно через дискретные, легко понятные и объяснимые фазы и, следовательно, ее легко понять; он также обеспечивает легко идентифицируемые вехи в процессе разработки. Возможно, именно по этой причине водопадная модель используется в качестве начального примера модели разработки во многих учебниках и курсах по разработке программного обеспечения. [14]
Моделирование может сыграть ценную роль в каскадной модели. Создавая компьютеризированное или математическое моделирование разрабатываемой системы, команды могут получить представление о том, как система будет работать, прежде чем переходить к следующему этапу. Моделирование позволяет тестировать и совершенствовать проект, выявлять потенциальные проблемы или узкие места, а также принимать обоснованные решения относительно функциональности и производительности системы.
Клиенты могут не знать точно, каковы их требования, прежде чем они увидят работающее программное обеспечение, и поэтому изменят свои требования, что приведет к перепроектированию, переработке и повторному тестированию, а также к увеличению затрат. [15]
Проектировщики могут не знать о будущих трудностях при разработке нового программного продукта или функции, и в этом случае лучше пересмотреть проект, чем упорствовать в проекте, который не учитывает какие-либо вновь обнаруженные ограничения, требования или проблемы. [16]
Организации могут попытаться решить проблему отсутствия конкретных требований со стороны клиентов, нанимая системных аналитиков для изучения существующих ручных систем и анализа того, что они делают и как их можно заменить. Однако на практике трудно провести строгое разделение между системным анализом и программированием. [17] Это связано с тем, что реализация любой нетривиальной системы почти неизбежно выявит проблемы и крайние случаи, которые системный аналитик не учел.
В ответ на очевидные проблемы с чистой водопадной моделью были представлены модифицированные каскадные модели, такие как «Сашими (Водопад с перекрывающимися фазами), Водопад с подпроектами и Водопад со снижением риска». [11]
Некоторые организации, такие как Министерство обороны США, теперь отдают предпочтение методологиям каскадного типа, начиная с MIL-STD-498, выпущенного в 1994 году, который поощряет эволюционное приобретение , а также итеративную и поэтапную разработку . [18]
В ответ на очевидные проблемы с «чистой» водопадной моделью было введено множество «модифицированных водопадных моделей». Эти модели могут устранить некоторые или все критические замечания в адрес «чистой» водопадной модели.
К ним относятся модели быстрого развития, которые Стив МакКоннелл называет «модифицированными водопадами»: [11] «модель сашими» Питера ДеГрейса (водопад с перекрывающимися фазами), водопад с подпроектами и водопад с уменьшением риска. Также существуют другие комбинации моделей разработки программного обеспечения, такие как «модель поэтапного водопада». [19]
Окончательная модель Уинстона В. Ройса, его предполагаемое улучшение первоначальной «водопадной модели», продемонстрировала, что обратная связь может (должна и часто будет) вести от тестирования кода к проектированию (поскольку тестирование кода выявляет недостатки в проекте) и от проектируйте обратно в соответствии со спецификацией требований (поскольку проблемы проектирования могут потребовать удаления противоречивых или иным образом невыполнимых/неразрабатываемых требований). В той же статье Ройс также выступал за большое количество документации, выполняя работу «по возможности дважды» (это мнение сходно с мнением Фреда Брукса , известного автором «Мифического человеко-месяца», влиятельной книги по управлению программными проектами ), который выступал за планирование «выбрось один») и максимально вовлекая клиента (чувство, похожее на чувство экстремального программирования ).
Заметки Ройса об окончательной модели:
