Royce 1970
Dr. Winston W. Royce, “Managing the
development of large software systems”.
Proc. IEEE WESCON, Aug 1970.
Reprinted 9th Intl. Conf. Softw. Eng., 1987.


Universally cited as the reference for the
waterfall model

But, the word “waterfall” is not mentioned

And the model looks more like a cascade
Moreover, the paper is actually against the
waterfall model
The Basic Waterfall Model
Engineering
at its best!
With Fallback
Problems

Doing everything in a single sequence is
unrealistic


A better model involves iteration between
successive steps
Testing comes too late and may uncover
problems in the initial design

The solution: do it twice
(Same advice as Fred Brooks in The Mythical ManMonth, but referring to a full-scale system)
Using a Prototype
New stage of
preliminary design
Note that prototype
is actually used!
Learning from Prototypes





Verify feasibility of approach and design
Temporary executable system used to gain
experience and identify problems in
performance, resource requirements, etc.
Study and compare alternative designs or
implementations, and foster creativity
Try out the user interface, to show clients/users,
get feedback, and understand requirements
May be used in real application domain and
actually evolve into full system
Exercise:
The ministry of interior wants to create a
computerized system for filing forms.
There are 31 different forms that need to be
supported, with various fields.
Need to be able to save partially filled forms,
return to form started earlier, print a completed
form, and submit it electronically.
What would you implement in a prototype?
Additional Emphases

Need to plan and control the testing

Need to involve the client in key points
Additional Emphases

Need to plan and control the testing

Need to involve the client in key points

Create multiple documents (requirements,
specification, design, test plan, manual) and
keep them up to date


“Write an overview document that is
understandable, informative, and current. Each and
every worker must have an elemental
understanding of the system.”
“If the documentation is in serious default my first
recommendation is simple: replace project
management.”
Summary
Frederick P. Brooks, Jr.
The Design of Design
Addison Wesley, 2010
Project manager for IBM’s System/360 and OS/360
Founded CS department at University of North Carolina
Received National Medal of Technology 1985
Received Turing Award 1999
Many other awards and honors
Famous for The Mythical Man-Month, Brooks’s Law, No
Silver Bullet
Waterfall Doesn’t Work
• Clients don’t know what they want
• We can’t map out all the alternatives in advance
• The design cannot be decomposed into a
sequence of decisions
• The goodness function cannot be computed
incrementally
• Desiderata and constraints keep changing
• Designers just don’t work that way
Root Causes I
• Requirements are done once up front
Need to get everything you might need in
• Sometimes done by committee
I’ll support yours if you support mine
Outcome: requirements bloat
Root Causes II
• we are not perfect
• Greedy clients try to pay less
• Builders tray to maximize income and not value/cost
• Misunderstandings abound
• So we need contracts
• Contracts must spell out the details before the
project is started
Alternative Contracting Scheme
1. Develop programatic idea
2. Contract with architect for services
•
Complete requirements
•
Conceptual design
•
Detailed design
•
Pay for hours worked
3. Contract with constructor
•
Use design document produced above
•
Fixed price contract for production
The Frustration
Royce’s paper is very insightful and foreshadows
several modern ideas.
On page 2 it says (of the waterfall) “I believe in
this concept, but the implementation described
above is risky and invites failure.”
Others have identified many additional problems.
So why is the waterfall model still being used?
And why is it a standard?