SOFTWARE PROCESS MODEL -02

A GENERIC PROCESS MODEL

2
PROCESS FLOW

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

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.

5
 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]
6
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?

7
 THE WATERFALL MODEL

Communication
project initiation Planning
requirement gathering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
f eedback

8
THE V-MODEL

9
THE INCREMENTAL MODEL

increment #n
Communic at ion
Planning

Modeling
analys is C o n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

delivery of
nth increment
increment # 2

Communic at ion
Planning

Modeling
analys is C o n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
delivery of
increment # 1 2nd increment

Communic at ion
Planning
Modeling
analys is C o n s t ru c t i o n
des ign c ode
t es t
De p l o y m e n t
d e l i v e ry delivery of
fe e dba c k

1st increment

project calendar time 10

EVOLUTIONARY MODELS: PROTOTYPING

Quick
Quick plan

Communication plan
communication

Modeling
Modeling
Quick design
Quick design

Deployment
Deployment Construction
Delivery
delivery & of prototype
Construction
& Feedback
feedback Construction
of
of prototype
prototype

11
EVOLUTIONARY MODELS: THE SPIRAL
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback test
12
EVOLUTIONARY MODELS: CONCURRENT
none

Modeling activity

represents the state

Under of a software engineering
activity or task
development

Awaiting
changes

Under review

Under
revision

Baselined

Done

13
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)

14
THE UNIFIED PROCESS (UP)
Elaboration
elaboration

Inception
inception

construction
Release
transition
software increment

production
15
UP PHASES
UP Phases
Inception Elaboration Construction Transition Production

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

16
 UP WORK PRODUCTS
Inception phase

Elaboration phase
Vision document
Initial use-case model
Initial project glossary
Construction phase
Use-case model
Initial business case Supplementary requirements
Initial risk assessment. including non-functional Design model
Transition phase
Project plan, Analysis model Software components
phases and iterations. Software architecture Delivered software increment
Integrated software
Business model, Description. increment Beta test reports
if necessary. Executable architectural General user feedback
Test plan and procedure
One or more prototypes prototype.
I nc ept i o Test cases
n Preliminary design model Support documentation
Revised risk list user manuals
Project plan including installation manuals
iteration plan description of current
adapted workflows increment
milestones
technical work products
Preliminary user manual

17
 For further Details: https://www.geeksforgeeks.org/rup-and-its-
phases/
ADVANTAGES:

 It provides good documentation, it completes the process in

itself.
 It provides risk-management support.
 It reuses the components, and hence total time duration is less.
 Good online support is available in the form of tutorials and
training.
DISADVANTAGES

 Team of expert professional is required, as the process is

complex.
 Complex and not properly organized process.
 More dependency on risk management.
 Hard to integrate again and again