See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/235035976

Spiral Development: Experience, Principles, and Refinements

Article · July 2000

CITATIONS READS

65 9,014

2 authors, including:

Barry Boehm
University of Southern California
395 PUBLICATIONS 27,680 CITATIONS

SEE PROFILE

All content following this page was uploaded by Barry Boehm on 27 August 2014.

The user has requested enhancement of the downloaded file.

 USC
University of Southern California
C S E Center for Software Engineering

Spiral Development: Experience,

Principles, and Refinements
Barry Boehm, USC
LA SPIN Presentation
June 28, 2000

boehm@sunset.usc.edu
http://sunset.usc.edu/MBASE

6/28/00 ©USC-CSE 1
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Model and MBASE

•Spiral experience
• Critical success factors
•Invariants and variants

•Stud poker analogy

•Spiral refinements
•WinWin spiral
•Life cycle anchor points
•MBASE
•Recent Developments
6/28/00 ©USC-CSE 2
 USC
University of Southern California
C S E Center for Software Engineering

“Spiral Development Model:”

Candidate Definition
The spiral development model is a risk-driven process
model generator. It is used to guide multi-stakeholder
concurrent engineering of software-intensive systems.
It has two main distinguishing features. One is a cyclic
approach for incrementally growing a system’s degree
of definition and implementation. The other is a set of
anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory
system solutions.

6/28/00 ©USC-CSE 3
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Invariants and Variants - 1

- Critical success factor examples
Invariants Why Invariant Variants
1. Concurrent rather • Avoids premature
than sequential sequential commitments 1a. Relative amount of
determination of to Rqts, Design, COTS, each artifact developed in
artifacts (OCD, Rqts, combination of cost/ each cycle.
Design, Code, Plans) schedule performance
in each spiral cycle. - 1 sec. response time 1b. Number of
concurrent mini-cycles in
each cycle.
2. Consideration in each • Avoids commitment to 2a. Choice of risk
cycle of critical- stakeholder- resolution techniques:
stakeholder objectives unacceptable or overly prototyping, simulation,
and constraints, risky alternatives. modeling, benchmarking,
product and process reference checking, etc.
alternatives, risk • Avoids wasted effort in
identification and elaborating 2b. Level of effort on
resolution, unsatisfactory each activity within each
stakeholder review alternatives. cycle.
and commitment to - Mac-based COTS
proceed.
3. Level of effort on each • Determines “how much 3a. Choice of methods
activity within each is enough” of each used to pursue activities:
cycle driven by risk activity: domain engr., MBASE/ WinWin, Rational
considerations. prototyping, testing, CM, USDP, JAD, QFD, ESP, …
etc.
- Pre-ship testing 3b. Degree of detail of
• Avoids overkill or artifacts produced in
belated risk resolution. each cycle.

6/28/00 ©USC-CSE 4
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Invariant 1: Concurrent Determination of Key

Artifacts (Ops Concept, Rqts, Design, Code, Plans)

• Why invariant
– Avoids premature sequential commitments to system
requirements, design, COTS, combination of cost/
schedule/ performance
– 1 sec response time
• Variants
1a. Relative amount of each artifact developed in each
cycle.
1b. Number of concurrent mini-cycles in each cycle.
• Models excluded
– Incremental sequential waterfalls with high risk of
violating waterfall model assumptions

6/28/00 ©USC-CSE 5
 USC
University of Southern California
C S E Center for Software Engineering

Sequential Engineering Buries Risk

$100M

Arch. A:
Custom
many cache processors

$50M

Arch. B:
Modified
Client-Server
Original Spec After Prototyping

1 2 3 4 5
Response Time (sec)
6/28/00 ©USC-CSE 6
 USC
University of Southern California
C S E Center for Software Engineering

Waterfall Model Assumptions

1. The requirements are knowable in advance of
implementation.
2. The requirements have no unresolved, high-risk
implications
– e.g., risks due to COTS choices, cost, schedule, performance,
safety, security, user interfaces, organizational impacts
3. The nature of the requirements will not change very much
– During development; during evolution
4. The requirements are compatible with all the key system
stakeholders’ expectations
– e.g., users, customer, developers, maintainers, investors
5. The right architecture for implementing the requirements is
well understood.
6. There is enough calendar time to proceed sequentially.

