1. The Waterfall Methodology
It was the best of methods,
it was the worst of methods.
Copyright © Curt Hill

2. Waterfall Model This is a classic engineering model
Predates software engineering in its use by other engineering disciplines
Consider the construction of a building for a business
Copyright © Curt Hill

3. A Building
Consider what is needed, what is wanted and what can be afforded
Always a compromise
Architect the building
Construct the building from the plans
Furnish the building
Occupy the building
Copyright © Curt Hill

4. Commentary
In the building approach each of the steps is finished before the next one is started
We do not redesign the building after construction is done
It requires that each step gets it right before proceeding
In software development this is called the waterfall model or linear sequential model
Copyright © Curt Hill

5. Operation & Maintenance
Waterfall Model
Requirements
Design
Unit Implementation
System Integration
Operation & Maintenance
Copyright © Curt Hill

6. Waterfall Model A sequential process Several phases
Each largely completes before the next one starts
There may be some overlap
Backing up is expensive – it throws away work already done
Copyright © Curt Hill

7. Adaptation
This technique works rather well for building and heavy manufacturing
Thus it was adapted to software engineering rather early
The term first appears in an 1976 paper although the model appears before this
In 1985 DOD required a process that included these steps: Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing
Copyright © Curt Hill

8. The Original Phases System and software requirements Analysis Design
A product requirements document
Analysis
Models, schema, and business rules
Design
Software architecture
Coding
Development, unit testing and integration
Testing
System debugging
Operations
Installation, support, and maintenance
Copyright © Curt Hill

9. Incorrect Assumptions
Constructing a building is much different than constructing software
Building construction has been fairly well understood for centuries
Seldom hear: Never heard of anything like that before
Physics makes backing up difficult
Many software development projects are knowledge acquisition projects
We do not know what we are getting into
Copyright © Curt Hill

10. A Thought Experiment
Think about a steel frame building like the Empire State Building
Now we cut out one of the corner pillars
In a building this is preposterous
In software it is reasonable
We do it all the time
This illustrates one of the serious differences between building and software construction
Copyright © Curt Hill

11. Waterfall Problems Works better for very large projects
Must have solid managerial support
There should be no technical questions that have not been answered
Many such projects are canceled before rolling out the product
Complete loss of investment
The volatility of requirements is fatal
Technical debt accumulates and is not visible until late in the project
Copyright © Curt Hill

12. Technical Debt
Technical debt refers to the eventual consequences of any system design
AKA design debt or code debt
Unfinished work that is required by a design
Most often seen in projects that are released early
Like financial debt this accrues interest making changes more difficult later
Prevents or makes more difficult enhancements
Copyright © Curt Hill

13. Waterfall Debt We do not see the problems early enough
Requirements were insufficient
Design was poor
Early code was not good
These problems come home to roost at the end of the project
This is when it is most difficult to change
Copyright © Curt Hill

14. Times Have Changed
If it is worth doing it is worth doing wrong until you figure out how to do it right
In the early days this was the best we knew how to do
The types of projects were often more compatible with this model
However, now only about 18% of real world projects are using Waterfall
Copyright © Curt Hill

15. In Contrast This method is very linear
This is a problem that many approaches have attempted to deal with
The notion is that unlike a building a software system evolves
This gives rise to incremental and evolutionary approaches
These produce a sequence of usable systems
Each more complete than the previous
Copyright © Curt Hill

16. When to use Requirements are very well documented, clear and fixed
No ambiguous requirements
Product definition is stable
Technology is understood and is not dynamic
Ample resources with required expertise are available to support the product
The project is short
Copyright © Curt Hill

17. Pros Easy to understand and use Easy to manage
Phases are completed one at a time
Works well for smaller projects where requirements are very well understood
Clearly defined stages
Well understood milestones
Easy to arrange tasks
Process and results are well documented
Copyright © Curt Hill

18. Lots of Cons No working software is produced until late
Plenty of risk and uncertainty
Poor model for long and ongoing projects
Poor where requirements are at a moderate to high risk of changing
It is difficult to measure progress within stages
Copyright © Curt Hill

19. More Cons Cannot accommodate changing requirements
Adjusting scope during the life cycle can end a project
Integration is done as a "big-bang. at the very end
Does not allow identifying technological or business bottleneck or challenges early
Copyright © Curt Hill

20. Historical Analogy
The first high level language was FORTRAN in the late 1950s
Every language that came out in the 1960s was intended to do things better than FORTRAN
Similarly Waterfall was the first methodology for software development
Most of what followed tries to correct a perceived flaw in it
Copyright © Curt Hill

21. Finally
The Waterfall methodology does well only with good specifications, good design and solid organizational support
Software development organizations should only use this in cases of unusual stability
Finally for now
Copyright © Curt Hill