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
 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. 2
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. 3
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. 4
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. 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 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. 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 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. 7
 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. 8
 The Waterfall Model
Co m m unic a t io n
p ro je c t init ia t io n Planning
re q uire m e n t g a t he rin g estimating Mo d e ling
scheduling
ana lys is Co ns t ru c t io n
tracking
des ign De plo y m e nt
c ode
t es t de liv e ry
s u p po 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. 9
Waterfall Process Model
Purpose
The waterfall model is a classical model used in system development life cycle
to create a system with a linear and sequential approach. It is termed as
waterfall because the model develops systematically from one phase to another in
a downward fashion.
The waterfall model is a breakdown of project activities into linear sequential
phases, where each phase depends on the deliverables of the previous one and
corresponds to a specialisation of tasks. The approach is typical for certain areas
of engineering design.
When compared with other methodologies, Waterfall focuses most on a clear,
defined set of steps. Its structure is simple—each project goes through these
steps:
Requirement gathering and documentation
System design
Implementation
Testing
Delivery/deployment
Maintenance

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10
Advantages
Waterfall relies on teams following a sequence of steps and never
moving forward until the previous phase has been completed. This
structure is suited to smaller projects with deliverables that are easy to
define from the start.
Waterfall can be a useful and predictable approach if requirements are
fixed, well documented, and clear, if the technology is understood and
mature.
A Waterfall approach can actually provide more predictable end result
for budget, timeline, and scope.
As an internal process, the Waterfall methodology focuses very little on
the end user or client involved with a project. Its main purpose has always
been to help internal teams move more efficiently through the
phases of a project, which can work well for the software world.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11
Disadvantages
 Waterfall is based entirely on following a set of steps that keep teams always
moving forward. The methodology, in its traditional form, leaves almost no room
for unexpected changes or revisions.
 As an internal process, the Waterfall methodology focuses very little on the end
user or client involved with a project.
 Saving the testing phase until the last half of a project is risky, but Waterfall
insists that teams wait until step four out of six to test their products.
 Critics of Waterfall felt that there was too much room for problems to remain
unnoticed until the project neared completion, which left large, costly changes as
the only solution.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12
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. 13
V Model
 In software development, the V-model represents a development
process that may be considered an extension of the waterfall model,
and is an example of the more general V-model. Instead of moving
down in a linear way, the process steps are bent upwards after the
coding phase, to form the typical V shape.
 It is also known as Verification and Validation model. It is based on the
association of a testing phase for each corresponding development
stage. Development of each step directly associated with the testing
phase. The next phase starts only after completion of the previous
phase i.e. for each development activity, there is a testing activity
corresponding to it.
 Verification: It involves static analysis technique (review) done without
executing code. It is the process of evaluation of the product
development phase to find whether specified requirements meet.
 Validation: It involves dynamic analysis technique (functional, non-
functional), testing done by executing code. Validation is the process
to evaluate the software after the completion of the development
phase to determine whether software meets the customer expectations
and requirements.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
 V Model
Design Phase:
Requirement Analysis: This phase contains detailed
communication with the customer to understand their requirements
and expectations. This stage is known as Requirement Gathering.
System Design: This phase contains the system design and the
complete hardware and communication setup for developing product.
Architectural Design: System design is broken down further into
modules taking up different functionalities. The data transfer and
communication between the internal modules and with the outside
world (other systems) is clearly understood.
Module Design: In this phase the system breaks dowm into small
modules. The detailed design of modules is specified, also known as
Low-Level Design (LLD).

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15
V Model
Testing Phase:
Unit Testing: Unit Test Plans are developed during module design phase. These
Unit Test Plans are executed to eliminate bugs at code or unit level.
Integration testing: After completion of unit testing Integration testing is
performed. In integration testing, the modules are integrated and the system is
tested. Integration testing is performed on the Architecture design phase. This test
verifies the communication of modules among themselves.
System Testing: System testing test the complete application with its
functionality, inter dependency, and communication.It tests the functional and non-
functional requirements of the developed application.
User Acceptance Testing (UAT): UAT is performed in a user environment that
resembles the production environment. UAT verifies that the delivered system
meets user’s requirement and system is ready for use in real world.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
V Model
 Why preferred?
 It is easy to manage due to the rigidity of the model. Each phase of V-Model has
specific deliverables and a review process.
 Proactive defect tracking – that is defects are found at early stage.
 When to use?
 Where requirements are clearly defined and fixed.
 The V-Model is used when ample technical resources are available with
technical expertise.
 Advantages:
 This is a highly disciplined model and Phases are completed one at a time.
 V-Model is used for small projects where project requirements are clear.
 Simple and easy to understand and use.
 This model focuses on verification and validation activities early in the life cycle
thereby enhancing the probability of building an error-free and good quality
product.
 It enables project management to track progress accurately.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
