Waterfall model - Wikipedia, the free encyclopedia

Page 1 of 7

Waterfall model
From Wikipedia, the free encyclopedia

The waterfall model is a sequential design process, often 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. The waterfall development model originates in the manufacturing and construction industries; highly structured physical environments in which afterthe-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.[1] 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.[2] This presentation was about the development of software for SAGE. In 1983 the paper was republished[3] with a foreword by Benington pointing out that the process was not in fact performed in strict top-down, but depended on a prototype.

The unmodified "waterfall model". Progress flows from the top to the bottom, like a cascading waterfall.

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 this article. Royce presented this model as an example of a flawed, non-working model.[6] This, in fact, is how the term is generally used in writing about software developmentto describe a critical view of a commonly used software development practice.[7]

Contents
1 Model 2 Supporting arguments 3 Criticism 4 Modified models 5 See also 6 References 7 Bibliography

http://en.wikipedia.org/wiki/Waterfall_model

12/24/2012

Model
In Royce's original waterfall model, the following phases are followed in order: 1. 2. 3. 4. 5. 6. 7. Requirements specification Design Construction (implementation or coding) Integration Testing and debugging (validation) Installation Maintenance

Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Various modified waterfall models (including Royce's final model), however, can include slight or major variations on this process.[citation

Waterfall model - Wikipedia, the free encyclopedia

Page 3 of 7

is the intent of Big Design Up Front and the waterfall model), new team members or even entirely new teams should be able to familiarize themselves by reading the documents.[9] Some waterfall proponents prefer the waterfall model for its simple approach and argue that it is more disciplined. 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.[citation needed] It is argued that the waterfall model and Big Design up Front in general can be suited to software projects that are stable (especially those projects with unchanging requirements, such as with shrink wrap software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started. The waterfall model also requires that implementers follow the well-made, complete design accurately, ensuring that the integration of the system proceeds smoothly.
[citation needed]

Criticism
Advocates of Agile software development argue the waterfall model is a bad idea in practicebelieving it impossible for any non-trivial project to finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them.[citation needed] For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up Front.[citation needed] Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a design based on faulty predictions, and that does not account for the newly discovered problems.[citation needed] In Code Complete (a book that criticizes widespread use of the waterfall model), Steve McConnell refers to design as a "wicked problem"a problem whose requirements and limitations cannot be entirely known before completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase.[citation needed] David Parnas, in A Rational Design Process: How and Why to Fake It, writes:[10]

http://en.wikipedia.org/wiki/Waterfall_model

12/24/2012

Waterfall model - Wikipedia, the free encyclopedia

Page 4 of 7

Many of the [system's] details only become known to us as we progress in the [system's] implementation. Some of the things that we learn invalidate our design and we must backtrack. Expanding the concept above, the project stakeholders (non-IT personnel) may not be fully aware of the capabilities of the technology being implemented. This can lead to what they "think is possible" defining expectations and requirements. This can lead to a design that does not use the full potential of what the new technology can deliver, or simply replicates the existing application or process with the new technology. This can cause substantial changes to the implementation requirements once the stakeholders become more aware of the functionality available from the new technology. An example is where an organization migrates from a paper-based process to an electronic process. While key deliverables of the paper process must be maintained, benefits of real-time data input validation, traceability, and automated decision point routing may not be anticipated at the early planning stages of the project.[citation needed] The idea behind the waterfall model may be "measure twice; cut once," and those opposed to the waterfall model argue that this idea tends to fall apart when the problem constantly changes due to requirement modifications and new realizations about the problem itself. A potential solution is for an experienced developer to spend time up front on refactoring to consolidate the software, and to prepare it for a possible update, no matter if such is planned already. Another approach is to use a design targeting modularity with interfaces to increase the flexibility of the software with respect to the design.[citation needed] Due to the types of criticisms discussed above, some organizations, such as the US Department of Defense, now have a preference against waterfall type methodologies, starting with MIL-STD-498 "clearly encouraging evolutionary acquisition and IID".[11] The current DoD Standard 5000.2, released in 2000, states a clear preference against waterfall: "There are two approaches, evolutionary and single step [waterfall], to full capability. An evolutionary approach is preferred. [In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability...software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development."[12]

Modified 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.[citation needed] Many different models are covered by Steve McConnell in the "Lifecycle Planning" chapter of his book Rapid Development: Taming Wild Software Schedules.[13] While all software development models bear some similarity to the waterfall model, as all software development models incorporate at least some phases similar to those used in the waterfall model, this section deals with those closest to the waterfall model. For models that apply further differences to the waterfall model, or for radically different models seek general information on the software development process.

http://en.wikipedia.org/wiki/Waterfall_model

12/24/2012

Waterfall model - Wikipedia, the free encyclopedia

Page 5 of 7

[citation needed]

See also
List of software development philosophies Agile software development Big Design Up Front Chaos model Iterative and incremental development Object-oriented analysis and design PRiSM Rapid application development Software development process Spiral model System Development Methodology V-model Dual Vee Model

References
1. ^ Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350361. doi:10.1109/MAHC.1983.10102. http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83501.pdf. Retrieved 2011-03-21. 2. ^ 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 3. ^ Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350361. doi:10.1109/MAHC.1983.10102. http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83501.pdf. Retrieved 2011-03-21. 4. ^ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut fr Gestaltungs- und Wirkungsforschung, TU-Wien. Retrieved on 2007-11-28 from http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html. 5. ^ Royce, Winston. "Managing the Development of Large Software Systems". http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf. 6. ^ Royce, Winston (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 19, http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf 7. ^ Conrad Weisert, Waterfall methodology: there's no such thing! 8. ^ McConnell (1996), p. 72, estimates that "...a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time". 9. ^ Arcisphere technologies (2012). "Tutorial: The Software Development Life Cycle (SDLC)". http://softwarelifecyclepros.com/wp-

http://en.wikipedia.org/wiki/Waterfall_model

12/24/2012

Waterfall model - Wikipedia, the free encyclopedia

Page 6 of 7

content/uploads/2012/05/Tutorial-Software-Development-LifeCycle-SDLC.pdf. 10. ^ "A Rational Design Process: How and Why to Fake It", David Parnas (PDF file) 11. ^ Iterative and Incremental Development: A Brief History, Craig Larman and Victor Basili, IEEE Computer, June 2003 12. ^ Department of Defense Instruction Number 5000.2, April 5, 2002, Subject: Operation of the Defense Acquisition System: 4.7.3.2.3.3. Acquisition Strategy Considerations. 13. ^ McConnell (1996), pp. 143-147, describes three modified waterfalls: Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with Risk Reduction.

Bibliography
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the the "relicensing" terms of the GFDL, version 1.3 or later. McConnell, Steve (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. ISBN 0-7356-0535-1. McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4. McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5. Parnas, David, A rational design process and how to fake it (PDF) An influential paper which criticises the idea that software production can occur in perfectly discrete phases. Royce, Winston (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 19, http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf. "Why people still believe in the waterfall model" The standard waterfall model for systems development NASA webpage, archived on Internet Archive March 10, 2005. Parametric Cost Estimating Handbook, NASA webpage based on the waterfall model, archived on Internet Archive March 8, 2005.

External links
Understanding the pros and cons of the Waterfall Model of software development "Waterfall model considered harmful" Project lifecycle models: how they differ and when to use them Going Over the Waterfall with the RUP by Philippe Kruchten CSC and IBM Rational join to deliver C-RUP and support rapid business change wiki:WaterFall Retrieved from "http://en.wikipedia.org/w/index.php?title=Waterfall_model&oldid=529531943" Categories: Software development philosophies Project management Design

http://en.wikipedia.org/wiki/Waterfall_model

12/24/2012

Waterfall model - Wikipedia, the free encyclopedia

Page 7 of 7

Navigation menu
This page was last modified on 24 December 2012 at 03:28. Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details. Wikipedia is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.

http://en.wikipedia.org/wiki/Waterfall_model

12/24/2012