Software application development ways
Every software development methodology has more or less its own approach to software development. There is a set of more general approaches, which are developed into several specific methodologies. These approaches are:
Waterfall: linear framework type.
Prototyping: iterative framework type
Incremental: combination of linear and iterative framework type
Spiral: combination linear and iterative framework type
Rapid Application Development (RAD): Iterative Framework Type
Waterfall model
This is classical model of Software application development The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. The first formal description of the waterfall model is often cited to be an article published by Winston W. Royce in 1970 although Royce did not use the term "waterfall" in this article.
Basic principles of the waterfall model are:
· Project is divided into sequential phases, with some overlap acceptable between phases.
· Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.
· Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase.
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.
Disadvantages:
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-oriented projects.
Poor model for long and ongoing projects.
Poor model where requirements are at a moderate to high risk of changing.
|