Каскадная модель разработки программного обеспечения
Waterfall model
Каскадная модель разработки: последовательные этапы (концепция, анализ, дизайн, тестирование). Классический подход в SDLC, возникший в строительстве и производстве.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Моделирование проекта последовательными этапами
Modelling a project in sequential phases
Модель водопада представляет собой разделение деятельности по разработке на линейные последовательные фазы, что означает, что они передаются друг другу, где каждая фаза зависит от результатов предыдущей и соответствует специализации задач. Как правило, это один из наименее итеративных и гибких подходов, поскольку прогресс движется преимущественно в одном направлении ("вниз", подобно водопаду) через фазы концепции, инициации, анализа, проектирования, реализации, тестирования, развертывания и сопровождения. Модель водопада – это самый ранний подход SDLC, который использовался в разработке программного обеспечения. Модель разработки "водопад" возникла в машиностроении и строительстве, где высокоструктурированные физические условия приводили к тому, что изменения в проектировании становились непомерно дорогими на ранних этапах разработки. Когда она впервые была применена к разработке программного обеспечения, признанных альтернатив для творческой работы, основанной на знаниях, не существовало.
The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development. The waterfall development model originated in the manufacturing and construction industries, where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process. When first adopted for software development, there were no recognized alternatives for knowledge based creative work.
История
Первая известная презентация, описывающая использование таких фаз в разработке программного обеспечения, была представлена Гербертом Д. Бенингтоном на Симпозиуме по передовым методам программирования для цифровых компьютеров 29 июня 1956 года. Эта презентация была посвящена разработке программного обеспечения для системы SAGE. В 1983 году работа была переиздана с предисловием Бенингтона, в котором он объяснял, что фазы были намеренно организованы в соответствии со специализацией задач, и отмечал, что процесс на самом деле не выполнялся строго сверху вниз, а зависел от прототипа. Однако он также считал, что в нем есть существенные недостатки, обусловленные тем, что тестирование проводилось только в конце процесса, что он назвал "рискованным и ведущим к сбоям". Возможно, термин "водопад" впервые был использован в статье Белла и Тайера в 1976 году. В 1985 году Министерство обороны США приняло модель "водопад" в стандарте DOD STD 2167 для работы с подрядчиками по разработке программного обеспечения. В этом стандарте итерации разработки программного обеспечения определялись как "последовательные фазы цикла разработки программного обеспечения", и утверждалось, что "подрядчик должен реализовать цикл разработки программного обеспечения, включающий следующие шесть фаз: анализ требований к программному обеспечению, предварительное проектирование, детальное проектирование, кодирование и модульное тестирование, интеграция и тестирование".
The first known presentation describing use of such phases in software engineering was held by Herbert D. Benington at the Symposium on Advanced Programming Methods for Digital Computers on 29 June 1956. This presentation was about the development of software for SAGE. In 1983 the paper was republished with a foreword by Benington explaining that the phases were on purpose organized according to the specialization of tasks, and pointing out that the process was not in fact performed in a strict top down fashion, but depended on a prototype. However, he also felt it had major flaws stemming from the fact that testing only happened at the end of the process, which he described as being "risky and invites failure". The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer. In 1985, the United States Department of Defense adopted the waterfall model in the DOD STD 2167 standard for working with software development contractors. This standard referred for iterations of a software development to "the sequential phases of a software development cycle" and stated that "the contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing".
Критика
Клиенты могут не знать точно, в чем заключаются их требования, пока не увидят работающее программное обеспечение, и поэтому могут изменить их, что приводит к перепроектированию, переразработке и повторному тестированию, а также к увеличению затрат. Разработчики могут не предвидеть будущие трудности при проектировании нового программного продукта или функции, и в этом случае лучше пересмотреть проект, чем упорствовать в дизайне, который не учитывает вновь выявленные ограничения, требования или проблемы. Организации могут пытаться решить проблему отсутствия конкретных требований со стороны клиентов, привлекая системных аналитиков для изучения существующих ручных систем и анализа их функциональности и способов замены. Однако на практике сложно поддерживать четкое разделение между системным анализом и программированием, поскольку реализация любой нетривиальной системы почти неизбежно выявит проблемы и пограничные случаи, которые не были учтены системным аналитиком. В ответ на недостатки классической каскадной модели были предложены ее модификации, такие как "Сашими (каскадная модель с перекрывающимися фазами), каскадная модель с подпроектами и каскадная модель с уменьшением рисков".
Clients may not know exactly what their requirements are before they see working software and so change their requirements, leading to redesign, redevelopment, and retesting, and increased costs. Designers may not be aware of future difficulties when designing a new software product or feature, in which case it is better to revise the design than persist in a design that does not account for any newly discovered constraints, requirements, or problems. Organisations may attempt to deal with a lack of concrete requirements from clients by employing systems analysts to examine existing manual systems and analyse what they do and how they might be replaced. However, in practice, it is difficult to sustain a strict separation between systems analysis and programming. This is because implementing any non trivial system will almost inevitably expose issues and edge cases that the systems analyst did not consider. In response to the perceived problems with the pure waterfall model, modified waterfall models were introduced, such as "Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with Risk Reduction."