The Waterfall Model Explained
The subject of software engineering does not only deal with software development, but with developing good software by using the knowledge of available theories, various defined methods, and the effective use of the tools at hand.
Software products, like any other engineering products, are oriented toward customers. Before development begins, a market study (or market research) identifies a potential customer's existing and possible future needs; the customer's need is then given to a research and development team to create a cost-effective system that solves it better than the competitors. Once the system is developed and tested in a hypothetical environment, the development team adopts one of several "software development process models" to build and deliver the proposed system. The basic, popular models include the System Development Life Cycle (SDLC), the Prototyping Model, the Rapid Application Development Model, and the Component Assembly Model. Each follows a particular life cycle to help ensure the project's success.
Where the Waterfall Model Fits
The Waterfall approach was the first process model to be introduced and widely followed in software engineering. It is in fact the SDLC in its original form — also called the Classic Life Cycle Model or the Linear Sequential Model. In the Waterfall approach, the whole process of software development is divided into separate phases that are cascaded one into the next, so that each phase begins only when the previous phase has achieved its defined goals and been signed off — hence the name "Waterfall." All the methods and processes undertaken are highly visible.
The Stages of the Waterfall Model
Requirement Analysis and Definition
All possible requirements of the system — the functionalities and constraints the end-user expects — are captured in this phase. Requirements are gathered from the end-user by consultation, analyzed for validity and feasibility, and documented in a Requirement Specification, which serves as the guideline for the next phase. (This stage is also known as the feasibility study, and its output records specific recommendations, personnel assignments, costs, the project schedule and target dates.)
System and Software Design
Before actual coding, it is important to understand exactly what will be created and what it should look like. The requirement specifications are studied and a system design prepared, which specifies the hardware and system requirements, the overall system architecture, and — for client/server technology — the number of tiers, the database design and the data structures. Any fault introduced in the design phase can be very expensive to fix later, so analysis and design are critical to the whole cycle. The design specifications serve as input for the next phase.
Implementation and Unit Testing (Code Generation)
The system is broken into small programs called units, and actual coding begins, decoding the design into a machine-readable form using programming tools such as compilers, interpreters and debuggers and high-level languages such as C, C++, Pascal and Java, chosen to suit the application. Each unit is developed and verified against its specification — this is Unit Testing.
Integration and System Testing
The individually tested units are integrated into a complete system and tested to check that all modules coordinate and that the system as a whole behaves as specified. A number of testing tools and methods are used to detect bugs committed in the previous phases. After successful testing, the software is delivered to the customer.
Operations and Maintenance
This is a virtually never-ending phase. Problems not found during development tend to surface once practical use begins, and changes may be required due to unforeseen inputs or changing system conditions, so issues are resolved after deployment — a process referred to as Maintenance.
Disadvantages of the Waterfall Model
- It is very important to gather all possible requirements during the requirement phase, but in practice requirements keep getting added even after that phase ends, which negatively affects development and its success.
- Problems belonging to a phase are seldom solved completely within it; many arise after the phase is signed off, resulting in a badly structured system.
- The project is not partitioned into phases in a flexible way.
- Because requirements keep getting added but not all are fulfilled, the delivered system can be almost unusable, and the missing requirements are met only in a newer version — increasing the overall cost of development.
