Chapter 2

 Process Models
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
The software process

A structured set of activities required to

develop a software system.
 A software process model is an abstract
representation of a process.

2
A Generic Process Model

3
Process Flow

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4
 Identifying a Task Set
 A task set defines the actual work to be
done to accomplish the objectives of a
software engineering action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be
applied

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5
 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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
 The Waterfall Model
Co m m unic a t io n
pro je c t init ia t io n Planning
re quire m e nt g a t he ring estimating Mo de ling
scheduling
analys is Co ns t ruc t io n
tracking
des ign De plo y m e nt
code
t es t de liv e ry
s uppo rt
f e e dba c k

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7
The V-Model

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
 The Incremental Model

incre m e nt # n
Co m m u n i c a t io n
Pla n ning
Mo de lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n
c ode De p l o y m e n t
t es t d e l i v e ry
fe e d b a c k

d e liv e ry o f
n t h in cre me n t
incre m e nt # 2

Co m m u n i c a t i o n
Pla nning
Mo d e ling
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode De p l o y m e n t
t est d e l i v e ry
fe e d b a c k
d e liv e ry o f
incre m e nt # 1 2 n d in cre me n t

Co m m u n i c a t i o n
Pla nnin g
Mo de lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode
t es t
De p l o y m e n t
d e l i v e ry d e liv e ry o f
fe e d ba c k
1 st in cre me n t

project calendar t ime

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9
Evolutionary Models: Prototyping

Q u i c Quick
k p lan
plan
Co m m u n ic a t io n
communication

Mo dModeling
e lin g
Q u i cdesign
Quick k d e s ig n

De p lo ym e n t
Deployment
D edelivery
liv e ry
&
& Fe e d b ac k Co n s t ru c t io n
Construction
feedback Construction
of
of prototype of prototype
p ro t o t y p e

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11
Evolutionary Models: Concurrent
none

Mode ling a c t ivit y

rep res ent s t he s t at e

Unde r o f a s o ft ware eng ineering
act ivit y o r t as k
de ve lopm e nt

Awa it ing
c ha nge s

Unde r re vie w

Unde r
re vis ion

Ba s e line d

Done

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12
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, architecture-
centric, iterative and incremental” software process
closely aligned with the Unified Modeling Language
(UML)
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
The Unified Process (UP)
Elaelaboration
b o ra t io n

In c e p t io n
inception

c o n s t ru c t io n
Re le a s e
t ra n s it io n
s oft wa re inc re m e nt

p ro d u c t io n

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
 UP Phases
UP Phases
Ince pt ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15
 UP Work Products
Ince pt ion phase

Elaborat ion phase

Vision do cu me n t
In it ial u se -case mo d e l
In it ial p ro je ct g lo s sary Const ruct ion phase
Use -case mo d e l
In it ial b us in e ss case Su pp le me n t ary re q u ire me n t s
In it ial risk asse ss me n t . in clu d in g n o n -fu n ct io n al De sign mo d e l
Transit ion phase
Pro je ct p lan, An aly s is mo d e l Soft ware co mp o n e n t s
p has e s an d it e rat io n s . So ft ware arch it e ct u re Int e g rat e d so ft ware De liv e re d s o ft ware in cre me n t
Bu sin e ss mo d e l, De script io n . in cre me n t Be t a t e st re p o rt s
if ne ce s sary . Exe cu t ab le arch it e ct u ral Te st p lan an d p ro ce d u re Ge n e ral u se r fe e d b ack
On e o r mo re p ro t o t y p e s p rot o t y p e .
In c e p t i o Te st cas e s
n Pre limin ary d e sig n mo d e l Sup po rt d o cu me nt at io n
Re vise d risk list u se r man u als
Pro je ct p lan in clu d ing in st allat io n manu als
it e rat ion plan d e scrip t io n of cu rre n t
adap t e d workflo ws in cre me n t
mile s t on e s
t e ch n ical wo rk p ro d u ct s
Pre limin ary u se r man u al

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
 Personal Software Process (PSP)
 Planning. This activity isolates requirements and develops both size and
resource estimates. In addition, a defect estimate (the number of defects
projected for the work) is made. All metrics are recorded on worksheets
or templates. Finally, development tasks are identified and a project
schedule is created.
 High-level design. External specifications for each component to be
constructed are developed and a component design is created. Prototypes
are built when uncertainty exists. All issues are recorded and tracked.
 High-level design review. Formal verification methods (Chapter 21) are
applied to uncover errors in the design. Metrics are maintained for all
important tasks and work results.
 Development. The component level design is refined and reviewed.
Code is generated, reviewed, compiled, and tested. Metrics are
maintained for all important tasks and work results.
 Postmortem. Using the measures and metrics collected (this is a
substantial amount of data that should be analyzed statistically), the
effectiveness of the process is determined. Measures and metrics should
provide guidance for modifying the process to improve its effectiveness.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
Team Software Process (TSP)
 Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans.
These can be pure software teams or integrated product
teams (IPT) of three to about 20 engineers.
 Show managers how to coach and motivate their teams
and how to help them sustain peak performance.
 Accelerate software process improvement by making
CMM Level 5 behavior normal and expected.
 The Capability Maturity Model (CMM), a measure of the
effectiveness of a software process, is discussed in Chapter 30.
 Provide improvement guidance to high-maturity
organizations.
 Facilitate university teaching of industrial-grade team
skills.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18