Classical Waterfall Model

The classical Waterfall Model was the first Process Model. It is also known as a linear-sequential life cycle model. It is very simple to understand and use.

It is a sequential lifecycle that is simple to understand and use each phase has to be completed finished before another start which means no overlapping is allowed.

It divides the software life cycle into the six phases.

1. Feasibility Study

The main aim of the feasibility study is to determine whether it would be technically and financially feasible to develop the product. The feasibility study activity involves analysis of the problem and collection of all relevant information relating to the product.

The collected data is analyzed to arrive at the following:

1. Only the important requirements of the customer are captured and the details of the requirement are ignored.
2. All the different ways in which the problem can be solved are identified.
3. Different solution strategies are analyzed to examine their benefits and shortcomings. 

2. Requirement Analysis and Specification

The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely requirements gathering and analysis, and requirements specification as follows:

• Requirements Gathering and Analysis: The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. Once the requirements have been gathered, the analysis activity is taken up. The goal of the requirement analysis is to weed out the incompleteness and inconsistencies in these requirements.
  
  
• Requirement Specification: The customer requirements identified during the requirements gathering and analysis activity are organized into a software requirement specification (SRS) document. The important components of this document are functional requirements, non-functional requirements, and the goals of implementation.

3. Design

The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase, the software architecture is derived from the SRS document.

4. Coding and Unit Testing

The purpose of coding and unit testing phase of software development is to translate the software design into the source code.The coding phase is also sometimes called the implementation phase.

The end-product of this phase is a set of program modules that been individually tested. After coding is complete, each module is unit-tested to determine the correct working of all individual modules.

5. Integration and Test Stage

Once the coding of application is done, it is then integrated with all other modules with different functionality. During each step of integration, earlier planned modules are incorporated into the parts included the structure of the software and then the entire system is tested.

• α Testing: In this testing, the software is tested by the development team, i.e., the developers.
• β Testing: In this testing, the software is tested by friendly customers and other target users who will use the beta version of your product.

6. Maintenance Phase

Another important phase of this model is the maintenance model. Updating the product, patching any bugs and errors and developing other essential components as per feedback to make this full software is done in this stage.

Advantages of Classical Waterfall Model

• Classical waterfall model is easy to understand and simple to use.
• In the waterfall model, only one phase is executed at a time or phases cannot overlap.
• In this model, each phase is clearly defined.
• Waterfall model works best for a small project, where requirements are clearly defined.
• Each Process, actions and results are well documented.

Disadvantages of Classical Waterfall Model

• The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the engineers during any of the life cycle phases. However, in practical development environments, the engineers do commit a large number of errors in almost every phase of the life cycle.
• It becomes tough to go back to the phase. For example, if the application has now shifted to the coding phase, and there is a change in requirement, It becomes tough to go back and change it.
• This model cannot accept the changes in requirements during development.