You are on page 1of 14

What is Waterfall model- advantages,

disadvantages and when to use it?


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:

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 well-thought 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.

http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantagesand-when-to-use-it/

Waterfall vs. Agile: Which is the Right Development


Methodology for Your Project?
by Mary Lotz, PMP
July 5th, 2013

Project Management Waterfall Agile Software Development Website


Development Web Application Development Mobile Application Development

One of the first decisions we face for each of our project implementations at
Segue is Which development methodology should we use? This is a topic
that gets a lot of discussion (and often heated debate). If this is not
something youve worked with before, a definition of development
methodology is in order; put very simply, its a way of organizing the work of
software development. This is NOT about a style of project management or
a specific technical approach, although you will often hear these terms all
thrown together or used interchangeably.
The two basic, most popular methodologies are:
1.

Waterfall: (ugh, terrible name!), which might be more properly called


the traditional approach, and

2.

Agile: a specific type of Rapid Application Development and newer


than Waterfall, but not that new, which is often implemented using Scrum.

Both of these are usable, mature methodologies. Having been involved in


software development projects for a long time, here are my thoughts on the
strengths and weaknesses of each.

The Waterfall Methodology


Waterfall is a linear approach to software development. In this
methodology, the sequence of events is something like:
1.

Gather and document requirements

2.

Design

3.

Code and unit test

4.

Perform system testing

5.

Perform user acceptance testing (UAT)

6.

Fix any issues

7.

Deliver the finished product


In a true Waterfall development project, each of these represents a distinct
stage of software development, and each stage generally finishes before
the next one can begin. There is also typically a stage gate between each;
for example, requirements must be reviewed and approved by the customer
before design can begin.
There are good things and bad about the Waterfall approach. On
the positive side:

Developers and customers agree on what will be delivered early in


the development lifecycle. This makes planning and designing more
straightforward.

Progress is more easily measured, as the full scope of the work is


known in advance.

Throughout the development effort, its possible for various members


of the team to be involved or to continue with other work, depending on the
active phase of the project. For example, business analysts can learn about
and document what needs to be done, while the developers are working on
other projects. Testers can prepare test scripts from requirements
documentation while coding is underway.

Except for reviews, approvals, status meetings, etc., a customer


presence is not strictly required after the requirements phase.

Because design is completed early in the development lifecycle, this


approach lends itself to projects where multiple software components must
be designed (sometimes in parallel) for integration with external systems.

Finally, the software can be designed completely and more carefully,


based upon a more complete understanding of all software deliverables.
This provides a better software design with less likelihood of the piecemeal
effect, a development phenomenon that can occur as pieces of code are
defined and subsequently added to an application where they may or may
not fit well.
Here are some issues we have encountered using a pure Waterfall
approach:

One area which almost always falls short is the effectiveness


of requirements. Gathering and documenting requirements in a way that is
meaningful to a customer is often the most difficult part of software
development, in my opinion. Customers are sometimes intimidated by
details, and specific details, provided early in the project, are required with
this approach. In addition, customers are not always able to visualize an
application from a requirements document. Wireframes and mockups can
help, but theres no question that most end users have some difficulty
putting these elements together with written requirements to arrive at a
good picture of what they will be getting.

Another potential drawback of pure Waterfall development is the


possibility that the customer will be dissatisfied with their delivered software

product. As all deliverables are based upon documented requirements, a


customer may not see what will be delivered until its almost finished. By
that time, changes can be difficult (and costly) to implement.

The Agile Methodology


Agile is an iterative, team-based approach to development. This approach
emphasizes the rapid delivery of an application in complete functional
components. Rather than creating tasks and schedules, all time is timeboxed into phases called sprints. Each sprint has a defined duration
(usually in weeks) with a running list of deliverables, planned at the start of
the sprint. Deliverables are prioritized by business value as determined by
the customer. If all planned work for the sprint cannot be completed, work is
reprioritized and the information is used for future sprint planning.
As work is completed, it can be reviewed and evaluated by the project team
and customer, through daily builds and end-of-sprint demos. Agile relies on
a very high level of customer involvement throughout the project, but
especially during these reviews.
Some advantages of the Agile approach are easy to see:

The customer has frequent and early opportunities to see the work
being delivered, and to make decisions and changes throughout the
development project.

The customer gains a strong sense of ownership by working


extensively and directly with the project team throughout the project.

If time to market for a specific application is a greater concern than


releasing a full feature set at initial launch, Agile can more quickly produce a
basic version of working software which can be built upon in successive
iterations.

Development is often more user-focused, likely a result of more and


frequent direction from the customer.

For more Agile Development benefits, please see 8 Benefits of Agile


Software Development
And, of course, there are some disadvantages:

The very high degree of customer involvement, while great for the
project, may present problems for some customers who simply may not
have the time or interest for this type of participation.

Agile works best when members of the development team are


completely dedicated to the project.

Because Agile focuses on time-boxed delivery and frequent


reprioritization, its possible that some items set for delivery will not be
completed within the allotted timeframe. Additional sprints (beyond those
initially planned) may be needed, adding to the project cost. In addition,
customer involvement often leads to additional features requested
throughout the project. Again, this can add to the overall time and cost of
the implementation.

The close working relationships in an Agile project are easiest to


manage when the team members are located in the same physical space,
which is not always possible. However, there are a variety of ways to handle
this issue, such as webcams, collaboration tools, etc.

The iterative nature of Agile development may lead to a frequent


refactioring if the full schope of the system is not considered in the intial
architecture and design. Without this refactoring, the system can suffer from
a reduction in overall quality. This becomes more pronounced in largerscale implementations, or with systems that include a high level of
integration.

Making the Choice Between Agile and


Waterfall
So, how do we choose? First, we change the game a little (which is what
most software development organizations do) by defining our own process.
At Segue, its called our Process Framework, and its a variation on the
traditional Waterfall methodology. Our modifications include use of
prototyping where possible to provide the customer a better view of their
finished product early in the design/development cycle. This helps to
improve the teams understanding of requirements and communication with
the customer. After the primary framework of the application is completed
per high level requirements, we continue to develop and also to reach out to
the customer for refinement of requirements. In this way, we strive to be as
iterative as possible without compromising our overall system architecture.
We consider the following factors when considering which methodology to
use:

The factors above are not equally weighted; each is assessed depending on
the individual project and circumstances.
Once weve decided which basic methodology to utilize, we can further
refine the process to best fit our project goals. Ultimately, although the way
in which we do our work is important, delivering a solid and maintainable
product that satisfies our customer is what really counts

http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-rightdevelopment-methodology

Waterfall model
From Wikipedia, the free encyclopedia

Software development process


Core activities

Requirements

Design

Construction

Testing

Debugging

Deployment

Maintenance
Paradigms and models

Software engineering

Waterfall

Prototyping

Incremental

V-Model

Dual Vee Model

Spiral

IID

Agile

Lean

DevOps

Methodologies and frameworks

Cleanroom

TSP

PSP

RAD

DSDM

MSF

Scrum

Kanban

UP

XP

TDD

ATDD

BDD

FDD

DDD

MDD

UDD

Supporting disciplines

Configuration management

Documentation

Software Quality assurance (SQA)

Project management

User experience
Tools

Compiler

Debugger

Profiler

GUI designer

Modeling

IDE
Build automation

Testing

Standards and BOKs

CMMI
IEEE standards

ISO 9001

ISO/IEC standards

SWEBOK
PMBOK

The unmodified "waterfall model". Progress flows from the top to the bottom, like a cascading waterfall.

The waterfall model is a sequential design process, used in software development processes, in
which progress is seen as flowing steadily downwards (like a waterfall) through the phases of
conception, initiation, analysis, design,
construction, testing,production/implementation and maintenance.
The waterfall development model originates in the manufacturing and construction industries:
highly structured physical environments in which after-the-fact changes are prohibitively costly, if
not impossible. Since no formal software development methodologies existed at the time, this
hardware-oriented model was simply adapted for software development. [1]
Contents
[hide]

1History

2Model

