Waterfall Method

A description needs to go at WaterFall, or maybe WaterfallModel, but until then we'll create another page so that for those who are too lazy to search the 19493 page WikiList can have yet another place to talk about this. But if you don't know what waterfall is, and you don't feel like clicking on the other links, it looks something like:

Page name notwithstanding, "waterfall" is a model of software development, but definitely not a method, the difference being that the model does not tell you how to do anything. Maybe if we begin to get this straight, a lot of confusion and bad feeling about the natural wonders of falling water will ... how you say ... evaporate.

By the way, if you notice the little phrase "Unit testing" under Implementation, that's what most people think of unit testing in the Mystical Land of Software Engineering. On UnitTestsReconsidered, there was a mismatch between the XpVsStandardDefinitionOfUnitTest.

The diagram above doesn't show the traditional waterfall model, which was one way, and which is the reason for its bad reputation. As drawn the above diagram could be followed in a iterative and/or rapid prototyping process, switching among various development activities as necessary, and that wouldn't be a bad thing. Think about it: water generally does NOT fall back UP a waterfall. And traditional waterfall projects rarely admit that they messed up a previous stage and need to revisit it (because of mental inertia ("We finished design; no, you can't update it!"), or the schedule is rigid and has no room for change ("We have to deliver in 90 days; we don't have time to redesign..." [even if we'll overshoot by 120 days when the flaws come out in acceptance testing]), etc...

The first published diagram of the waterfall that I know of was in WinstonRoyce?'s paper, and the term "waterfall" isn't even used in that paper. It may have been drawn on many napkins prior to that, and undoubtedly has an oral history that predates its written history. But in the interest of not rewriting history, could we have your sources for the notions of "traditional waterfall" above, please?

These are discussed in considerable detail in SteveMcConnell, 1996. RapidDevelopment: Taming Wild Software Schedules, MicrosoftPress.

Commercial software projects often reduce the formality of the full waterfall model. In the last few years, a paradigm known as ExtremeProgramming has emerged that emphasizes reducing the cost of software changes, developing test cases before coding, developing code using pairs of programmers, and putting most of the documentation into the code [KentBeck, 2000: ExtremeProgrammingExplainedEmbraceChange, AddisonWesley]

http://asd-www.larc.nasa.gov/barkstrom/public/The_Standard_Waterfall_Model_For_Systems_Development.htm

Royce's paper was published in 1970, while the McConnell and Beck sources above are 1996 and 2000, respectively. On the SteveMcConnell page of this wiki, McConnell is credited with having "introduced" the spiral model. There is no mention there of BarryBoehm's paper, "A Spiral Model of Software Development and Enhancement" [1987], in which Boehm discusses an early (1957) "stagewise model", and subsequent enhancement to it by Royce (in the 1970 paper) including feedback loops and prototyping, which Boehm calls the "waterfall model". Boehm says this about Royce's waterfall model:

A primary source of difficulty with the waterfall model has been its emphasis on fully-elaborated documents as completion criteria for early requirements and design phases. For some classes of software, such as compilers or secure operating systems, this is the most effective way to proceed. But it does not work well for many classes of software, particularly interactive end-user applications.

He then goes on to discuss evolutionary development models and how they ease the problems of the more rigid waterfall, but introduce some new [old] difficulties:

But evolutionary development has its difficulties also. It is generally difficult to distinguish from the old "code and fix" model, whose spaghetti code and lack of planning were the initial motivation for the waterfall model ... [and also falters in] ... situations in which several independently-evolved applications must subsequently be closely integrated ... [and in ] ... bridging situations, in which the new software is incrementally replacing a large existing system. If the existing system is poorly modularized, it is difficult to provide a good sequence of "bridges" ...

In introducing the spiral model, Boehm characterizes it as "based on experience with various refinements of the waterfall model as applied to large government software projects. The spiral model includes most previous models as special cases..."

The difference between Boehm's treatment of waterfall and early stagewise models and the way this wiki treats them is a matter of maturity. Boehm's analysis is historic, incremental and evolutionary. Most importantly, he maintains the value of waterfall notions in their place among a matrix of refinements and improvements. The treatment of waterfall on wiki is ahistoric and non-evolutionary. Wiki hasn't done its homework with respect to software process models, and makes a poor example of evolutionary values, all its recent XP hoopla notwithstanding. Wiki grow up.

-- WaldenMathews

The way Wiki "grows up" is by refactoring. It changes, improves, by the participation of those who are expert in the field taking the time to correct errors, remove the heat and retain the light. At present this topic is treated on 5 pages by page name: WaterFall, WaterfallAnalogy, WaterfallMethod, WaterfallModel, WaterfallSyndrome, and on 90 other pages by referring to it.

The topic could do with a large refactoring by one who has the "ability to make it fully conscious". As you said in another place:

"As you develop something ... anything ..., what is it that guides you toward the correct result at any given moment? My thesis, again, is that that "thing" can be expressed, evaluated, improved, etc. But it depends on your ability to make it fully conscious, and then to express it. You may not wish to do either, but that's a different matter." -- WaldenMathews

I accept your nomination, and will now take applications for a pairing partner with whom to address the task. An openness to the value of contributions pre-1990 to the software field is a key criterion for this position. Interested applicants should contact me by email. -- wm

... but definitely not a method, the difference being that the model does not tell you how to do anything ...

It was a method at the time. Specifically, it told you "Do design, then coding, then testing, then you're done". Nowadays, the 'how' is more detailed, but back then, that was the 'how'.

What time are you referring to?

The time it was invented/discovered. Honestly, I haven't a clue as to dates. I just know that at one time, the WaterfallMethod was the NextBigThing.

Another Waterfall: http://www.worldofescher.com/gallery/internet/waterfall.html