Lecture Software process improvement: Lesson 5 - Dr. Ghulam Ahmad Farrukh

Process Models
Lecture # 5

1


Why Software Process?
• Software development can be exceedingly 
complex and there are often many 
alternative ways to perform the various 
tasks
• There is a need for a organized set of 
activities, which when performed 
accurately, will result in an orderly 
development effort
2


Software Process
• A defined process can help guide the 
software professionals through tasks, which 
can be performed in a number of ways, in 
an orderly way
• This results in the establishment of a 
process definition they can understand

3


Software Process
• This enable software professionals to better 

understand
– What they should do
– What they expect from their co­workers, and 
what they are expected to provide in return

• This allows them to focus on doing their 
jobs; contract between co­workers
4


Software Process
• Operational definitions are “something 
everyone can communicate about and work 
to” – Deming
• They provides organizations with a 
consistent working framework while 
permitting individual adjustments to unique 
needs
5


Software Engineering
• Software engineering is not a routine 
activity that can be structured and 
regimented like repetitive manufacturing or 
clerical procedure
• It is an intellectual process that must 
dynamically adjust to the creative needs of 
the professionals and their tasks; trade­off is 
needed 

6


Process Trade­off Factors ­ 1
• Since software projects have differences, 
their software engineering processes must 
have differences as well
• In the absence of a universal software 
engineering process, organizations and 
projects must define processes that meet 
their own unique needs
7


Process Trade­off Factors ­ 2
• The process used for a given project must 
consider the experience level of the 
members, current product status and the 
available tools and facilities

8


Process Standardization
• Elaborate on the need to have 
standardization and the need to have 
individual creativity
• Example: music, artistic painting, electrical 
circuits, etc.
• Let’s see what are the compelling reasons 

for process standardization
9


Process Standards ­ 1
• Process standardization helps to reduce the 
problems of training, review, and tool 
support
• With standard methods, each project’s 
experiences can contribute to overall 
process improvement

10


Process Standards ­ 2
• Process standards provide the basis for 
process and quality measurements
• Since process definitions take time and 
effort to produce, it is impractical to 
produce new ones for each project

11


Customization And Standardization
• The conflicting needs for customization and 
standardization can often be resolved by 
establishing a process architecture, which 
consists of a standard set of unit or “kernel” 

process steps with rules for describing and 
relating them
• Customization is achieved through appropriate 
interconnections of these standard elements 
into tailored process models
12


Software
• The term software refers to a program and 
all the associated information and materials 
needed to support its installation, operation, 
repair, and enhancement

13


Definitions ­ 1
• Software Engineering Process
– The total set of software engineering activities 
needed to transform a user’s requirements into 
software

14


Definitions ­ 2
• Software Process Architecture
– A framework within which project­specific 
software processes are defined

• Software Process Model
– One specific embodiment of a software process 
architecture

15


Software Processes
• Software processes can be categorized 
according to the level of details organized 
in these processes
• Some can be high­level (with little detail), 
while others can be low­level processes 
with lots of details; still others may fall in 
between
• Careful analysis results in …
16


Levels of Software Process 
Models
• Universal or U Process Models
• Atomic or A Process Models
• Worldly or W Process Models

17


Universal or U Process Models

• U process models provide high­level 
overview
• Traditional Waterfall, Spiral, and other later 
process models fall in this category
• Typically task­oriented

18


Universal or U Process Models
• The fundamental problem with simplistic U 
–level software process models is that they 
do not accurately represent what is really 
done
• The reason is that traditional process 
models are extremely sensitive to task 
sequence; consequently, simple adjustments 
can destroy the entire framework
19


Universal or U Process Models
• Take the example of the waterfall model, 
which has been used in the software 
industry for a long time
• Provides a very simplified view of 
activities, which can lead to inaccurate 
model development

20

A Version of Waterfall Model
System
requirements
engineering

Software
requirements
engineering

Software
design
Programming
and
unit testing

System
testing
System
operation

21


Spiral model of the software process
Determine objectives
alternatives and
constraints

Risk
analysis

Evaluate alternatives
identify, resolve risks

Risk
analysis
Risk
analysis

REVIEW
Requirements plan
Life-cycle plan

Development
plan

Plan next phase

Integration
and test plan

Prototype 3
Prototype 2

Operational
protoype

Risk

analy sis Prototype 1

Simulations, models, benchmarks
Concept of
Operation

S/W
requirements

Requirement
validation

Product
design

Detailed
design

Code
Unit test
Design
V&V
Integr ation
test
Acceptance
test
Develop, verify
Service
next-level product

Problems with Universal Model
• This results from an over­emphasis on 
modeling tasks
• It limits human flexibility and tends to 
arbitrarily impose rigidity
• It becomes progressively less helpful as the 
number of possible task sequences increases
• The model becomes very difficult if not 
impossible to understand
23


Problems with Universal Model
• When such process models are used to 
guide the process automation, project 
management, or contract administration, the 
resulting process rigidity can cause serious 
problems

24


• The question, therefore, is not “what is the 
right way to model the process?” but “what 
is the most appropriate way to model this 
process for this purpose?”

25