SDLC Compareing the options, choosing a model

Comparison of Lifecycle Model Features

The table belowdepicts the various features of the lifecycle models to help you compare and select a model to use on future projects. In selecting a lifecycle approach or when creating your own, you will need to do the following:

Characterize your project, and see how well it matches one or more of the lifecycles discussed.

• For the lifecycle models that are most appropriate, focus on the shortcomings of the lifecycle and determine whether those are serious enough to rule out use of that model.
• As much as possible (it is not possible to get everyone to agree in all cases), gain the concurrence of your development team on which model to use.
• Get commitment from the leadership team—if problems occur, the surest way for the project to fail is to have the leadership of the company panic and abandon the process.
• Gain concurrence or at least tacit approval from your stakeholders. Identify what, if anything, must be altered in the best candidate lifecycle for Fit to work on your new project.
• Be innovative.
• Be flexible during the project and ready to alter the lifecycle depending on the circumstances.
• Take into account the level of experience and maturity of your software development team.

Lifecycle Model	Pros	Cons	Most Applicable To
Waterfall	Controllable results; consistent with engineering practice	Forestalls delivering results until late in the development cycle	All project sizes
Slam dunk	Gets something going right away	Not truly a lifecycle; results generally unsatisfactory	Not recommended
Spiral	Reflects reality of software development in the large; reports of use quite positive	Complex and intricate; requires extensive management infrastructure	Major multimillion-dollar efforts; ill suited to small efforts
Evolutionary	Begin controlled, working software early on; longer testing period than otherwise possible	Nothing stable for long; high change level without much maturity occurring in software	Small to medium projects
Stage gate	Practically guarantees adherence to some discipline	Requires an infrastructure, maturity, and process some firms might not have	Medium to large
Rapid prototyping	Get something going early on; lots of review time	Often results in runaway coding	Small to large
Agile-programming	Puts discipline into the prototyping approach	Requires a mature, disciplined team; strict adherence to process	Small to medium
Synchronization and stabilization	Controls changes; long testing cycle to improve quality	Based on premise that quality can be tested into a system	Small to very large

The message here is that success in managing projects results from many factors. The lifecycle is only one of them, but a necessary one. If you have had success with one lifecycle more than with another, before adopting it on your next project, ask yourself whether those previous experiences with this lifecycle were similar enough to the new project to make this choice a good one. If you are new to software project management and have not had the experience of employing one lifecycle model or another, try going with what you understand and what you and your team feel comfortable with, bearing in mind some that alterations might be necessary.

It is tempting to think that because any chosen lifecycle will have to be altered anyway, it is a waste of time to adopt such a model in the first place. The problem with such a position is that both the customer and the development team need to know what lies ahead, commit to achieving the milestones laid out before them, and apply a sanity check to what is being proposed. Without a lifecycle plan, you are asking for a greater leap of faith than either of these groups can tolerate.