Thursday, January 15, 2009

Waterfall Lifecycle Model/ Linear Sequential/ Classic Life Cycle Model





Water fall / Linear Sequential /Classic Life Cycle Model

The "waterfall model", documented in 1970 by Royce was the first publicly documented life cycle model. The model was developed to help with the increasing complexity of aerospace products.

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.

The least flexible and most obsolete of the life cycle models. Well suited to projects that has low risk in the areas of user interface and performance requirements, but high risk in budget and schedule predictability and control.

Advantages
§ Simple and easy to use.
§ Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
§ Phases are processed and completed one at a time.
§ Works well for smaller projects where requirements are very well understood/stable.

Disadvantages
§ It’s difficult to respond to changing customer requirements.
§ Adjusting scope during the life cycle can kill a project
§ No working software is produced until late during the life cycle.
§ High amounts of risk and uncertainty.
§ Poor model for complex and object-orented projects.
§ Poor model for long run and ongoing projects.
Waterfall Model

Strengths:
•Emphasizes completion of one phase before moving on
•Emphasises early planning, customer input, and design
•Emphasises testing as an integral part of the life cycle •Provides quality gates at each life cycle phase

Weakness:
•Depends on capturing and freezing requirements early in the life cycle
•Depends on separating requirements from design
•Feedback is only from testing phase to any previous stage
•Not feasible in some organizations
•Emphasises products rather than processes

No comments:

Post a Comment