Chapter 2

 Process Models

Slide Set to accompany

Sof tware 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 Sof tware 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 Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 1
 A Generic Process Model

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

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 3
Identif ying a Task Set
 A task set defines the actual work to be done to accomplish the
objectives of a sof tware 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 Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 4
Process Patterns
 A process pattern
 describes a process-related problem that is encountered during sof tware
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 sof tware process.

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 5
Process Pattern Types
 Stage patterns—defines a problem associated with a framework
activity for the process.
 Task patterns—defines a problem associated with a sof tware
engineering action or work task and relevant to successful
sof tware 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 Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 6
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 sof tware organization; uses the SEI CMM as
the basis for the assessment [Dun01]
 SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for sof tware process
assessment. The intent of the standard is to assist organizations in developing an objective
evaluation of the ef ficacy of any defined sof tware process. [ISO08]
 ISO 9001:2000 for Sof tware—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 sof tware organizations and companies. [Ant06]

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 7
 Prescriptive Models
 Prescriptive process models advocate an orderly approach to sof tware
engineering
That leads to a few questions …
 If prescriptive process models strive for structure and order, are they
inappropriate for a sof tware 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 sof tware work?

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 8
 The Waterfall Model
C o m m u n ic a t io n
p ro je c t in it ia t io n Planning
re q u ire m e n t g a t h e rin g
estimating
M o d e lin g
scheduling
a n a ly s i s C o n s t r u c t io n
tracking
d e s ig n D e p lo y m e n t
c o de

t e s t d e liv e r y
s u p p o rt
f e e d b a c k

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

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

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

Quick plan for prototype

plan
communication throughaway and evolutionary
prototypes
Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 12
Evolutionary Models: The Spiral

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 13
Evolutionary Models: Concurrent Parallel process flow

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 14
 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,
specif ying, designing, and constructing aspects
 Unified Process—a “use-case driven, architecture-centric, iterative and
incremental” sof tware process closely aligned with the Unified
Modeling Language (UML)
notations are used as a syntax to build design

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 15
The Unified Process (UP)
elaboration

inception

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

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 17
UP Work Products

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 18
Personal Sof tware 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 uncer tainty 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 impor tant 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 impor tant tasks and work results.
 Postmor tem. Using the measures and metrics collected (this is a substantial amount of data that should be
analyzed statistically), the ef fectiveness of the process is determined. Measures and metrics should provide
guidance for modif ying the process to improve its ef fectiveness.

These slides are designed to accompany Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 19
Team Sof tware Process (TSP)
 Build self-directed teams that plan and track their work, establish goals, and
own their processes and plans. These can be pure sof tware 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 per formance.
 Accelerate sof tware process improvement by making CMM Level 5 behavior
normal and expected.
 The Capability Maturity Model (CMM), a measure of the ef fectiveness of a
sof tware 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 Sof tware Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 20