Waterfall model

From Wikipedia, the free encyclopedia

Jump to: navigati= on,=20 search<= /A>

Softwa= re=20 Development Process
This article is part of the Software=20 Development Process series
Activities and = Steps
Requ= irements=20 \| Architecture<= /A>=20 \| Implementation= =20 \| Testing = \| Deployment<= /TD>
Models
Agile \|=20 Clea= nroom=20 \| Iterative=20 \| RAD=20 \| RUP \| = Spiral \| = Waterfall \| XP
Supporting = Disciplines
C= onfiguration=20 Management \| Documentatio= n=20 \| Project=20 Management \| User = Experience=20 Design

The waterfall model is a sequential software= =20 development model (a process for the creation of software) in which=20 development is seen as flowing steadily downwards (like a waterfall) = through the=20 phases of requirements = analysis, design, implementation, = testing = (validation),=20 = integration,=20 and maintenance. The=20 origin of the term "waterfall" is often cited to be an article published = in 1970 by W. W.=20 Royce. Royce himself advocated an iterative=20 approach to software development and did not even use the term=20 "waterfall."

1 History of the = waterfall=20 model=20
2 Usage of the = waterfall=20 model=20
3 Arguments for = the waterfall=20 model=20
4 Criticism of = the waterfall=20 model=20
5 Modified = waterfall=20 models=20
- 5.1 Royce's = final=20 model=20
- 5.2 The = "sashimi"=20 model=20
- 5.3 Other = alternative=20 models
6 See = also=20
7 References=20
8 External = links=20

[edit]=20 History of the waterfall model

In 1970 Royce proposed what is presently referred to as the waterfall = model=20 as an initial concept, a model which he argued was flawed (Ro= yce=20 1970). His paper then explored how the initial model could be = developed into=20 an iterative model, with feedback from each phase influencing subsequent = phases,=20 similar to many methods used widely and highly regarded by many today. = It is=20 only the initial model that received notice; his own criticism of this = initial=20 model has been largely ignored. The "waterfall model" quickly came to = refer not=20 to Royce's final, iterative design, but rather to his purely = sequentially=20 ordered model. This article will use this popular meaning of the = phrase=20 waterfall model. For an iterative model similar to Royce's final = vision, see=20 the spiral model.

Despite Royce's intentions for the waterfall model to be modified = into an=20 iterative model, use of the "waterfall model" as a purely sequential = process is=20 still popular, and, for some, the phrase "waterfall model" has since = come to=20 refer to any approach to software creation which is seen as inflexible = and=20 non-iterative. Those who use the phrase waterfall model pejoratively for = non-iterative models that they dislike usually see the waterfall model = itself as=20 naive and unsuitable for a "real world" = process.

[edit]=20 Usage of the waterfall model

=20

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

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

Requirem= ents=20 specification=20
Design=20
Construction (aka: implementation = or=20 coding)=20
Integration=20
Testing and debugging (aka:=20 verification)=20
Installation=20
Maintenance=20

To follow the waterfall model, one proceeds from one phase to the = next in a=20 purely sequential manner. For example, one first completes "requirements = specification" =E2=80=94 they set in stone the requirements of the = software. (Example=20 requirements for Wikipedia may be "Wikipedia allows anonymous editing of = articles; Wikipedia enables people to search for information", although = real=20 requirements specifications will be much more complex and detailed.) = When the=20 requirements are fully completed, one proceeds to design. The software = in=20 question is designed and a "blueprint" is drawn for implementers = (coders) to=20 follow =E2=80=94 this design should be a plan for implementing the = requirements given.=20 When the design is fully completed, an implementation of that design is = made by=20 coders. Towards the later stages of this implementation phase, disparate = software components produced by different teams are integrated. (For = example,=20 one team may have been working on the "web page" component of Wikipedia = and=20 another team may have been working on the "server" component of = Wikipedia. These=20 components must be integrated together to produce the whole system.) = After the=20 implementation and integration phases are complete, the software product = is=20 tested and debugged; any faults introduced in earlier phases are removed = here.=20 Then the software product is installed, and later maintained to = introduce new=20 functionality and remove bugs.

