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.
Classical waterfall model is the earliest, best known and most commonly used methodology. 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.
Table of Contents
- 1 Classical Waterfall Model
- 2 Six Phases of Classical Waterfall Model
- 3 Application of Waterfall Model
- 4 Advantages of Waterfall Model
- 5 Disadvantages of Waterfall Model
Six Phases of Classical Waterfall Model
The waterfall model is intuitively the most obvious way to develop software. It divides the software life cycle into the six phases, as shown in Figure 1.
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:
- An abstract problem definition: Only the important requirements of the customer are captured and the details of the requirement are ignored.
- Formulation of the different strategies for solving the problem: All the different ways in which the problem can be solved are identified.
- Evaluation of the different solution strategies: Different solution strategies are analyzed to examine their benefits and shortcomings. This analysis usually requires making approximate estimates of the resources required, cost of development, and development time required for each of the alternative solutions.
Once the best solution is identified, all later phases of development are carried out to as per this solution. In other words, we can say that during the feasibility study, very high-level decisions regarding the exact solution strategy to be adopted are made. At feasibility study stage, it may also be determined that none of the solution is feasible due to high cost, resource constraints, or some technical reasons.
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.
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. There are two design approaches being used at present: traditional design approach and object-oriented design approach.
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 since the design is implemented into a workable solution in this phase. Each component of design is implemented as a program module. 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 System Testing
During this phase, the different modules are integrated in a planned manner. The plan specifies the order in which modules are combined to realize the full system. Integration of various modules are normally carried out incrementally over a number of steps. After each integration step, the partially integrated system is tested. Finally, after all modules have been successfully integrated and tested, system is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document.
Alpha testing: is the type of testing which is performed by the developer’s.
Beta testing: is the type of testing which is performed by a real users and friendly set of customers.
Maintenance involves monitoring and improving system performance, enhancing system services, and upgrading to newer versions. Maintenance of a typical software product requires much more effort than the effort necessary to develop the product itself. The past studies indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in 40:60 ratio.
Application of Waterfall Model
- Limited amount of ambiguous or unconfirmed requirements.
- A software that needs well documented documentations.
- Use of mature technology and not dynamic.
- Management can provide enough resources and experts to pick up the role at its phase.
Advantages of 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.
- It has clearly understood milestones.
- Each Process, actions and results are well documented.
Disadvantages of Waterfall Model
Below are the list of Shortcomings of Waterfall Model:
- Idealistic 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.
- Waterfall model assumes that all requirements are defined correctly at the beginning of the project, and on the basis of that, the development work starts. However, that is rarely the case in real life projects. The customer keeps changing the requirements as their development proceeds. Thus, it becomes difficult to accommodate later requirements change request made by the customer.
- Phases are sequential: Classical waterfall model assumes, that all the phases are sequential. However, that is rarely the case.
For example, for efficient utilization of manpower in a company, the members assigned the testing work may start their work immediately after the requirements specification to design the system test cases. Consequently, it is safe to say that in a practical software development scenario, the different phases might overlap, rather than having a precise point in time at which one phase stops and the other starts.