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

редактировать

Не измененная «модель водопада». Прогресс течет сверху вниз, как каскадный водопад.

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

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

Содержание

  • 1 История
  • 2 Модель
  • 3 Поддерживающие аргументы
  • 4 Критика
  • 5 Модифицированный водопад модели
  • 6 Последняя модель Ройса
  • 7 См. также
  • 8 Ссылки
  • 9 Внешние ссылки

История

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

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

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

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

Модель

В исходной каскадной модели Ройса следующие этапы выполняются по порядку:

  1. Системные и требования к программному обеспечению : отражены в документе с требованиями к продукту
  2. Анализ : приводит к моделям, схеме и бизнес-правилам
  3. Дизайн : приводит к s архитектура программного обеспечения
  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. Вовлекать клиента

См. Также

Ссылки

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

На Викискладе есть материалы, связанные с Waterfall модели.
Последняя правка сделана 2021-06-20 09:35:09
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте