WATERFALL MODEL

1. The waterfall model was first defined by

Winston W. Royce in 1970 and has been
widely used for software projects ever since.
2. The waterfall Model illustrates the software
development process in a linear sequential
flow. This means that any phase in the
development process begins only if the
previous phase is complete.

CONTD
3. The waterfall approach does not define the
process to go back to the previous phase to
handle changes in requirement. Therefore,
different projects may follow different
approaches to handle such situations.
4. In Royce's original waterfall model, the
following phases are followed in order
Traditional Systems Development
Lifecycle (The Waterfall Model)
Planning
Traditional Systems Development
Lifecycle (The Waterfall Model)
Planning
Analysis
Traditional Systems Development
Lifecycle (The Waterfall Model)
Planning
Analysis
Logical
Design
Traditional Systems Development
Lifecycle (The Waterfall Model)
Planning
Analysis
Logical
Design
Physical
Design
Traditional Systems Development
Lifecycle (The Waterfall Model)
Planning
Analysis
Logical
Design
Physical
Design
Implementation
STEPS
1. PLANNING:
It involves a macro level study of the customer
requirements. This phase also involves defining
alternative solutions to the customer
requirements and cost-benefit justification of
these alternatives.
2. ANALYSIS :
It involves carrying out detailed study of the
customer requirements and arriving at the exact
requirements of the proposed system. The phase
involves freezing the requirements before the
design phase begins.
3. DESIGN:
It involves translating the identified
requirements into a logical structure, called
design that can be implemented in a
programming logic.
4. TESTING:
It involves integrating and testing all the
modules developed in the previous phase as
a complete system.
5. IMPLEMENTATION AND MAINTENANCE:
It involves converting the new system
design into operation. This may involve
implementing the software system and
training the operating staff before the
software system is functional.

When to use the Waterfall
Model
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new
platform.
WHY NOT WATERFALL
MODEL?
Requirements are not stable/unchanging

The market changesconstantly.

The technology changes.

The goals of the stakeholders change.

The design may need to change during
implementation

Requirements are incomplete and changing.

Too many variables, unknowns, and
novelties.

A complete specification must be as detailed
as code itself.

Software is very hard- Discover Magazine,
1999: Software characterized as the most
complex machine humankind builds.


The waterfall approach assumes that
requirements are stable and frozen across
the project plan.

However, this is usually not true in case of
large projects where requirements may
evolve across the development process.
ADVANTAGES
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff,
track)
Works well when quality is more important
than cost or schedule

DISADVANTAGES
All requirements must be known upfront
Deliverables created for each phase are
considered frozen inhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of
software development iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview
the system (until it may be too late)

ALTERNATIVE TO
WATERFALL MODEL
JAD (Joint
Application
Development)

RAD (Rapid
Application
Development)

SPIRAL MODEL
JOINT APPLICATION
DEVELOPMENT (JAD)
It is a process that accelerates the design of
information technology solutions.
JAD uses customer involvement and group
dynamics to accurately depict the user's view
of the business need and to jointly develop a
solution.
Before the advent of JAD, requirements were
identified by interviewing stakeholders
individually. The ineffectiveness of this
interviewing technique, which focused on
individual input rather than group consensus,
led to the development of the JAD approach.
JAD offers a team oriented approach to the
development of information management
solutions that emphasize a consensus
based problem-solving model.
By incorporating facilitated workshops and
emphasizing a spirit of partnership, JAD
enables system requirements to be
documented more quickly and accurately
than if a traditional approach were used.
JAD combines technology and business
needs in a process that is consistent,
repeatable, and effective.
WHEN TO USE JAD
JAD can be successfully applied to a
wide range of projects, including the
following:(17)
New systems
Enhancements to existing systems
System conversions
Purchase of a system
RAPID APPLICATION
MODEL (RAD)
Requirements planning phase (a workshop
utilizing structured discussion of business
problems)
User description phase automated tools
capture information from users
Construction phase productivity tools,
such as code generators, screen generators,
etc. inside a time-box. (Do until done)
Cutover phase -- installation of the system,
user acceptance testing and user training

RAD STRENGTHS
Reduced cycle time and improved productivity with
fewer people means lower costs
Time-box approach mitigates cost and schedule
risk
Customer involved throughout the complete cycle
minimizes risk of not achieving customer
satisfaction and business needs
Focus moves from documentation to code
(WYSIWYG).
Uses modeling concepts to capture information
about business, data, and processes.

RAD WEAKNESSES
Accelerated development process must
give quick responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be
modularized
Developers and customers must be
committed to rapid-fire activities in an
abbreviated time frame.