There are many approaches to developing software, aptly defined and designed, which are employed during the process. These approaches are also referred to as 'Software Development Process Models'. Each process model follows a particular life cycle in order to ensure success in the process of software development.

One such approach used in software development is 'The Waterfall Model'. The waterfall approach was first a process model, to be introduced and followed widely in software engineering to ensure success of the project. In the waterfall approach, the whole process of software development is divided into separate phases. These phases are:
  1. Requirement Specifications Phase
  2. Software Design Phase
  3. Implementation Phase
  4. Testing and Maintenance Phase
The phases are aligned in a cascading manner, so that the second phase is started as and when a defined set of goals are achieved for first phase and it is signed off, and hence the name 'waterfall'.
Stages of the Waterfall Model Explained
Requirement Analysis and Definition
All possible requirements of the system to be developed are stated in this phase. Requirements are a set of functions and constraints that the end user expects from the system. The requirements are gathered from the end user, and are analyzed for their validity and the possibility of incorporating them. Finally, a requirement specification document is created which serves the purpose of a guideline for the next phase of the model.
System and Software Design
Before starting the actual coding phase, it is highly important to understand the requirements of the end user and also have an idea of how the end product should look like. The requirement specifications from the first phase are studied here, and a system design is prepared. The design helps in specifying hardware and system requirements, and also helps in defining the overall system architecture. The system design specifications serve as an input for the next phase of the model.
Installation and Deployment
The software is now applied by the customer to his/her own system(s). What the customer needs to take care of is his own system complying with the minimum system requirements of the software. He also needs to take care of any system configurations and reconfigurations on his side of the deal. Once the software is properly installed, he will begin communication with the dealers on a need-to-know basis, and help report any bugs that occur.
Implementation and Unit Testing
On receiving system design documents, the work is divided in modules/units and actual coding starts. The system is first elaborated into small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as unit testing. Unit testing mainly verifies if the modules/units meet their specifications.
Operations & Maintenance
This phase of the model is virtually never-ending. Generally, problems with the system (which are not found during the development cycle) come up after its practical use starts, so the issues related to the system are solved after its deployment. Not all the problems come into picture directly, but they arise from time to time and need to be solved; hence this process is referred to as maintenance, even though its still pretty much in the testing phase.
  • There is clear compartmentalization of work and control. That makes it easier to set a schedule for the tasks to be completed within a specified period.
  • Only after the work for a particular phase is over, does the other phase start, due to which there is no overlapping of phases, or the product does not have to go through different iterative steps.
  • This model is much easier to envision. Since the processes are all carried out in a linear trickle-down manner, the cost of resources is reduced to a large extent, which in turn helps in reducing the cost of the project considerably.
  • Lastly, the documentation and testing happens at the end of each phase, which helps in maintaining the quality of the project.
  • Not all requirements are received at once, the requirements from a customer may keep getting added to the list even after the end of the 'requirement gathering and analysis' phase. This may negatively affect the system development process.
  • The problems with one phase are never solved completely during the same phase. In fact, many problems arise after a phase is completed. This results in a badly structured system, as not all the problems are solved immediately.
  • The project is not always partitioned in a flexible way.
  • As the requirements of the customer are added to the list, not all the requirements are fulfilled, this results in development of an almost unusable system. These requirements are then met in the newer version of the system, which increases the development cost.
Although there are a few disadvantages of the model, it continues to be the most widely-used approach in the industry. This can be attributed to the fact that the advantages of this model outweigh its disadvantages in most types of projects. And lastly, even if the team does not have a lot of experience, this model still perfectly serves the purpose.