6/28/00 ©USC-CSE 7
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Invariant 2: Each cycle does

objectives, constraints, alternatives, risks,
review, commitment to proceed
• Why invariant
– Avoids commitment to stakeholder-unacceptable or overly
risky alternatives.
– Avoids wasted effort in elaborating unsatisfactory alternatives.
– Windows-only COTS
• Variants
2a. Choice of risk resolution techniques: prototyping, simulation,
modeling, benchmarking, reference checking, etc.
2b. Level of effort on each activity within each cycle.
• Models excluded
– Sequential phases with key stakeholders excluded

6/28/00 ©USC-CSE 8
 USC
University of Southern California
C S E Center for Software Engineering

Windows-Only COTS Example:

Digital Library Artifact Viewer
• Great prototype using ER Mapper
– Tremendous resolution
– Incremental-resolution artifact display
– Powerful zoom and navigation features
• Only runs well on Windows
– Mac, Unix user communities forced to wait
– Overoptimistic assumptions on length of wait
• Eventual decision to drop ER Mapper

6/28/00 ©USC-CSE 9
 USC
University of Southern California
C S E Center for Software Engineering

Models Excluded: Sequential

Phases Without Key Stakeholders
User,
Customer
Customer,
Developer
Developer,
User, Maintainer
Elaboration,
Inception Construction Transition

• High risk of win-lose even with spiral phases

– Win-lose evolves into lose-lose
• Key criteria for IPT members (AFI 63-123)
– Representative, empowered, knowledgeable, collaborative, committed

6/28/00 ©USC-CSE 10
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Invariant 3: Level of Effort

Driven by Risk Considerations
• Why invariant
– Determines ‘how much is enough” of each activity:
domain engr., prototyping, testing, CM, etc.
– Pre-ship testing
– Avoids overkill or belated risk resolution.
• Variants
3a. Choice of methods used to pursue activities:
MBASE/WinWin, Rational RUP, JAD, QFD, ESP, . . .
3b. Degree of detail of artifacts produced in each cycle.
• Models excluded
– Risk-insensitive evolutionary or incremental
development

6/28/00 ©USC-CSE 11
 USC
University of Southern California
C S E Center for Software Engineering

Pre-Ship Test Risk Exposure

10
RE (total)
Risk Exposure RE
8
RE = (Market share
Size (Loss) • losses)
Prob (Loss) 6

RE (defect losses)
2

Amount of testing; Time to market

6/28/00 ©USC-CSE 12
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Invariants and Variants - 2

Invariants Why Invariant Variants
4. Degree of detail of artifacts • Determines “how much is 4a. Choice of artifact
produced in each cycle enough” of each artifact representations (SA/SD,
driven by risk (OCD, Rqts, Design, Code, UML, MBASE, formal
considerations. Plans) in each cycle. specs, programming
languages, etc.)
Ÿ Avoids overkill or belated risk
resolution
5. Managing stakeholder life- • Avoids analysis paralysis, 5a. Number of spiral cycles or
cycle commitments via the unrealistic expectations, increments between anchor
LCO, LCA, and IOC Anchor requirements creep, points.
Point milestones (getting architectural drift, COTS
engaged, getting married, shortfalls and 5b. Situation-specific merging
having your first child), incompatibilities, of anchor point milestones.
unsustainable architectures,
traumatic cutovers, useless
systems.
6. Emphasis on system and • Avoids premature 6a. Relative amount of
life cycle activities and suboptimization on hardware, hardware and software
artifacts rather than software, or initial determined in each cycle.
software and initial development considerations.
development activities 6b. Relative amount of
and artifacts. capability in each life cycle
increment.

6c. Degree of productization

(alpha, beta, shrink-wrap,
etc.) of each life cycle
increment.

