CS301 Software Engineering

Waterfall Model

Sunil Kumar P V
CSE
Waterfall Model

1
Waterfall Model

ˆ Classical waterfall model divides life cycle into

following phases:
ˆ Feasibility study,
ˆ Requirements analysis and specification,
ˆ Design,
ˆ Coding and unit testing,
ˆ Integration and system testing,
ˆ Maintenance.

2
Waterfall Model- Relative Effort
ˆ Phases between feasibility
study and testing is called
development phases.
ˆ Among all life cycle
phases maintenance phase
consumes maximum
effort.
ˆ Among development
phases, testing phase
consumes the maximum
effort. 3
Feasibility Study

4
Feasibility Study

ˆ Main aim of feasibility study: determine

whether developing the software is:
ˆ Financially worthwhile
ˆ Technically feasible.
ˆ Roughly understand what customer wants:
ˆ Data which would be input to the system,
ˆ Processing needed on these data,
ˆ Output data to be produced by the system,
ˆ Various constraints on the behavior of the system.

5
Feasibility Study: Activities

ˆ Work out an overall understanding of the

problem.
ˆ Formulate different solution strategies.
ˆ Examine alternate solution strategies in terms
of:
ˆ resources required,
ˆ cost of development, and
ˆ development time

6
Cost Benefit Analysis

ˆ Perform a cost/benefit analysis:

ˆ Determine which solution is the best.
ˆ May also find that none of the solutions is feasible
due to:
ˆ high cost,
ˆ resource constraints,
ˆ technical reasons.
ˆ Need to identify all costs — these could be:
ˆ Development costs
ˆ Set-up
ˆ Operational costs
ˆ Identify the value of benefits
ˆ Check benefits are greater than costs
7
The Business Case

ˆ Benefits of delivered
project must
outweigh costs
ˆ Costs include:
ˆ Development
ˆ Operation
ˆ Benefits:
ˆ Quantifiable
ˆ Non-quantifiable

8
The Business Case

ˆ Feasibility studies should help write a ‘business

case’
ˆ Should provide a justification for starting the
project
ˆ Should show that the benefits of the project
will exceed various costs
ˆ Needs to take account of business risks

9
Business Case Template

1. Executive summary
2. Project background: Focus on what the project is
undertaking
3. Business opportunity: What difference will it make? And
what if we don’t do it?
4. Costs: Include the cost of development, implementation,
training, change management, and operations.
5. Benefits: Presented in terms of revenue generation and
cost reductions
6. Benefits: Usually presented in terms of revenue
generation and cost reductions.
7. Risks: Identify risks and explain how these will be
managed
10
Requirement Analysis and Specification

ˆ Aim of this phase:

ˆ Understand the exact requirements of the
customer,
ˆ Document them properly.
ˆ Consists of two distinct activities:
ˆ Requirements gathering and analysis
ˆ Requirements specification.

11
Requirements Analysis and Specification

ˆ Gather requirements data from the customer:

ˆ Analyze the collected data to understand what
customer wants
ˆ Remove requirements problems:
ˆ Inconsistencies
ˆ Anomalies
ˆ Incompleteness
ˆ Organize into a Software Requirements
Specification (SRS) document.

12
Requirement Analysis

ˆ Gathering relevant data: Usually collected from

the end-users through interviews and
discussions.
ˆ The data you initially collect from the users
usually contain several contradictions and
ambiguities.
ˆ Because each user typically has only a partial
and incomplete view of the system.

13
Requirement Analysis

ˆ Ambiguities and contradictions must be

identified and resolved by discussions with the
customers.
ˆ Next, requirements are organized into a
Software Requirements Specification (SRS)
document.

14
Design

ˆ During design phase requirements specification

is transformed into a form suitable for
implementation in some programming
language.
ˆ Two commonly used design approaches:
ˆ Traditional approach,
ˆ Object oriented approach

15
Design: Traditional Approach

ˆ Consists of two activities:

ˆ Structured analysis (typically carried out by using
DFD, Data Flow Diagram)
ˆ Structured design

16
Structured Design

ˆ High-level design:
ˆ decompose the system into modules,
ˆ represent invocation relationships among the
modules.
ˆ Detailed design:
ˆ different modules designed in greater detail:
ˆ data structures and algorithms for each module are
designed

17
Object Oriented Design

ˆ First identify various objects (real world

entities) occurring in the problem:
ˆ Identify the relationships among the objects.
ˆ OOD advantages:
ˆ Lower development effort,
ˆ Lower development time,
ˆ Better maintainability

18
Coding and Unit Testing

ˆ Each module of the design is coded,

ˆ Each module is unit tested: that is, tested
independently as a stand alone unit, and
debugged.
ˆ Each module is documented.

19
Integration Testing

ˆ Different modules are integrated in a planned

manner:
ˆ Consists of a number of steps.
ˆ During each integration step, the partially
integrated system is tested.

20
System Testing

ˆ After all the modules have been successfully

integrated and tested, system testing is carried
out.
ˆ Goal of system testing: Ensure that the
developed system functions according to its
requirements as specified in the SRS document.

21
Maintenance

ˆ Requires much more effort than the effort to

develop the product itself.
ˆ Development effort to maintenance effort is
typically 40:60.
ˆ Types of Maintenance
ˆ Corrective maintenance: Correct errors which were
not discovered during the product development
phases.
ˆ Perfective maintenance:
ˆ Improve implementation of the system
ˆ Enhance functionalities of the system
ˆ Adaptive maintenance:
ˆ Port software to a new environment
22
Iterative Waterfall Model

ˆ Classical waterfall model is idealistic

ˆ Assumes that no defect is introduced during any
development activity
ˆ In practice. defects do get introduced in almost every
phase of the life cycle.
ˆ Defects usually get detected much later in the life cycle:
ˆ For example, a design defect might go unnoticed till the
coding or testing phase.
ˆ The later the phase in which the defect gets detected,
the more expensive is its removal — why?

23
Iterative Waterfall Model

ˆ Once a defect is detected, the phase in which it

occurred needs to be reworked.
ˆ Redo some of the work done during that and
all subsequent phases.
ˆ Therefore we need feedback paths in the
classical waterfall model.

24
Iterative Waterfall Model

25
Phase Containment of Errors

ˆ If a design problem is detected in the design

phase itself, the problem can be taken care of
much more easily than say if it is identified at
the end of the integration and system testing
ˆ Reason: rework must be carried out not only to
the design but also to code and test phases

26
Phase Containment of Errors

ˆ The principle of detecting errors as close to its

point of introduction as possible is known as
phase containment of errors.
ˆ Errors should be detected un the same phase in
which they are introduced
ˆ Iterative waterfall model is by far the most
widely used model.
ˆ Almost every other model is derived from the
waterfall model.
27
Waterfall Strengths

ˆ Easy to understand, easy to use, especially by

inexperienced staff
ˆ Milestones are well understood by the team
ˆ Provides requirements stability during
development
ˆ Facilitates strong management control (plan,
staff, track)

28
Waterfall Deficiencies

ˆ All requirements must be known upfront

ˆ But in most projects requirement change
occurs after project starts
ˆ Can give a false impression of progress
ˆ Integration is one big bang at the end
ˆ Little opportunity for customer to pre-view the
system

29
When to use the Waterfall Model?

ˆ Requirements are well known and stable

ˆ Technology is understood
ˆ Development team have experience with similar
projects

30
References

1. Fundamentals of SW Engg by Prof. Rajib Mall

(Text book)
2. NPTEL video lectures by Prof. Rajib Mall

31
Thank you..

32