Posted on

Waterfall software development process

Brief History of Waterfall software development process

The Waterfall software development process was introduced by computer scientist Winston Royce in 1970. Royce first wrote about Waterfall in an article called, Managing the Development of Large Software Systems. Although Royce didn’t directly refer to his model as Waterfall, the article was actually about a process that was flawed for software development. Royce’s model allowed for more repetition between stages of the model, which Waterfall doesn’t allow you to do.
Royce’s actual model was more iterative in how it worked and allowed more room to maneuver between stages. We will discuss a more iterative way of working when we discuss Agile later on in the blog. Although Royce didn’t refer to his model as the Waterfall model directly, he is credited with the first description of what we refer to as the Waterfall model.
Royce’s original article consists of the following stages, which we’ll go into more detail on in a moment. Those stages are:
 Requirements Specification
 Detail Design
 Construction, where developers start crafting code
 Integration, where all the code is brought together and compiled into a run-able solution
 Testing and Debugging, where your testing will try to find defects that the developers
will fix
 Installation, where you deploy your system so that it can be used by your end users.
 Maintenance, where you fix any issues that are raised by the users.

How waterfall Process Works

The Waterfall process is split into separate stages, where the outcome of one stage is the input for the next stage. In the first stage, Requirements Specification, all possible requirements for the system to be developed are captured and documented in a requirement specification document. This document normally requires sign-off by key project and business stakeholders.
This part of the Waterfall model is typically organized by the business analysts, but depending on the size of your project, team, or organization, other members of your development team may be involved. This stage is about teasing out the requirements of the system from your stakeholders. This would include the required functionality, documentation of business rules and processes, and capturing any regulatory and compliance requirements that will affect the overall system


The next stage is System Design. The requirement specifications from the first stage are inspected, and the system design is put together. This design helps in specifying the system design requirements, and also helps with designing the overall system’s architecture. It is this stage where architects, solution designers, and developers will work together to decide how the overall system will be constructed. This is from a code perspective, and also a technology
choice and infrastructure perspective.

The next phase is Implementation. This is the phase where the developers take the design and start producing code to turn the design into a reality. The developers may also write automated unit and integration tests at this stage.
After the Implementation phase, we have the Integration and Testing phase. This is where all the deliverables from the implementation phase are brought together and tested as a whole.
The testing team should be working to a defined test plan. Once the system has been tested and signed off by the test team, the next stage is deploying the solution to your end users. Your end users may be internal customers within your organization, or customers.

Once the solution has been deployed, it goes into the Maintenance phase, where any issues that are reported will need fixing and re-deploying. This would generally be in the form of release patch fixes to your system. You may also perform small enhancements to the system at this phase. If an enhancement is quite large in scope, then you might start the Waterfall process again and start capturing further requirements.
All of these phases are cascaded, where progress is seen as flowing steadily downwards like a waterfall. The next phase is started only after a pre-defined set of goals are achieved from the previous phase. In this model, the phases do not overlap.