The waterfall model This takes the fundamental process activities of
specification, development, validation, and evolution and represents them as
separate process phases such as requirements specification, software design,
implementation, testing, and so on.
The first published model of the software development process was
derived from
more general system engineering processes (Royce, 1970). Because of the
cascade from one phase to another, this model is known as the waterfall
model or software life cycle. The waterfall model is an example of a plan-driven
processin principle, you must plan and schedule all of the process activities
before starting work on them.
The principal stages of
the waterfall model directly reflect
fundamental development activities:
the
1. Requirements
analysis
and
definition
The
systems
services,
constraints, and goals are established by consultation with system users.
They are then defined in detail and serve as a system specification.
2. System and software design The systems design process allocates the
requirements to either hardware or software systems by establishing an
overall system architecture. Software design involves identifying and
describing the fundamental software system abstractions and their
relationships.
3. Implementation and unit testing During this stage, the software design
is realized as a set of programs or program units. Unit testing involves
verifying that each unit meets its specification.
4. Integration and system testing The individual program units or
programs are integrated and tested as a complete system to ensure that
the software requirements have been met. After testing, the software
system is delivered to the customer.
5. Operation and maintenance Normally (although not necessarily), this is
the longest life cycle phase. The system is installed and put into practical
use. Maintenance involves correcting errors which were not discovered
in earlier stages of the life cycle, improving the implementation of system
units and enhancing the systems services as new requirements are
discovered.
In principle, the result of each phase is one or more documents that are
approved
(signed off). The following phase should not start until the previous phase has
finished.
In practice, these stages overlap and feed information to each other.
During design, problems with requirements are identified. During coding,
design problems are found and so on. The software process is not a simple
linear model but involves feedback from one phase to another. Documents
produced in each phase may then have to be modified to reflect the changes
made.
Because of the costs of producing and approving documents, iterations
can be costly and involve significant rework. Therefore, after a small number of
iterations, it is normal to freeze parts of the development, such as the
specification, and to continue with the later development stages. Problems are
left for later resolution, ignored, or programmed around. This premature
freezing of requirements may mean that the system wont do what the user
wants. It may also lead to badly structured systems as design problems are
circumvented by implementation tricks.
During the final life cycle phase (operation and maintenance) the
software is put
into use. Errors and omissions in the original software requirements are
discovered.
Program and design errors emerge and the need for new functionality is
identified.
The system must therefore evolve to remain useful. Making these
changes (software maintenance) may involve repeating previous process stages.
The waterfall model is consistent with other engineering process models
and documentation is produced at each phase. This makes the process visible
so managers can monitor progress against the development plan. Its major
problem is the inflexible partitioning of the project into distinct stages.
Commitments must be made at an early stage in the process, which makes it
difficult to respond to changing customer requirements.
In principle, the waterfall model should only be used when the
requirements are well understood and unlikely to change radically during
system development. However, the waterfall model reflects the type of process
used in other engineering projects. As is easier to use a common management
model for the whole project, software processes based on the waterfall model
are still commonly used.
An
important
variant
of
the
waterfall
model
is
formal
system
development, where a mathematical model of a system specification is created.
This model is then refined, using mathematical transformations that preserve
its consistency, into executable code. Based on the assumption that your
mathematical transformations are correct, you can therefore make a strong
argument that a program generated in this way is consistent with its
specification.
Formal development processes, such as that based on the B method
(Schneider, 2001; Wordsworth, 1996) are particularly suited to the development
of systems that have stringent safety, reliability, or security requirements. The
formal approach simplifies the production of a safety or security case. This
demonstrates to customers or regulators that the system actually meets its
safety or security requirements.
Processes based on formal transformations are generally only used in the
development of safety-critical or security-critical systems. They require
specialized expertise. For the majority of systems this process does not offer
significant cost benefits over other approaches to system development.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC
approach to be followed based on the internal and external factors. Some
situations where the use of Waterfall model is most appropriate are:
Requirements are very well documented, clear and fixed.
Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the
product.
The project is short.
Waterfall Model Pros & Cons
Advantage
The
advantage
of
waterfall
development
is
that
it
allows
for
departmentalization and control. A schedule can be set with deadlines for each
stage of development and a product can proceed through the development
process model phases one by one.
Development moves from concept, through design, implementation,
testing,
installation,
troubleshooting,
and
ends
up
at
operation
and
maintenance. Each phase of development proceeds in strict order.
Disadvantage
The disadvantage of waterfall development is that it does not allow for
much reflection or revision. Once an application is in the testing stage, it is
very difficult to go back and change something that was not well-documented
or thought upon in the concept stage.
The following table lists out the pros and cons of Waterfall model:
Pros
Cons
Simple
and
easy
to
understand and use
until late during the life cycle.
Easy to manage due to the
rigidity of the model. each
phase
has
specific
process.
Phases are processed and
Works
well
for
projects
amounts
of
risk
and
Not a good model for complex and
object-oriented projects.
completed one at a time.
High
uncertainty.
deliverables and a review
No working software is produced
Poor model for long and ongoing
projects.
smaller
Not
suitable
where
for
the
requirements
projects
are
at
where
moderate
requirements are very well
changing.
understood.
uncertainty is high with this
Clearly defined stages.
process model.
Well
understood
Easy to arrange tasks.
Process and results are
well documented.
high
So
risk
risk
of
and
It is difficult to measure progress
within stages.
milestones.
to
Cannot accommodate changing
requirements.
Adjusting scope during the life
cycle can end a project.
Integration is done as a "bigbang. at the very end, which
doesn't
allow
technological
identifying
or
any
business
bottleneck or challenges early.
