Waterfall model

Software development process
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Tools
Standards and BOKs
The unmodified "waterfall model". Progress flows from the top to the bottom, like a cascading waterfall.

The waterfall model is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance. Despite the development of new software development process models, the Waterfall method is still the dominant process model with over a third of software developers still using it.[1]

The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Because no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.[2]

History

The first known presentation describing use of similar phases in software engineering was held by Herbert D. Benington at Symposium on advanced programming methods for digital computers on 29 June 1956.[3] This presentation was about the development of software for SAGE. In 1983 the paper was republished with a foreword by Benington pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype.[2]

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[4][5] although Royce did not use the term waterfall in that article. Royce presented this model as an example of a flawed, non-working model; which is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice.[6]

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

In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A, their standards for working with software development contractors, which stated that "the contractor shall implement a software development cycle that includes the following six phases: Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing".[8]

Model

In Royce's original waterfall model, the following phases are followed in order:

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

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

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

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

It is argued that the waterfall model can be suited to projects where requirements and scope are fixed, the product itself is firm and stable, and the technology is clearly understood.[13]

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

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

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

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

While advocates of agile software development argue the waterfall model is an ineffective process for developing software, some sceptics suggest that the waterfall model is a false argument used purely to market alternative development methodologies.[17]

See also

References

  1. ↑ "The Demise of the Waterfall Model Is Imminent - ACM Queue". Retrieved 2016-09-28.
  2. 1 2 Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs" (PDF). IEEE Annals of the History of Computing. IEEE Educational Activities Department. 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.
  3. ↑ 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
  4. 1 2 Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9
  5. ↑ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Retrieved on 2007-11-28 from http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html
  6. ↑ Conrad Weisert, Waterfall methodology: there's no such thing!
  7. ↑ 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.
  8. ↑ Military Standard Defense System Software Development
  9. 1 2 McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5.
  10. ↑ "Waterfall Software Development Model". 5 February 2014. Retrieved 11 August 2014.
  11. ↑ Arcisphere technologies (2012). "Tutorial: The Software Development Life Cycle (SDLC)" (PDF). Retrieved 2012-11-13.
  12. ↑ Hughey, Douglas (2009). "Comparing Traditional Systems Analysis and Design with Agile Methodologies". University of Missouri – St. Louis. Retrieved 11 August 2014.
  13. ↑ "When should you use Waterfall Model?". Retrieved 2016-09-28.
  14. ↑ Parnas, David L.; Clements, Paul C. (1986). "A rational design process: How and why to fake it" (PDF). Software Engineering, IEEE Transactions: 251–257. Retrieved 2011-03-21.
  15. ↑ McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4.
  16. ↑ Larman, Craig; Basili, Victir (2003). "Iterative and Incremental Development: A Brief History". IEEE Computer (June ed.). 36: 47–56. doi:10.1109/MC.2003.1204375.
  17. ↑ A Waterfall Systems Development Methodology … Seriously? David Dischave 2012 Archived July 2, 2014, at the Wayback Machine.
Wikimedia Commons has media related to Waterfall models.
This article is issued from Wikipedia - version of the 11/17/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.