V Model
 Disadvantages:
 High risk and uncertainty.
 It is not a good for complex and object-oriented projects.
 It is not suitable for projects where requirements are not clear and contains
high risk of changing.
 This model does not support iteration of phases.
 It does not easily handle concurrent events.

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

incre me nt # n
Co m m u n ic a t i o n
Pla n n in g

Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n
code De p l o y m e n t
t est d e l i v e ry
fe e db a c k

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

Co m m u n ic a t i o n
Pla n n in g

Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n code 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 io n
Pla n nin g
Mo d e ling
a n a ly s is C o n s t ru c t i o n
d e s ig n c od e
d e liv e ry o f
De p lo y m e n t
t es t d e l i v e ry
fe e d b a 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. 19
Incremental Model
 The incremental build model is a method of software development
where the product is designed, implemented and tested
incrementally until the product is finished. It involves both
development and maintenance. The product is defined as finished
when it satisfies all of its requirements.
 Each iteration passes through the requirements, design, coding
and testing phases. And each subsequent release of the system
adds function to the previous release until all designed functionality
has been implemented.
Characteristics of an Incremental module includes
 System development is broken down into many mini development
projects
 Partial systems are successively built to produce a final total system
 Highest priority requirement is tackled first
 Once the requirement is developed, requirement for that increment
are frozen.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20
Incremental Model
When to use Incremental models?
Requirements of the system are clearly understood
When demand for an early release of a product arises
When software engineering team are not very well skilled
or trained
When high-risk features and goals are involved
Such methodology is more in use for web application and
product based companies

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

Advantages Disadvantages
•The software will be generated quickly •It requires a good planning designing
during the software life cycle
•Problems might cause due to system
•It is flexible and less expensive to change architecture as such not all
requirements and scope requirements collected up front for the
entire software lifecycle
•Throughout the development stages •Each iteration phase is rigid and does
changes can be done not overlap each other
•Rectifying a problem in one unit
•This model is less costly compared to
requires correction in all the units and
others
consumes a lot of time

•A customer can respond to each building  

•Errors are easy to be identified  

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

Q u i c k p la n
Quick
Co m m u n ic a t io n plan
communication
Mo d e l in g
Modeling
Qu ic k d e s ig n
Quick design

De p lo ym e n t
Deployment Construction
De liv e ry
delivery
& Fe e d b & ac k
of Co
prototype
n s t ru c t io n
feedback Construction
of
of
p roprototype
t o t ype

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 23
Prototype Model
 The basic idea in Prototype model is that instead of freezing the requirements
before a design or coding can proceed, a throwaway prototype is built to understand
the requirements. This prototype is developed based on the currently known
requirements. Prototype model is a software development model. By using this
prototype, the client can get an “actual feel” of the system, since the interactions
with prototype can enable the client to better understand the requirements of the
desired system.  Prototyping is an attractive idea for complicated and large systems
for which there is no manual process or existing system to help determining the
requirements .
Advantages of Prototype model:
 Users are actively involved in the development
 Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified
Requirements validation, Quick implementation of, incomplete, but
functional, application.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 24
Prototype Model
 Disadvantages of Prototype model:
 Leads to implementing and then repairing way of building systems.
 Practically, this methodology may increase the complexity of the system as
scope of the system may expand beyond original plans.
 Incomplete application may cause application not to be used as the
full system was designed
Incomplete or inadequate problem analysis.
 When to use Prototype model:  
 Prototype model should be used when the desired system needs to have a
lot of interaction with the end users.
 Typically, online systems, web interfaces have a very high amount of
interaction with end users, are best suited for Prototype model. It might take
a while for a system to be built that allows ease of use and needs minimal
training for the end user.
 Prototyping ensures that the end users constantly work with the system and
provide a feedback which is incorporated in the prototype to result in a
useable system. They are excellent for designing good human computer
interface systems.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 25
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. 26
 Spiral Model
 The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. Its
one of the software development models like Waterfall, Agile, V-Model.
 Planning Phase: Requirements are gathered during the planning phase. Requirements
like ‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System
Requirement specifications’.
 Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and
alternate solutions.  A prototype is produced at the end of the risk analysis phase. If any
risk is found during the risk analysis then alternate solutions are suggested and
implemented.
 Engineering Phase: In this phase software is developed, along with testing at the end of
the phase. Hence in this phase the development and testing is done.
 Evaluation phase: This phase allows the customer to evaluate the output of the project to
date before the project continues to the next spiral.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 27
Spiral Model
 Advantages of Spiral model:
 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
 Disadvantages of Spiral model:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 28
Spiral Model
When to use Spiral model:
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of potential changes to
economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)

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

Modeling a ct ivit y

rep res ents the state

Under o f a s oftware eng ineering
activity o r tas k
de ve lopm e nt

Awa it ing
c hange s

