Problems with waterfall development model

ashish — Fri, 03 Aug 2007 15:40:03 +0000

Other software development models were developed (such as the Agile model) because it was felt that the sequential process defined in the Waterfall model was argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product’s lifecycle in a complete form before the next step is started. As an example, clients are almost never confident of their requirements being in a final form before they see a working prototype and can comment upon it; they may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested into preparing a comprehensive design. In addition, designers cannot anticipate technical difficulties with their design, and typically these difficulties become clear during development, at which time it is expensive to change design.
Summary of problems:
- Client requirements are never complete at the time of requirement specification. They change, and it is realistic to anticipate that such change would occur
- Each phase needs information from the following phases to be fully complete. For example, requirements phase needs information from design phase as to what is feasible; design phase needs feedback from coding phase as to which design has the best chances of succeeding
- Builds in a waterfall model are typically available much later, but there is a need to have builds much earlier so as to build confidence
- Each phase has people who are specialised for that phase. It is a hard task to get people specialized for each phase, as well as make sure that they are connecting with each other for proper information transfer

Waterfall Development Model

ashish — Fri, 03 Aug 2007 15:39:06 +0000

What is the Waterfall method?
A classic SDLC model, with a linear and sequential method that has goals for each development phase. The waterfall model simplifies task scheduling, because there are no iterative or overlapping steps. One drawback of the waterfall model is that it does not allow for much revision.
This model has the following activities.
1. System/Information Engineering and Modeling
2. Software Requirements Analysis
3. Systems Analysis and Design
4. Code Generation / Implementation
5. Testing
6. Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes “requirements specification” — they set in stone the requirements of the software.When the requirements are fully completed, one proceeds to design. The software in question is designed and a “blueprint” is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated.
After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs.
Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them.

Learn Software Development » Waterfall

Problems with waterfall development model

Waterfall Development Model