3Supporting arguments

4Criticism

5See also

6References

7External links

History[edit]
The first known presentation describing use of similar phases in software engineering was held
by Herbert D. Benington at Symposium on advanced programming methods for digital computers
on 29 June 1956.[2] This presentation was about the development of software for SAGE. In 1983
the paper was republished with a foreword by Benington pointing out that the process was not in
fact performed in a strict top-down fashion, but depended on a prototype. [1]

The first formal description of the waterfall model is often cited as a 1970 article by Winston W.
Royce,[3][4] although Royce did not use the term waterfall in that article. Royce presented this
model as an example of a flawed, non-working model; which is how the term is generally used in
writing about software developmentto describe a critical view of a commonly used software
development practice.[5]
The earliest use of the term "waterfall" may have been a 1976 paper by Bell and Thayer.[6]
In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A,
their standards for working with software development contractors, which stated that "the
contractor shall implement a software development cycle that includes the following six phases:
Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing". [7]

Model[edit]
In Royce's original waterfall model, the following phases are followed in order:
1. System and software requirements: captured in a product requirements document
2. Analysis: resulting in models, schema, and business rules
3. Design: resulting in the software architecture
4. Coding: the development, proving, and integration of software
5. Testing: the systematic discovery and debugging of defects
6. Operations: the installation, migration, support, and maintenance of complete systems
Thus the waterfall model maintains that one should move to a phase only when its preceding
phase is reviewed and verified.
Various modified waterfall models (including Royce's final model), however, can include slight or
major variations on this process.[3] These variations included returning to the previous cycle after
flaws were found downstream, or returning all the way to the design phase if downstream phases
deemed insufficient.

Supporting arguments[edit]
Time spent early in the software production cycle can reduce costs at later stages. For example,
a problem found in the early stages (such as requirements specification) is cheaper to fix than the
same bug found later on in the process (by a factor of 50 to 200).[8]
In common practice, waterfall methodologies result in a project schedule with 2040% of the time
invested for the first two phases, 3040% of the time to coding, and the rest dedicated to testing
and implementation. The actual project organization needs to be highly structured. Most medium
and large projects will include a detailed set of procedures and controls, which regulate every
process on the project.[9]
A further argument for the waterfall model is that it places emphasis on documentation (such as
requirements documents and design documents) as well as source code. In less thoroughly
designed and documented methodologies, knowledge is lost if team members leave before the

project is completed, and it may be difficult for a project to recover from the loss. If a fully working
design document is present (as is the intent of Big Design Up Front and the waterfall model), new
team members or even entirely new teams should be able to familiarize themselves by reading
the documents.[10]
The waterfall model provides a structured approach; the model itself progresses linearly through
discrete, easily understandable and explainable phases and thus is easy to understand; it also
provides easily identifiable milestones in the development process. It is perhaps for this reason
that the waterfall model is used as a beginning example of a development model in many
software engineering texts and courses.[11]
It is argued that the waterfall model can be suited to projects where requirements and scope are
fixed, the product itself is firm and stable, and the technology is clearly understood. [12]

Criticism[edit]
Clients may not know exactly what their requirements are before they see working software and
so change their requirements, leading to redesign, redevelopment, and retesting, and increased
costs.[13]
Designers may not be aware of future difficulties when designing a new software product or
feature; in which case, it is better to revise the design than persist in a design that does not
account for any newly discovered constraints, requirements, or problems. [14]
In response to the perceived problems with the pure waterfall model, modified waterfall
models were introduced, such as "Sashimi (Waterfall with Overlapping Phases), Waterfall with
Subprojects, and Waterfall with Risk Reduction".[8]
Some organizations, such as the United States Department of Defense, now have a stated
preference against waterfall type methodologies, starting with MIL-STD-498, which
encourages evolutionary acquisition and Iterative and Incremental Development.[15]
While advocates of agile software development argue the waterfall model is an ineffective
process for developing software, some sceptics suggest that the waterfall model is a false
argument used purely to market alternative development methodologies.[16]

https://en.wikipedia.org/wiki/Waterfall_model

You might also like