Software Engineering: A Practitioner’s Approach,
7/e
Chapter 2
Prescriptive Process Models
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
Coming up: Prescriptive Models
1
Prescriptive Models
Prescriptive process models advocate an orderly approach to
software engineering
That leads to a few questions …
 If prescriptive process models strive for structure and order, are they
inappropriate for a software world that thrives on change?
 Yet, if we reject traditional process models (and the order they
imply) and replace them with something less structured, do we make
it impossible to achieve coordination and coherence in software
work?

Coming up: The Waterfall Model
2
The Waterfall Model
Com m unic a t ion
proje c t init ia t ion
re quire m e nt ga t he ring
Planning
es timating
sc heduling
track ing
Mode ling
analysis
design
Const r uc t ion
code
t est
De ploy m e nt
de liv e ry
s upport
f e e dba c k
Use when:
-Requirements are stable and well-understood,
very short timeline (maintenance fixes)
Coming up: The V-Model
3
The V-Model
Same as Waterfall, diagram used to
emphasize types of testing are linked
to different phases in the model
-Requirements are stable and wellunderstood
Coming up: The Incremental Model
4
The Incremental Model
increment # n
Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is
des ign
Co n s t ru c t i o n
c ode
t es t
De p l o y m e n t
d e l i v e ry
fe e dba c k
deliv ery of
nt h increment
increment # 2
Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is
des ign
Co n s t ru c t i o n
c ode
De p l o y m e n t
t es t
d e l i v e ry
fe e dba c k
increment # 1
deliv ery of
2nd increment
Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is
des ign
Co n s t ru c t i o n
c ode
De p l o y m e n t
t es t
d e l i v e ry
fe e dba c k
deliv ery of
1st increment
project calendar t ime
Coming up: The Incremental Model
5
The Incremental Model
Requires: Operational product that provides some value to users at
each increment.
Advantages
-Helps users get software faster
-Provides ability for the team to evaluate and replan
-May complete an initial functionality to get buy-in or funding for later
increments
Disadvantages
-May not be good for very risky systems
-Full working systems may require long increments
Coming up: The RAD Model
6
The RAD Model
Team # n
M o d e lin g
busines s m odeling
dat a m odeling
process m odeling
C o n s t r u c t io n
com ponent reuse
aut om at ic code
generat ion
t est ing
Team # 2
Com m unicat ion
Mo d eling
b u si n e ss m o d e l i n g
dat a m odeling
p ro ce ss m o d e l i n g
Planning
Co nst r uct io n
Team # 1
co m p o n e n t re u se
a u t o m a t i c co d e
g e n e ra t i o n
t e st i n g
Mode ling
De ploym e nt
int egrat ion
deliv ery
feedback
business modeling
dat a modeling
process modeling
Const r uct ion
component reuse
aut omat ic code
generat ion
t est ing
6 0 - 9 0 days
Coming up: The RAD Model
7
The RAD Model
RAD = Rapid Application Development
Requires: very well understood requirements.
Very fast cycles (60-90 days) to create a lot of functionality
Emphasizes use of existing components/automatic code generation
Challenges:
- Large staff needed to form RAD teams
- Must have modularizable based software
- Developers and Customers must be willing to make quick decisions
- Time-consuming overall system tuning is difficult
Coming up: Evolutionary Models: Prototyping
8
Evolutionary Models: Prototyping
Used when partial system
can be delivered, then
evolved into full system
Qu ick p lan
Com m unicat ion
communication
Prototyping is a tool that can
be used during any process
Used when customer only
has a vague idea of what
they want
Modeling
Mo
d e lin g
Qu
ick d e sig n
Quick
design
Deployment
Deployment
De live r y
delivery &
& Fe e dback
feedback
Plan to either throw-away or
evolve into real product -there will be pressure at the
end to evolve into the real
product
Coming up: Evolutionary Models: The Spiral
Quick
plan
Const r uct ion
of
Construction
pr
ot ype
of ot
prototype
9
Evolutionary Models: The Spiral
planning
Complete
highest risk
items first
estimation
scheduling
risk analysis
communication
Used to mitigate
risk on riskintensive
projects
Every spiral
revises
cost/budget/sche
dule/etc…
Coming up: Still Other Process Models
modeling
analysis
design
start
deployment
delivery
feedback
construction
code
test
10
Still Other Process Models




Component based development—the process to apply
when reuse is a development objective
Formal methods—emphasizes the mathematical
specification of requirements
AOSD—provides a process and methodological
approach for defining, specifying, designing, and
constructing aspects
Unified Process—a “use-case driven, architecturecentric, iterative and incremental” software process
closely aligned with the Unified Modeling Language
(UML)
Coming up: The Unified Process (UP)
11
The Unified Process (UP)
Elab
o r at io n
elaboration
Incep t io n
inception
inception
co nst r uct io n
Release
soft ware increment
t r ansit io n
p r o d uct io n
Coming up: UP Phases
12
UP Phases
UP Phases
Incept ion
Elaborat ion
Const ruct ion
Transit ion
Product ion
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations
Coming up: UP Work Products
#1
#2
#n-1
#n
13
UP Work Products
Incept ion phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary .
One or more prot ot y pes
I nc e pt i o
n
Coming up: Pick a model
Elaborat ion phase
Use-case model
Supplement ary requirement s
including non-funct ional
Analy sis model
Soft ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot y pe.
Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workflows
milest ones
t echnical work product s
Preliminary user manual
Const ruct ion phase
Design model
Soft ware component s
Int egrat ed soft ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
Transit ion phase
Deliv ered soft ware increment
Bet a t est report s
General user feedback
14
Pick a model

Developing software to automatically drive racecars
through a track without crashing. This has never been
attempted before under software control. The
requirements are stable.

Waterfall, Incremental, Spiral, RAD?
Coming up: Pick a model
15
Pick a model

Developing software to track the financial bailout. The
software requirements are very clear. You need to create
a system to perform 3 distinct tasks:





Display where the money went
Display the amount of money left and how it’s allocated
Allow people to request funds from a particular subset of the
money
All functions will interface with each other and the same
underlying database.
Waterfall, Incremental, Spiral, RAD?
Coming up: Pick a model
16
Pick a model

Just checking if you were awake
Coming up: Prescriptive Software Models
17
Prescriptive Software Models




Variations of these models are VERY commonly used today
If you think about it, they are focused in different areas, but have
many similarities (all do the basic structure -- communication,
planning, construction, testing, deployment, maintenance)
You will almost definitely do some version of these processes when
you graduate
If you had never been to CS421, and never learned them, and then
started your own company, you would STILL do your own version of
these processes… they make sense!
Currently these processes are evolving into Agile methods
Lets have a look!
End of presentation
18