Software Process Model

What is a Process … ?
• When we provide a service or create a product we always
follow a sequence of steps to accomplish a set of tasks
– You do not usually
• put up the drywall before the wiring for a house is installed or
• bake a cake before all the ingredients are mixed together
• We can think of a series of activities as a process
• Any process has the following characteristics
– It prescribes all of the major activities
– It uses resources and produces intermediate and final
products
– It may include sub-processes and has entry and exit criteria
– The activities are organized in a sequence
– Constrains or control may apply to activities
(budget control, availability of resources )
 Software Processes
When the process involves the building of some product
we refer to the process as a life cycle
Software development process – software life cycle

Coherent sets of activities for

– Specifying,
– Designing,
– Implementing and
– Testing software systems
A Generic Process Model

4
Process Flow

5
 The software process
• A structured set of activities required to develop a
software system
– Specification;
– Design;
– Validation;
– Evolution.
• A software process model is an abstract representation
of a process. It presents a description of a process from
some particular perspective.

6
 Generic software process models
• The waterfall model
– Separate and distinct phases of specification and
development.
• Evolutionary development
– Specification, development and validation are interleaved.
• Component-based software engineering
– The system is assembled from existing components.
• There are many variants of these models e.g. formal
development where a waterfall-like process is used but
the specification is a formal specification that is refined
through several stages to an implementable design.

7
 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?
8
 The Waterfall
Communication
Model
project initiation Planning
requirement gathering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
f eedback

9
 Waterfall model
Require ments
definition

System and
software design

Implementa tion
and unit testing

Integration and
system testing

Operation and
maintenance

10
 Waterfall model phases
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance

The drawback of the waterfall model is the

difficulty of accommodating change after the
process is underway
 Waterfall model problems
• Inflexible partitioning of the project into distinct stages
• This makes it difficult to respond to changing customer
requirements
• Therefore, this model is only appropriate when the
requirements are well-understood

Waterfall model describes a

process of stepwise refinement
 Based on hardware engineering models
 Widely used in military and aerospace
industries
 Why Not a Waterfall
But software is different :
 No fabrication step
 Program code is another design level
 Hence, no “commit” step – software can always be changed…!
 No body of experience for design analysis (yet)
 Most analysis (testing) is done on program code
 Hence, problems not detected until late in the process
 Waterfall model takes a static view of requirements
 Ignore changing needs
 Lack of user involvement once specification is written
Unrealistic separation of specification from the design
Doesn’t accommodate prototyping, reuse, etc
 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.

14
 Waterfall Advantages
• Natural approach for problem solving

• Conceptually simple, cleanly divides the

problem into distinct independent phases

• Easy to administer in a contractual setup –

each phase is a milestone

Software Process 15
 Waterfall disadvantages
• Assumes that requirements can be specified and
frozen early

• May fix hardware and other technologies too early

• Follows the “big bang” approach – all or nothing

delivery; too risky

• Very document oriented, requiring docs at the end

of each phase
Software Process 16
 Waterfall Usage
• Well suited for projects where requirements
can be understood easily and technology
decisions are easy
• Has been used widely

• For standard/familiar type of projects it still

may be the most optimum

• Well suited to the out sourcing model

Software Process 17
 Evolutionary development
• Exploratory development
- Objective is to work with customers and to evolve a final system
from an initial outline specification.
- Should start with well-understood requirements.
- The system evolves by adding new features as they are
proposed by customer.
• Throw-away prototyping
– Objective is to understand the system requirements. Should
start with poorly understood requirements
• Develop “quick and dirty” system quickly;
• Expose to user comment;
• Refine;
Until adequate system developed.
– Particularly suitable where:
- detailed requirements not possible;
 Evolutionary development
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
 Evolutionary development
• Problems
– Lack of process visibility
– Systems are often poorly structured
– Special skills (e.g. in languages for
rapid prototyping) may be required
• Applicability
– For small or medium-size interactive systems
– For parts of large systems (e.g. the user interface)
– For short-lifetime systems
 Evolutionary Models
Prototyping
• Addresses the requirement specification limitation
of waterfall

• Instead of freezing requirements only by

discussions, a prototype is built to understand the
requirements

• Helps alleviate the requirements risk

• A small waterfall model replaces the requirements

stage
Software Process 21
 Evolutionary Models
Prototyping
Quick
Quick plan
plan
Communication
communication

Modeling
Modeling
Quick
Quick design
design

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

22
Prototyping

Software Process 23
 Development of prototype
