Lecture 3&4

Process Models

Muhammad Noman

1
Process Models
 Process
In Chapter 1, a process was defined as a collection of work
activities, actions, and tasks that are performed when some
work product is to be created. Each of these activities, actions,
and tasks reside within a framework or model that defines their
relationship with the process and with one another.

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.

2
A Generic Process Model
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.
A linear process flow executes each of the five framework activities in
sequence, beginning with communication and culminating with
deployment (Figure 2.2a).
An iterative process flow repeats one or more of the activities before
proceeding to the next (Figure 2.2b).
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 (Figure 2.2c).
A parallel process flow (Figure 2.2d) 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).

3
A Generic Process Model

4
Process Flow

5
Defining a Framework Activity
A software team would need significantly more information before it could
properly execute any one of these activities as part of the software
process. Therefore, you are faced with a key question.
What actions are appropriate for a framework activity, given the nature of
the problem to be solved?
The characteristics of the people doing the work, and the stakeholders
who are sponsoring the project?
For a small software project with simple, straightforward requirements, the
communication activity might encompass little more than a phone call with
the appropriate stakeholder. Therefore, the only necessary action is
phone conversation and work tasks (the task set) that this action
encompasses 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.
If the project was considerably more complex. The communication activity
might have six distinct actions inception, elicitation, elaboration, 6
negotiation, specification, and validation (Ch 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

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

8
Process Pattern
 Pattern Name. The pattern is given a meaningful name
describing it within the context of the software process (e.g.,
TechnicalReviews).
 Forces. The environment in which the pattern is
encountered and the issues that make the problem visible
and may affect its solution.
 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.
9
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 effect 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]

10
Prescriptive Models
 Prescriptive process models advocate an orderly
approach to software engineering.
 All software process models can accommodate the
generic framework activities described in Chapter 1, but
each applies a different emphasis to these activities and
defines a process flow that invokes each framework
activity (as well as software engineering actions and
tasks) in a different manner .

11
The Waterfall Model
• The waterfall model is also called as 'Linear sequential
model' or 'Classic life cycle model'.
• In this model, each phase is fully completed before the
beginning of the next phase.
• This model is used for the small projects.
• In this model, feedback is taken after each phase to ensure
that the project is on the right path.
• Testing part starts only after the development is complete.
Communicat ion
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Const ruct ion
tracking
design Deployment
code
t est delivery
support
f eedback

12
The V-Model
A variation in the representation of the waterfall model is called the V-
model. The V-model represents 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.

In reality, there is no fundamental difference between the classic life

cycle and the V-model. The V-model provides a way of visualizing how
verification and validation actions are applied to earlier engineering
work.
13
The V-Model

14
Waterfall Model
Advantages of waterfall model

• The waterfall model is simple and easy to understand,

implement, and use.
• All the requirements are known at the beginning of the
project, hence it is easy to manage.
• It avoids overlapping of phases because each phase is
completed at once.
• This model works for small projects because the
requirements are understood very well.
• This model is preferred for those projects where the quality is
more important as compared to the cost of the project.

15
Waterfall Model
Disadvantages of the waterfall model

• This model is not good for complex and object oriented

projects.
• It is a poor model for long projects.
• The problems with this model are uncovered, until the
software testing.
• The amount of risk is high.

16
The Incremental Model
• The incremental model combines the elements of
waterfall model and they are applied in an iterative
fashion.
• The first increment in this model is generally a core
product.
• Each increment builds the product and submits it to the
customer for any suggested modifications.
• The next increment implements on the customer's
suggestions and add additional requirements in the
previous increment.
• This process is repeated until the product is finished.
For example, the word-processing software is developed
using the incremental model.
17
The Incremental Model

18
The Incremental Model
Advantages of incremental model

• This model is flexible because the cost of development is low

and initial product delivery is faster.
• It is easier to test and debug during the smaller iteration.
• The working software generates quickly and early during the
software life cycle.
• The customers can respond to its functionalities after every
increment

19
The Incremental Model
Disadvantages of the incremental model

• The cost of the final product may cross the cost estimated
initially.
• This model requires a very clear and complete planning.
• The planning of design is required before the whole system is
broken into small increments.
• The demands of customer for the additional functionalities
after every increment causes problem during the system
architecture.

