Waterfall model

Last updated

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. [1] The approach is typical for certain areas of engineering design. In software development, [1] 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. [2] [ better source needed ] The waterfall model is the earliest SDLC approach that was used in software development.[ citation needed ]

Contents

The waterfall development model originated in the manufacturing and construction industries,[ citation needed ] where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process. [ citation needed ] When first adopted for software development, there were no recognized alternatives for knowledge-based creative work. [3] [ better source needed ]

History

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. [4] 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. [3]

Although the term "waterfall" is not used in the paper, the first formal detailed diagram of the process later known as the "waterfall model" is often[ citation needed ] cited as a 1970 article by Winston W. Royce. [5] [6] [7] 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". [5] The rest of his paper introduced five steps which he felt were necessary to "eliminate most of the development risks" associated with the unaltered waterfall approach. [5]

Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach. [8] [ better source needed ]

The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer. [9] [ better source needed ]

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 [10] 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". [10] [11]

Model

Although Royce never recommended nor described a waterfall model[ citation needed ], rigid adherence to the following phases are criticized by him:

  1. System and software requirements: captured in a product requirements document
  2. Analysis: resulting in models, schema, and business rules
  3. Design: resulting in the software architecture
  4. Coding: the development, proving, and integration of software
  5. Testing: the systematic discovery and debugging of defects
  6. Operations: the installation, migration, support, and maintenance of complete systems

Thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified.

Various modified waterfall models (including Royce's final model), however, can include slight or major variations on this process. [5] These variations included returning to the previous cycle after flaws were found downstream, or returning all the way to the design phase if downstream phases deemed insufficient.

Supporting arguments

Time spent early in the software production cycle can reduce costs at later stages. For example, a problem found in the early stages (such as requirements specification) is cheaper to fix than the same bug found later on in the process (by a factor of 50 to 200). [12]

In common practice, waterfall methodologies result in a project schedule with 20–40% of the time invested for the first two phases, 30–40% of the time to coding, and the rest dedicated to testing and implementation. The actual project organization needs to be highly structured. Most medium and large projects will include a detailed set of procedures and controls, which regulate every process on the project. [13] [ failed verification ]

A further argument for the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as source code.[ citation needed ] In less thoroughly designed and documented methodologies, knowledge is lost if team members leave before the project is completed, and it may be difficult for a project to recover from the loss. If a fully working design document is present (as is the intent of big design up front and the waterfall model), new team members or even entirely new teams should be able to familiarise themselves by reading the documents. [14]

The waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily identifiable milestones in the development process. It is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and courses. [15]

Simulation can play a valuable role within the waterfall model. By creating computerized or mathematical simulations of the system being developed, teams can gain insights into how the system will perform before proceeding to the next phase. Simulations allow for testing and refining the design, identifying potential issues or bottlenecks, and making informed decisions about the system's functionality and performance.

Criticism

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. [16]

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. [17]

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. [18] 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." [12]

Some organisations, such as the United States Department of Defense, now have a stated preference against waterfall-type methodologies, starting with MIL-STD-498 released in 1994, which encourages evolutionary acquisition and Iterative and Incremental Development . [19]

Modified waterfall models

In response to the perceived problems with the "pure" waterfall model, many 'modified waterfall models' have been introduced. These models may address some or all of the criticisms of the "pure" waterfall model.

These include the Rapid Development models that Steve McConnell calls "modified waterfalls": [12] Peter DeGrace's "sashimi model" (waterfall with overlapping phases), waterfall with subprojects, and waterfall with risk reduction. Other software development model combinations such as "incremental waterfall model" also exist. [20]

Royce's final model

Royce final model 1970 Royce Managing the Development of Large Software Systems Fig10.PNG
Royce final model

Winston W. Royce's final model, his intended improvement upon his initial "waterfall model", illustrated that feedback could (should, and often would) lead from code testing to design (as testing of code uncovered flaws in the design) and from design back to requirements specification (as design problems may necessitate the removal of conflicting or otherwise unsatisfiable/undesignable requirements). In the same paper Royce also advocated large quantities of documentation, doing the job "twice if possible" (a sentiment similar to that of Fred Brooks, famous for writing the Mythical Man Month, an influential book in software project management, who advocated planning to "throw one away"), and involving the customer as much as possible (a sentiment similar to that of extreme programming).

Royce notes on the final model are:

  1. Complete program design before analysis and coding begins
  2. Documentation must be current and complete
  3. Do the job twice if possible
  4. Testing must be planned, controlled, and monitored
  5. Involve the customer

See also

Related Research Articles

<span class="mw-page-title-main">Spiral model</span> Software development process model

The spiral model is a risk-driven software development process model. Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping.

<span class="mw-page-title-main">Iterative and incremental development</span> Development methodology

Iterative and incremental development is any combination of both iterative design or iterative method and incremental build model for development.

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

Rapid application development (RAD), also called rapid application building (RAB), is both a general term for adaptive software development approaches, and the name for James Martin's method of rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications.

Software development is the process used to create software. Programming and maintaining the source code is the central step of this process, but it also includes conceiving the project, evaluating its feasibility, analyzing the business requirements, software design, testing, to release. Software engineering, in addition to development, also includes project management, employee management, and other overhead functions. Software development may be sequential, in which each step is complete before the next begins, but iterative development methods where multiple steps can be executed at once and earlier steps can be revisited have also been devised to improve flexibility, efficiency, and scheduling.

A requirement is a singular documented physical or functional need that a particular design, product, or process aims to satisfy. It is commonly used in engineering design, systems engineering, software engineering, enterprise engineering, product development, and process optimization. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Web development is the work involved in developing a website for the Internet or an intranet. Web development can range from developing a simple single static page of plain text to complex web applications, electronic businesses, and social network services. A more comprehensive list of tasks to which Web development commonly refers, may include Web engineering, Web design, Web content development, client liaison, client-side/server-side scripting, Web server and network security configuration, and e-commerce development.

In software development, agile practices include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s). Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from, and underpin, a broad range of software development frameworks, including Scrum and Kanban.