• Starts with initial requirements
• Only key features which need better
understanding are included in prototype
• No point in including those features that are
well understood
• Feedback from users taken to improve the
understanding of the requirements

Software Process 24
 Prototyping
• Cost can be kept low
– Build only features needing clarification

– “quick and dirty” – quality not important, scripting etc

can be used

– Things like exception handling, recovery, standards are

omitted

– Cost can be a few % of the total

– Learning in prototype building will help in building,

besides improved requirements
Software Process 25
 Prototyping
• Advantages
– Requirement will be more stable and more likely to
satisfy user needs
– Early opportunity to explore scale/performance issues
– Ability to modify or cancel the project early
– Enhanced user engagement

• Disadvantages:
– Potential hit on cost and schedule
– Potential false sense of security if prototype does not
focus on key (high risk) issues
Software Process 26
 Prototyping
• Applicability:
– When req are hard to elicit
– When confidence in reqs is low
– Where reqs are not well understood
– When design is driven by user needs

• Variants
– Paper Prototypes
– UI Prototypes
– Technology Proving
– Rapid Prototyping environments
Software Process 27
 Iterative Development
• Counters the “all or nothing” drawback of the
waterfall model
• Combines benefit of prototyping and waterfall
• Develop and deliver software in increments
• Each increment is complete in itself
• Can be viewed as a sequence of mini-waterfalls
• Feedback from one iteration is used in the future
iterations

Software Process 28
Iterative Enhancement

Software Process 29
 Iterative Development
• Most Software Products follow it

• Used commonly in customized development

also
– Businesses want quick response for sw
– Cannot afford the risk of all-or-nothing

• Newer approaches like XP, Agile,… all rely on

iterative development
Software Process 30
 Iterative Development
• Benefits
– Get-as-you-pay
– feedback for improvement

• Drawbacks
– Architecture/design may not be optimal
– Amount of refactoring may increase
– Total cost may increase

Software Process 31
 Iterative Development
• Applicability
– where response time is important,
– risk of long projects cannot be taken,
– all req not known

• Execution
– Each iteration is a mini waterfall – decide the
specs, then plan the iteration
– Length of iteration driven by amount of new
functionality to be added in an iteration
Software Process 32
 Summary – waterfall

Strength Weakness Types of

Projects
Simple All or nothing – too Well understood
Easy to execute risky problems, short
Intuitive and Req frozen early duration projects,
logical May chose automation of
outdated existing manual
Easy contractually
hardware/tech systems
Disallows changes
No feedback from
users
Encourages req
bloating
Software Process 33
 Summary – Prototyping

Strength Weakness Types of

Projects
Helps req Front heavy Systems with
elicitation Possibly higher novice users; or
Reduces risk cost and schedule areas with req
Better and more Encourages req uncertainity.
stable final system bloating Heavy reporting
Disallows later based systems
change can benefit from
UI proto

Software Process 34
 Summary – Iterative

Strength Weakness Types of

Projects
Regular deliveries, Overhead of For businesses
leading to biz planning each where time is imp;
benefit iteration risk of long
Can accommodate Total cost may projects cannot be
changes naturally increase taken; req not
Allows user System arch and known and evolve
feedback design may suffer with time
Avoids req Rework may
bloating increase
Naturally
prioritizes req
Allows reasonable Software Process 35
exit points
 Process iteration
• System requirements ALWAYS evolve in the
course of a project so process iteration where
earlier stages are reworked is always part of
the process for large systems.
• Iteration can be applied to any of the generic
process models.
• Two (related) approaches
– Incremental delivery;
– Spiral development.
36
 Incremental delivery
• Rather than deliver the system as a single delivery,
the development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
• User requirements are prioritised and the highest
priority requirements are included in early
increments.
• Once the development of an increment is started, the
requirements are frozen though requirements for
later increments can continue to evolve.

37
 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
increment # 2 nth increment

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
delivery of
De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

1st increment

project calendar time

38
 Incremental development

Define outline Assign requirements Design system

requirements to increments architectur
e

Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete

39
Incremental development advantages
• Customer value can be delivered with each
increment so system functionality is available
earlier.
• Early increments act as a prototype to help
elicit requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to
receive the most testing.

40
Incremental means adding, Iterative means
reworking (by Alistair Cockburn)
• Incremental development is a staging and scheduling strategy in which the
various parts of the system are developed at different times or rates and
integrated as they are completed. The alternative is to develop the entire
system with a big bang integration at the end.
• Iterative development is a rework scheduling strategy in which time is set
aside to revise and improve parts of the system. The alternative development
is to get it right the first time (or at least declare that it is right!).

