2+ decades ago, US Air Force acquisition classes taught exactly this method. I don't recall whether they used the word "waterfall", but they showed the same diagrams and treated software development like massive hardware projects, such as building an F-16: first you write a long requirements document, then generate a voluminous design document, then break the design into a work breakdown structure, farm out component implementation to developers, then finally integrate, test, and ship. It borrowed heavily from the field of Systems Engineering.
In my experience it never worked. We were able to achieve success only by secretly ignoring the rules and process and instead developing software in what detractors called a "cowboy" process. When "agile" came out, it changed our lives. We adopted a few new good ideas, but mostly kept working as we had been. But now we could point to this quasi-official "agile process", with tailoring as they recommend. As long as we were following a process, and not being "cowboys", folks seemed satisfied.
These days the Air Force has caught on to "agile". They even have 400-page manuals on the process to follow to be "agile"! We still cut some corners here and there and do what we think makes sense, but there's far less process push-back than there was in the past.
Acquisitions didn't use Waterfall that I ever saw, until you got to the software specific courses. Then they did, and it was one of several software development lifecycles you were allowed to choose between for projects.
Many program offices and project managers selected it because it was pretty, not because it was sensible.
> These days the Air Force has caught on to "agile". They even have 400-page manuals on the process to follow to be "agile"! We still cut some corners here and there and do what we think makes sense, but there's far less process push-back than there was in the past.
Circa 2010 (+/- a couple years) USAF also picked up Lean in a big way. But their version of Lean was almost exactly the opposite, in practice, of what was done and described by industry as Lean. A key element of Lean being that you actually let the people doing the work provide feedback and direct improvement efforts. USAF's version had the managers (who never did the work) walk around and observe, then change processes to be "leaner". That is, pure scientific management in the Taylorism style.
USAF is a great place for good ideas to get their names reused for old ideas.
Here’s a 2019 presentation about Lockheed Martin’s F-16 team adopting SAFe (Scaled Agile Framework). It was a successful first step because the dev team was able to deliver Program Increments to QA in just nine months, down from 3-4 years.
I'd argue that designing an aircraft still fails badly with waterfall and it is a major reason that aviation is massively behind where it should be right now. Space-x shows that you can build rockets, a lot better, if you ditch that waterfall process.
Agreed, waterfall fails right off the bat at "gather requirements."
If you ask the Air Force how fast a new proposed plane has to fly, they'll say "as fast as possible." Or maybe they'll say "fast enough to accomplish the mission and win wars." But neither of those would be accepted as requirements.
So in reality the Air Force will answer that question with another question: "well how fast can you make it fly?" Which of course depends on a lot of tradeoffs of performance, munitions, and cost. So in reality lots of design and technology tradeoffs go back and forth during the requirements phase, and at some point someone makes a rather arbitrary requirement like "The plane must be able to fly at Mach 2.5." That gets set in stone and drives the program forever after.
So the very notion of "requirements" is complete fiction. Perhaps the plane could have a top speed of Mach 2.2 and still achieve the mission, or go Mach 2.8 and fail to achieve the mission, depending on other aspects of the design.
In my experience it never worked. We were able to achieve success only by secretly ignoring the rules and process and instead developing software in what detractors called a "cowboy" process. When "agile" came out, it changed our lives. We adopted a few new good ideas, but mostly kept working as we had been. But now we could point to this quasi-official "agile process", with tailoring as they recommend. As long as we were following a process, and not being "cowboys", folks seemed satisfied.
These days the Air Force has caught on to "agile". They even have 400-page manuals on the process to follow to be "agile"! We still cut some corners here and there and do what we think makes sense, but there's far less process push-back than there was in the past.