<span class="mw-page-title-main">Dynamic systems development method</span>

Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution delivery rather than being focused specifically on software development and code creation and could be used for non-IT projects. The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

Microsoft Solutions Framework (MSF) is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology services from Microsoft. MSF is not limited to developing applications only; it is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF does not force the developer to use a specific methodology.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

The incremental build model is a method of software development where the product is designed, implemented, and tested incrementally until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping. According to the Project Management Institute, an incremental approach is an "adaptive development approach in which the deliverable is produced successively, adding functionality until the deliverable contains the necessary and sufficient capability to be considered complete."

<span class="mw-page-title-main">V-model (software development)</span> Software development methodology

In software development, the V-model represents a development process that may be considered an extension of the waterfall model and is an example of the more general V-model. Instead of moving down linearly, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction, respectively.

<span class="mw-page-title-main">Winston W. Royce</span> American software engineer

Winston Walker Royce (August 15, 1929 – June 7, 1995) was an American computer scientist, director at Lockheed Software Technology Center in Austin, Texas. He was a pioneer in the field of software development, known for his 1970 paper from which the Waterfall model for software development was mistakenly drawn.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

A programming team is a team of people who develop or maintain computer software. They may be organised in numerous ways, but the egoless programming team and chief programmer team have been common structures.

<span class="mw-page-title-main">Extreme programming</span> Software development methodology

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Evolutionary database design involves incremental improvements to the database schema so that it can be continuously updated with changes, reflecting the customer's requirements. People across the globe work on the same piece of software at the same time hence, there is a need for techniques that allow a smooth evolution of database as the design develops. Such methods utilize automated refactoring and continuous integration so that it supports agile methodologies for software development. These development techniques are applied on systems that are in pre-production stage as well on systems that have already been released. These techniques not only cover relevant changes in the database schema according to customer's changing needs, but also migration of modified data into the database and also customizing the database access code accordingly without changing the data semantics.

References

  1. 1 2 Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). "The Waterfall Model in Large-Scale Development". In Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (eds.). Product-Focused Software Process Improvement. Lecture Notes in Business Information Processing. Vol. 32. Berlin, Heidelberg: Springer. pp. 386–400. Bibcode:2009pfsp.book..386P. doi:10.1007/978-3-642-02152-7_29. ISBN   978-3-642-02152-7.
  2. ↑ "The Traditional Waterfall Approach". www.umsl.edu. Retrieved 2022-02-23.
  3. 1 2 Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs" (PDF). IEEE Annals of the History of Computing. 5 (4). IEEE Educational Activities Department: 350–361. doi:10.1109/MAHC.1983.10102. S2CID   8632276 . Retrieved 2011-03-21. Archived July 18, 2011, at the Wayback Machine
  4. ↑ United States, Navy Mathematical Computing Advisory Panel (29 June 1956), Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC   10794738
  5. 1 2 3 4 Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9
  6. ↑ "Waterfall". Bremen University - Mathematics and Computer Science.
  7. ↑ Abbas, Noura; Gravell, Andrew M.; Wills, Gary B. (2008). "Historical Roots of Agile Methods: Where Did "Agile Thinking" Come From?" (PDF). In Abrahamsson, Pekka; Baskerville, Richard; Conboy, Kieran; Fitzgerald, Brian; Morgan, Lorraine; Wang, Xiaofeng (eds.). Agile Processes in Software Engineering and Extreme Programming. Lecture Notes in Business Information Processing. Vol. 9. Berlin, Heidelberg: Springer. pp. 94–103. doi:10.1007/978-3-540-68255-4_10. ISBN   978-3-540-68255-4.
  8. ↑ Conrad Weisert, Waterfall methodology: there's no such thing!
  9. ↑ Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem? Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976.
  10. 1 2 DOD-STD-2167 - Military Standard : Defence System Software Development". Department of Defence, United States of America. 1985-06-04. p. 11.{{cite book}}: CS1 maint: date and year (link)
  11. ↑ "Military Standard Defense System Software Development" (PDF).
  12. 1 2 3 McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN   1-55615-900-5.
  13. ↑ "Waterfall Software Development Model". 5 February 2014. Retrieved 11 August 2014.
  14. ↑ Arcisphere technologies (2012). "Tutorial: The Software Development Life Cycle (SDLC)" (PDF). Retrieved 2012-11-13.
  15. ↑ Hughey, Douglas (2009). "Comparing Traditional Systems Analysis and Design with Agile Methodologies". University of Missouri – St. Louis. Retrieved 11 August 2014.
  16. ↑ Parnas, David L.; Clements, Paul C. (1986). "A rational design process: How and why to fake it" (PDF). IEEE Transactions on Software Engineering (2): 251–257. doi:10.1109/TSE.1986.6312940. S2CID   5838439 . Retrieved 2011-03-21.
  17. ↑ McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN   1-55615-484-4.
  18. ↑ Ensmenger, Nathan (2010). The Computer Boys Take Over . MIT Press. p.  42. ISBN   978-0-262-05093-7.
  19. ↑ Larman, Craig; Basili, Victir (2003). "Iterative and Incremental Development: A Brief History". IEEE Computer. 36 (6) (June ed.): 47–56. doi:10.1109/MC.2003.1204375. S2CID   9240477.
  20. ↑ "Methodology:design methods".
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.