Introduction

This article is an attempt to encourage developers to step out and think about the way they develop and deliver software. It’s very common to assume that once you have the software specs to hand, you can go ahead and develop, test, and deliver the software, to the best of your abilities. But most projects hit setbacks – and some of these may have been avoided if you’d thought about the project lifecycle before jumping in and starting the project. For example, problems may be caused by reasons like improper understanding of the requirements, difficulty bringing the clients on board, or the project turns out not to be commercially successful. Similarly, development may become an unnecessarily complex task due to creeping requirements, the scope of which should have been defined before development started. Issues like architectural instability and lack of co-ordination among the team can also arise. So it’s worth asking if there is some method or process, which can reduce these difficulties, and can bring more control and guidance to a project, irrespective of the kind of software you are developing. Software Life Cycle Modeling precisely addresses these issues. In this article I describe some of the various life cycle models, and also touch on their importance in current software development scenarios.

Life cycle models are neither theoretical frameworks nor conceptual blocks; they literally lay the road for improving the quality of deliverables, and also organize the development process into neatly separated phases. They minimize the risks – or at least allow you to plan the risks – involved in software development; they can lead to enhanced customer understanding and relationships, thereby helping to bring about requirements understanding and the final successful delivery of software. It is an orchestration of the individual and collective capabilities that contributes towards the success of a software project, and this factor can be seen in the various life cycle models

Any software project involves people and processes, be it a single developer project with that one person handling a minimum set of requirements to be met, or a massive organization like Microsoft for which thousands of employees may be involved in a project, with detailed process and project guidelines following various established quality control frameworks like CMM or ISO 9000. Every project goes through a Software Development Life Cycle ( SDLC ) even if the developers involved are not consciously aware of using one.

In case of a traditional development project, after collecting the requirements, the choice of the style of development usually stems from the developers’ understanding of the scope of the requirements and the complexity, vagueness and the limitations of addressing the requirements. Every life cycle model has been designed keeping in mind the way people understand the requirements and develop the software, so when deciding upon the kind of life cycle model you are able to weigh the options. There is a useful Tamil saying, which says, Think and plan before you act, to think after acting upon a decision is agony (for the interested: the saying comes from a Tamil epic named Thirukkural). The same saying applies here: The options that are generated during the initial phase of requirements gathering often acquire their own momentum once the life cycle model is selected and applied with relevance to the project.

It’d be impossible in an article this size to point out all the known lifecycle models, so I’ll concentrate on some of the more important traditional ones. In particular the lifecycle models I’ll discuss are

• Pure Waterfall


• Code and Fix


• Spiral


• Modified Waterfalls


• Sashimi (Waterfall with Overlapping Phases)


• Waterfall with sub projects


• Waterfall with Risk Reduction


• Evolutionary prototyping


• Staged Delivery


• Design to Schedule


• Evolutionary Delivery


• Design-To-Tools

These are traditional life cycle models; more recently, industries are designing much more sophisticated industrial life cycle models, including like Rational Unified Process (RUP), and development methodologies like Agile methodologies. The traditional models have the advantage of being easy to understand and follow without special software. They also contain all the foundational concepts that have been adopted in more recent approaches, and therefore do form a good basis on which to approach an understanding of lifecycle models.

Pure Waterfall

Software development can be seen as a double-edged weapon in which the myriad end user and business requirements stand at one end, while at the other end you have the sophisticated and complex technologies that can be used for developing the required software. It is clearly not always possible to relate these two ends directly, but they can be more easily related by breaking the cycle into the steps to get from one end to the other. The pure waterfall model states that there should be a diagonal flow of the different phases of software development without allowing re-tracking to the previous phases.

Figure 1. Pure Waterfall Model.

This is an idealization, which in practice is not normally possible especially given that you are dealing with human resources. In practice what is required is a kind of artistic approach, which lays more emphasis on patience and also application of reflective design principles. The pure waterfall model may apply to areas like the business analyst who does the initial requirements gathering. Also, sometimes it happens that the conceptualization of software, analysis of requirements and the architectural design flows smoothly without much hindrance or hiccups, resulting in a good approximation to the pure waterfall. In most cases however it’s probably not appropriate to regard pure waterfall as a practical approach for the SDLC.