Under review

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. 30
Concurrent Model
 Concurrent Process model is an evolutionary process model in software
engineering. The term concurrent mean “done at the same time”. ... The
concurrent process model shows the current state of activities, tasks and their
associated states that remain in different phases.
Where is Concurrent Model Used?
The concurrent process model is often used as the paradigm for the development
of client/server applications. A client/server system is composed of a set of
functional components. When applied to client/server, the concurrent process
model defines activities in two dimensions a system dimension and component
dimension.
What is the Purpose of Concurrent Model?
The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the Software engineering
activities, actions, or tasks. Commercial off-the-shelf (COTS) Software
components, developed by vendors who offer them as products, can be used
when Software is to be built.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 31
Concurrent Model
 Advantages of the concurrent development model
This model is applicable to all types of software development
processes. It is easy for understanding and use. It gives immediate
feedback from testing. It provides an accurate picture of the
current state of a project.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 32
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. 33
The Unified Process (UP)
Ela b o ra t io n
elaboration

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 increm e nt

p ro d uc 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. 34
Unified Process model
 The unified process model (or UPM is an iterative, incremental,
architecture-centric, and use-case driven approach for
developing software. This model consists of four phases, including:
 Inception, in which you collect requirements from the customer and
analyze the project's feasibility, its cost, risks, and profits.
 The primary goals of Elaboration are to address known risk factors
and to establish and validate the system architecture
 Construction is the largest phase of the project. In this phase, the
remainder of the system is built on the foundation laid in Elaboration.
System features are implemented in a series of short, time-boxed
iterations. Each iteration results in an executable release of the
software.
 The final project phase is Transition. In this phase the system is
deployed to the target users. Feedback received from an initial
release (or initial releases) may result in further refinements to be
incorporated over the course of several Transition phase iterations.
The Transition phase also includes system conversions and user
training.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 35
Unified Model
Advantages:
This is a complete methodology in itself with an emphasis on accurate documentation
It is proactively able to resolve the project risks associated with the client's evolving requirements
requiring careful change request management
Less time is required for integration as the process of integration goes on throughout the  software
development life cycle.
The development time required is less due to reuse of components.
There is online training and tutorial available for this process.

Disadvantages:
The team members need to be expert in their field to develop a software under this methodology.
The development process is too complex and disorganized.
On cutting edge projects which utilise new technology, the reuse of components will not be
possible. Hence the time saving one could have made will be impossible to fulfill.
Integration throughout the process of software development, in theory sounds a good thing. But
on particularly big projects with multiple development streams it will only add to the confusion and
cause more issues during the stages of testing

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 36
Unified Model
When to use this Model?
Itis used to prepare basis for the project, including preparation of business case,
establishing project scope and setting boundaries, outlining key requirements, and
possible architecture solution together with design tradeoffs, identifying risks, and
development of initial project plan—schedule with main milestones .
Characteristics:
The key characteristics of the Unified Process are: It is an iterative and
incremental development framework.

Those best practices are:

Develop Software Iteratively.
Manage Requirements.
Use Component-based Architectures.
Visually Model Software.
Verify Software Quality.
Control Changes to Software.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 37
UP Phases
UP Phases
Ince pt ion Elaborat ion Const ruct ion Trans it 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. 38
 UP Work Products
Ince pt ion phase

Elaborat ion phase

Vis io 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
Const ruct ion phase
Us e -case mo d e l
In it ial b u sin e ss cas e Su p p le me n t ary re q u ire me n t s
In it ial risk as se ssme n t . in clu d in g n o n -fu n ct io n al De sig n mo d e l
Transit ion phase
Pro je ct p lan , An aly sis mo d e l So ft ware co mp o n e n t s
p h ase s an d it e rat io n s . So ft ware arch it e ct u re In t 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 s s mo d e l, De scrip t io n . in cre me n t Be t a t e s t re p o rt s
if n e ce s sary . Exe cu t ab le arch it e ct u ral Ge n e ral u se r fe e d b ack
Te s t p lan an d p ro ce d u re
On e o r mo re p ro t o t y p e s p ro t o t y p e .
In c e p t i o Te s t case s
n Pre limin ary d e sig n mo d e l Su p p o rt d o cu me n t at io n
Re v ise d risk list u se r man u als
Pro je ct p lan in clu d in g in st allat io n man u als
it e rat io n p lan d e scrip t io n o f cu rre n t
ad ap t e d wo rkflo ws in cre me n t
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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 39
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. 40
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. 41
Exercise
 Q: Describe a process framework in your own words when we say that framework activities
are applicable to all projects, does this mean that the same work tasks are applied for all
projects, regardless of size and complexity? Explain.
 Q: As you move outward along the Spiral process flow, What can you say about the software
that is being developed or maintained?
 Why does an iterative process make the project easier to manage change?

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