Widely considered the oldest Software development methodology, the Waterfall method is ordered set of steps. Another way to describe it is as a line that only goes in one direction. Russell Kay at Computerworld describes as “a sequence of stages in which the output of each stage becomes the input for the next”. He lists the following steps:
- Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
- Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
- Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
- Implementation: The real code is written here.
- Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
- Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
- Maintenance: What happens during the rest of the software’s life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
Almost all other fields have used something similar to the waterfall method at some point. Compared to other methodologies used today, it is a very simple method. Still, it has many troubling problems, especially those having to do with not being able to go back in the steps.
In my opinion, while it may work for some projects, the waterfall method isn’t really a good one for software development, because it doesn’t take advantage of the benefits of coding. Unlike other fields, coding doesn’t typically have limited resources to code, meaning there can be many version and different version can introduce only small
