PROCESS MODELS

 When you work to build a product or system, it’s important

to go through a series of predictable steps—a road map that
helps you create a timely, high-quality result. The road map
that you follow is called a “software process.”
 Software engineers and their managers adapt the process to
their needs and then follow it.
 Additionally, the people who have requested the software
have a role to play in the process of defining, building, and
testing it.
 There are a number of software process assessment
mechanisms that enable organizations to determine the
“maturity” of their software process, such as, the quality,
timeliness, and long-term viability of the product.
 A software process is defined as a framework for the
activities, actions, and tasks that are required to build high-
quality software.

1
A Generic Process
Model

2
A Generic Process
Model
 generic process framework for software engineering
defines five framework activities—communication,
planning, modeling, construction, and deployment.

 In addition, a set of umbrella activities—project

tracking and control, risk management, quality
assurance, configuration management, technical
reviews, and others—are applied throughout the
process.

 one important aspect of the software process is

process flow.
 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.

3
Process Flow

4
Process Flow
 A linear process flow executes each of the five
framework activities in sequence, beginning with
communication and culminating with deployment.
 An iterative process flow repeats one or more of
the activities before proceeding to the next.
 An evolutionary process flow executes the
activities in a “circular” manner. Each circuit
through the five activities leads to a more complete
version of the software.
 A parallel process flow executes one or more
activities in parallel with other activities (e.g.,
modeling for one aspect of the software might be
executed in parallel with construction of another
aspect of the software).

5
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

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

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

8
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]

9
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?

10
 The Waterfall
Model
Co m m u nic a t io n
p ro je c t in it ia t io n Planning
re qu ire m e n t g a t he rin g estimating Mo d e lin g
scheduling
a na lys is Co n s t ru c t io n
tracking
de s ign De plo y m e nt
c ode
t es t d e liv e ry
s u pp o rt
f e e d ba c k

11
The Waterfall Model
 The waterfall model, sometimes called the
classic life cycle.

 This model suggests a systematic, sequential

approach to software development that
begins with customer specification of
requirements and progresses through
planning, modeling, construction, and
deployment, culminating in ongoing support
of the completed software.

 A variation in the representation of the

waterfall model is called the V-model.
12
The V-Model

13
The V-Model
 the V-model depicts the relationship of quality assurance
actions to the actions associated with communication,
modeling, and early construction activities.

 As a software team moves down the left side of the V, basic

problem requirements are refined into progressively more
detailed and technical representations of the problem and its
solution.

 Once code has been generated, the team moves up the right
side of the V, essentially performing a series of tests (quality
assurance actions) that validate each of the models created
as the team moved down the left side.

 The V-model provides a way of visualizing how verification

and validation actions are applied to earlier engineering work.

14
Why Waterfall Model
sometimes fail?
 Real projects rarely follow the
sequential flow that the model
proposes.

 It is often difficult for the customer to

state all requirements explicitly.

 The customer must have patience.

15
The Incremental
Model
incre m e nt # n
Co m m u n i c a t i o n
Pla n ning

Mo de ling
a n a ly s is Co n s t ru c t i o n
d e s ig n
c ode 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 # 2 n t h in cre me n t

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

Mo d e ling
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode 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 i o n
Pla nnin g
Mo de ling
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode
d e liv e ry o f
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

1 st in cre me n t

project calendar t ime

16
The Incremental Model
 The incremental model combines elements of linear
and parallel process flows.
 the incremental model applies linear sequences in a
staggered fashion as calendar time progresses.
 Each linear sequence produces deliverable
“increments” of the software [McD93] in a manner that
is similar to the increments produced by an
evolutionary process flow.
 When an incremental model is used, the first increment
is often a core product. That is, basic requirements are
addressed but many supplementary features (some
known, others unknown) remain undelivered.
 The incremental process model focuses on the
delivery of an operational product with each
increment.

17
Evolutionary Process
Models

 Evolutionary process models produce an

increasingly more complete version of the
software with each iteration.
 We need a process model that has been
explicitly designed to accommodate a product
that evolves over time.
 Evolutionary models are iterative.
 They are characterized in a manner that
enables you to develop increasingly more
complete versions of the software.

18
Evolutionary Models:
Prototyping
Quick
Qu i c k p la n

Co m m u n ic a t io n plan
communication

Modeling
Mo d e lin g
Qu ic k d e s i g n
Quick design

De p loym e n t
Deployment Construction
De liv e ry
delivery
& Fe e d b a&
ck
of prototype
Co n s t ru c t io n
feedback Construction
of
ofp ro
prototype
t o t yp e

19
Evolutionary Models:
Prototyping
 When your customer has a legitimate need, but is
clueless about the details, develop a prototype as a
first step.

 Regardless of the manner in which it is applied, the

