EE493.

04
Spiral Model

Royal Military College of Canada

Electrical and Computer Engineering

Major JW Paul Professor Greg Phillips

Jeff.Paul@rmc.ca Greg.Phillips@rmc.ca
+1-613-541-6000 ext. 6091 +1-613-541-6000 ext. 6656
 Phriday Philosophy

Winter 04 EEE/GEF 493B 4-2

 Review
• Why “iterative” or “prototyping” processes?
Build
System
requirements
prototype

Software Review vs
requirements
Quick
critical
design
criteria
Analysis
Refine
prototype
Design
Build
prototype
Coding
Customer
Quick
evaluates
design
prototype Testing

Refine
Maintenance
prototype

Hard to get any stage of the waterfall process “right”

Winter 04 EEE/GEF 493B 4-3
 Evolutionary Prototyping
Gather
requirements
from customer
Build
prototype
• Key question
Quick
Customer
evaluates Derive design
What do you
design
prototype
prototype first?
Refine
prototype
Tune system

Operate and
maintain

• Key feature
Rapidly develop simple models of system
– get rapid feedback & clarify requirements
– reduce uncertainty about design aspects

Winter 04 EEE/GEF 493B 4-4

 Dangers of Prototyping
• implementation of prototype
• compromises may be implemented
• refactoring not defined
• lacking comprehensive design

• Aside: do these dangers outweigh the benefits?

• When to stop?

Winter 04 EEE/GEF 493B 4-5

Today’s Class

Spiral Model
 Boehm’s observation (1988)
• both the waterfall & prototyping models
are aimed a reducing risk
– waterfall reduces risk of requirements/design
thrashing by insisting they are finalized early
– prototyping reduces risk of misunderstanding
user needs by giving user constant feedback
(as prototypes) while system evolves
• relative risks vary by project, change
through project life span
develop software lifecycle model that
explicitly recognizes risk as key driver
Winter 04 EEE/GEF 493B 4-7
 Spiral model
1. Establish next- 2. Evaluate product
level objectives, and process
constraints, alternatives, identify
alternatives and resolve risks

5. Review progress,
confirm commitment
to continue

3. Develop, verify
4. Plan next phases next-level product

Winter 04 EEE/GEF 493B 4-8

 OODA Loop

OBSERVE

ACT ORIENT

DECIDE

Winter 04 EEE/GEF 493B 4-9

Example
Spiral
model 1 2

project

4 3
Winter 04 EEE/GEF 493B 4-10
 Starting & Stopping
• start with a hypothesis
– a particular user need can be
met cost-effectively by the
development of a software
system
• stop when
– system complete and fielded
– hypothesis cannot be met

Winter 04 EEE/GEF 493B 4-11

 Maintenance
• start with a hypothesis
– a modification to this software
system is a cost-effective way
of meeting a particular user
need

Winter 04 EEE/GEF 493B 4-12

 Key Feature
• development of work
products non-uniform
– highest risk items
addressed first, well
documented
• Incorporates
prototyping as a risk-
reduction activity
• Provides an integral
framework for rework
Winter 04 by allowing previous
EEE/GEF 493B 4-13
 Advantages
• flexibility
– accommodates a wide range of development approaches
and a wide range of software applications
• focuses early attention on options involving the reuse of
existing software
• accommodates preparation for lifecycle evolution, growth,
and changes of the software product
• provides a mechanism for incorporating software quality
objectives into software product development
• focuses on eliminating errors and unattractive alternatives
early;
• provides a unified approach for new development and
maintenance
• provides a viable framework for integrated hardware-
software system development.
Winter 04 EEE/GEF 493B 4-14
 Advantages II
• The spiral model is a realistic approach to the
development of large-scale software products because the
software evolves as the process progresses. In addition,
the developer and the client better understand and react
to risks at each evolutionary level.
• The model uses prototyping as a risk reduction
mechanism and allows for the development of prototypes
at any stage of the evolutionary development.
• It maintains a systematic stepwise approach, like the
classic life cycle model, but incorporates it into an iterative
framework that more reflect the real world.
• If employed correctly, this model should reduce risks
before they become problematic, as consideration of
technical risks are considered at all stages.

Winter 04 EEE/GEF 493B 4-15

 Difficulties
• Contracting
– the Spiral model is difficult (but not impossible) to use
in a contracting situation
• difficult to accommodate the required flexibility
• difficult to contract without specifying deliverables in
advance
• Risk assessment expertise
– successful use of the model requires the effective
identification and resolution of risks, something many
managers and developers are poorly trained in
• Need for further elaboration
– as defined, the model is quite general and is difficult
to effectively apply without significant expertise

Winter 04 EEE/GEF 493B 4-16

 Summary

Winter 04 EEE/GEF 493B 4-17

 Review
• What is a key feature of the spiral
model?
• Relate the waterfall model to the
spiral model

Winter 04 EEE/GEF 493B 4-18

 Questions?

Winter 04 EEE/GEF 493B 4-19

 Next Class
• Rational Unified Process

Winter 04 EEE/GEF 493B 4-20