Code and Fix

This is one of the more primitive models used for software development; as the name suggests it implies using the available requirements and immediately starting the coding. The software may then be fixed with patches as and when the requirements evolve. The model involves whatever combination of informal design, coding, debugging and testing methodologies may happen to be in use in an organization, and as you’ll have guessed is the model that often ends up being invoked when teams start coding without giving any real prior thought to the appropriate lifecycle model to use. Code and fix is an inefficient and dangerous approach for developing quality software and so should not normally be accepted. However it may be used as a supportive approach for what is called as an instant development and delivery of software projects, or for extremely small projects (the kind whose total development time would be measured in hours).

Spiral

The spiral model gives a risk-oriented approach towards the software development process. As discussed earlier there are inherent limitations in terms of understanding the requirements as well as technological limitations. You may also encounter performance and scalability issues and also the incompleteness of the software deliverables which often becomes a potential threat for creeping requirements and inability to handle the clients efficiently. All these risks have to be evaluated before the development process starts in full swing and this is what the spiral model is designed to take account of. The spiral model is shown in Figure 2.

Figure 2. Spiral Model.

You start at the center of the figure and spiral outwards as the project progresses. Risk analysis is done repeatedly as the project moves from each phase to the next phase; prototypes are developed and rolled out based on the risk evaluation plan. Gradually, greater clarity is added in the process and then the development process becomes iterative in nature. All the other steps or processes in the software development start participating in the iteration – including the architectural model, software design, detailed design, development, unit testing, integration testing, acceptance testing and finally the actual implementation of the software. Note however one exception to the iterative process: Requirements will normally be fixed in the first iteration because of the ripple effect that would be caused by changing requirements. Keeping requirements fixed means that as more choices open up in the later iterations, these choices can be carefully evaluated against known risk plans.

Modified Waterfalls

The waterfall model treats each phase of the software development process as relatively separate and sequential. As discussed earlier this model represents only an ideal approach, rather than providing more practical and adaptable approach towards software development. To counter this there exist modified waterfall models, which I’ll describe here.

Sashimi

Peter DeGrace describes one of the modifications of the waterfall model as the sashimi model. The name comes from a Japanese hardware development model (from Fuji Xerox) and refers to the Japanese style of presenting sliced raw fish, with the slices overlapping each other. The traditional waterfall model allows for minimal overlapping between phases at the end of phase review. By contrast sashimi suggests a stronger degree of overlap, as shown in Figure 3. This model allows you to digress and move away towards the next phase while you are in the middle of the previous phase. For example if you are in requirements analysis, you can start to simultaneously look at architectural design, so something of a kind of parallel development effort starts. This is flexible, but you should bear in mind it also gives room for inaccurate deadlines, miscommunication, mistaken assumptions and inefficiency. Sashimi is most beneficial if there is an effective understanding between the teams that work on the different phases.

Figure 3. Sashimi Model

Waterfall with Sub-Projects

The pure waterfall model does not allow revisiting the previous phases of the SDLC, for example once you are working on the architectural design you cannot go back to the requirements analysis phase. As the name suggests the waterfall with sub projects model, shown in 4, rectifies this by allowing for separate projects from the main track of the model to be executed and finally rejoined. Figure 4 also shows that the model is refined to allow some backgracking. It means to some extent you have different options for how to proceed after the architectural design. You may also want to generate ideas, or enforce certain creative development practices like innovative and agile development methodologies, which enables the development team to develop and test different modules and integrate all the resultant modules, or to selectively choose the best approach and proceed ahead with the system testing. Waterfall with sub-projects allows for all this, but at the expense of the risk of unforeseen interdependencies. You can partly account for that by eliminating dependencies at architecture time or waiting until after detailed-design time to break the project into subprojects.

Figure 4. Waterfall with Sub Projects.
This figure has been reduced in size to fit in the text. To view the full image Click here

Waterfall with Risk Reduction

