Much of our industry believes Waterfall means a single-pass development process. Dr. Royce explicitly said to do it twice. (It was a military officer who later took the process and made it into a single pass.)
If you learned it as a two-pass process, then you learned it correctly.
This is simply historically incorrect. Waterfall means a single pass by definition.
Royce described the pre-existing state of the art - the single-pass model (Waterfall) - and suggested a modification to a 2-pass model. (This can be seen as a precursor to Boehm's n-pass Spiral model.)
To suggest that the single-pass model was invented later as a corruption of Royce's paper is nonsense. Virtually all software was developed this way both before and after the paper.
What is odd is that the earliest and most commonly cited reference to the Waterfall methodology is a paper that explicitly says that it doesn't work. Let this be a lesson on not burying the lede.
In the version of the paper linked earlier in the forum, I take the following to mean two passes: build a model and then use lessons learned to build the final product. But it's a matter of interpretation and semantics. My own interpretation is contradicted further down in my comment by someone from that era (see the Larman paper linked). C'est la vie, I'm sticking with my interpretation. I think we can agree that Royce did not mean our modern "Agile" approach.
"If the computer program in question is being developed for the first time, arrange
matters so that the version finally delivered to the customer for operational deployment is actually the second
version insofar as critical design/operations areas are concerned."
Note that, in the section referencing DoD-Std-2167, the author of the DoD standard does state explicitly that he understood Waterfall to be one-pass. Certainly he implicitly promoted it as such.
The mistake I believe you're making is in assuming that because most people reference Royce's paper for a description of Waterfall, that means that the definition of Waterfall is whatever the main subject of that paper is. This does not follow.
The paper describes a number (more than 2) of possible models. The main subject of the paper is probably the "2-pass waterfall" diagram in Figure 7. However, when people refer to this paper in the context of the Waterfall model, they mean Figure 2. The Waterfall model is called the Waterfall model because Figure 2 looks like a waterfall, with the water never flowing uphill.
Figure 7, however, was largely ignored. (Though Brooks later recapitulated it as "Build one to throw away; you will, anyhow". I don't know whether it was influential in the development of the Spiral model or not, though it seems like a logical progression.) As far as I know this model never even got a name attached to it. Its influence pales in comparison to Figure 2, which was the first and best published reference to a design process that almost everybody accepted as "ideal" at the time.
Note that when Brooks tells the story in The Mythical Man-Month about making the mistake of getting a large group of mediocre engineers to write specifications instead of giving the job to a small group of elite engineers because he didn't want the larger group just sitting on their thumbs for a year, this was all happening in the mid 60s. Here's another contemporary quote:
The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job. —Doug Ross, 1968
Winston Royce did not invent the Waterfall model in 1970, he was just describing the already-dominant paradigm as a prelude to proposing something different. The model had been around forever, Royce provided a convenient diagram (Figure 2!) in the course of trying to critique (or even replace) it, and the name "Waterfall" got attached later.
> Note that, in the section referencing DoD-Std-2167, the author of the DoD standard does state explicitly that he understood Waterfall to be one-pass.
Of course he did, and he understood it correctly. The thing he didn't understand was that it was a terrible idea.
Had he (properly) read Royce's paper, he would have seen that it actually advocated a slightly better (but still pretty terrible) idea, but that idea was not and is not the Waterfall model. The Waterfall model is the one in Figure 2 that looks like a waterfall. Hence the name.
> My own interpretation is contradicted further down in my comment by someone from that era (see the Larman paper linked). C'est la vie, I'm sticking with my interpretation.
Um, OK then.
Thanks for the link though, it was really interesting.
I always thought waterfall was inherently iterative you could jump back up the stack at any point in the process one sucsessfull project I worked on at BT (management system for the Uk's SMDS network) had several instances of going back and redoing stages before we even got to the final development phase.
Have you ever seen water jump back up a few stages of a waterfall? (Hint: no.) It's called the Waterfall model exactly because that kind of thing is explicitly not part of it (see Figure 2 in the Royce paper linked above). That's the whole point of the name.
It goes without saying that no software development effort has ever lived up to this standard. Nonetheless, the fact that it is not possible to develop non-trivial designs (for software or anything else) like this in no way prevented people from advocating it as the "ideal" design process.
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 development—to describe a critical view of a commonly used software development practice.
You're being a bit too literal. The name came from the resemblance of a diagram in the paper to a waterfall. The name wasn't meant to constrain the methodology to strict characteristics of a waterfall. The steps are meant to be followed in order. It is gated. But, nothing constrains the steps from being repeated. That is the crux of the difference between Dr. Royce's paper and what the military formed as a standard based on the paper.
I took a college comp sci course a few years ago. The professor talked for a few minutes about the Waterfall methodology. In short, she said "we in academia gaffed by promoting the Waterfall methodology for several decades. It's now cause for laughter in academic circles when someone proposes the Waterfall method for software development."
My theory - agile/iterative development rarely gets sold because we continue to believe we aren't susceptible to planning fallacy.