6/28/00 ©USC-CSE 13
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Invariant 4:
Degree of Detail Driven by Risk Considerations
• Why invariant
– Determines “how much is enough” of each artifact
(OCD, Rqts, Design, Code, Plans) in each cycle.
• Screen layout rqts.
– Avoids overkill or belated risk resolution.
• Variants
– 4a. Choice of artifact representations (SA/SD, UML,
MBASE, formal specs, programming languages, etc.)
• Models excluded
– Complete, consistent, traceable, testable requirements
specification for systems involving significant levels of
GUI, COTS, or deferred decisions

6/28/00 ©USC-CSE 14
 USC
University of Southern California
C S E Center for Software Engineering

Risk-Driven Specifications
• If it’s risky not to specify precisely, Do
– Hardware-software interface
– Prime-subcontractor interface
• If it’s risky to specify precisely, Don’t
– GUI layout
– COTS behavior

6/28/00 ©USC-CSE 15
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Invariant 5:
Use of LCO, LCA, IOC, Anchor Point Milestones
• Why invariant
– Avoids analysis paralysis, unrealistic expectations,
requirements creep, architectural drift, COTS shortfalls
and incompatibilities, unsustainable architectures,
traumatic cutovers, useless systems.
• Variants
5a. Number of spiral cycles or increments between anchor
points.
5b. Situation-specific merging of anchor point milestones
• Can merge LCO and LCA when adopting an
architecture from mature 4GL, product line
• Models excluded
– Evolutionary or incremental development with no life
cycle architecture
6/28/00 ©USC-CSE 16
 USC
University of Southern California
C S E Center for Software Engineering

Life Cycle Anchor Points

• Common System/Software stakeholder commitment
points
– Defined in concert with Government, industry affiliates
– Coordinated with the Rational Unified Process
• Life Cycle Objectives (LCO)
– Stakeholders’ commitment to support architecting
– Like getting engaged
• Life Cycle Architecture (LCA)
– Stakeholders’ commitment to support full life cycle
– Like getting married
• Initial Operational Capability (IOC)
– Stakeholders’ commitment to support operations
– Like having first child

6/28/00 ©USC-CSE 17
 USC
University of Southern California
C S E Center for Software Engineering

Win Win Spiral Anchor Points

