Introduction
The
Software Development Life Cycle (
SDLC) is a
methodology that, when implemented correctly, can be an excellent
framework for developing
quality software products in a
timely manner. More generally, it is a planned approach that follows a series of steps and development levels.
There is no one set SDLC process;
Methodologies and
interpretations can vary a great deal, based on a variety of factors including the type of software being developed, the resources available, the development environment, even
personal tastes, to some degree. Thus, this
writeup is not intended to be an exhaustive
tome on SDLC -- at least not yet. Instead, it will be an effort to
identify and describe some of the most common methodologies and
terminology.
Common SDLC Models: Steps and Processes
There are generally several different major phases that are
implemented in any particular SDLC process. Again, they vary slightly, based on whether you are using a
Single Version or
Iterative Model.
Single Model Phases:
The Phases for the Iterative Model can vary slightly, but they generally can be tracked to the following:
In the Iterative Model, each Phase is completed a number of times...
iterations.
Single Version vs. Iterative: Model Differences
The difference between Single Version and and Iterative Models primarily involves the number of times that development goes through each of the associated phases.
In the
Single Version Model, all phases are thoroughly planned and tasked through completion, each phase being implemented once; generally, each phase is completed before the next is started -- although there is some variation on that (see "Variations on the Waterfall", below).
On the other hand,
Iterative Models tend to compete small sub-sections or versions of a project, as they pass through each of its associated phases, with planning, reassessment and perhaps revision of the project, during each phase. As each sub-section or version of the project goes through development, different levels of planning, testing, and
risk analysis are implemented, as the entire project nears completion.
Furthermore, both models have their advantages, disadvantages, much of which depends on the application and project scope. Examining the
Single Version Model, while easy to "follow", if any phase is not well thought-out or implemented, it become increasingly expensive (in terms of
man-hours and money) to go back and re-examine a step, the further a team goes along in the process. The ability to supply feedback for a given process can also be difficult, meaning that flaws may not be realised until later. Finally, should requirements suddenly change, much development time can be lost, if the project has to "
back up" to re-implement these changes.
The
Iterative Model takes into account the possibility of requirement or design change, and involves much risk management analysis to try and catch issues when they first become available, and to determine whether or not the project should even continue. It notes that risk cannot entirely be discounted, but that, with careful planning, it can be managed. On the other hand, the extra analysis built-in to this model can feel "
top-heavy" and/or "
bureaucratic", and for good reason - sometimes close to half of the development time is spent in review and analysis. Furthermore, due to the many steps in this model, delays in one phase of a given
iteration can end up being serious in nature, sometimes jeopardizing the entire project!
Common SDLC Model Implementations
Single Version
- "Big Ball of Mud" Model: This is not really a Single Version Model, per say... really it's here more for comparison. This model is usually just as the name describes. No plan generally means no quality, little maintainable or reusable code, lots of bureaucracy, duplicate effort, spaghetti code, and running around in circles. Yuck.
- Waterfall Model: The Waterfall Model is pretty much your orthodox "Single Model" implementaion. It follows the phases listed above, one step at a time, until each phase is completed. That is, of course, unless "they aren't"...
- Variations on the Waterfall: These are both slight variations on the Waterfall. They follow the general flow of the standard "Single Model" process tree, but with some slight differences.
- Overlapping Processes/Feedback Waterfall - In this case, a phase is not always 100% complete before the next phase is started. For example, coding can sometimes take place when the architecture is still being fleshed out; Likewise, with regular software drops to QA, testing can be completed and issues can be found, before the coding is ever complete.
- Overlapping Project/Phase Waterfall - Likewise, in this situation, new instances of the Waterfall Method process are spawned, during the completion of another. This can be done to "piggyback" technologies, or perhaps simply because an active SDLC process is only one of many in a given project.
Validation Model: The Validation model is a slight departure from the steps listed for the Single Model implementation. In this type, there are several major processes in the timeframe, each of which has an adjoining validation process...
- During the Requirements Phase, there is an associated Acceptance Test Phase;
- During the Design Phase. there is an associated Integration Test Phase, and
- During the Coding Phase, there is an associated Unit Test Phase.
- Following the Coding Phase, there is Release or Implementation, which is then followed by more testing!
Iterative
- Spiral Model: This type starts with Risk Analysis, often followed by prototype models of the project. Following that, real development begins, followed by requirement validation. Next, the development plan is put into place, followed by more review and risk analysis. At this point, development is ramped up, followed by more in-depth validation... and the process repeats, for the most part, until completion.
- Fountain Model: This implementation attempts to streamline the sometimes-laborious Iterative Model. It actually follows the Waterfall Model fairly closely; however, said "Waterfall" itself is implemented several times, each being an iteration that addresses one particular subset of functionality. It is during the Validation phase that re-evaluation and analysis occurs. This allows more resources to be added at a later iteration, if necessary
Miscellaneous SDLC Models
A few words on a couple of other models.
- Rapid Application Development Model: The RAD is used in environments where customised products need to be shipped quickly and efficiently. To do this, Design, Construction and Test phases are reduced and/or eliminated. Obviously, this can be risky; It's generally used when resources such as time, and more likely developers, come at a premium.
- "Extreme Programming": This a relatively new model; It involves including everyone on a team in all the processes - Concept, Design, Construction, Validation, etc. Generally, team members work together during the early stages of the project, and then work in pairs during the programming and testing phases. Doing so is said to ensure good coding practises and guarantee code review.
- Others: There are a number of other methods, such as the "Sawtooth" and the "Rational Unified Process", but for the most part, they are variations on the ones listed above.
Conclusion
Implementation of an SDLC Model can greatly improve a resulting software product, not to mention saving a group, team, or
corporation a lot of time, resources and
headaches down the road. Not all Models are right for any given project, so the model must be chosen carefully, based on the project's scope. In the end, however, any sort of
rational, well thought-out process will net a better result, with less
hassle.
Works Referenced:
http://www.cs.hmc.edu/courses/2002/spring/cs121/slides03.6.pdf
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?software+development+life+cycle
http://www.csd.uwo.ca/faculty/beau/PM/CS377-Development.html
http://www.xprogramming.com/xpmag/whatisxp.htm
If you have any comments, changes, or recommendations to make, I'd appreciate all feedback.