Increment Iterate
.”fundamentally means “add onto .”fundamentally means “change

repeating the process on a new repeating the process on the

.section of work same section of work

repeat the process (, design, repeat the process (, design,

,implement, evaluate) ,implement, evaluate)
 Incremental Development

• The first increment delivers one slice of

functionality through the whole system.
• The second increment delivers another
slice of functionality through the whole system.
• The third increment delivers the rest of
the system
 Iterative Development
• \

• The first iteration delivers enough of

feature 1 to evaluate what is correct
and what needs revision.
• After the second iteration, some revised
parts still need improvement.
• The third iteration produces the final
and stable feature
 Incremental & Iterative - summary
• Iterative model - This model iterates requirements, design, build and
test phases again and again for each requirement and builds up a
system iteratively till the system is completely build.
• Incremental model - It is non integrated development model. This
model divides work in chunks and one team can work on many
chunks. It is more flexible.
• Spiral model - This model uses series of prototypes in stages,
the development ends when the prototypes are developed into
functional system. It is flexible model and used for
large and complicated projects.
• Evolutionary model - It is more customer focused model. In this
model the software is divided in small units which is delivered earlier
to the customers.
• V-Model - It is more focused on testing. For every phase some testing
activity are done.
 Spiral development
• Process is represented as a spiral rather than
as a sequence of activities with backtracking.
• Each loop in the spiral represents a phase in
the process.
• No fixed phases such as specification or design
- loops in the spiral are chosen depending on
what is required.
• Risks are explicitly assessed and resolved
throughout the process.
• This was the motivation behind developing the Spiral
Model - Risk 45
 Evolutionary Models: The
Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test
46
 Spiral Model Basic Farmeworks
• Communication
Software development process starts with
communication between customer and developer.
• Planning
It includes complete estimation and scheduling and
risk analysis.
• Modelling
It includes detail requirement analysis and project
design.
Flowchats and UML Diagrams to show pictorial flow
of process and programs.
 Spiral Model Basic Farmeworks
• Construction
Coding – Design details are implemented using
appropriate programming language.
Testing – Testing is carried out by testing team.
• Deployment
It includes software delivery, support and feedback from
customer.

• Note: After customer evaluation, next spiral

implements customer’s suggestions plus
enhancements plan.
 Spiral model sectors
• Objective setting
– Specific objectives for the phase are identified.
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the
key risks.
• Development and validation
– A development model for the system is chosen which can
be any of the generic models.
• Planning
– The project is reviewed and the next phase of the spiral is
planned.

50
 Spiral Model Usage

 Spiral model has been very influential in helping people

think about iteration in software processes and
introducing the risk-driven approach to development.

 In practice, however, the model is rarely used as

published for practical software development.

Chapter 2 Software Processes 14

 When to use Spiral Model

• A Spiral model in software engineering is used when

project is large
• When releases are required to be frequent, spiral
methodology is used
• When creation of a prototype is applicable
• When risk and costs evaluation is important
• Spiral methodology is useful 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
 Advantages of Spiral Model
• Software is produced early in the software life cycle.
• Risk handling is one of important advantages of the Spiral
model, it is best development model to follow due to the
risk analysis and risk handling at every phase.
• Flexibility in requirements. In this model, we can easily
change requirements at later phases and can be
incorporated accurately. Also, additional Functionality can
be added at a later date.
• It is good for large and complex projects.
• It is good for customer satisfaction. We can involve
customers in the development of products at early phase
of the software development. Also, software is produced
Advantages of Spiral Model continue…
• Strong approval and documentation control.
• It is suitable for high risk projects, where
business needs may be unstable. A highly
customized product can be developed using
this.
 Disadvantages of Spiral Model
• It is not suitable for small projects as it is expensive.
• It is much more complex than other SDLC models. Process is
complex.
• Too much dependable on Risk Analysis and requires highly specific
expertise.
• Difficulty in time management. As the number of phases is
unknown at the start of the project, so time estimation is very
difficult.
• Spiral may go on indefinitely.
• End of the project may not be known early.
• It is not suitable for low risk projects.
• May be hard to define objective, verifiable milestones. Large
numbers of intermediate stages require excessive documentation.
 Evolutionary Models: Concurrent
none

Modeling act ivit y

represents the state

Under of a software engineering
activity or task
development

A wait ing
changes

Under review

Under
revision

Baselined

Done

56
 Concurrent development model
• 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.
 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.
a) Differentiate in between waterfall and spiral model.