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

Водопадная модель представляет собой разбиение деятельности по разработке на линейные последовательные этапы, то есть они передаются друг другу, где каждый этап зависит от результатов предыдущего и соответствует специализации задач. ^{[ 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 ]} жесткое соблюдение следующих этапов им подвергается критике:

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

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

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

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

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

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

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

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

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

Критика

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Ссылки

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

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

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

[:0-1] Jump up to: ^а ^б Петерсен, Кай; Волин, Клаас; Бака, Деян (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. дои : 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

[benington-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 .

[royce-8] Jump up to: ^а ^б ^с ^д Ройс, Уинстон (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] Конрад Вайсерт, Методика водопада: такого не существует!

[:inheriting_agile-12] Линебергер, Роб (25 апреля 2024 г.). Наследование Agile: Руководство для ИТ-практиков по управлению разработкой программного обеспечения в пост-Agile-мире . Дарем, Северная Каролина: Sandprint Press. п. 36. ISBN 9798989149605 .

[13] Белл, Томас Э. и Т.А. Тайер. Требования к программному обеспечению: действительно ли они являются проблемой? Материалы 2-й международной конференции по программной инженерии. Издательство IEEE Computer Society, 1976.

[:1-14] Jump up to: ^а ^б DOD-STD-2167 - Военный стандарт: Разработка программного обеспечения оборонных систем» . Министерство обороны Соединенных Штатов Америки. 04.06.1985. стр. 11.

[15] «Разработка программного обеспечения для стандартных оборонных систем» (PDF) .

[inheriting_agile-16] Линебергер, Роб (25 апреля 2024 г.). Наследование Agile: Руководство для ИТ-практиков по управлению разработкой программного обеспечения в пост-Agile-мире . Дарем, Северная Каролина: Sandprint Press. п. 37. ИСБН 9798989149605 .

[rapid-17] Jump up to: ^а ^б ^с МакКоннелл, Стив (1996). Быстрая разработка: укрощение диких графиков работы программного обеспечения . Майкрософт Пресс. ISBN 1-55615-900-5 .

[18] «Модель разработки программного обеспечения «Водопад» . 5 февраля 2014 года . Проверено 11 августа 2014 г.

[19] Арцисферные технологии (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 . ISBN 978-0-262-05093-7 .

[24] Ларман, Крейг; Базили, Виктор (2003). «Итеративная и поэтапная разработка: краткая история» . IEEE-компьютер . 36 (6) (ред. июня): 47–56. дои : 10.1109/MC.2003.1204375 . S2CID 9240477 .

[25] «Методология:методы проектирования» .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]

[ 23 ]

[ 24 ]

[ 25 ]