Water Fall Model :
If we see the actual model of the water fall model in figure, because of the cascade from one phase to another this model is known as the water fall model of software life cycle or linear sequential model.
As the figure shows, the process is structured as a cascade of phases, where the output of one phase constitutes the input of the next one. Each phase, in turn, is structured as set of activities that might be executed by different people concurrently.
Figure : Waterfall Model
The phases in the figure are as follows :
- Feasibility study.
- Requirements analysis and specification.
- Design and specification.
- Coding and Module testing.
- Integration and system testing.
Feasibility Study : The first phase is known as feasibility study. The purpose of this phase is to produce a feasibility study document that evaluates the costs and benefits of the proposed application.
To do so, it is first necessary to analyze the problem, at least at a global level. The feasibility study is usually done within limited time bounds and under pressure.
In sum, the feasibility study tries to anticipate future scenarios of software development. Its result is a document that should contain at least following items:
- A definition of the problem.
- Determination of technical economic viability
- Alternative solutions and their expected benefits
- Required resources, costs, and delivery dates in each proposed alternative solutions.
Requirement Analysis and Specification : This phase exactly tells the requirement and needs of the project. This is very important and critical phase in waterfall model. The purpose of a requirements analysis is to identify the qualities required of the application, in terms of functionality, performance, ease of use, portability, and so on.
The requirements describes the “what” of a system, not the “how”. This phase produces a large document, contains a description of what the system will do without describing how it will be done. The resultant document is known as software Requirement Specification (SRS) document.
An SRS document must contain following:
- Detailed statement of problem
- Possible alternative solution to problem
- Functional requirement of the software system
- Constraints on the software system
Design and Specification: The goal of the design phase is to transform the requirements in the SRS document into a structure that is suitable for implementation in some programming language.
Two distinctly different design approaches are available: the traditional design approach and the object-oriented approach.
Coding and Module Testing: Coding and module testing is the phase in which we actually write programs using a programming language. It was the only recognized development phase in early development processes, but it is just one of several phases in a waterfall process. The output of this phase is an implemented and tested collection of modules.
Module testing is the main quality control activity that is carried out in this phase. Other such activities may include code inspections to check adherence to coding standards and, more generally, to check for a disciplined programming style, as well as checking of software generally, to check for a disciplined programming style, as well as checking of software qualities other than functional correctness, performance although this is often better done at a later stage of coding.
Integration and System Testing: During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps.
The objective of system testing is to determine whether the software system performs as per the requirements mentioned in SRS documents. This testing is known as system testing. A fully developed software product is system tested. The system testing is done in three phases called Alpha, Beta and Acceptance Testing.
Delivery and Maintenance: The delivery of software is often done in two stages. In the first stage, the application is distributed among a selected group of customers prior to its official release. The purpose of this procedure is to perform a kind of controlled experiment to determine, on the basis of feedback from users, whether any changes are necessary prior to the official release. In the second stage, the product is distributed to the customers.
We defined maintenance as the set of activities that are performed after the system is delivered to the customer. Basically, maintenance consists of correcting any remaining errors in the systems (corrective maintenance), adapting the application to changes in the environment (adaptive maintenance), and improving changing, or adding features and qualities to the applications (perfective maintenance).
Merits of Waterfall Model:
1 It is a linear model.
2 It is segmental model.
3 It is systematic and sequential.
4 It is simple one.
5 It has proper documentations.
Demerits of Waterfall Model:
1 It is difficult to define all requirements at the beginning of a project.
2 This model is not suitable for accommodating any change.
3 A working version of the system is not seen until late in the project’s life.
4 It does not scale up well to large project.
5 It involves heavy documentation.
6 We cannot go in the backward direction while SDLC performs.
7 There is no sample model for clearly in realization the customers’ needs.
8 There is no risk analysis.
9 If there is any mistake or error in any phase then we cannot make good software.
10 It is a document driven process that requires formal documents at the end of the each phase.