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.

1
 A Generic Process Model
• A process is a collection of work activities,
actions, and tasks that are performed
when some product is to be created
• These reside within a framework or model
that defines their relationship with the
process and with one another
• The software process is represented in
Figure 2.1

2
A Generic Process Model

3
 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.

4
Process Flow

5
 Identifying a Task Set
• A task set defines the actual work to be
done to accomplish the objectives of a
software engineering action (page 34)
– A list of the tasks to be accomplished
– A list of the work products to be produced
– A list of the quality assurance filters to be
applied

6
Identifying a Task Set

7
 Process Patterns (Self Study)
• 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.
8
• Just in Time Books have run a mail order record business
for two years, catering to a wide variety of readers. They
now wish to develop a fully computerised business
system covering every aspect of their business, including
an interactive web site where orders with credit card
payments could be taken from anywhere in the world. The
owner and staff are anxious about the change and want
core functions to be implemented as soon as possible.

• Suggest the most appropriate prescriptive software

process model that might be used as a basis for
managing the development of the above system.

11
Prescriptive Models
 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?

13
 Prescriptive Models
• 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

14
 The Waterfall Model
Communicat ion
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Const ruct ion
tracking
design Deployment
code
t est delivery
support
f eedback

15
Waterfall Strengths
 Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (planning,
staffing, tracking)
• Works well when quality is more important
than cost or schedule
17
Waterfall Deficiencies
 Waterfall Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are considered frozen
– inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of software
development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system (until
it may be too late)
• Real projects rarely follow the sequential flow that the
model proposes
• Difficult for the customer to state all requirements explicitly
• The customer must have patience

19
When to use the Waterfall
Model
 When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new
platform.

21
The V-Model
A variant of the
Waterfall that
emphasizes the
verification and
validation of the
product.
Testing of the
product is planned in
parallel with a
corresponding phase
of development

22
V-Shaped Strengths
 V-Shaped Strengths
• Emphasize planning for verification and
validation of the product in early stages of
product development
• Each deliverable must be testable
• Project management can track progress
by milestones
• Easy to use

24
V-Shaped Weaknesses
 V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations of phases
• Does not easily handle dynamic changes
in requirements
• Does not contain risk analysis activities

26
When to use the V-Shaped
Model
 When to use the V-Shaped Model
• Excellent choice for systems requiring high
reliability – hospital patient control
applications
• All requirements are known up-front
• Solution and technology are known

28
The Incremental Model
 The Incremental Model
• Initial requirements are reasonably well defined, but
overall scope of the development effort precludes a
purely linear process
• Compelling need to provide a limited set of software
functionality to users quickly and then refine and expand
in later software releases
• Incremental model applies linear sequences in a
staggered fashion as calendar time progresses
• The first increment is often a core product
• Focuses on the delivery of an operational product with
each increment

30
The Incremental Model

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

M odeling
ana l y s i s Co n s t ru c t i o n
des i gn
c o de 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 # 2 nt h increment

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

M odeling
a na ly s i s Co n s t ru c t i o n
d es 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
increment # 1 2nd increment

Co m m u n i c a t i o n
Pla nning
M odeling
a nal y s is Co n s t ru c t i o n
d es i gn c ode 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

31
Incremental Model Strengths
 Incremental Model Strengths
• Useful when staffing is unavailable for a complete implementation by
the business deadline
• Increments can be planned to manage technical risks – new
hardware not available as yet
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced

33
Incremental Model
Weaknesses
 Incremental Model Weaknesses
• Requires good planning and design
• Requires early definition of a complete and
fully functional system to allow for the
definition of increments
• Well-defined module interfaces are
required (some will be developed long
before others)
• Total cost of the complete system is not
lower
35
When to use the Incremental
Model
When to use the Incremental Model
• Risk, funding, schedule, program complexity,
or need for early realization of benefits.
• Most of the requirements are known up-front
but are expected to evolve over time
• A need to get basic functionality to the market
early
• On projects which have lengthy development
schedules
• On a project with new technology

37
Evolutionary Models:
Prototyping
 Evolutionary Models: Prototyping
• Customer defines a set of general objectives for the
software but does not identify detailed requirements for
functions and features
• The developer may be unsure of the efficiency of an
algorithm, the adaptability of an operating system, or
the form of human-machine interaction should take
• Can be used as a stand-alone process model or
commonly used as a technique that can be
implemented within the context of any one of the
process model
• Assist stakeholders to better understand what is to be
built when requirements are fuzzy
39
Evolutionary Models: Prototyping
Q u i ck p l an
Quick
Com m unicat ion plan
communication
Mo d e l i n g
Modeling
Q u i ck d e si g n
Quick design

