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] поскольку реализация любой нетривиальной системы часто выявляет проблемы и пограничные случаи, которые системный аналитик не рассматривал.

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

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

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

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

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

Окончательная модель Royce

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

Замечания Ройса по поводу окончательной модели следующие:

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

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

Ссылки

  1. ^ ab Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). "Модель водопада в крупномасштабной разработке". В Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (ред.). Улучшение процесса разработки программного обеспечения, ориентированного на продукт . Конспект лекций по обработке деловой информации. Том 32. Берлин, Гейдельберг: Springer . С. 386–400. Bibcode : 2009pfsp.book..386P. doi : 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). «Модель водопада». Энциклопедия наук и религий (ALC Runehov; L. Oviedo (ред.)) . Дордрехт , Нидерланды: Springer : 2343–2344. doi :10.1007/978-1-4020-8265-8_200285. ISBN 978-1-4020-8264-1.
  4. ^ Андреас П. Шмидт; Кристина Кунцманн (16 сентября 2014 г.). Проектирование для созревания знаний: от программного обеспечения, основанного на знаниях, к поддержке содействия развитию знаний . i-KNOW '14: Труды 14-й Международной конференции по технологиям знаний и бизнесу, основанному на данных. ACM . С. 1–7. doi :10.1145/2637748.2638421.
  5. ↑ Соединенные Штаты, Консультативная группа по математическим вычислениям ВМС (29 июня 1956 г.), Симпозиум по передовым методам программирования для цифровых компьютеров , [Вашингтон, округ Колумбия]: Управление военно-морских исследований, Департамент ВМС, OCLC  10794738
  6. ^ Бенингтон, Герберт Д. (1 октября 1983 г.). «Производство больших компьютерных программ» (PDF) . Анналы истории вычислительной техники IEEE . 5 (4). Отдел образовательной деятельности IEEE: 350–361. doi :10.1109/MAHC.1983.10102. S2CID  8632276 . Получено 21.03.2011 .Архивировано 18 июля 2011 г. на Wayback Machine
  7. ^ Ларман, Крейг; Базили, Виктор (июнь 2003 г.). «Итеративное и инкрементальное развитие: краткая история» (PDF) . Компьютер . 36 (6): 47–56. doi :10.1109/MC.2003.1204375.
  8. ^ abcd Ройс, Уинстон (1970), «Управление разработкой больших программных систем» (PDF) , Труды IEEE WESCON , 26 (август): 1–9
  9. ^ "Водопад". Бременский университет - Математика и информатика .
  10. ^ Аббас, Нура; Грэвелл, Эндрю М.; Уиллс, Гэри Б. (2008). «Исторические корни гибких методов: откуда взялось «гибкое мышление»?» (PDF) . В Абрахамссон, Пекка; Баскервиль, Ричард; Конбой, Киран; Фицджеральд, Брайан; Морган, Лоррейн; Ван, Сяофэн (ред.). Гибкие процессы в программной инженерии и экстремальном программировании . Конспект лекций по обработке деловой информации. Том 9. Берлин, Гейдельберг: Springer . стр. 94–103. doi :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 Press, 1976.
  14. ^ ab DOD-STD-2167 - Военный стандарт: Разработка программного обеспечения для оборонных систем" . Министерство обороны, Соединенные Штаты Америки. 1985-06-04. стр. 11.
  15. ^ «Разработка программного обеспечения для систем обороны военного стандарта» (PDF) .
  16. ^ Лайнбергер, Роб (25 апреля 2024 г.). Наследование Agile: руководство для ИТ-практиков по управлению разработкой программного обеспечения в пост-Agile-мире. Дарем, Северная Каролина: Sandprint Press. стр. 37. ISBN 9798989149605.
  17. ^ ab Макконнелл, Стив (1996). Быстрая разработка: укрощение диких графиков программного обеспечения. Microsoft Press. ISBN 1-55615-900-5.
  18. ^ "Waterfall Software Development Model". 5 февраля 2014 г. Получено 11 августа 2014 г.
  19. ^ Arcisphere technologies (2012). "Учебник: Жизненный цикл разработки программного обеспечения (SDLC)" (PDF) . Получено 13.11.2012 .
  20. ^ Хьюи, Дуглас (2009). «Сравнение традиционного системного анализа и проектирования с гибкими методологиями». Университет Миссури – Сент-Луис . Получено 11 августа 2014 г.
  21. ^ Парнас, Дэвид Л.; Клементс, Пол К. (1986). «Рациональный процесс проектирования: как и зачем его подделывать» (PDF) . IEEE Transactions on Software Engineering (2): 251–257. doi :10.1109/TSE.1986.6312940. S2CID  5838439 . Получено 21.03.2011 .
  22. ^ Макконнелл, Стив (2004). Code Complete, 2-е издание. Microsoft Press. ISBN 1-55615-484-4.
  23. ^ Энсменгер, Натан (2010). Компьютерные парни берут верх . MIT Press. стр. 42. ISBN 978-0-262-05093-7.
  24. ^ Ларман, Крейг; Базили, Виктор (2003). «Итеративное и инкрементальное развитие: краткая история». IEEE Computer . 36 (6) (июньское издание): 47–56. doi :10.1109/MC.2003.1204375. S2CID  9240477.
  25. ^ «Методология:методы проектирования».

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

На Викискладе есть медиафайлы по теме «Модели водопада» .