Модель водопада - Waterfall model

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры
Немодифицированная «модель водопада». Прогресс течет сверху вниз, как ниспадающий водопад.

Модель водопада является разбивкой деятельности по проекту в линейные последовательные фазы, где каждая фаза зависит от результатов предыдущего одного и соответствуют специализациям задач. Подход типичен для определенных областей инженерного проектирования . В разработке программного обеспечения это, как правило, один из менее итеративных и гибких подходов, поскольку прогресс идет в основном в одном направлении («вниз», как водопад ) через фазы концепции, инициирования, анализа , проектирования , конструирования , тестирования , развертывания и сопровождения. .

Модель развития водопада возникла в обрабатывающей и строительной отраслях; где высокоструктурированная физическая среда означала, что изменения в конструкции стали чрезмерно дорогими гораздо раньше в процессе разработки. Когда она была впервые принята для разработки программного обеспечения, не существовало признанных альтернатив творческой работе, основанной на знаниях.

История

Первая известная презентация, описывающая использование таких этапов в разработке программного обеспечения, была проведена Гербертом Д. Бенингтоном на Симпозиуме по передовым методам программирования для цифровых компьютеров 29 июня 1956 года. Эта презентация была посвящена разработке программного обеспечения для SAGE . В 1983 году статья была переиздана с предисловием Бенингтона, в котором объяснялось, что фазы были специально организованы в соответствии со специализацией задач, и указывается, что процесс на самом деле не выполнялся строго сверху вниз, а зависел от прототипа. .

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

Пять дополнительных шагов Ройса (которые включали написание полной документации на различных этапах разработки) так и не получили широкого распространения, но его диаграмма того, что он считал ошибочным, стала отправной точкой при описании «водопадного» подхода.

Впервые термин «водопад» использовался в статье Белла и Тайера 1976 года.

В 1985 году Министерство обороны США зафиксировало этот подход в DOD-STD-2167A , своих стандартах работы с подрядчиками по разработке программного обеспечения, в которых говорилось, что «подрядчик должен реализовать цикл разработки программного обеспечения, который включает следующие шесть этапов: Анализ требований к программному обеспечению. , Эскизный проект, рабочий проект, кодирование и модульное тестирование, интеграция и тестирование ».

Модель

В оригинальной модели водопада Ройса следующие фазы выполняются по порядку:

  1. Системные и программные требования : отражены в документе с требованиями к продукту
  2. Анализ : создание моделей , схем и бизнес-правил
  3. Дизайн : в результате возникла программная архитектура
  4. Кодирование : разработка , тестирование и интеграция программного обеспечения.
  5. Тестирование : систематическое обнаружение и отладка из дефектов
  6. Операции : установка , миграция , поддержка и обслуживание полных систем.

Таким образом, водопадная модель утверждает, что к фазе следует переходить только тогда, когда ее предыдущая фаза просматривается и проверяется.

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

Подтверждающие аргументы

Время, потраченное на раннем этапе производственного цикла программного обеспечения, может снизить затраты на более поздних этапах. Например, проблему, обнаруженную на ранних этапах (например, спецификацию требований), дешевле исправить, чем ту же ошибку, обнаруженную позже в процессе (в 50–200 раз).

В обычной практике водопадные методологии приводят к тому, что в график проекта 20–40% времени уходит на первые две фазы, 30–40% времени - на кодирование, а остальное - на тестирование и внедрение. Фактическая организация проекта должна быть высоко структурированной. Большинство средних и крупных проектов будут включать подробный набор процедур и средств контроля, которые регулируют каждый процесс проекта.

Еще одним аргументом в пользу водопадной модели является то, что она делает упор на документации (такой как документы требований и проектные документы), а также на исходный код . В менее тщательно разработанных и задокументированных методологиях знания теряются, если члены команды уходят до завершения проекта, и для проекта может быть трудно оправиться от потери. Если присутствует полностью рабочий проектный документ (как это предусмотрено в Big Design Up Front и водопадной модели), новые члены команды или даже совершенно новые команды должны иметь возможность ознакомиться, прочитав документы.

Модель водопада обеспечивает структурированный подход; сама модель развивается линейно через дискретные, легко понятные и объяснимые фазы и, следовательно, ее легко понять; он также обеспечивает легко определяемые вехи в процессе разработки. Возможно, именно по этой причине модель водопада используется в качестве начального примера модели разработки во многих текстах и ​​курсах по программной инженерии.

Критика

Клиенты могут не знать точно, каковы их требования, прежде чем они увидят работающее программное обеспечение и, таким образом, изменят свои требования, что приведет к перепроектированию, переработке и повторному тестированию, а также к увеличению затрат.

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

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

В ответ на предполагаемые проблемы с чистой моделью водопада были введены модифицированные модели водопада, такие как «Сашими (водопад с перекрывающимися фазами), водопад с подпроектами и водопад с уменьшением риска».

Некоторые организации, такие как Министерство обороны США, теперь заявили о предпочтении методологий водопадного типа, начиная с MIL-STD-498 , который поощряет эволюционное приобретение и итеративную и инкрементную разработку .

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

Фазы Rational Unified Process (RUP) признают программную потребность в контрольных точках, чтобы поддерживать проект в нужном русле, но поощряют итерации (особенно в рамках дисциплин) внутри фаз. Фазы RUP часто называют «водопадными».

Модифицированные модели водопада

В ответ на предполагаемые проблемы с «чистой» моделью водопада было введено множество модифицированных моделей водопада . Эти модели могут отражать некоторые или все критические замечания по поводу «чистой» модели водопада.

К ним относятся модели быстрого развития, которые Стив МакКоннелл называет «модифицированными водопадами»: «модель сашими» Питера ДеГрейса (водопад с перекрывающимися фазами), водопад с подпроектами и водопад с уменьшением риска. Также существуют другие комбинации моделей разработки программного обеспечения, такие как «инкрементная водопадная модель».

Последняя модель Ройса

Ройс финальная модель

Последняя модель Уинстона У. Ройса , его предполагаемое улучшение первоначальной «водопадной модели», проиллюстрировала, что обратная связь может (должна и часто будет) вести от тестирования кода к дизайну (поскольку тестирование кода выявляет недостатки в дизайне) и от возвращение дизайна в соответствие со спецификацией требований (поскольку проблемы проектирования могут потребовать удаления конфликтующих или иным образом невыполнимых / не подлежащих проектированию требований). В той же статье Ройс также выступал за большой объем документации, выполняя эту работу «дважды, если возможно» (мнение, аналогичное мнению Фреда Брукса , известного своим автором «Мифического месяца человека», влиятельной книги по управлению проектами программного обеспечения , который выступал за планирование "выбросить один") и максимально вовлечь клиента (мнение, аналогичное настроению в экстремальном программировании ).

Примечания Ройса к окончательной модели:

  1. Завершите разработку программы до начала анализа и кодирования
  2. Документация должна быть актуальной и полной.
  3. Если возможно, проделайте эту работу дважды
  4. Тестирование необходимо планировать, контролировать и контролировать.
  5. Вовлекайте клиента

Смотрите также

использованная литература

внешние ссылки