Waterfall Development Process Model

The Waterfall is the simplest software development process model, where there are discrete development stages: specification, design, implementation, testing and maintenance. In principle, one stage must be complete before progress to the next stage is possible. The model was originally proposed by Royce, though variations of the model have evolved depending on the nature of activities and the flow of control between them. In this model, a project begins with feasibility analysis.
Upon successfully demonstrating the feasibility of a project, the requirements analysis and project planning begins. The design starts after the requirements analysis is complete, and coding begins after the design is complete. Once the programming is completed, the code is integrated and testing is done. Upon successful completion of testing, the system is installed.
After this, the regular operation and maintenance of the system takes place. The model is shown in Figure wf.01.

Figure wf.01 Waterfall Development Process Model
1. System Feasibility. 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. Obviously, the more we understand the problem, the better we can identify alternative solutions, their costs, and their potential benefits to the user. Therefore, ideally, one should perform as much analysis of the problem as is needed to do a wellfounded feasibility study.
The feasibility study is usually done within limited time bounds and under pressure. Often, its result is an offer to the potential customer. Since we cannot be sure that the offer will be accepted, economic reasons prevent us from investing too many resources into analyzing the problem. In sum, the feasibility study tries to anticipate future scenarios of software development. Its result is a document that should contain at least the following items:

A definition of the problem.
Determination of technical and economic viability.
Alternative solutions and their expected benefits.
Required resources, costs, and delivery dates in each proposed alternative solution.

At the end of this phase, a report called a feasibility study is prepared by a group of software engineers. The client or the customer is also consulted through a questionnaire. This report determines whether the project is feasible or not. After being successful in the feasibility study, the requirement analysis is carried out.

2. Requirement Analysis and Project Planning. This phase exactly tells the requirements and needs of the project. This is a very important and critical phase in the 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 describe the "what" of a system, not the "how". This phase produces a large document and contains a description of what the system will do without describing how it will be done. The resultant document is known as the software requirement specification (SRS) document. An SRS document must contain the following:

Detailed statement of problem.
Possible alternative solution to problem.
Functional requirements of the software system.
Constraints on the software system.

The SRS document must be precise, consistent, and complete. There is no scope for any ambiguity or contradiction in the SRS document. An SRS document may be organized as a problem statement, introduction to the problem, functional requirements of the system, non-functional requirements of the system, behavioral descriptions, and validation criteria.

3. System Design and Detailed 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. Two distinctly different design approaches are available: the traditional design approach and the object-oriented design approach.

Traditional Design Approach. The traditional design approach is currently being used by many software-development houses. Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. This is followed by a structured design activity. During structured design, the results of structured analysis are transformed into the software design.Structured design is undertaken once the structured analysis activity is complete. Structured design consists of two main activities: architectural design (also called high-level design) and detailed design (also called low-level design). High-level design involves decomposing the system into modules, and representing the interfaces and the invocation relationships among the modules. During detailed design, internals of the individual modules are designed in greater detail (e.g., the data structures and algorithms of the modules are designed and documented).
Object-Oriented Design Approach. This is a new paradigm. Various objects in the system are identified. After the identification of objects, the relationships among them are also explored. The OOD approach has several benefits, such as lower development time and effort and better maintainability.

4. Coding. Coding 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 also often subject to company standards, including a precise definition of a test plan, the definition of testing criteria to be followed (e.g., black-box versus white-box, or a mixture of the two), the definition of completion criteria (when to stop testing), and the management of test cases. Debugging is a related activity performed in this phase.
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 qualities other than functional correctness (e.g., performance), although this is often better done at a later stage of coding.

5. Testing and Integration. 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 (can you guess the reason for this?). Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. The objective of system testing is to determine whether the software system performs per the requirements mentioned in the SRS document. This testing is known as system testing. A fully developed software product is system tested. The system testing is done in three phases: Alpha, Beta, and Acceptance Testing.

Alpha Testing is conducted by the software-development team at the developer’s site.
Beta Testing is performed by a group of friendly customers in the presence of the software-development team.
Acceptance Testing is performed by the customers themselves. If the software is successful in acceptance testing, the product is installed at the customer’s site.

6. Intallation 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 define 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 system (corrective maintenance), adapting the application to changes in the environment (adaptive maintenance), and improving, changing, or adding features and qualities to the application (perfective maintenance).
Recall that the cost of maintenance is often more than 60% of the total cost of software and that about 20% of maintenance costs may be attributed to corrective and adaptive maintenance, while over 50% is attributable to perfective maintenance. Based on this breakdown, we observed that evolution is probably a better term than maintenance, although the latter is used more widely.

Waterfall Development Process Model

www.CodeNirvana.in