Chapter 4

 Process Models
Slide Set to accompany
Software Engineering: A Practitioner’s
Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim

Slides copyright © 1996, 2001, 2005, 2009, 2014 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, 8/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, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 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?

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 2
 The Waterfall
Model
Co m m u nic a t io n
p ro je c t in it ia t io n Planning
re qu ire m e n t g a t he rin g estimating Mo d e lin g
scheduling
a na lys is Co n s t ru c t io n
tracking
de s ign De plo y m e nt
c ode
t es t d e liv e ry
s u pp o rt
f e e d ba c k

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 3
The V-Model

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 4
The Incremental
Model
incre m e nt # n
Co m m u n i c a t i o n
Pla n ning

Mo de 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 # 2 n t h in cre me n t

Co m m u n i c a t i o n
Pla n ning

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 ling
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode
d e liv e ry o f
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

1 st in cre me n t

projectEngineering:
These slides are designed to accompany Software calendar tAime
Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 5
Evolutionary Models:
Prototyping
Quick
Qu i c k p la n

Co m m u n ic a t io n plan
communication

Modeling
Mo d e lin g
Qu ic k d e s i g n
Quick design

De p loym e n t
Deployment Construction
De liv e ry
delivery
& Fe e d b a&
ck
of prototype
Co n s t ru c t io n
feedback Construction
of
ofp ro
prototype
t o t yp e

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 6
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, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 7
Evolutionary Models:
Concurrent
none

Mode ling a c t ivit y

rep res ents the s tate

Unde r o f a s o ftware eng ineering
activity o r task
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, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 8
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, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 9
The Unified Process (UP)
elaboration
Ela b o ra t io n

Inc e p t io n
inception

c o ns t ruc t io n
Releas e
t ra ns it io n
s oft ware inc rem ent

p ro d uc t io n
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 10
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, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 11
 UP Work Products
Ince pt ion phase
Visio n d o cu me n t
In it ial u se -case mo d e l
In it ial p ro je ct g lo ssary
In it ial b u sin e ss case
In it ial risk asse ssme n t .
Pro je ct p lan ,
p h ase s an d it e rat io n s.
Bu sin e ss mo d e l,
if n e ce ssary .
On e o r mo re p ro t o t y p e s
In c e p t i o
n Pre limin ary d e sig n mo d e l
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman.
Elaborat ion phase
Use -case mo d e l
Su p p le me n t ary re q u ire me n t s
in clu d in g n o n -fu n ct io n al
An aly sis mo d e l
So ft ware arch it e ct u re
De scrip t io n .
Exe cu t ab le arch it e ct u ral
p ro t o t y p e .
Re v ise d risk list
Pro je ct p lan in clu d in g
it e rat io n p lan
ad ap t e d wo rkflo ws
mile st o n e s
t e ch n ical wo rk p ro d u ct s
Pre limin ary u se r man u al
Const ruct ion phase
De sig n mo d e l
Transit ion phase
So ft ware co mp o n e n t s
De liv e re d so ft ware in cre me n t
In t e g rat e d so ft ware
in cre me n t Be t a t e st re p o rt s
Ge n e ral u se r fe e d b ack
Te st p lan an d p ro ce d u re
Te st case s
Su p p o rt d o cu me n t at io n
u se r man u als
in st allat io n man u als
d e scrip t io n o f cu rre n t
in cre me n t
12
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. An external specification is created for each
component 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 measures and metrics collected the effectiveness of
the process is determined. If this is a large amount of data it should be
analyzed statistically), 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, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 13
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, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 14