20
Evolutionary Models
Evolutionary models
Evolutionary models are iterative type models.
They allow to develop more complete versions of the software.

Following are the evolutionary process models.

1. The prototyping model

2. The spiral model Construction
3. Concurrent development model of prototype

21
Evolutionary Models: Prototyping
• Prototype is defined as first or preliminary form using which
other forms are copied or derived.
• Prototype model is a set of general objectives for software.
• It does not identify the requirements like detailed input,
output.
• It is software working model of limited functionality.
• In this model, working programs are quickly produced.

Construction
of prototype

22
Evolutionary Models: Prototyping

Q u i ck p l an
Quick
Com m unicat ion plan
communication
Mo d e l i n g
Modeling
Q u i ck d e si g n
Quick design

Deployment
Deployment Construction
De live r y
delivery
& Fe e dback& of Const
prototype
r uct ion
feedback Construction
of
of ot
pr prototype
ot ype

23
 Evolutionary Models: Prototyping
Phases of Prototyping Model
1. Communication
In this phase, developer and customer meet and discuss the overall
objectives of the software.
2. Quick design
• Quick design is implemented when requirements are known.
It includes only the important aspects like input and output format of the
software.
• It focuses on those aspects which are visible to the user rather than the
Construction
of prototype
detailed plan.
• It helps to construct a prototype.
3. Modeling quick design
• This phase gives the clear idea about the development of software
because the software is now built.
• It allows the developer to better understand the exact requirements.
24
.
 Evolutionary Models: Prototyping
4. Construction of prototype
The prototype is evaluated by the customer itself.

5. Deployment, delivery, feedback

• If the user is not satisfied with current prototype then it refines
according to the requirements of the user.
• The process of refining the prototype is repeated until all
the requirements of users are met.
• When the users are satisfied with the developed
Construction
prototype then
the system is developed on the basis of final prototype.
of prototype

25
 Evolutionary Models: Prototyping
Advantages of Prototyping Model

• Prototype model need not know the detailed input, output,

processes, adaptability of operating system and full machine
interaction.
• In the development process of this model users are actively
involved.
• The development process is the best platform to understand the
system by the user. Construction
• Errors are detected much earlier. of prototype

• Gives quick user feedback for better solutions.

• It identifies the missing functionality easily. It also identifies the
confusing or difficult functions.

26
 Evolutionary Models: Prototyping
Disadvantages of Prototyping Model

• The client involvement is more and it is not always considered by

the developer.
• It is a slow process because it takes more time for development.
• Many changes can disturb the rhythm of the development team.
• It is a thrown away prototype when the users are confused with it.

Construction
of prototype

27
Evolutionary Models: The Spiral
• Spiral model is a risk driven process model.
• It is used for generating the software projects.
• In spiral model, an alternate solution is provided if
the risk is found in the risk analysis, then alternate
solutions are suggested and implemented.
• It is a combination of prototype and sequential model
or waterfall model.
• In one iteration all activities are done, for large
project's the output is small.

28
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test

29
Evolutionary Models: The Spiral
Advantages of Spiral Model

• It reduces high amount of risk.

• It is good for large and critical projects.
• It gives strong approval and documentation control.
• In spiral model, the software is produced early in the
life cycle process.

Disadvantages of Spiral Model

• It can be costly to develop a software model.

• It is not used for small projects.
30
Evolutionary Models: Concurrent
• The concurrent development model is called as concurrent
model.
• 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.

31
Evolutionary Models: Concurrent
none

Modeling act ivit y

represents the state

Under of a software engineering
activity or task
development

Await ing
changes

Under review

Under
revision

Baselined

Done

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

33
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)
34
The Unified Process (UP)
Elaborat ion
elaboration

Incept ion
inception

const ruct ion

Release
t ransit ion
soft ware increment

product ion

35
UP Phases
UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

36
 UP Work Products
Incept ion phase

Elaborat ion phase

Vision document
Init ial use-case model
Init ial project glossary Const ruct ion phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Transit ion phase
Design model
Project plan, Analy sis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Int egrat ed soft ware Deliv ered soft ware increment
Business model, Descript ion. increment Bet a t est report s
if necessary . Execut able archit ect ural Test plan and procedure General user feedback
One or more prot ot y pes prot ot y pe.
I nc e pt i o Test cases
n Preliminary design model Support document at ion
Rev ised 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

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

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

39