software life cycle model

[ganeshbala]

Software life cycle model

A software life cycle model depicts the significant phases or activities of a software project from conception until the product is retired. It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables. Typically, a life cycle model addresses the phases of a software project: requirements phase, design phase, implementation, integration, testing, operations and maintenance. Much of the motivation behind utilizing a life cycle model is to provide structure to avoid the problems of the "undisciplined hacker" or corporate IT bureaucrat (which is probably ten times dangerous then undisciplined hacker). As always, it's a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.

Software life cycle models describe the interrelationships between software development phases. The common life cycle models are:

* Waterfall model. The least flexible of the life cycle models. Still it is well suited to projects which have a well defined architecture and established user interface and performance requirements. The waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development (Those are the ones most likely to be outsourced overseas ;-)

* Extreme programming(XP) is the latest incarnation of Waterfall model and is the most recent software fad. Most postulates of Extreme programming are pure fantasy. It has been well known for a long time that big bang or waterfall models don't work well on projects with complex or shifting requirements. The same is true for XP. Too many shops implement XP as an excuse for not understanding the user requirements. XP try improve classic waterfall model by trying to start coding as early as possible but without creating a full-fledged prototype as the first stage. In this sense it can be considered to be variant of evolutionary prototyping (see below). Often catch phase "Emergent design" is used instead of evolutionary prototyping.

It also introduces a very questionable idea of pair programming as an attempt to improve extremely poor communication between developers typical for large projects. While communication in large projects is really critical and attempts to improve it usually pay well, "pair programming" is a questionable strategy. There are two main problems here:
o In a way it can be classified as a hidden attempt to create one good programmer out of two mediocre. But in reality it is creating one mediocre programmer from two or one good. No senior developer is going to put up with some jerk sitting on his lap asking questions about every line. It just prevents the level of concentration needed for high quality coding. Microsoft's idea of having a tester for each programmer is more realistic: one developer writes tests while the other one develops the actual code to be tested. This forces each of them to communicate and because tester has different priorities then developer such communication brings the developer a new and different perspective on his code, which really improves quality. This combination of different perspectives is a really neat idea as you can see from the stream of Microsoft Office products and operating systems (look for example on the quality of components in Office 2003, especially FrontPage and Excel).
o You can also think about pair programming as a perverse way to enforce code reviews (if code reviews are good, do them all the time and for a change remove computer from one guy, so that he can concentrate on reviewed the code written by a lucky one who has the computer ;-).

* Throwaway prototyping model. It was advocated by Brooks. Useful in "proof of concept" or situations where requirements and user's needs are unclear or poorly specified. The approach is to construct a quick and dirty partial implementation of the system during or before the requirements phase. Typical implementation language is scripting language and Unix shell (due to availability huge amount of components that can be used for construction of the prototype).

* Spiral model. The spiral model is a variant of "dialectical spiral" and as such provides useful insights into the life cycle of the system. Can be considered as a generalization of the prototyping model. That why it is usually implemented as a variant of prototyping model with the first iteration being a prototype.

* Evolutionary prototyping model. This is kind of mix of Waterfall model and prototyping. Presuppose gradual refinement of the prototype until a usable product emerge. Might be suitable in projects where the main problem is user interface requirements, but internal architecture is relatively well established and static. Can help to cope with organizational sclerosis. One variant involves so called "binary" software implementation model using a scripting language plus statically typed language. In this case system first is coded in a scripting language and then gradually critical components are rewritten in the lower language. This new development paradigm was pioneered by Ousterhout with TCL but also possible with Python, various scripting language that use JVM (Jython +Java, etc) or Microsoft .NET framework (for example Iron Python + C++). Lately a perverse form of evolutionary prototyping was advocated as the optimal OSS development model (see below).

* OSS development model is the latest variant of evolutionary prototype model. See also OSS development model

The "waterfall model" was probably the first published model and as a specific model for military it was not as naive as some proponents of other models suggest. The model was developed to help cope with the increasing complexity of aerospace products. The waterfall model followed a documentation driven paradigm.

Prototyping model was probably the first realistic of early models because many aspects of the syst4m are unclear until a working prototype is developed. It was advocated by Brooks in early 60th.

A better model, the "spiral model" was suggested by Boehm in 1985. The spiral model is a variant of "dialectical spiral" and as such provides useful insights into the life cycle of the system. But it also presuppose unlimited resources for the project. No organization can perform more then a couple iterations during the initial development of the system. the first iteration is usually called prototype.

Prototype based development requires more talented managers and good planning while waterfall model works (or does not work) with bad or stupid managers works just fine as the success in this model is more determined by the nature of the task in hand then any organizational circumstances. Like always humans are flexible and programmer in waterfall model can use guerrilla methods of enforcing a sound architecture as manager is actually a hostage of the model and cannot afford to look back and re-implement anything substantial.

Because the life cycle steps are described in very general terms, the models are adaptable and their implementation details will vary among different organizations. The spiral model is the most general. Most life cycle models can in fact be derived as special instances of the spiral model. Organizations may mix and match different life cycle models to develop a model more tailored to their products and capabilities. there is nothing wrong about using waterfall model for some components of the complex project that are relatively well understood and strait forward. But mixing and matching definitely needs a certain level of software management talent.