Chapter 2

◼ Process Models
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
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
A Layered Technology

tools

methods

process model

a “quality” focus

Software Engineering

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2
A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3
 A process is a collection of
activities, actions, and tasks that
Definition of Terms are performed when some work
product is to be created

An activity strives to achieve a broad

objective (e.g., communication with
stakeholders) and is applied
regardless of the application domain,
size of the project, complexity of the
effort, or degree of rigor with which
software engineering is to be applied.
A task focuses on a small, but well-
defined objective (e.g., conducting a
unit test) that produces a tangible
outcome.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Process Framework
◼ In the context of software engineering, a process is
not a rigid prescription for how to build computer
software. Rather, it is an adaptable approach that
enables the people doing the work (the software
team) to pick and choose the appropriate set of
work actions and tasks. The intent is always to
deliver software in a timely manner and with
sufficient quality to satisfy those who have
sponsored its creation and those who will use it.

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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
Process Flow
◼ describes how the framework activities and the
actions and tasks that occur within each framework
activity are organized with respect to sequence and
time
◼ It can be linear, iterative, evolutionary or parallel

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7
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. 8
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
◼ You may create a Task Network and Timeline
Chart

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

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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12
Process Patterns
◼ A process pattern
◼ describes a process-related problem that is
encountered during software engineering work,
◼ identifies the environment in which the problem has
been encountered, and
◼ suggests one or more proven solutions to the
problem.
◼ Stated in more general terms, a process pattern
provides you with a template [Amb98]—a
consistent method for describing problem
solutions within the context of the software
process.

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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15
Process Patterns
◼ Pattern Name. The pattern is given a meaningful
name describing it within the context of the
software process (e.g., Technical Reviews).
◼ Forces. The environment in which the pattern is
encountered and the issues that make the problem
visible and may affect its solution.
◼ Type. The pattern type is specified. Ambler
[Amb98] suggests three types:

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
Process Pattern Types
◼ Stage patterns—defines a problem associated
with a framework activity for the process.
◼ Task patterns—defines a problem associated
with a software engineering action or work
task and relevant to successful software
engineering practice
◼ Phase patterns—define the sequence of
framework activities that occur with the
process, even when the overall flow of
activities is iterative in nature.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18
Process Assessment and Improvement
◼ Standard CMMI Assessment Method for Process Improvement
(SCAMPI) — provides a five step process assessment model that
incorporates five phases: initiating, diagnosing, establishing, acting and
learning.
◼ CMM-Based Appraisal for Internal Process Improvement (CBA
IPI)—provides a diagnostic technique for assessing the relative
maturity of a software organization; uses the SEI CMM as the basis for
the assessment [Dun01]
◼ SPICE—The SPICE (ISO/IEC15504) standard defines a set of
requirements for software process assessment. The intent of the
standard is to assist organizations in developing an objective
evaluation of the efficacy of any defined software process. [ISO08]

◼ ISO 9001:2000 for Software—a generic standard that applies to any

organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies. [Ant06]

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

Communication
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
f eedback

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 22
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. 23
 Problems with Waterfall
Model
◼ Real projects rarely follow the sequential flow that the model
proposes. Although the linear model can accommodate iteration, it
does so indirectly. As a result, changes can cause confusion as the
project team proceeds.
◼ It is often difficult for the customer to state all requirements
explicitly. The waterfall model requires this and has difficulty
accommodating the natural uncertainty that exists at the
beginning of many projects.
◼ The customer must have patience. A working version of the
program(s) will not be available until late in the project time span.
A major blunder, if unde-tected until the working program is
reviewed, can be disastrous.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 24
 The Incremental Model

increment # n
Co m m u n i c a t i o n
Pla nning

M ode ling
a n a ly s i s Co n s t ru c t i o n
d e s ig n
c od e 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
nt h increment
increment # 2

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

M ode ling
a na ly s is Co n s t ru c t i o n
d es 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 dba c k
deliv ery of
increment # 1 2nd increment

Co m m u n i c a t i o n
Pla nning
M ode ling
a n a ly s i s Co n s t ru c t i o n
d e s ig n c o de De p l o y m e n t
t es t d e l i v e ry deliv ery of
fe e dba c k

1st increment

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

Q u i ck p l an
Quick
plan
Co m m u n icat io n
communication

Mo d e lin g
Modeling
Q u i ck d e si g n
Quick design

Deployment
Deployment
De live r y
delivery &
& feedback
Fe e d b ack Co n st r u ct io n
Construction
o f Construction
of prototype of prototype
p r o t o t yp e

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

Modeling act ivit y

represent s t he st at e
Under of a sof t ware engineering
act ivit y or t ask
development

A wait ing
changes

Under review

Under
revision

Baselined

Done

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 29
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 (Aspect-Oriented Software Development )—
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. 30
 The Unified Process (UP)
elaboration
Elab o r at io n

Incep t io n
inception

co nst r uct io n
Release
t r ansit io n
soft ware increment

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
p r o d uct io n
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 31
 Phases in UP
◼ Inception - encompasses both customer communication and
planning activities.
◼ Elaboration - encompasses the communication and modeling
activities of the generic process model
◼ Construction - identical to the construction activity defined
for the generic software process
◼ Transition - encompasses the latter stages of the generic con-
struction activity and the first part of the generic deployment
(delivery and feedback) activity
◼ Production - coincides with the deployment activity of the
generic process
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 32
 Unified Process (UP) Phases
UP Phases
Incept 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. 33
 UP Work Products
Incept ion phase

Elaborat ion phase

Vision document
Init ial use-case model
Init ial project glossary Const ruct ion phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Design model
Transit ion phase
Project plan, Analy sis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Deliv ered soft ware increment
Int egrat ed soft ware
Business model, Descript ion. increment Bet a t est report s
if necessary . Execut able archit ect ural Test plan and procedure General user feedback
One or more prot ot y pes prot ot y pe.
I nc e pt i o Test cases
n Preliminary design model Support document at ion
Rev ised risk list user manuals
Project plan including inst allat ion manuals
it erat ion plan descript ion of current
adapt ed workflows increment
milest ones
t echnical work product s
Preliminary user manual

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

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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 37
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. 38
TSP Framework Activities
◼ project launch
◼ high-level design
◼ Implementation
◼ integration and test, and
◼ postmortem

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 39
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 40
Assignment
◼ What is Agile Software Development
◼ What are the steps?
◼ Give examples and describe different Agile Model
Process
◼ Submission: Feb ___ via MS Teams

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