Waterfall with risk reduction is similar to the pure waterfall model but also seeks to take account of a common problem: Many projects break away from the waterfall model, in the sense that the timelines planned are not met, because risks that should have been addressed in the Requirements analysis and in the Architectural design phases were not effectively planned for. Requirements gathering and analysis, and architectural design are the two major phases before the actual development work starts for any software development activity. From experience, unless these two phases generate sufficient clarity, the risk of incorrect underlying assumptions in these two phases will cascade into subsequent phases. The waterfall with risk reduction model is created by modifying the waterfall model to include a risk reduction spiral in the beginning of the SDLC (This spiral should follow the early stages of the spiral model discussed earlier). As the following diagram depicts, this gives a gray shade for these two phases indicating additional risks which can be surmounted with detailed requirements gathering activities like developing user-interface prototypes, story-boarding, conducting user interviews and to span the architectural design.

Figure 5. Waterfall with Risk Reduction.
This figure has been reduced in size to fit in the text. To view the full image Click here

Evolutionary Prototyping

Evolutionary prototyping is generally applied to very large systems that span many modules with extensive inter-dependencies. In this situation the system may be so complex that you cannot reasonably arrive at the complete list of deliverables in a single go, so instead you iteratively develop the prototype. Say for example you are developing a production tracking software for Animation studios spread across the globe. Using evolutionary prototyping in this scenario, you might first develop an initial concept and then design and implement an initial prototype. Then you would interact with the users of the system to arrive at a better prototype, the process being repeated until you have addressed most of the complexities. Hence what initially seems to be an insurmountable task gradually becomes achievable, and all the hidden patterns and relationships are gradually understood. A classic example of this model is provided by the .NET Framework, which evolved from very open beta versions to the final stage as a result of user feedback. You can often see evolutionary prototyping at work in open source software too.

Figure 6. Evolutionary Prototyping

This kind of prototyping is also useful in cases where the requirements change rapidly so cannot initially be finalized. The disadvantages of this model are that the number of iterations that has to be done to arrive at the final list of deliverables is unpredictable, and also extensive user co-operation is required. Normally the business deal has to come to a conclusion at some point so that this process typically stops at a stage where there is a win-win situation for both the client and the company that develops and delivers the Software.

Staged Delivery

When the complexity of the system that the analyst interacts with is sufficiently simple as to be comprehensible at the outset, you can go for staged delivery model. (also known as incremental implementation). In this model you partition the deliverables into a well-defined set of phases. You do not deliver the software at the end of the project as a single deliverable but you deliver it in successive stages throughout the project.

By adopting this model, you have the chance to show good early progress in the project and you can gain the confidence of the customer with the deliverables that meets the specific set of requirements at each stage, and then moving along in the subsequent stages. This also ensures that the schedule pressure is met and the developers are also comfortable with the set of deliverables and as they progress.

Figure 7. Staged Delivery

Design to Schedule

Those who have started their software career in a small software development company will very likely be well acquainted with this kind of model. Constraints of resources and money drive this model. With design to schedule, you will probably identify certain clients who have only a minimum set of core requirements and you will develop the software in stages and according to a schedule to implement these features. Based on agreed deadlines, an initial set of product features are identified as being most important, to ensure that a saleable (albeit not as feature-rich) product is available quickly. So fewer developers are used for increasing the feature set of the product and more of them concentrate on solving the production issues arising out of the initial installation of the product. The important point of this model is the way things are prioritized, and that it can help the developers to get more clarity about where they have started and what is the exact stage of the project life cycle they are in. Design to schedule gives clarity in managing the developer’s schedule, so that the peaks of effort and stress get relieved by being able to supply an initial set of deliverables to clients. After a number of releases the product gets matured and refined.

Figure 8. Design to Schedule
This figure has been reduced in size to fit in the text. To view the full image Click here

Evolutionary Delivery

Evolutionary delivery, as the name suggests, is a model that allows freedom for the company to deliver an initial version and show it to the customer, elicit their feedback and refine the software until it satisfies the implicit and explicit requirements of the customer. This model is basically a win-win approach for both the company and the customers. To take an example, suppose you are developing software to display live cricket or football scores. Here the preliminary analysis reveals the need to create a database with the information about all the players, and that the application should define and display scores. Even the design of the architecture will be clear, in the sense what goes into the application, eg. if it is used for a portal display, or in a television commentary. Based on the usage of a preliminary version of the software, the customers may come up with much more elegant forms of screen design, better techniques to display statistics, and this may result in enhancing the base architecture with visual display features and statistics support. In a situation like this where the software is exposed to a large set of users, eliciting customer feedback and incorporating the changes is a very critical phase both for testing as well as enhancing or more precisely evolving the software from the conceptual domain to implementation.

