“You should use iterative development only on
projects that you want to succeed.”
− Martin Fowler
Barry W. Boehm, “A Spiral Model of Software
Development and Enhancement”. Computer
21(5), pp. 61-72, May 1988
Prof. Software engineering,
Univ. Southern California
Worked at General Dynamics, Rand, TRW
Director of DARPA Information Science
and Technology Office 1989-1992
Fellow of ACM, IEEE
COCOMO cost model, Spiral model, ...
The Basic Force



Code-driven development

“Code-and-fix” approach

No design leads to poor code and frustrated clients
Document-driven development

Waterfall model: each step produces a new document

Requirement for fully developed documents unrealistic
Risk-driven development

Support iterative development

Decide how to proceed by reducing risk of failure
The Spiral Model


Several rounds of development: system
concept, requirements, design
In each round, mitigate risks

Define objectives of part you are doing

Map alternatives for implementation




Recognize constraints on theseWhat
alternatives
you actually
depends
on
Use prototyping, analysis, etc. todo
gain
necessary
the biggest
knowledge and reduce risk
remaining risk
Plan the next step
At the end, perform sequence of coding, testing,
and integration
Using the Spiral

Start with hypothesis that something can be done

Round 1: concept and lifecycle plan

Round 2: top level requirements




Additional rounds: preliminary design, detailed
design
May go back and redo previous round if needed
If the evaluation at some stage shows that it won't
work then stop
At the end you have a workable design that
addresses all risks – go on to coding
Risks

Developing software is fraught with uncertainty

Uncertainty implies risk

This needs to be quantified:
RiskExposure = Probability x Loss

Can be used to chose between alternatives:
select the one where the expected exposure is
smaller
Barry W. Boehm, “Software Risk Management: Principles and Practices”.
IEEE Software 8(1), pp. 32-41, Jan 1991
Risk Management
identification
assessment
what can go wrong
checklists, verify assumptions
analysis
how, implications (cost models)
prioritization
based on exposure
Risk
management
planning
avoid or reduce (spiral)
resolution
control
find appropriate alternatives
prototypes, analysis, simulation
monitoring (top 10)
fixed issues stay fixed
Milestones

In waterfall model there are many milestones
This is too rigid and sequential Make sure we
know what
we want
But there are three really important
ones:
Elaborate
to do,
and thatonit
 Life-cycle objectives
Prepare
forwill
the
how
things
can
be
done
transition
be builtto the
 Life-cycle architecture
client in terms of
 Initial operational capability
site and training


(these foreshadow the unified process)
Barry W. Boehm, “Anchoring the Software Process”.
IEEE Software 13(4), pp. 73-82, Jul 1996
Milestones

Milestones are not (necessarily) documents!


Not a fully specified spec or architecture, but a
framework that will evolve
For example, important interfaces must be specified
precisely, but user interfaces can be a prototype

Articulation of feasibility and rationale are important

Agreement of stakeholders is crucial
Tom Gilb
Principles of Software Engineering Management
Addison Wesley, 1988
Born in the USA
Moved to UK to study
Fell in love, moved to Norway
Worked for IBM for 5 years
Independent consultant with son Kai
www.gilb.com
EVO
• Short for Evolutionary Delivery, chapters 7 and
13 in the book
• “Arguably the best systems engineering project
management method. However, it is also
probably the least known and the least
discussed”
• Core idea:
Deliver value to stakeholders early and often
EVO
• Iterative and incremental
• Deliver in small parts, instead of big bang at the end
(note: not only develop in parts, but actually deliver)
EVO
• Iterative and incremental
• Deliver in small parts, instead of big bang at the end
(note: not only develop in parts, but actually deliver)
• Each iteration is like a waterfall
• Analysis, design, build, test
• Small scope and fast turnaround
• Each iteration must give customer some value
• Prioritize according to maximal value for minimal cost
• Don’t over-plan
EVO
The Norwegian mountain survival principle:
You need never be ashamed of turning back in
time
The juicy bits first principle:
If you deliver the juiciest bits of the project first,
they will forgive cost and budget overruns
The mountain goat principle:
Take one step at a time up the slippery
mountain, and make sure each hoof is on solid
ground first
Prioritization
1. Divide functions into “urgently needed”, “needed
soon”, and “needed later”
2. Divide urgent functions into high/low political value
and high/low economic value
3. Divide high-value functions into low/high
implementation cost
4. Divide low-cost functions into fast implementation or
slower implementation
5. Divide fast implementation into low/high risk of failure
6. Implement low-risk, fast, low-cost, high-value, urgent
function
7. Repeat, monitoring and learning from mistakes
Planning
• Need a general idea of where you want to go
• But not a detailed plan for the whole way
• inflexible
• Wasted effort
• Analogy of road trip from London to Rome
• At each step, plan only that step
Contracts
• Conventionally pay for work
• Millions of dollars paid for work that led to failure
• No incentive to deliver working software
• “No cure no pay”
• Pay for delivered functionality
• Incremental payments match incremental
development
• Incentive to produce working software
Additional Emphases
• Don’t forget non-functional requirements
• Quality attributes such as performance
• Resource attributes such as storage space
• Providing this can be more costly than the basic
functionality
• Everything can and should be quantified
• Break it down into components
• Find the relevant scale for each one
Example: Ease of Access
Perspective
• What projects can benefit from EVO?
Slide from presentation about NSA system leaked by
Edward Snowden, 2013