Bautista, Juan Carlos

Figueroa, Henerando
Ellena, Jhefferson

Flores, Jonnel
Flores, Jolan
BSIT 3-2

Waterfall (a.k.a. Traditional) Methodology

The waterfall model is a popular version of the systems
development life cycle model for software engineering. Often
considered the classic approach to the systems development life
cycle, the waterfall model describes a development method that is
rigid and linear. Waterfall development has distinct goals for
each phase of development where each phase is completed for the
next one is started and there is no turning back.
The perceived advantages of the waterfall process are that
it allows for departmentalization and managerial control. A
schedule is typically set with deadlines for each stage of
development and a product can proceed through the development
process. In theory, this process leads to the project being
delivered on time because each phase has been planned in detail.
In practice, waterfall development often falls short of
expectations as it does not embrace the inevitable changes and
revisions that become necessary with most projects. Once an
application is in the testing stage, it is very difficult to go
back and change something that was not thought of in the concept
stage. Alternatives to the waterfall model include joint
application development (JAD), rapid application development
(RAD), sync and stabilize, build and fix, and the spiral model.
The

Waterfall

Model

was

first

Process

Model

to

be

introduced. It is also referred to as a linear-sequential life

cycle model.

It is very simple to understand and use.

In a

waterfall model, each phase must be completed fully before the

next phase can begin. This type of model is basically used for
the for the project which is small and there are no uncertain
requirements. At the end of each phase, a review takes place to
determine if the project is on the right path and whether or not
to continue or discard the project. In this model the testing
starts only after the development is complete. In waterfall model
phases do not overlap.

Diagram of Waterfall-model:

The stages of The Waterfall Model are:

Requirement Analysis & Definition:
Requirements are set of functionalities and constraints that
the end-user (who will be using the system) expects from the
system. The requirements are gathered from the end-user by
consultation, these requirements are analyzed for their validity

and the possibility of incorporating the requirements in the

system to be development is also studied. Finally, a Requirement
Specification document is created which serves the purpose of
guideline for the next phase of the model.
System & Software Design:
Before a starting for actual coding, it is highly important
to understand what we are going to create and what it should look
like? The requirement specifications from first phase are studied
in this phase and system design is prepared. System Design helps
in specifying hardware and system requirements and also helps in
defining overall system architecture. The system design
specifications serve as input for the next phase of the model.
Implementation & Unit Testing:
On receiving system design documents, the work is divided in
modules/units and actual coding is started. The system is first
developed in small programs called units, which are integrated in
the next phase. Each unit is developed and tested for its
functionality; this is referred to as Unit Testing. Unit testing
mainly verifies if the modules/units meet their specifications.
Integration & System Testing:
As specified above, the system is first divided in units
which are developed and tested for their functionalities. These
units are integrated into a complete system during Integration
phase and tested to check if all modules/units coordinate between
each other and the system as a whole behaves as per the
specifications. After successfully testing the software, it is
delivered to the customer.

Operations & Maintenance:

This phase of The Waterfall Model is virtually never ending
phase (Very long). Generally, problems with the system developed
(which are not found during the development life cycle) come up
after its practical use starts, so the issues related to the
system are solved after deployment of the system. Not all the
problems come in picture directly but they arise time to time and
needs to be solved; hence this process is referred as
Maintenance.
Advantages of waterfall model:

This model is simple and easy to understand and use.

It is easy to manage due to the rigidity of the model each

phase has specific deliverables and a review process.

In this model phases are processed and completed one at a

time. Phases do not overlap.

Waterfall

model

works

well

for

smaller

projects

where

requirements are very well understood.

Disadvantages of waterfall model:

Once an application is in the testing stage, it is very

difficult to go back and change something that was not wellthought out in the concept stage.

No working software is produced until late during the life

cycle.

High amounts of risk and uncertainty.

Not a good model for complex and object-oriented projects.

Poor model for long and ongoing projects.

Not suitable for the projects where requirements are at a

moderate to high risk of changing.

When to use the waterfall model:

This model is used only when the requirements are very well
known, clear and fixed.

Product definition is stable.

Technology is understood.

There are no ambiguous requirements

Ample resources with required expertise are available freely

The project is short.

Very less customer enter action is involved during the

development of the product. Once the product is ready then only
it can be demoed to the end users. Once the product is developed
and if any failure occurs then the cost of fixing such issues are
very high, because we need to update everywhere from document
till the logic.

Example: Product developmentWaterfall methodology

If a team were to develop a customer address book using the
Waterfall methodology, the order of work would be as follows
(timeframes are for demonstration purposes only):
PRODUCT REQUIREMENTS
Product manager creates requirements documents that include the
following requirements (in order of priority):

User should be able to create new contacts.

User should be able to view their contacts.

User should be able to import contacts from other

programs.

User should be able to email their contacts from the

address book.

User should be able to add pictures to represent their

contacts.

These requirement documents will include detailed requirements,

user scenarios and potential layouts for the functionality.
Timeframe: 2 weeks
ANALYSIS
Engineering team takes these requirements and analyzes them,
asking questions as needed. Product manager updates documents as
questions are resolved.
Timeframe: 1 week
DESIGN
Engineering team creates a design for functionality, including
database design, mock-ups and workflows.
Timeframe: 3 weeks
IMPLEMENTATION
Engineering team develops functionality and prepares it for
testing.
Timeframe: 1 week
SOFTWARE PRODUCT TESTING
Product team tests entire functionality.

Timeframe: 2 weeks
RELEASE
The product functionality is released.
TOTAL elapsed time: 9 weeks
Note: if any changes to the design occur during this workflow,
the project would have to return to the second or third phase and
restart the process.

References:

*(January 26,2016) http://www.ukessays.com/essays/informationtechnology/the-history-of-the-waterfall-model-informationtechnology-essay.php

*(January 27,2016) http://istqbexamcertification.com/what-iswaterfall-model-advantages-disadvantages-and-when-to-use-it/

*(January 27,2016) https://www.marsdd.com/mars-library/productdevelopment-the-waterfall-methodology-model-in-softwaredevelopment/