Process Models

CHAPTER 2
Quick Look
What is it?
◦ Prescriptive process models define a distinct set of activities, actions,
tasks, milestones, and work products that are required to engineer
high quality software
◦ These Process models are not perfect, but they do provide a useful
roadmap
Who does it?
◦ Software engineers adapt them to their needs and then follow it
Why is it important?
◦ It provides stability, control and organization to an activity
What are the steps?
◦ The process guides a software team through a set of framework
activities that are organized into a process flow that may be linear,
incremental, or evolutionary.
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

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING:

A PRACTITIONER’S APPROACH, 7/E (MCGRAW-HILL, 2009). SLIDES 3
COPYRIGHT 2009 BY ROGER PRESSMAN.
Process Flow

THESE SLIDES ARE DESIGNED TO ACCOMPANY

SOFTWARE ENGINEERING: A PRACTITIONER’S
4
APPROACH, 7/E (MCGRAW-HILL, 2009). SLIDES
Software Process Models
A model
◦ is a structured collection of elements that describe
characteristics of effective processes.
Software Process Model
◦ Is the strategy to adopt software engineering as a
layered technology
◦ A simplified representation of a set of activities
whose goal is the development or evolution of
software, presented from specific perspective
Prescriptive Models
Prescriptive software process models called
“prescriptive” because
◦ Prescribe a set of process elements- framework
activities, software engineering actions, tasks, work
products, quality assurance and change control
mechanisms for each project.

◦ Prescribes a workflow - The manner in which the

process elements are interrelated to each other
(linear, incremental or evolutionary)
Software engineers have traditionally chosen a
generic process framework consisting of the
following framework activities which can be
applied on any process model

I. Communication
II. Planning
III. Modeling
IV. Construction
V. Deployment

The terminology and details of each process model differ,

but the generic framework activities
remain reasonably consistent.
The Process Model: Adaptability
The framework activities will always be applied on
every project ... BUT
The tasks (and degree of rigor) for each activity will
vary based on:
◦ the type of project (an “entry point” to the model)
◦ characteristics of the project
◦ common sense judgment; concurrence of the project
team
◦ The environment in which the work will be conducted
WATERFALL MODEL
The Waterfall Model
Alternate names
◦ Linear Sequential Model
◦ Classic Life cycle
Introduction
◦ A systematic, sequential approach to software
development that begins at the system level and
progresses through analysis, design, coding, testing,
and support.
OR
◦ A systematic, sequential approach to software
development that begins with customer specification
of requirements and progresses through planning,
modeling, construction, and deployment, culminating
in on-going support of the completed software.
 The Waterfall
Model
Co m m u n ic a t io n
p ro je c t in it ia t io n Planning
re q u ire m e n t g a t h e rin g estimating Mo d e lin g
scheduling
a na lys is Co n s t ru c t io n
tracking
de s ign De p lo y m e n t
c ode
t es t d e liv e ry
s u p p o rt
f e e dba c k

12
Waterfall Model Phases
There are separate identified phases in the waterfall model:
◦ Requirements analysis and definition
◦ System and software design
◦ Implementation and unit testing
◦ Integration and system testing
◦ Operation and maintenance

The main drawback of the waterfall model is the difficulty of

accommodating change after the process is underway. In
principle, a phase has to be complete before moving onto the next
phase.

CHAPTER 2 SOFTWARE PROCESSES 13

Used When
◦ The requirements of a problem are reasonably well
understood
◦ When work flows from communication through
deployment in a reasonably linear fashion.
Waterfall model problems
Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements.
◦ Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process.
◦ Few business systems have stable requirements.

The waterfall model is mostly used for large systems engineering

projects where a system is developed at several sites.
◦ In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.

CHAPTER 2 SOFTWARE PROCESSES 15

Disadvantages
Real projects rarely follow the sequential flow that the model
proposes.
It is often difficult for the customer to state all requirements
explicitly.
A working version of the program will not be available until late in
the project time span.
Linear nature leads to “blocking states”.
The V-Model

17
INCREMENTAL MODEL
The Incremental Model
This is a combination of the linear sequential model and
the iterative model.
The problem is broken into increments, and each
increment is tackled as a linear sequence.
Further increments can either be done after the previous
ones, or can overlap with the previous ones.
Incremental delivery focuses on the delivery of an
operational product with each increment.
Early increments are stripped-down versions of the final
product, but they do provide capability that serves the
user and also provides a platform for evaluation by the
user.
Incremental Model
Incremental development

CHAPTER 2 SOFTWARE PROCESSES 21

Incremental
Development
Advantages
This approach has the advantages that : -

◦ Less staffing available for a complete implementation by

the business deadline that has been established for the
project (Early increments can be implemented with fewer
people)
◦ Early delivery is guaranteed
◦ Progress of the whole project is not delayed if one of the
resources is not available for part of it
◦ Increments can be planned to manage technical risks
Incremental
Development
Advantages
The cost of accommodating changing customer requirements is
reduced.
◦ The amount of analysis and documentation that has to be redone is
much less than is required with the waterfall model.

It is easier to get customer feedback on the development work

that has been done.
◦ Customers can comment on demonstrations of the software and see
how much has been implemented.

More rapid delivery and deployment of useful software to the

customer is possible.
◦ Customers are able to use and gain value from the software earlier
than is possible with a waterfall process.

CHAPTER 2 SOFTWARE PROCESSES 23

Incremental development
problems
The process is not visible.
◦ Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to
produce documents that reflect every version of the system.
System structure tends to degrade as new increments are added.
◦ Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.

CHAPTER 2 SOFTWARE PROCESSES 24

Prototype Model
Software prototyping
A prototype is an initial version of a system used to demonstrate
concepts and try out design options.
A prototype can be used in:
◦ The requirements engineering process to help with requirements
elicitation and validation;
◦ In design processes to explore options and develop a UI design;
◦ In the testing process to run back-to-back tests.

CHAPTER 2 SOFTWARE PROCESSES 26

Software prototyping
A prototype is a smaller-scale, representative or
working model of the user requirements or a proposed
design for an information system.
The user evaluates it and improvements are made.
This continues in an iterative fashion until a satisfactory
product is achieved
 Evolutionary Models:
Prototyping
Quick
Qu i c k p la n

Co m m u n ic a t io n plan
communication

Modeling
Mo d e lin g
Qu ic k d e s i g n
Quick design

De p loym e n t
Deployment Construction
De liv e ry
delivery
& Fe e d b a&
ck
of prototype
Co n s t ru c t io n
feedback Construction
of
ofp ro
prototype
t o t yp e

THESE SLIDES ARE DESIGNED TO ACCOMPANY

SOFTWARE ENGINEERING: A PRACTITIONER’S
28
APPROACH, 7/E (MCGRAW-HILL, 2009). SLIDES
The process of prototype
development

CHAPTER 2 SOFTWARE PROCESSES 29

Prototyping can be treated as a standalone
process model
More commonly treated as a TECHNIQUE that
can be implemented within the context of any
one of the process models

Assists to better understand what is to be

built when requirements are fuzzy
Benefits of prototyping
Improved system usability.
A closer match to users’ real needs.
Improved design quality.
Improved maintainability.
Reduced development effort.

CHAPTER 2 SOFTWARE PROCESSES 31

Throw away prototyping
◦ Prototype merely used for the identification of
requirements
Evolutionary prototyping
◦ Final product will be based upon it