“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 these alternatives Use prototyping, analysis, etc. to gain necessary

knowledge and reduce risk Plan the next step

At the end, perform sequence of coding, testing, and integration

What you actuallydo depends on

the biggestremaining risk

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

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

Risk Management

Riskmanagement

assessment

control

identification

analysis

prioritization

planning

resolution

monitoring

Milestones

In waterfall model there are many milestones This is too rigid and sequential

But there are three really important ones: Life-cycle objectives Life-cycle architecture Initial operational capability

(these foreshadow the unified process)

Make sure weknow what we want

to do, and that itcan be done

Elaborate onhow things will

be builtPrepare for thetransition to theclient in terms ofsite and training

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 USAMoved to UK to studyFell in love, moved to NorwayWorked for IBM for 5 yearsIndependent consultant with son Kaiwww.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

Prioritization1. 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