Process Models

Dr B Veera Jyothi
Assistant Professor
CBIT
 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
 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.
 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.
 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]
 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?
Co m m unic a t io n
pro je c t init ia t io n Planning
re quire m e nt g a t he rin g estimating Mo de ling
scheduling
analys is Co ns t ruc t io n
tracking
des ign De plo y m e nt
code
t es t de liv e ry
s u pp o rt
f e e dba c k
 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

 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
 planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test
 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
 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)
 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
 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
 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 s s case Su p p le me n t ary re q u ire me n t s
In it ial risk asse s sme n t . in clu d in g n o n -fu n ct io n al De sig n mo d e l
Transition phas e
Pro je ct p lan , An aly s is 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 oft ware in cre me n t
Bu sin e ss mo d e l, De scrip t io n . incre me n t Be t a t e s t re p o rt s
if n e ce ssary . Exe cu t ab le arch it e ct u ral Ge ne ral u se r fe e d b ack
Te st p lan an d p roce 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 inst allat io n man u als
it e rat io n p lan d e s crip t io n o f cu rre n t
ad ap t e d wo rkflo ws in cre me n t
mile s t 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
 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.
 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.