A development process model specifies some activities that, according to the model, should be performed, and the order in which they should be performed. As stated earlier, for cost, quality, and project management reasons, development processes are generally phased.
As the development process specifies the major development and quality assurances activities that need to be performed in the project, the development process really forms the core of the software process. Due to the importance of development process, various models have been proposed.
Waterfall Model:
It states that the phases are organized in a linear manner. There are variations of the waterfall model depending on the nature of activities and the flow of control between them. In a typical model, a project begins with feasibility analysis. On successfully demonstrating the feasibility of a project, the requirement 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 installed.
After this, the regular operation and maintenance of the system takes place. With the waterfall model, the sequence of activities performed in a software development project is: requirement analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. There are two basic assumptions for justifying the linear ordering of phases in the manner proposed by the waterfall mode. The various phases in this model are:
1. System Feasibility
2. Requirement Analysis & Project Planning
3. System Design
4. Detailed Design
5. Coding
6. Testing & Integration
7. Installation
8. Operations & maintenance
The various products produced in Waterfall model are:
- Requirements document
- Project plan
- System Design Document
- Detailed Design Document
- Test plan & test reports
- Final code
- Software manuals
- Review reports
Assumptions in Waterfall Model:
For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway. Any different ordering of the phases will result in a less successful software product.
Limitations:
The waterfall model assumes that the requirements of a system can be frozen (i.e. base lined) before the design begins. This is possible for systems designed to automate an existing manual system. But for new systems, determining the requirements is difficult, as the user does not even know the requirements. Hence, having unchanging requirements is unrealistic for such projects.
1. Freezing the requirements usually requires choosing the hardware (because it forms a part of the requirements specification). A large project might take a few years to complete. It the hardware is selected early, it is likely that the final software will use a hardware technology on the verge of becoming obsolete.
2. The waterfall model stipulates that the requirements be completely specified before the rest of the development can proceed. In some situations it might be desirable to first develop a part of the system completely and then later enhance the system in phases.
3. It is a document driven process that requires formal documents at the end of each phase. This approach tends to make the process documentation heavy and is not suitable for many applications, particularly interactive applications, where developing elaborate documentation of the user interfaces is not feasible.
Dinesh Thakur holds an B.C.A, MCDBA, MCSD certifications. Dinesh authors the hugely popular