Deployment
Deployment
De live r y
delivery
& Fe e dback& Const r uct ion
feedback Construction
of
of ot
pr prototype
ot ype

Construction
of prototype

40
Structured Evolutionary
Prototyping Strengths
 Structured Evolutionary
Prototyping Strengths
• Customers can “see” the system
requirements as they are being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates
awareness of additional needed functionality

42
Structured Evolutionary
Prototyping Weaknesses
 Structured Evolutionary
Prototyping Weaknesses
• Tendency to abandon structured program
development for “code-and-fix”
development
• Bad reputation for “quick-and-dirty”
methods
• Overall maintainability may be overlooked
• The customer may want the prototype
delivered.
• Process may continue forever (scope
creep)
44
 When to use
Structured Evolutionary Prototyping
 When to use
Structured Evolutionary Prototyping
• Requirements are unstable or have to
be clarified
• As the requirements clarification stage
of a waterfall model
• Develop user interfaces
• New, original development
• With the analysis and design portions
of object-oriented development.

46
 Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis
Adds risk
communication
analysis, and
modeling prototyping to
analysis the waterfall
design
model
start
Each cycle
involves the
same sequence
deployment of steps as the
construction
delivery
code waterfall
feedback test process model

47
Spiral Model Strengths
 Spiral Model Strengths
• Provides early indication of insurmountable
risks, without much cost
• Users see the system early because of rapid
prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently

49
Spiral Model Weaknesses
 Spiral Model Weaknesses
• Time spent for evaluating risks too large for small
or low-risk projects
• Time spent planning, resetting objectives, doing
risk analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-
development phase activities
• May be hard to define objective, verifiable
milestones that indicate readiness to proceed
through the next iteration

51
When to use Spiral Model
 When to use Spiral Model
• When creation of a prototype is appropriate
• 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)
53
Evolutionary Models: Concurrent

none

Modeling act ivit y

rep resent s t he st at e
Under o f a so f t ware eng ineering
act ivit y o r t ask
development

A wait ing
changes

Under review

Under
revision

Baselined

Done

54
Still Other Process Models
• Component based development—the process to apply
when reuse is a development objective. Spiral model
variation in which applications are built from prepackaged
software components called classes
• Formal methods—emphasizes the mathematical
specification of requirements.
• AOSD—provides a process and methodological approach
for defining, specifying, designing, and constructing
aspects like user interfaces, security, and memory
management that impact many parts of the system being
developed ...read up on MVC in the .Net Platform
• Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely
aligned with the Unified Modeling Language (UML)

55
 The Unified Process (UP)
• Inception phase
– business requirement for the software identified
- rough architecture of the system is proposed
- Incremental, iterative nature of project planned
- Preliminary use cases – describe which features
and functions each major class of users desires
- Identifies resources, assess major risks, defines
schedule, etc

56
 The Unified Process (UP)
• Elaboration phase
- Refines and expands the preliminary use
cases
- Expands the architectural representation
- Can create an “executable architectural
baseline” to demonstrate the viability of the
architecture but does not provide all features
and functions required to use the system
- Ensure that scope risks and delivery dates
remain reasonable

57
 The Unified Process (UP)
• Construction Phase
- Develops software components that will
make each use case operational for end
users
- Requirements and design models that were
started during elaboration phase are
completed to reflect final version of software
increment and implemented in source code
- Unit tests are designed and executed
- Integration activities are conducted

58
 The Unified Process (UP)
• Transition phase
- Software given to end users for beta
testing and user feedback reports
- Software team creates necessary support
information (e.g. user manuals,
troubleshooting guides, etc)
- At the end of this phase – software
increment becomes a usable software
release

59
 The Unified Process (UP)
• Production Phase
- Ongoing use of software monitored
- Support for the operating environment is
provided
- Defect reports and request for changes
are submitted and evaluated

60
The Unified Process (UP)
Elaborat ion
elaboration

Incept ion
inception

const ruct ion

Release
t ransit ion
soft ware increment

product ion

61
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

62
 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 Transit ion phase
Design model
Project plan, Analy sis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Int egrat ed soft ware Deliv ered soft ware increment
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

63