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

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

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

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

История

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

Первое формальное описание модели водопада часто цитируется в статье 1970 г. Уинстон В. Ройс,[3][4] хотя Ройс не использовал термин водопад в этой статье. Ройс представил эту модель как пример несовершенной, неработающей модели; именно так этот термин обычно используется при написании статей о разработке программного обеспечения - для описания критического взгляда на широко используемую практику разработки программного обеспечения.[5]

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

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

Модель

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

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

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

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

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

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

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

Еще одним аргументом в пользу водопадной модели является то, что она делает упор на документации (такой как документы требований и проектные документы), а также исходный код. В менее тщательно разработанных и задокументированных методологиях знания теряются, если члены команды уходят до завершения проекта, и для проекта может быть трудно оправиться от потери. Если присутствует полностью рабочий проектный документ (что является целью Большой дизайн спереди и модель водопада), новые члены команды или даже совершенно новые команды должны иметь возможность ознакомиться, прочитав документы.[10]

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

Утверждается, что водопадная модель может быть адаптирована для проектов, в которых требования и объем фиксированы, сам продукт является прочным и стабильным, а технология понятна.[12]

Критика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ а б Бенингтон, Герберт Д. (1 октября 1983 г.). «Производство больших компьютерных программ» (PDF). IEEE Annals of the History of Computing. Департамент образовательной деятельности IEEE. 5 (4): 350–361. Дои:10.1109 / MAHC.1983.10102. S2CID  8632276. Получено 2011-03-21. В архиве 18 июля 2011 г. Wayback Machine
  2. ^ Соединенные Штаты, Консультативная группа по математическим вычислениям ВМФ (29 июня 1956 г.), Симпозиум по передовым методам программирования для цифровых компьютеров, [Вашингтон, округ Колумбия]: Управление военно-морских исследований, Департамент ВМФ, OCLC  10794738
  3. ^ а б Ройс, Уинстон (1970), «Управление разработкой больших программных систем» (PDF), Труды IEEE WESCON, 26 (Август): 1–9
  4. ^ Wasserfallmodell> Entstehungskontext, Маркус Рерих, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Проверено 28 ноября 2007 г. http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html
  5. ^ Конрад Вайзерт, Методология водопада: такого не бывает!
  6. ^ Белл, Томас Э. и Т. А. Тайер. Программные требования: действительно ли это проблема? Материалы 2-й международной конференции по программной инженерии. IEEE Computer Society Press, 1976.
  7. ^ "Разработка программного обеспечения для оборонных систем военного стандарта" (PDF).
  8. ^ а б c МакКоннелл, Стив (1996). Быстрая разработка: укрощение дикого расписания программного обеспечения. Microsoft Press. ISBN  1-55615-900-5.
  9. ^ «Модель разработки программного обеспечения Waterfall». 5 февраля 2014 г.. Получено 11 августа 2014.
  10. ^ Технологии Arcisphere (2012). «Учебное пособие: жизненный цикл разработки программного обеспечения (SDLC)» (PDF). Получено 2012-11-13.
  11. ^ Хьюги, Дуглас (2009). «Сравнение традиционного системного анализа и проектирования с гибкими методологиями». Университет Миссури - Сент-Луис. Получено 11 августа 2014.
  12. ^ "Когда следует использовать модель водопада?". Получено 2016-09-28.
  13. ^ Парнас, Дэвид Л .; Клементс, Пол К. (1986). «Процесс рационального проектирования: как и зачем его подделывать» (PDF). IEEE Transactions по разработке программного обеспечения (2): 251–257. Дои:10.1109 / TSE.1986.6312940. S2CID  5838439. Получено 2011-03-21.
  14. ^ МакКоннелл, Стив (2004). Код завершен, 2-е издание. Microsoft Press. ISBN  1-55615-484-4.
  15. ^ Энсменгер, Натан (2010). Компьютерные парни захватывают власть. п.42. ISBN  978-0-262-05093-7.
  16. ^ Ларман, Крейг; Базили, Виктир (2003). «Итеративная и инкрементальная разработка: краткая история». IEEE Computer (Июньское ред.). 36 (6): 47–56. Дои:10.1109 / MC.2003.1204375. S2CID  9240477.
  17. ^ Методология разработки водопадных систем… Серьезно? пользователя David Dischave. 2012 г. В архиве 2 июля 2014 г. Wayback Machine
  18. ^ «Методология: методы проектирования».

внешняя ссылка