Technical Documentation
The waterfall methodology uses a sequential or linear approach to software development. The project is broken down into a sequence of tasks, with the highest level grouping referred to as phases. A true waterfall approach requires phases that are completed in sequence and have formal exit criteria, typically a sign-off by the project stakeholders.
When used for a software development process, the waterfall methodology has seven stages:
Potential requirements, deadlines and guidelines for the project are analyzed and placed into a formal requirements document, also called a functional specification. This stage of development defines and plans the project without mentioning specific processes.
The system specifications are analyzed to generate product models and business logic to guide production. This is also when financial and technical resources are audited for feasibility.
A design specification document is created to outline technical design requirements, such as the programming language, hardware, data sources, architecture and services.
The source code is developed using the models, logic and requirement specifications designated in the prior phases. Typically, the system is coded in smaller components, or units, before being put together.
This is when quality assurance, unit, system and beta tests identify issues that must be resolved. This may cause a forced repeat of the coding stage for debugging. If the system passes integration and testing, the waterfall continues forward.
The product or application is deemed fully functional and is deployed to a live environment.
Corrective, adaptive and perfective maintenance is carried out indefinitely to improve, update and enhance the product and its functionality. This could include releasing patch updates and new versions.
Today, Agile methodology is often used in place of the waterfall model. However, there are advantages to the waterfall approach, such as the following:
Enables large or changing teams to move toward a common goal that’s been defined in the requirements stage.
Forces structured, disciplined organization.
Simplifies understanding, following and arranging tasks.
Facilitates departmentalization and managerial control based on the schedule or deadlines.
Reinforces good coding habits to define before implementing design and then code.
Enables early system design and specification changes to be easily do.
Clearly defines milestones and deadlines.
Disadvantages of the waterfall model typically center around the risk associated with a lack of revision and flexibility. Specific issues include the following:
Design isn’t adaptive; when a flaw is found, the entire process often needs to start over.
Method doesn’t incorporate midprocess user or client feedback, and makes changes based on results.
Waterfall model delays testing until the end of the development lifecycle.
It doesn’t consider error correction.
The methodology doesn’t handle requests for changes, scope adjustments and updates well.
Waterfall doesn’t let processes overlap for simultaneous work on different phases, reducing overall efficiency.
No working product is available until the later stages of the project lifecycle.
Waterfall isn’t ideal for complex, high-risk ongoing projects.