Figure 9. Evolutionary Delivery
This figure has been reduced in size to fit in the text. To view the full image Click here

Design-to-Tools

This approach is useful when you have a good set of tools available to assist with product development, for example you wish to use Microsoft Commerce Server to quickly deliver a website. Other examples are that you have existing code generators and class libraries built with certain predefined functionalities, which meet many of the software requirements of the client. These kinds of development practices are in vogue in some specific vertical requirements like portals. A good example would be if you were designing a portal to give which gives free email facilities based on advertising revenue.

Strengths and Weaknesses of Life cycle models

You may have gathered from this discussion of the different models that selecting a life cycle model is closely tied with the psychology of decision making. You need to be clear about the initial parameters that go in making the selection and be able to assess pros and cons of the project chosen for development and deployment.

The following table shows compares the various models for the relative strengths and weaknesses in different areas. This table is reproduced with kind permission of Microsoft Press and is taken from the book, Rapid Development (81-7853-013-9) by Microsoft Press. All rights reserved. You can buy this book at http://www.microsoft.com/MSpress/books/770.asp.

Life Cycle Model Capability	Pure Waterfall	Code-and-Fix	Spiral	Modified Waterfalls	Evolutionary Prototyping
Works with poorly understood requirements	Poor	Poor	Excellent	Fair to Excellent	Excellent
Works with poorly understood architecture	Poor	Poor	Excellent	Fair to Excellent	Poor to Fair
Produces highly reliable system	Excellent	Poor	Excellent	Fair to Excellent	Poor to Fair
Produces System with large growth envelope	Excellent	Poor to Fair	Excellent	Excellent	Excellent
Manages Risks	Poor	Poor	Excellent	Fair	Fair
Can be constrained to a Predefined Schedule	Fair	Poor	Fair	Fair	Poor
Has low overhead	Poor	Excellent	Fair	Excellent	Fair
Allows for Midcourse corrections	Poor	Poor To excellent	Fair	Fair	Excellent
Provides customer with progress visibility	Poor	Fair	Excellent	Fair to Excellent	Fair
Provides management with progress visibility	Fair	Poor	Excellent	Fair to Excellent	Fair
Requires little manager or developer sophistication	Fair	Excellent	Poor	Poor to Fair	Poor

Life Cycle Model Capability	Staged Delivery	Evolutionary Delivery	Design-To-Schedule	Design-To-Tools	Commercial-Off-the-Shelf-Software
Works with poorly understood requirements	Poor	Fair to excellent	Poor to Fair	Fair	Excellent
Works with poorly understood architecture	Poor	Poor	Poor	Poor to Excellent	Poor to Excellent
Produces highly reliable system	Excellent	Fair To Excellent	Fair	Poor To Excellent	Poor To Excellent
Produces System with large growth envelope	Excellent	Excellent	Fair To Excellent	Poor	N/A
Manages Risks	Fair	Fair	Fair To Excellent	Poor To Fair	N/A
Can be constrained to a Predefined Schedule	Fair	Fair	Excellent	Excellent	Excellent
Has low overhead	Fair	Fair	Fair	Fair To Excellent	Excellent
Allows for Midcourse corrections	Poor	Fair To Excellent	Poor To Fair	Excellent	Poor
Provides customer with progress visibility	Fair	Excellent	Fair	Excellent	N/A
Provides management with progress visibility	Excellent	Excellent	Excellent	Excellent	N/A
Requires little manager or developer sophistication	Fair	Fair	Poor	Fair	Fair

Conclusion

The aim of this article was to give a perspective of the software development process, so that you can apply the principles of life cycle modeling to your projects. It’s important to understand though that ultimately it is the people and the processes that contributes towards the success of any software project, as much as the technology and tools being used. I’ve surveyed some of the more important models; although I’ve not specifically discussed how to apply the various models, the information should be sufficient to allow you to think about the processes by which you develop software products, in the light of an awareness of some of the different cycles that might be used. It’s also worth pointing out that quality standards like ISO 9000 and CMMi frameworks emphasize the importance of choosing appropriate life cycle models.