(Risk-driven level of detail for each element)
Milestone Element Life Cycle Objectives (LCO) Life Cycle Architecture (LCA)
• Top-level system objectives and scope • Elaboration of system objectives and scope of increment
Definition of - System boundary • Elaboration of operational concept by increment
- Environment parameters and assumptions
Operational - Evolution parameters
Concept • Operational concept
- Operations and maintenance scenarios and parameters
- Organizational life-cycle responsibilities (stakeholders)
• Exercise key usage scenarios • Exercise range of usage scenarios
System Prototype(s) • Resolve critical risks • Resolve major outstanding risks
• Top-level functions, interfaces, quality attribute levels, • Elaboration of functions, interfaces, quality attributes,
Definition of System including: and prototypes by increment
Requirements - Growth vectors and priorities - Identification of TBD’s( (to-be-determined items)
- Prototypes • Stakeholders’ concurrence on their priority concerns
• Stakeholders’ concurrence on essentials
• Choice of architecture and elaboration by increment
• Top-level definition of at least one feasible architecture
- Physical and logical components, connectors,
Definition of System - Physical and logical elements and relationships
configurations, constraints
- Choices of COTS and reusable software elements
and Software • Identification of infeasible architecture options
- COTS, reuse choices
Architecture - Domain-architecture and architectural style choices
• Architecture evolution parameters
• Identification of life-cycle stakeholders • Elaboration of WWWWWHH* for Initial Operational
Capability (IOC)
- Users, customers, developers, maintainers, interoperators,
Definition of Life- general public, others - Partial elaboration, identification of key TBD’s for later
Cycle Plan • Identification of life-cycle process model increments
- Top-level stages, increments
• Top-level WWWWWHH* by stage
• Assurance of consistency among elements above • Assurance of consistency among elements above
Feasibility - via analysis, measurement, prototyping, simulation, etc.
• All major risks resolved or covered by risk management
Rationale - Business case analysis for requirements, feasible architectures
plan
*WWWWWHH: Why, What, When, Who, Where, How, How Much
6/28/00 ©USC-CSE 18
 USC
University of Southern California
C S E Center for Software Engineering

Initial Operational Capability (IOC)

• Software preparation
– Operational and support software
– Data preparation, COTS licenses
– Operational readiness testing
• Site preparation
– Facilities, equipment, supplies, vendor support
• User, operator, and maintainer preparation
– Selection, teambuilding, training

6/28/00 ©USC-CSE 19
 USC
University of Southern California
C S E Center for Software Engineering

Evolutionary Development Assumptions

1. The initial release is sufficiently satisfactory to key
system stakeholders that they will continue to
participate in its evolution.
2. The architecture of the initial release is scalable to
accommodate the full set of system life cycle
requirements (e.g., performance, safety, security,
distribution, localization).
3. The operational user organizations are sufficiently
flexible to adapt to the pace of system evolution
4. The dimensions of system evolution are compatible
with the dimensions of evolving-out the legacy
systems it is replacing.
6/28/00 ©USC-CSE 20
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Model and Incremental Commitment:

Stud Poker Analogy
• Evaluate alternative courses of action
– Fold: save resources for other deals
– Ante: buy at least one more round
• Using incomplete information
– Hole cards: competitive situation
– Rest of deck: chance of getting winner
• Anticipating future possibilities
– Likelihood that next round will clarify outcome
• Commit incrementally rather than all at once
– Challenge: DoD POM process makes this hard to do
6/28/00 ©USC-CSE 21
 USC
University of Southern California
C S E Center for Software Engineering

Anchor Points and Rational RUP Phases

Engineering Manufacturing
Stage Stage

Inception Elaboration ConstructionTransition

LCO LCA IOC
Feasibility Architecture Usable Product
Iterations Iterations Iterations Releases

R D I D R D I D R D I D R D I D
E E M E E E M E E E M E E E M E
Q S P P Q S P P Q S P P Q S P P
Management Management Management Management
RATIONAL
Software Corporation

6/28/00 22
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Model Refinements

•Where do objectives,
The WinWin Spiral Model
constraints, alternatives come
from? 2. Identify Stakeholders’ Win-Win
win conditions Extensions

–Win Win extensions

3. Reconcile win
1. Identify next-level
conditions. Establish
•Lack of intermediate milestones Stakeholders
next level objectives,
constraints, alternatives

–Anchor Points: LCO, LCA, IOC

7. Review, commitment
4. Evaluate product and
–Concurrent-engineering spirals process alternatives.
Resolve Risks
6. Validate product
between anchor points and process
definitions
5. Define next level of product and
•Need to avoid model clashes, process - including partitions Original
Spiral
provide more specific guidance
–MBASE

6/28/00 ©USC-CSE 23
 USC
University of Southern California
C S E Center for Software Engineering

MBASE Electronic Process Guide (1)

6/28/00 ©USC-CSE 24
 USC
University of Southern California
C S E Center for Software Engineering

MBASE Electronic Process Guide (2)

6/28/00 ©USC-CSE 25
 USC
University of Southern California
C S E Center for Software Engineering

Spiral Invariant 6:
Emphasis on System and Life Cycle Activities and
Artifacts
• Why invariant
– Avoids premature suboptimization on hardware, software, or
development considerations.
• Scientific American
• Variants
6a. Relative amount of hardware and software determined in
each cycle.
6b. Relative amount of capability in each life cycle increment
6c. Degree of productization (alpha, beta, shrink-wrap, etc.) of
each life cycle increment.
• Models excluded
– Purely logical object-oriented methods
• Insensitive to operational, performance, cost risks
6/28/00 ©USC-CSE 26
 USC
University of Southern California
C S E Center for Software Engineering

Problems With Programming-Oriented

Top-Down Development
“SCIENTIFIC AMERICAN” SUBSCRIPTION PROCESSING

6/28/00 ©USC-CSE 27
 USC
University of Southern California
C S E Center for Software Engineering

Summary: Hazardous Spiral Look-Alikes

• Incremental sequential waterfalls with significant COTS,
user interface, or technology risks
• Sequential spiral phases with key stakeholders excluded
from phases
• Risk-insensitive evolutionary or incremental development
• Evolutionary development with no life-cycle architecture
• Insistence on complete specs for COTS, user interface, or
deferred-decision situations
• Purely logical object-oriented methods with operational,
performance, or cost risks
• Impeccable spiral plan with no commitment to managing
risks

6/28/00 ©USC-CSE 28
 USC
University of Southern California
C S E Center for Software Engineering

Summary: Successful Spiral Examples

• Rapid commercial: C-Bridge’s RAPID process

• Large commercial: AT&T/Lucent/Telcordia
spiral extensions
• Commercial hardware-software: Xerox Time-
to-Market process
• Large aerospace: TRW CCPDS-R
• Variety of projects: Rational Unified Process,
SPC Evolutionary Spiral Process, USC
MBASE approach

6/28/00 ©USC-CSE 29
 USC
University of Southern California
C S E Center for Software Engineering

Recent Developments
• Workshop contents available on SEI web site
– http://www.sei.cmu.edu/cbs/spiral 2000
– SEI Tech Reports forthcoming
• Followon Workshop September 13-15, 2000
– DUSD/S&T sponsor; n Washington DC
– SEI lead organizer, in collaboration with USC
• New DoDD 5000-series acquisition directives due
July-Aug
– Emphasize evolutionary acquisition; spiral
• ASD/C3I Panel report on evolutionary acquisition
– recommends use of spiral development

6/28/00 ©USC-CSE 30
 USC
University of Southern California
C S E Center for Software Engineering

Hands-on Tutorials at USC, July 25-27

• Easy WinWin: July 25-26
– Objective: Learn to initiate and conduct Easy WinWin
requirements negotiations in your organization
– Mode: Hands-on at individual workstation
– Registration: Free to USC-CSE Affiliates; $500. otherwise
• MBASE* Electronic Process Guide: July 27
– Objective: Learn to use MBASE and its EPG
– Mode: Lecture in morning; hands-on in afternoon
– Registration: Free to USC-CSE Affiliates: $250. otherwise
• Details at http://sunset.usc.edu/upcoming-events

*MBASE: Model-Based (System) Architecting and Software Engineering

6/28/00 ©USC-CSE 31
 USC
University of Southern California
C S E Center for Software Engineering

References
(MBASE material available at http://sunset.usc.edu/MBASE)
[Boehm, 1988]. “ A Spiral Model of Software Development and Enhancement,”Computer, May
1988, pp. 61-72.

[Boehm, 1989]. “Software Risk Management”, IEEE Computer Society Press, 1989.

[Boehm-Ross, 1989]. “Theory W Software Project Management: Principles and Examples” IEEE
Trans. Software Engr., July 1989.

[Boehm-Bose, 1994]. “A Collaborative Spiral Software Process Model Based on Theory W,”
Proceedings, ICSP 3, IEEE, Reston, Va. October 1994.

[Boehm-Port, 1999b]. “When Models Collide: Lessons from Software Systems Analysis,” IEEE IT
Professional, January/February 1999, pp. 49-56.

6/28/00 ©USC-CSE 32
 USC
University of Southern California
C S E Center for Software Engineering

B. Boehm, D. Port, “Escaping the Software Tar Pit: Model Clashes and How to Avoid Them,” ACM
Software Engineering Notes, January, 1999, pp. 36-48.

B. Boehm et al., “Using the Win Win Spiral Model: A Case Study,” IEEE Computer, July 1998, pp. 33-44.

B. Boehm et al., “Developing Multimedia Applications with the WinWin Spiral Model,” Proceedings,
ESEC/FSE 97, Springer Verlag, 1997.

M.J. Carr, S.L. Konda, I. Monarch, F.C. Ulrich, and C.F. Walker,”Taxonomy-Based Risk Identification,”
CMU/SEI-93-TR-06, Software Engineering Institute, 1993

R.N. Charette, Software Engineering Risk Analysis and Management, McGraw Hill, 1989.

M.A. Cusumano and R. W. Selby, Microsoft Secrets, Free Press, 1995

E. Hall, Managing Risk, Addison Wesley, 1998.

W. E. Royce, Software Project Management: A Unified Framework, Addison Wesley, 1998.

J. Thorp and DMR, The Information Paradox, McGraw Hill, 1998.

6/28/00 ©USC-CSE 33

View publication stats