| You
are here: Freetutes.com
> Systems
Analysis and Design
Waterfall Software Development Life Cycle Model
The simplest software development life cycle model is the waterfall model, which
states that the phases are organized in a linear order. A project begins with
feasibility analysis. On the successful demonstration of the feasibility analysis,
the requirements analysis and project planning begins.
The design starts after the requirements analysis is done. And coding begins
after the design is done. Once the programming is completed, the code is integrated
and testing is done. On succeeful completion of testing, the system is installed.
After this the regular operation and maintenance of the system takes place. The
following figure demonstrates the steps involved in waterfall life cycle model.
The Waterfall Software Life Cycle Model
With the waterfall model, the activities performed in a software development
project are requirements analysis, project planning, system design, detailed design,
coding and unit testing, system integration and testing. Linear ordering of activities
has some important consequences. First, to clearly identify the end of a phase
and beginning of the others. Some certification mechanism has to be employed at
the end of each phase. This is usually done by some verification and validation.
Validation means confirming the output of a phase is consistent with its input
(which is the output of the previous phase) and that the output of the phase is
consistent with overall requirements of the system.
The consequences of the need of certification is that each phase must have
some defined output that can be evaluated and certified. Therefore, when the activities
of a phase are completed, there should be an output product of that phase and
the goal of a phase is to produce this product. The outputs of the earlier phases
are often called intermediate products or design document. For the coding phase,
the output is the code. From this point of view, the output of a software project
is to justify the final program along with the use of documentation with the requirements
document, design document, project plan, test plan and test results.
Another implication of the linear ordering of phases is that after each phase
is completed and its outputs are certified, these outputs become the inputs to
the next phase and should not be changed or modified. However, changing requirements
cannot be avoided and must be faced. Since changes performed in the output of
one phase affect the later phases, that might have been performed. These changes
have to made in a controlled manner after evaluating the effect of each change
on the project.This brings us to the need for configuration control or configuration
management.
The certified output of a phase that is released for the best phase is called
baseline. The configuration management ensures that any changes to a baseline
are made after careful review, keeping in mind the interests of all parties that
are affected by it. There are two basic assumptions for justifying the linear
ordering of phase in the manner proposed by the waterfall model.
For a successful project resulting in a successful product, all phases listed
in the waterfall model must be performed anyway.
Any different ordering of the phases will result in a less successful software
product.
Project Output in a Waterfall Model
As we have seen, the output of a project employing the waterfall model is not
just the final program along with documentation to use it. There are a number
of intermediate outputs, which must be produced in order to produce a successful
product.
The set of documents that forms the minimum that should be produced in each
project are:
- Requirement document
- Project plan
- System design document
- Detailed design document
- Test plan and test report
- Final code
- Software manuals (user manual, installation manual etc.)
- Review reports
Except for the last one, these are all the outputs of the phases. In order
to certify an output product of a phase before the next phase begins, reviews
are often held. Reviews are necessary especially for the requirements and design
phases, since other certification means are frequently not available. Reviews
are formal meeting to uncover deficiencies in a product. The review reports are
the outcome of these reviews.
Other Software/System Development Life Cycles
<<
Previous Page | Contents
| Next Page >>
|
