stringtranslate.com

Модель водопада

Водопадная модель представляет собой разбиение деятельности по разработке на линейные последовательные этапы, то есть они передаются друг другу, где каждый этап зависит от результатов предыдущего и соответствует специализации задач. [1] Подход характерен для определенных областей инженерного проектирования . В разработке программного обеспечения [1] этот подход , как правило, относится к числу менее итеративных и гибких подходов, поскольку прогресс протекает в основном в одном направлении (нисходящий, как водопад ) через этапы концепции, инициации, анализа , проектирования , построения , тестирования , развертывания и внедрения. обслуживание . [2] Водопадная модель — это самый ранний подход SDLC , который использовался при разработке программного обеспечения. [3]

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

История

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

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

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

Самое раннее использование термина «водопад», возможно, было в статье Белла и Тайера 1976 года. [13] [ нужен лучший источник ]

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

Модель

Хотя Ройс никогда не рекомендовал и не описывал каскадную модель, [16] жесткое следование следующим этапам подвергается критике со стороны него:

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

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

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

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

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

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

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

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

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

Критика

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

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

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

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

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

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

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

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

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

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

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

Заметки Ройса об окончательной модели:

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

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

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

  1. ^ Аб Петерсен, Кай; Волин, Клаас; Бака, Деян (2009). «Модель водопада в крупномасштабном развитии». В Бомариусе, Фрэнк; Ойво, Маркку; Яринг, Пяйви; Абрахамссон, Пекка (ред.). Улучшение процесса разработки программного обеспечения, ориентированного на продукт . Конспекты лекций по обработке деловой информации. Том. 32. Берлин, Гейдельберг: Шпрингер . стр. 386–400. Бибкод : 2009pfsp.book..386P. дои : 10.1007/978-3-642-02152-7_29. ISBN 978-3-642-02152-7.
  2. ^ Том Гилб . «Эволюционное развитие» против «модели водопада»«. Замечания по разработке программного обеспечения ACM SIGSOFT . 10 (3): 49–61. doi : 10.1145/1012483.1012490.Значок открытого доступа
  3. ^ Линда Шеррелл (2013). «Модель водопада». Энциклопедия наук и религий (АЛК Рунехов; Л. Овьедо (ред.)) . Дордрехт , Нидерланды: Springer : 2343–2344. дои : 10.1007/978-1-4020-8265-8_200285. ISBN 978-1-4020-8264-1.
  4. ^ Андреас П. Шмидт; Кристин Кунцманн (16 сентября 2014 г.). Проектирование для развития знаний: от программного обеспечения, основанного на знаниях, до поддержки развития знаний . i-KNOW '14: Материалы 14-й Международной конференции по технологиям знаний и бизнесу, управляемому данными. АКМ . стр. 1–7. дои : 10.1145/2637748.2638421.
  5. ^ США, Консультативная группа ВМС по математическим вычислениям (29 июня 1956 г.), Симпозиум по передовым методам программирования для цифровых компьютеров , [Вашингтон, округ Колумбия]: Управление военно-морских исследований, Департамент ВМФ, OCLC  10794738
  6. ^ Бенингтон, Герберт Д. (1 октября 1983 г.). «Производство больших компьютерных программ» (PDF) . IEEE Анналы истории вычислений . 5 (4). Отдел образовательной деятельности IEEE: 350–361. дои : 10.1109/MAHC.1983.10102. S2CID  8632276 . Проверено 21 марта 2011 г.Архивировано 18 июля 2011 года в Wayback Machine .
  7. ^ Ларман, Крейг; Базили, Виктор (июнь 2003 г.). «Итеративная и поэтапная разработка: краткая история» (PDF) . Компьютер . 36 (6): 47–56. дои : 10.1109/MC.2003.1204375.
  8. ^ abcd Royce, Winston (1970), «Управление разработкой больших программных систем» (PDF) , Proceedings of IEEE WESCON , 26 (август): 1–9
  9. ^ «Водопад». Бременский университет – математика и информатика .
  10. ^ Аббас, Нура; Гравелл, Эндрю М.; Уиллс, Гэри Б. (2008). «Исторические корни гибких методов: откуда взялось «гибкое мышление»?» (PDF) . В Абрахамссоне, Пекка; Баскервиль, Ричард; Конбой, Киран; Фицджеральд, Брайан; Морган, Лоррейн; Ван, Сяофэн (ред.). Гибкие процессы в программной инженерии и экстремальном программировании . Конспекты лекций по обработке деловой информации. Том. 9. Берлин, Гейдельберг: Шпрингер . стр. 94–103. дои : 10.1007/978-3-540-68255-4_10. ISBN 978-3-540-68255-4.
  11. ^ Конрад Вайсерт, Методика водопада: такого не существует!
  12. ↑ Линебергер, Роб (25 апреля 2024 г.). Наследование Agile: Руководство для ИТ-практиков по управлению разработкой программного обеспечения в пост-Agile-мире. Дарем, Северная Каролина: Sandprint Press. п. 36. ISBN 9798989149605.
  13. ^ Белл, Томас Э. и Т.А. Тайер. Требования к программному обеспечению: действительно ли они проблема? Материалы 2-й международной конференции по программной инженерии. Издательство IEEE Computer Society, 1976.
  14. ^ ab DOD-STD-2167 - Военный стандарт: Разработка программного обеспечения оборонных систем» . Министерство обороны Соединенных Штатов Америки. 04.06.1985. стр. 11.
  15. ^ «Разработка программного обеспечения для системы военной обороны» (PDF) .
  16. ↑ Линебергер, Роб (25 апреля 2024 г.). Наследование Agile: Руководство для ИТ-практиков по управлению разработкой программного обеспечения в пост-Agile-мире. Дарем, Северная Каролина: Sandprint Press. п. 37. ИСБН 9798989149605.
  17. ^ abc МакКоннелл, Стив (1996). Быстрая разработка: укрощение диких графиков работы программного обеспечения. Майкрософт Пресс. ISBN 1-55615-900-5.
  18. ^ «Модель разработки программного обеспечения «Водопад»» . 5 февраля 2014 года . Проверено 11 августа 2014 г.
  19. ^ Технологии Arcisphere (2012). «Учебное пособие: жизненный цикл разработки программного обеспечения (SDLC)» (PDF) . Проверено 13 ноября 2012 г.
  20. ^ Хьюи, Дуглас (2009). «Сравнение традиционного системного анализа и проектирования с гибкими методологиями». Университет Миссури — Сент-Луис . Проверено 11 августа 2014 г.
  21. ^ Парнас, Дэвид Л.; Клементс, Пол К. (1986). «Процесс рационального проектирования: как и зачем его подделывать» (PDF) . Транзакции IEEE по разработке программного обеспечения (2): 251–257. дои : 10.1109/TSE.1986.6312940. S2CID  5838439 . Проверено 21 марта 2011 г.
  22. ^ МакКоннелл, Стив (2004). Код завершен, 2-е издание. Майкрософт Пресс. ISBN 1-55615-484-4.
  23. ^ Энсменгер, Натан (2010). Компьютерные мальчики берут верх . МТИ Пресс. п. 42. ИСБН 978-0-262-05093-7.
  24. ^ Ларман, Крейг; Базили, Виктор (2003). «Итеративная и поэтапная разработка: краткая история». IEEE-компьютер . 36 (6) (ред. июня): 47–56. дои : 10.1109/MC.2003.1204375. S2CID  9240477.
  25. ^ «Методология: методы проектирования».

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

Викискладе есть медиафайлы, связанные с моделями Waterfall .

маловодный;дизайн