Software Engineering: A Practitioner’s Approach,
6/e
Chapter 3
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
estimat ing
scheduling
tracking
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
Coming up: The Incremental Model
3
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
4
The Incremental Model
Requires: Operational product 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
5
The RAD Model
Team # n
M o d e lin g
bus ines s m odeling
dat a m odeling
proc ess m odeling
C o n s t r u c t io n
c om ponent reus e
aut om at ic c ode
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
6
The RAD Model
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
7
Evolutionary Models: Prototyping
Prototyping is a tool that can
be used during any process
Qu ick p l an
Com m unicat ion
communication
Used when customer only
has a vague idea of what
they want
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
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
Const r uct ion
of
Construction
pr
ot ype
of ot
prototype
8
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
9
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)
10
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
11
UP Phases
UP Phas e s
Incept ion
Elaborat ion
Const ruct ion
Transit ion
Product ion
Wor k flow s
Requirements
Analysis
Design
Implementation
Test
Support
Iterati ons
Coming up: UP Work Products
#1
#2
#n-1
#n
12
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
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
Coming up: Prescriptive Software Models
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
13
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?
14
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?
15
Pick a model

Just checking if you were awake
16
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!
17