The lifecycle model defines the phases of the development process, the order they occur in, the degree to which they may overlap, and the entry and exit criteria for each phase.
I. Water-Fall Model
The Waterfall life cycle model was introduced by Winston Royce in 1970 and is currently the most commonly used model for software development. It emphasizes that software is developed in sequential phases (e.g., analysis, design, code, etc.) with established milestones, documents, and reviews at the end of each phase. There is no overlap of each phases (i.e., design can't begin until analysis is completed) and the entire scope of the project is addressed at each phase. The waterfall lifecycle is often criticized as being a "one way street, with no turning back" where once analysis is complete, design can begin, but once design has begun, analysis cannot be re-entered - the requirements are frozen.
"One phase starts when the previous phase completes for all modules/units. Since the previous phase's end determine the start of the next phase, a small delay in one phase may propagate till the end. Such small delay in each phase may cause bigger delay or time-over-runs on the project"
- Waterfall Model Assumption
The requirements are knowable in advance of implementation.
The requirements have no unresolved, high-risk implications. e.g., risks due to COTS choices, cost, schedule, performance, safety, security, and user interface organizational impacts.
The nature of the requirements is compatible with all the key system stakeholders‘ expectations. e.g. users, customer, developers, maintainers, investors
The right architecture for implementing the requirements is well understood.
There is enough calendar time to proceed sequentially.
- Advantages of Waterfall Model
Conversion of existing projects in to new projects.
For proven platforms and technologies, it works fine.
Suitable for short duration projects.
The waterfall model is effective when there is no change in the requirements, and the requirements are fully known.
If there is no Rework, this model builds a high quality product.
The stages are clear cut
All R&D done before coding starts, implies better quality program design
- Disadvantages of Waterfall Model
Testing is postponed to later stage till coding completes.
Not suitable for large projects
It assumes uniform and orderly sequence of steps.
Risk in certain project where technology itself is a risk.
Correction at the end of phase need correction to the previous phase, so rework is more.
Real projects rarely flow in a sequential process.
It is difficult to define all requirements at the beginning of a project.
The model has problems adapting to change.
A working version of the system is not seen until late in the project's life.
Errors are discovering later (repairing problem further along the lifecycle becomes progressively more expensive).
Maintenance cost can be as much as 70% of system costs.
II. V Model
The main messages of the V-model are: “Start testing as early as possible to find defects as early as possible."
Already during the early development stages, it is possible to start your testing activities, because the sooner an error is corrected, the cheaper it is. If an error is transferred to a next stage, the cost to solve it rises exponentially. To avoid this, we must verify (test) each step taken in the development process of the application.
E.g. based on user requirements, set-up in the beginning of the development stage, the test team can immediately derive the test requirements (The test team has to be independent from the development team to avoid making the same thinking mistake again!). Then these test requirements can be used to verify whether or not the user requirements contain any errors. (Mostly logical errors: gaps in the user requirements, or wrong assumptions...) A programmer can do a perfect job in programming, but if the analysis he received contains an error, all his work may become useless. So it is very important that an error is not transferred to the next stage.
III. Spiral Model
The spiral lifecycle is similar to the Incremental approach but takes risk analysis into account. Each phase of the project is broken into planning, risk analysis, development, and evaluation steps. As each component or phase is begun risk or alternative analysis is carried out to determine the best way to deal with the current phase. In this way each phase is developed in a way that makes the risk acceptable (assuming the risk analysis is valid) to the team.
As with the incremental approach the broader picture must be understood before the development of each phase can be begun; there is no use trying to hit an ill-defined target.
The spiral life cycle requires that risk analysis be done. Other than in a broad way (i.e. should we even begin this project) I have rarely seen risk analysis used in project development. The use of this approach would require the greatest organizational change of all of the lifecycle processes. If the organization could be made to see the benefits of this approach it could be adopted. As with any change however the inclusion of new and locally unproven approaches can be viewed as a risk in itself and difficult to introduce.
IV. Rapid Application Development (RAD)
RAD refers to a development life cycle designed to give much faster development and higher quality systems than the traditional life cycle. It is designed to take advantage of powerful development software like CASE tools, prototyping tools and code generators. The key objectives of RAD are: High Speed, High Quality and Low Cost. RAD is a people-centered and incremental development approach.
Active user involvement, as well as collaboration and co-operation between all stakeholders are imperative. Testing is integrated throughout the development life cycle so that the system is tested and reviewed by both developers and users incrementally.
- Advantages of RAD
With conventional methods, there is a long delay before the customer gets to see any results. With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use. With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered.
- Why use RAD?
Bad Reasons for Using RAD
To prevent cost overruns (RAD needs a team already disciplined in cost management) To prevent runaway schedules (RAD needs a team already disciplined in time management).
Good Reasons for using RAD
To converge early toward a design acceptable to the customer and feasible for the developers To limit a project's exposure to the forces of change To save development time, possibly at the expense of economy or product quality.
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
No comments:
Post a Comment