Chapter 2

 Process Models

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

It is the oldest paradigm for SE. When requirements are well

defined and reasonably stable, it leads to a linear fashion.
(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements explicitly.
Blocking state. 3. code will not be released until very late.)

The classic life cycle suggests a systematic, sequential approach

3
to software development.
 A variation of waterfall model
depicts the relationship of
The V-Model quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.

Team first moves down the left

side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.

4
The Incremental Model

5
 The Incremental Model
 When initial requirements are reasonably well
defined, but the overall scope of the development
effort prevents a purely linear process. A need to
expand a limited set of new functions to a later
system release.
 It combines elements of linear and parallel process
flows. Each linear sequence produces deliverable
increments of the software.
 The first increment is often a core product with many
supplementary features. Users use it and evaluate it
with more modifications to better meet the needs.
6
 Evolutionary Models
 Software system evolves over time as requirements often
change as development proceeds. Thus, a straight line to
a complete end product is not possible. However, a limited
version must be delivered to meet competitive pressure.
 Usually a set of core product or system requirements is
well understood, but the details and extension have yet to
be defined.
 You need a process model that has been explicitly
designed to accommodate a product that evolved over
time.
 It is iterative that enables you to develop increasingly more
7
complete version of the software.
 Two types are introduced, namely Prototyping and Spiral
 Evolutionary Models: Prototyping
 When to use: Customer defines a set of general objectives but does not identify
detailed requirements for functions and features. Or Developer may be unsure
of the efficiency of an algorithm, the form that human computer interaction
should take.
 What step: Begins with communication by meeting with stakeholders to define
the objective, identify whatever requirements are known, outline areas where
further definition is mandatory. A quick plan for prototyping and modeling (quick
design) occur. Quick design focuses on a representation of those aspects the
software that will be visible to end users. ( interface and output). Design leads to
the construction of a prototype which will be deployed and evaluated.
Stakeholder’s comments will be used to refine requirements.
 Both stakeholders and software engineers like the prototyping paradigm. Users
get a feel for the actual system, and developers get to build something
immediately. However, engineers may make compromises in order to get a
prototype working quickly. The less-than-ideal choice may be adopted forever
8

after you get used to it.

Evolutionary Models: Prototyping

Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

9
 Evolutionary Models: The Spiral
 It couples the iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model and is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems.
 Two main distinguishing features: one is cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing its degree of risk. The other is a set of
anchor point milestones for ensuring stakeholder commitment to feasible and mutually
satisfactory system solutions.
 A series of evolutionary releases are delivered. During the early iterations, the release might be
a model or prototype. During later iterations, increasingly more complete version of the
engineered system are produced.
 The first circuit in the clockwise direction might result in the product specification; subsequent
passes around the spiral might be used to develop a prototype and then progressively more
sophisticated versions of the software. Each pass results in adjustments to the project plan. Cost
and schedule are adjusted based on feedback. Also, the number of iterations will be adjusted by
project manager.
 Good to develop large-scale system as software evolves as the process progresses and risk
should be understood and properly reacted to. Prototyping is used to reduce risk.
 However, it may be difficult to convince customers that it is controllable as it demands 10
considerable risk assessment expertise.
Evolutionary Models: The Spiral

11
 Three Concerns on
Evolutionary Processes
 First concern is that prototyping poses a problem to project planning
because of the uncertain number of cycles required to construct the
product.
 Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that
the process will fall into chaos. On the other hand if the speed is too
slow then productivity could be affected.
 Third, software processes should be focused on flexibility and
extensibility rather than on high quality. We should prioritize the speed
of the development over zero defects. Extending the development in
order to reach high quality could result in a late delivery of the product
when the opportunity role has disappeared.
12
 Concurrent Model
 Allow a software team to represent iterative and concurrent elements of any of
the process models. For example, the modeling activity defined for the spiral
model is accomplished by invoking one or more of the following actions:
prototyping, analysis and design.
 The Figure shows modeling may be in any one of the states at any given time.
For example, communication activity has completed its first iteration and in the
awaiting changes state. The modeling activity was in inactive state, now makes
a transition into the under development state. If customer indicates changes in
requirements, the modeling activity moves from the under development state
into the awaiting changes state.
 Concurrent modeling is applicable to all types of software development and
provides an accurate picture of the current state of a project. Rather than
confining software engineering activities, actions and tasks to a sequence of
events, it defines a process network. Each activity, action or task on the network
13
exists simultaneously with other activities, actions or tasks. Events generated at
one point trigger transitions among the states.
Concurrent Model

14