prototyping paradigm assists you and other
stakeholders to better understand what is to be
built when requirements are fuzzy.

 The prototyping paradigm begins with

communication.

 A prototyping iteration is planned quickly, and

modeling (in the form of a “quick design”) occurs.

20
Evolutionary Models:
Prototyping
 Quick design focuses on a representation of those
aspects of the software that will be visible to end
users (e.g., human interface layout or output
display formats).

 The quick design leads to the construction of a

prototype.

 The prototype is deployed and evaluated by

stakeholders, who provide feedback that is used
to further refine requirements.

21
Evolutionary Models: The
Spiral planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test

22
Evolutionary Models: The
Spiral
 Boehm describes the spiral model in the
following manner:
 The spiral development model is a risk-driven process
model generator that is used to guide multi-stakeholder
concurrent engineering of software intensive systems.
 It has two main distinguishing features. One is a 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.

 Using the spiral model, software is developed

in a series of evolutionary releases.

23
Evolutionary Models: The
Spiral

 During early iterations, the release might be a

model or prototype. During later iterations,
increasingly more complete versions of the
engineered system are produced.
 A spiral model is divided into a set of framework
activities defined by the software engineering
team.
 Each of the framework activities represent one
segment of the spiral path.
 As this evolutionary process begins, the software
team performs activities that are implied by a
circuit around the spiral in a clockwise direction,
beginning at the center.
 Risk is considered as each revolution is made.
24
Evolutionary Models: The
Spiral
 Anchor point milestones—a combination of work
products and conditions that are attained along the
path of the spiral—are noted for each evolutionary
pass.
 The first circuit around the spiral might result in the
development of a 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 through the planning region results in
adjustments to the project plan.
 Cost and schedule are adjusted based on feedback
derived from the customer after delivery.
 In addition, the project manager adjusts the planned
number of iterations required to complete the software.

25
Evolutionary Models:
Concurrent
none

Mode ling a c t ivit y

rep res ents the s tate

Unde r o f a s o ftware eng ineering
activity o r task
de ve lopm e nt

Awa it ing
c ha nge s

Unde r re vie w

Unde r
re vis ion

Ba s e line d

Done

26
Evolutionary Models:
Concurrent
 The concurrent development model, sometimes
called concurrent engineering, allows a software
team to represent iterative and concurrent
elements of any of the process models.
 The concurrent model is often more appropriate
for product engineering projects where different
engineering teams are involved.
 The activity—modeling—may be in any one of the
states12 noted at any given time.
 Similarly, other activities, actions, or tasks (e.g.,
communication or construction) can be
represented in an analogous manner.
 All software engineering activities exist
concurrently but reside in different states.

27
Specialized 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
28
The Unified Process
 Unified Process—a “use-case driven,
architecture-centric, iterative and
incremental” software process closely
aligned with the Unified Modeling Language
(UML)
 the Unified Process is an attempt to draw on
the best features and characteristics of
traditional software process models, but
characterize them in a way that implements
many of the best principles of agile software
development.
 The Unified Process recognizes the
importance of customer communication and
streamlined methods for describing the
customer’s view of a system (the use case) 29
The Unified Process
 It emphasizes the important role of
software architecture and “helps the
architect focus on the right goals, such
as understandability, reliance to future
changes, and reuse”.

 It suggests a process flow that is

iterative and incremental, providing the
evolutionary feel that is essential in
modern software development.

30
The Unified Process (UP)
elaboration
Ela b o ra t io n

Inc e p t io n
inception

c o ns t ruc t io n
Re le a s e
t ra ns it io n
s oft wa re inc re m e nt

p ro d uc t io n

31
The Unified Process (UP)
Phases
 The inception phase of the UP encompasses both
customer communication and planning activities.
 The elaboration phase encompasses the
communication and modeling activities of the
generic process model.
 The construction phase of the UP is identical to
the construction activity defined for the generic
software process.
 The transition phase of the UP encompasses the
latter stages of the generic construction activity
and the first part of the generic deployment
(delivery and feedback) activity.
 The production phase of the UP coincides with the
deployment activity of the generic process.

32
UP
Phases
UP Phases
Ince pt ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

33
 UP Work Products
Ince pt ion phase

Elaborat ion phase

Visio 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
Use -case mo d e l
In it ial b u sin e ss case Su p p le me n t ary re q u ire me n t s
In it ial risk asse 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 De liv e re d so ft ware in cre me n t
In t e g rat e d so ft ware
Bu sin e ss mo d e l, De scrip t io n . in cre me n t Be t a t e st re p o rt s
if n e ce ssary . Exe cu t ab le arch it e ct u ral Ge n e ral u se r fe e d b ack
Te st 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 st 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

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

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

36