Process Models

Definition of Software Process

 A framework for the activities, actions, and tasks
that are required to build high-quality software.

 SP defines the approach that is taken as software is

engineered.

 Is not equal to software engineering, which also

encompasses technologies that populate the
process– technical methods and automated tools.
A Generic Process Model
 A Generic Process Model
 A 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.
 A Generic Process Model

Question is:
 How the framework activities and the actions and tasks
that occur within each activity are organized with respect
to sequence and time? See the process flow for answer.
Process Flow
 Process Flow
 Linear process flow executes each of the five
activities in sequence.
 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 leads to a more
complete version of the software.
 A parallel process flow executes one or more
activities in parallel with other activities ( modeling
for one aspect of the software in parallel with
construction of another aspect of the software.
 Process Flow
 Before you can proceed with the process model,
 A key question: what actions are appropriate for a
framework activity given the nature of the problem,
the characteristics of the people and the
stakeholders?
 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
 Identifying a Task Set
 For example, a small software project requested by
one person with simple requirements, the
communication activity might encompass little more
than a phone all with the stakeholder. Therefore, the
only necessary action is phone conversation, the work
tasks of this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.
 Example of a Task Set for
Elicitation
 The task sets for Requirements gathering action for a
simple project may include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions
required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
 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.
 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.
 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?
The Waterfall Model
 The Waterfall Model
It is the oldest paradigm for SE. When requirements are
well defined and reasonably stable, it leads to a linear
fashion.
introduced by Royce in 1970.

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 to software development.
The Waterfall Model (Modified)
 The Waterfall Model
Advantages

It is relatively simple to understand.

It is a sequential model. Each phase is followed by the next

in sequential order. In any phase, if you want to return back
some earlier phase then you would have to go through the
entire process again sequentially.

It needs very few resources

There is no scope of phase overlap here as you cannot

proceed to the next phase until you finish the earlier phase.
 The Waterfall Model
Disadvantages

It is not very flexible

It takes a lot more time

No backtracking is allowed

Revision is prohibited

It is difficult to estimate time and cost

The V-Model
 The V-Model
A variation of waterfall model depicts the relationship
of 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.
The Incremental Model
The Incremental Model (time line view)

increment # n
Co m m u n i c a t i o n
Pl a nn i ng

M odeling
analys is Co n s t ru c t i o n
design
code De p l o y m e n t
t est d e l i v e ry
fe e dba c k

delivery of
increment # 2 nt h increment

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

M odeling
analys is Co n s t r u c t i o n
design 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

Co m m u n i c a t i o n
Pl a nn i ng
M odeling
analy sis Co n s t ru c t i o n
des ign code
t est
De p l o y m e n t
d e l i v e ry delivery of
feedback
1st increment

project calendar time

 The Incremental Model
 When initial requirements are reasonably well defined,
but the overall scope of the development effort
precludes a purely linear process. A compelling 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.
Evolutionary Models: Prototyping

Q u i ck p l a n
Quick
Co m m u n icat io n plan
communication
Mo d e l i n g
Modeling
Q u ick d e sig n
Quick design

Deploym ent
Deployment Construction
D e live r y
delivery of Co
prototype
& Fe e d b & ack n st r u ct io n
feedback Construction
of
ofr oprototype
p t o t yp e
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
Construction increasingly more
of prototype
complete version of the software.
 Two types are introduced, namely Prototyping and Spiral models.
Evolutionary Models: Prototyping
When to use:
 Customer defines a set of general objectives but does not
identify detailed requirements for functions and features.
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)
Construction
occur. of prototype

 Quick design focuses on a representation of those aspects

the software that will be visible to end users. ( interface
and output).
 Evolutionary Models: Prototyping
 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. Construction
of prototype
Drawback
 However, engineers may make compromises in order to get
a prototype working quickly. The less-than-ideal choice may
be adopted forever after you get used to it.
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test
 Evolutionary Models: The Spiral
 It couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model
 Each phase in spiral model begins with a design goal and
ends with the client reviewing the progress.
 The spiral model was first mentioned by Barry Boehm in
his 1986 paper.
 A series of evolutionary releases are delivered.
 The exact number of loops of the spiral is unknown and can
vary from project to project.
 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.
 Evolutionary Models: The Spiral
 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 considerable risk assessment
expertise.
 Evolutionary Models: The Spiral
When to use Spiral Methodology?
 When project is large
 When releases are required to be frequent
 When creation of a prototype is applicable
 When risk and costs evaluation is important
 For medium to high-risk projects
 When requirements are unclear and complex
 When changes may require at any time
 When long term project commitment is not feasible due to
changes in economic priorities
Evolutionary Models: Concurrent
Concurrent models are those models within which the
various activities of software development happen at the
same time, for faster development and a better outcome.

The concurrent model is also referred to as a parallel

working model.
Evolutionary Models: Concurrent
Evolutionary Models: Concurrent
The communication activity has completed in the first
iteration and exits in the awaiting changes state.

The modeling activity completed its initial

communication and then go to the underdevelopment
state.

If the customer specifies the change in the requirement,

then the modeling activity moves from the under
development state into the awaiting change state.

The concurrent process model activities moving from

one state to another state
Evolutionary Models: Concurrent
Advantages of the concurrent development model
This model is applicable to all types of software
development processes.
It is easy for understanding and use.
It gives immediate feedback from testing.
It provides an accurate picture of the current state of a
project.

Disadvantages of the concurrent development model

It needs better communication between the team
members. This may not be achieved all the time.
It requires to remember the status of the different
activities.
 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.
 Aspect Oriented software development (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).
The Unified Process (UP)
Elab o r at ion
elaboration

Incep t io n
inception

co nst r uct io n
Release
t r ansit io n
soft ware increment

pr oduct io n
 UP Work Products
Inception phase

Elaboration phase
Vision document
Init ial use-case model
Init ial project glossary Construction phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Transition phase
Design model
Project plan, Analysis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Int egrat ed soft ware Delivered soft ware increment
Business model, Descript ion. increment Bet a t est report s
if necessary. Execut able archit ect ural General user feedback
Test plan and procedure
One or more prot ot ypes prot ot ype.
I nc e pt i o
Test cases
n Preliminary design model Support document at ion
Revised 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
 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.
 Personal Software Process (PSP)

 High-level design review. Formal verification

methods 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.
 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.
 Provide improvement guidance to high-maturity
organizatioAccelerate 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.