Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
  • Компилятор
  • Отладчик
  • Профайлер
  • Дизайнер графического интерфейса
  • Моделирование
  • IDE
  • Автоматизация сборки
  • Автоматизация выпуска
  • Инфраструктура как код
  • Тестирование
Стандарты и свод знаний
  • БАБОК
  • CMMI
  • Стандарты IEEE
  • ISO 9001
  • Стандарты ISO / IEC
  • PMBOK
  • SWEBOK
  • ITIL
  • IREB
Глоссарии
  • Искусственный интеллект
  • Информатика
  • Электротехника и электроника
Контуры
  • План разработки программного обеспечения
  • v
  • т
  • е
Немодифицированная «модель водопада». Прогресс течет сверху вниз, как ниспадающий водопад.

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

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

История [ править ]

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

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

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

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

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

Модель [ править ]

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

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

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

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

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

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

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

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

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

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

Критика [ править ]

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

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

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

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

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

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

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

Модифицированные модели водопада [ править ]

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

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

Последняя модель Ройса [ править ]

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

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

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

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

См. Также [ править ]

  • Список философий разработки программного обеспечения
  • Гибкая разработка программного обеспечения
  • Большой дизайн спереди
  • Модель хаоса
  • DevOps
  • Итеративная и инкрементальная разработка
  • Объектно-ориентированный анализ и дизайн
  • Быстрая разработка приложений
  • Процесс разработки программного обеспечения
  • Спиральная модель
  • Структурированный системный анализ и метод проектирования (SSADM)
  • Методология разработки системы
  • Традиционная инженерия
  • V-модель

Ссылки [ править ]

  1. ^ a b Бенингтон, Герберт Д. (1 октября 1983 г.). «Производство больших компьютерных программ» (PDF) . IEEE Annals of the History of Computing . Департамент образовательной деятельности IEEE. 5 (4): 350–361. DOI : 10.1109 / MAHC.1983.10102 . S2CID  8632276 . Проверено 21 марта 2011 . Архивировано 18 июля 2011 года в Wayback Machine.
  2. ^ США, Консультативная группа по математическим вычислениям ВМФ (29 июня 1956 г.), Симпозиум по передовым методам программирования для цифровых компьютеров , [Вашингтон, округ Колумбия]: Управление военно-морских исследований, Департамент военно-морского флота, OCLC 10794738 
  3. ^ a b c d Ройс, Уинстон (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. ^ a b c МакКоннелл, Стив (1996). Быстрое развитие: укрощение дикого расписания программного обеспечения . Microsoft Press. ISBN 1-55615-900-5.
  9. ^ "Модель разработки программного обеспечения водопада" . 5 февраля 2014 . Проверено 11 августа 2014 .
  10. ^ Технологии Arcisphere (2012). «Учебное пособие: Жизненный цикл разработки программного обеспечения (SDLC)» (PDF) . Проверено 13 ноября 2012 .
  11. ^ Хьюи, Дуглас (2009). «Сравнение традиционного системного анализа и проектирования с гибкими методологиями» . Университет Миссури - Сент-Луис . Проверено 11 августа 2014 .
  12. ^ "Когда следует использовать модель водопада?" . Проверено 28 сентября 2016 .
  13. ^ Парнас, Дэвид Л .; Клементс, Пол К. (1986). «Процесс рационального проектирования: как и зачем его подделывать» (PDF) . IEEE Transactions по разработке программного обеспечения (2): 251–257. DOI : 10.1109 / TSE.1986.6312940 . S2CID 5838439 . Проверено 21 марта 2011 .  
  14. ^ МакКоннелл, Стив (2004). Код завершен, 2-е издание . Microsoft Press. ISBN 1-55615-484-4.
  15. ^ Ensmenger, Nathan (2010). Компьютерные мальчики берут верх . п. 42 . ISBN 978-0-262-05093-7.
  16. ^ Ларман, Крейг; Базили, Виктир (2003). «Итеративное и инкрементное развитие: краткая история» . IEEE Computer (июньское издание). 36 (6): 47–56. DOI : 10,1109 / MC.2003.1204375 . S2CID 9240477 . 
  17. ^ Методология разработки водопадных систем… Серьезно? пользователя David Dischave. 2012. Архивировано 2 июля 2014 года в Wayback Machine.
  18. ^ «Методология: методы проектирования» .

Внешние ссылки [ править ]

  • Понимание плюсов и минусов водопадной модели разработки программного обеспечения
  • Модели жизненного цикла проекта: чем они отличаются и когда их использовать
  • Переход на водопад с RUP по Филиппу Крючтен
  • CSC и IBM Rational объединяются для предоставления C-RUP и поддержки быстрых изменений бизнеса
  • c2: Водопад