Thus the waterfall model maintains that one should move to a phase = only when=20 its preceding phase is completed and perfected. Phases of development in = the=20 waterfall model are thus discrete, and there is no jumping back and = forth or=20 overlap between them.

However, there are various modifed=20 waterfall models (including Royce's final model) that may include = slight or=20 major variations upon this process.

[edit]=20 Arguments for the waterfall model

Time spent early on in software production can lead to greater = economy later=20 on in the software lifecycle; that is, it has been shown many times that = a bug=20 found in the early stages of the production lifecycle (such as = requirements=20 specification or design) is more economical (cheaper in terms of money, = effort=20 and time) to fix than the same bug found later on in the process. = ([McConnell=20 1996], p. 72, estimates that "a requirements defect that is left = undetected=20 until construction or maintenance will cost 50 to 200 times as much to = fix as it=20 would have cost to fix at requirements time.") This should be obvious to = some=20 people; if a program design is impossible to implement, it is easier to = fix the=20 design at the design stage than to realize months down the track when = program=20 components are being integrated that all the work done so far has to be = scrapped=20 because of a broken design.

This is the central idea behind Big Design Up = Front=20 (BDUF) and the waterfall model - time spent early on making sure that=20 requirements and design are absolutely correct is very useful in = economic terms=20 (it will save you much time and effort later). Thus, the thinking of = those who=20 follow the waterfall process goes, one should make sure that each phase = is 100%=20 complete and absolutely correct before proceeding to the next phase of = program=20 creation. Program requirements should be set in stone before design is = started=20 (otherwise work put into a design based on "incorrect" requirements is = wasted);=20 the programs design should be perfect before people begin work on = implementing=20 the design (otherwise they are implementing the "wrong" design and their = work is=20 wasted), etcetera.

A further argument for the waterfall model is that it places emphasis = on=20 documentation (such as requirements documents and design documents) as = well as=20 source=20 code. More "agile" methodologies can de-emphasize documentation in = favour of=20 producing working code - documentation however can be useful as a = "partial=20 deliverable" should a project not run far enough to produce any = substantial=20 amounts of source code (allowing the project to be resumed at a later = date). An=20 argument against agile development methods, and thus partly in favour of = the=20 waterfall model, is that in agile methods project knowledge is stored = mentally=20 by team members. Should team members leave, this knowledge is lost, and=20 substantial loss of project knowledge may be difficult for a project to = recover=20 from. Should a fully working design document be present (as is the = intent of Big=20 Design Up Front and the waterfall model) new team members or even = entirely new=20 teams should theoretically be able to bring themselves "up to = speed" by=20 reading the documents themselves. With that said, agile methods do = attempt to=20 compensate for this. For example, extreme = programming=20 (XP) advises that project team members should be "rotated" through = sections of=20 work in order to familiarize all members with all sections of the = project=20 (allowing individual members to leave without carrying important = knowledge with=20 them).

As well as the above, some prefer the waterfall model for its simple = and=20 arguably more disciplined approach. Rather than what the waterfall = adherent sees=20 as "chaos" the waterfall model provides a structured approach; the model = itself=20 progresses linearly through discrete, easily understandable and = explainable=20 "phases" and is thus easy to understand; it also provides easily = markable=20 "milestones" in the development process. It is perhaps for this reason = that the=20 waterfall model is used as a beginning example of a development model in = many=20 software engineering texts and courses.

It is argued that the waterfall model and Big Design Up Front in = general can=20 be suited to software projects which are stable (especially those = projects with=20 unchanging requirements, such as with "shrink wrap" software) and where = it is=20 possible and likely that designers will be able to fully predict problem = areas=20 of the system and produce a correct design before implementation = is=20 started. The waterfall model also requires that implementers follow the = well=20 made, complete design accurately, ensuring that the integration of the = system=20 proceeds smoothly.

The waterfall model is widely used, including by such large software=20 development houses as those employed by the US Department = of=20 Defense and NASA=20 (see "the=20 waterfall model") and upon many large government projects (see "the standard waterfall model" on the Internet = Archive).=20 Those who use such methods do not always formally distinguish between = the "pure"=20 waterfall model and the various modified waterfall models, so it can be=20 difficult to discern exactly which models are being used to what = extent.

Steve = McConnell sees the=20 two big advantages of the pure waterfall model as producing a "highly = reliable=20 system" and one with a "large growth envelope", but rates it as poor on = all=20 other fronts. On the other hand, he views any of several modified = waterfall=20 models (described below) as preserving these advantages while also = rating as=20 "fair to excellent" on "work[ing] with poorly understood requirements" = or=20 "poorly understood architecture" and "provid[ing] management with = progress=20 visibility", and rating as "fair" on "manag[ing] risks", being able to = "be=20 constrained to a predefined schedule", "allow[ing] for midcourse = corrections",=20 and "provid[ing] customer with progress visibility". The only criterion = on which=20 he rates a modified waterfall as poor is that it requires sophistication = from=20 management and developers. (Rapid Development, 156)

[edit]=20 Criticism of the waterfall model

The waterfall model however is argued by many to be a bad idea in = practice,=20 mainly because of their belief that it is impossible to get one phase of = a=20 software product's lifecycle "perfected" before moving on to the next = phases and=20 learning from them (or, at least, the belief that this is impossible for = any=20 non-trivial program). For example, clients may not be aware of exactly = what=20 requirements they want before they see a working prototype and can = comment upon=20 it; they may change their requirements constantly, and program designers = and=20 implementers may have little control over this. If clients change their=20 requirements after a design is finished, that design must be modified to = accommodate the new requirements, invalidating quite a good deal of = effort if=20 overly large amounts of time have been invested into "Big Design Up = Front".=20 (Thus, methods opposed to the naive waterfall model--such as those used = in Agile=20 software development--advocate less reliance on a fixed, static = requirements=20 document or design document). Designers may not (or, more likely, = cannot) be=20 aware of future implementation difficulties when writing a design for an = unimplemented software product. That is, it may become clear in the=20 implementation phase that a particular area of program functionality is=20 extraordinarily difficult to implement. If this is the case, it is = better to=20 revise the design than to persist in using a design that was made based = on=20 faulty predictions and that does not account for the newly discovered = problem=20 areas.

Steve McConnell in Code = Complete (a book=20 which criticizes the widespread use of the waterfall model) refers to = design as=20 a "wicked problem" = - a=20 problem whose requirements and limitations cannot be entirely known = before=20 completion. The implication is that it is impossible to get one phase of = software development "perfected" before time is spent in = "reconnaissance"=20 working out exactly where and what the big problems are.

To quote from David Parnas' "a=20 rational design process and how to fake it (PDF)":

=E2=80=9CMany of the [system's] details only become known to us as = we progress in=20 the [system's] implementation. Some of the things that we learn = invalidate our=20 design and we must backtrack.=E2=80=9D

The idea behind the waterfall model may be "measure twice; cut once", = and=20 those opposed to the waterfall model argue that this idea tends to fall = apart=20 when the problem being measured is constantly changing due to = requirement=20 modifications and new realizations about the problem itself. The idea = behind=20 those who object to the waterfall model may be "time spent in = reconnaissance is=20 seldom wasted".

In summary, the criticisms of a non-iterative development approach = (such as=20 the waterfall model) are as follows:

Many software projects must be open to change due to external = factors; the=20 majority of software is written as part of a contract with a client, = and=20 clients are notorious for changing their stated requirements. Thus the = software project must be adaptable, and spending considerable effort = in design=20 and implementation based on the idea that requirements will never = change is=20 neither adaptable nor realistic in these cases.=20
Unless those who specify requirements and those who design the = software=20 system in question are highly competent, it is difficult to know = exactly what=20 is needed in each phase of the software process before some time is = spent in=20 the phase "following" it. That is, feedback from following phases is = needed to=20 complete "preceding" phases satisfactorily. For example, the design = phase may=20 need feedback from the implementation phase to identify problem design = areas.=20 The counter-argument for the waterfall model is that experienced = designers may=20 have worked on similar systems before, and so may be able to = accurately=20 predict problem areas without time spent prototyping and implementing. =
Constant testing from the design, implementation and verification = phases=20 is required to validate the phases preceding them. Constant "prototype = design"=20 work is needed to ensure that requirements are non-contradictory and = possible=20 to fulfill; constant implementation is needed to find problem areas = and inform=20 the design process; constant integration and verification of the = implemented=20 code is necessary to ensure that implementation remains on track. The=20 counter-argument for the waterfall model here is that constant = implementation=20 and testing to validate the design and requirements is only needed if = the=20 introduction of bugs is likely to be a problem. Users of the waterfall = model=20 may argue that if designers (et cetera) follow a disciplined process = and do=20 not make mistakes that there is no need for constant work in = subsequent phases=20 to validate the preceding phases.=20
Frequent incremental builds (following the "release early, release = often"=20 philosophy) are often needed to build confidence for a software = production=20 team and their client.=20
It is difficult to estimate time and cost for each phase of the=20 development process without doing some "recon" work in that phase, = unless=20 those estimating time and cost are highly experienced with the type of = software product in question.=20
The waterfall model brings no formal means of exercising = management=20 control over a project and planning control and risk management are = not=20 covered within the model itself.=20
Only a certain number of team members will be qualified for each = phase;=20 thus to have "code monkeys" who are only useful for implementation = work do=20 nothing while designers "perfect" the design is a waste of resources. = A=20 counter-argument to this is that "multiskilled" software engineers = should be=20 hired over "specialized" staff.

[edit]=20 Modified waterfall models

In response to the perceived problems with the "pure" waterfall = model, many=20 modified waterfall models have been introduced. These models may address = some or=20 all of the criticisms of the "pure" waterfall model. Many different = models are=20 covered by Steve McConnell in the "lifecycle planning" chapter of his = book=20 Rapid Development: Taming Wild Software Schedules.

While all software development models will bear at least some = similarity to=20 the waterfall model, as all software development models will incorporate = at=20 least some phases similar to those used within the waterfall model, this = section=20 will deal with those closest to the waterfall model. For models which = apply=20 further differences to the waterfall model, or for radically different = models=20 seek general information on the softwa= re=20 development process.

[edit]=20 Royce's final model

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

[edit]=20 The "sashimi" model

The sashimi model (so called because it features overlapping phases, = like the=20 overlapping fish of Japanese sashimi) was = originated by Peter=20 DeGrace. It is sometimes simply referred to as the "waterfall model = with=20 overlapping phases" or "the waterfall model with feedback". Since phases = in the=20 sashimi model overlap, information of problem spots can be acted upon = during=20 phases of the waterfall model that would typically "precede" others in = the pure=20 waterfall model. For example, since the design and implementation phases = will=20 overlap in the sashimi model, implementation problems may be discovered = during=20 the "design and implementation" phase of the development process. This = helps=20 alleviate many of the problems associated with the Big Design Up Front=20 philosophy of the waterfall model.

[edit]=20 Other alternative models

The "waterfall model with subprojects" and the "waterfall model with = risk=20 reduction" are two other modified versions of the waterfall model. In = some ways=20 the spiral model is = comparable=20 to the waterfall model; a "waterfall model with iteration."

[edit]=20 See also

Agile = software=20 development=20
Big Design = Up=20 Front=20
Chaos model=20
Iterative=20 and incremental development=20
Rapid= =20 application development=20
Softwa= re=20 development process=20
Spiral model=20
Syst= em=20 Development Methodology, a type of waterfall model

[edit]=20 References

This article was originally = based on=20 material from the Free=20 On-line Dictionary of Computing, which is licensed under=20 the GFDL= .

McConnell, = Steve=20 (2006). Software Estimation: Demystifying the Black Art. = Microsoft=20 Press. ISBN=20 0-7356-0535-1. =20
McConnell, = Steve=20 (2004). Code Complete, 2nd edition. Microsoft Press. ISBN=20 1-55615-484-4. =20
McConnell, Steve = (1996).=20 Rapid Development: Taming Wild Software Schedules. Microsoft = Press. ISBN=20 1-55615-900-5. =20
Parnas, David, = A rational design process and how to fake it (PDF) = An=20 influential paper which criticises the idea that software production = can occur=20 in perfectly discrete phases.=20
Royce, = Winston=20 (1970), "Managing the Development of Large Software = Systems",=20 Proceedings of IEEE WESCON 26(August): 1-9.=20
Joel Spolsky on Big Design Up Front=20
Joel Spolsky - "daily builds are your friend"=20
"Why people still believe in the waterfall model"=20
The standard waterfall model for systems = development NASA=20 webpage, archived on Internet = Archive=20 March 10, 2005.=20
Parametric=20 Cost Estimating Handbook, NASA webpage based on the waterfall = model,=20 archived on Internet = Archive=20 March 8,2005.

[edit]=20 External links

The pros and cons of the Waterfall Model of software=20 development=20
Further=20 criticism of Joels arguments for BDUF and of BDUF in general=20
(Technical) = discussion of=20 the waterfall model on c2.com=20
"Waterfall model considered harmful"=20
Project Lifecycles: waterfall, rapid application = development, and=20 all that (A whitepaper on the = waterfall=20 model from the Lux group (a software "design, development and = documentation"=20 company))=20
The waterfall model at whatis.com=20
"The demise of the waterfall model is imminent" and = other urban=20 myths=20
Project=20 lifecycle models: how they differ and when to use them=20
Conrad Weisert, Waterfall=20 methodology: there's no such thing!=20
A spoof = international=20 Waterfall conference=20
Software Processes (also the Waterfall Model) =

Retrieved from "http://en.wikipedia= .org/wiki/Waterfall_model"

Category: = Software=20 development process

Views

Article=20
Discussion= =20
Edit=20 this page=20
History=20

Personal tools

Sign=20 in / create account

interaction

About = Wikipedia=20
Communit= y=20 portal=20
Recent=20 changes=20
Upload file = wizard=20
Contact = us=20
Make a = donation=20
Help=20

Search

Toolbox

What=20 links here=20
Related=20 changes=20
Upload file=20
Special = pages=20
Printable=20 version=20
Permanent=20 link
Cite=20 this article

In other languages

Dansk=20
Deutsch=20
Italiano=20
=D7=A2=D7=91=D7=A8=D7=99=D7=AA=20
=E6=97=A5=E6=9C=AC=E8=AA=9E=20
Nederlands=20
Polski=20
Portugu=C3=AAs=20
=D0=A0=D1=83=D1=81=D1=81= =D0=BA=D0=B8=D0=B9=20
Svenska=20
=E4=B8=AD=E6=96=87=20

This page was last modified 00:34, 22 May 2007.=20
All text is available under the terms of the GNU=20 Free Documentation License. (See Copyrights= =20 for details.)
Wikipedia=C2=AE is a registered trademark of the Wikimedia Foundation, = Inc., a=20 US-registered 501(c)= (3)=20 t= ax-deductible=20 nonprofit charity= .
Privacy = policy=20
About = Wikipedia=20
Discla= imers=20