This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Life-cycle Models
Some projects attempt to follow a sequence of phases like those identified above in linear fashion. They perform each stage before moving on to the next. This is commonly referred to as a waterfall type approach or life-cycle (Sommerville, 2001), since the project proceeds like water falling over a series of rocky outcroppings, never going back to a previous level. The waterfall approach promises linearity and predictability to tightly control the software process.
In practice, the waterfall approach may not provide the most efficient life-cycle model for every application. The waterfall model assumes that you can thoroughly uncover and understand every detail at every stage so that you never need to revisit it. This requires a monumental planning effort up front that is extremely costly and ultimately imperfect. Worse still, unknowns in the software process and its dependencies are seldom accommodating enough to allow a waterfall strategy to be effective. During the normal discovery process, we learn things at later stages that affect the conclusions reached in previous stages. Over the course of the project, uncontrollable variables also undermine the monumental waterfall plan.
The strict waterfall is often imposed as a management knee-jerk reaction to previous failures. It is an attempt to eliminate all risk by imposing the unattainable requirement that you reach perfection at each stage. The waterfall approach virtually eliminates any possible benefit of optimization or adaptation. The typical result is mediocre, uninspired software at best.
Because of these demonstrated limitations, the word waterfall has come to be associated with inflexible, simplistic, and outdated software management in recent years. Although most software professionals today will no longer admit to managing a waterfall process, many do nevertheless. You can easily recognize the waterfall in the simple phase level Gantt charts that they create using Microsoft Project. His waterfall method is still widely used in practice if not in name, simply because it is the easiest to conceptualize and the easiest way to demonstrate managerial competence.
The evolutionary or iterative life-cycle approach was developed to introduce some flexibility into the waterfall approach. It replaces monumental planning with high-level phased plan and detailed iteration plans. It breaks up the monumental plan into a series of smaller waterfall processes. Each iteration is not planned in detail until well into the previous iteration. This gives the process the flexibility to evolve as it proceeds, benefiting from what was uncovered in the previous iteration. This approach helps to avoid premature, wasted planning and allows the process to make beneficial course corrections.
A more radical form of the evolutionary approach is Extreme Programming (Beck, 2000). This starts with the very realistic acknowledgment that the users don't really know what they want until they see it. Coders work in pairs to continually tear apart the code and refine it. Stories are written on index cards to describe things the program should do.
The Spiral method (Boehm, 1988) is an iterative learning variant that emphasizes risk as the major factor for driving the project. It recommends a life-cycle flow, represented diagrammatically as a spiral, in which a series of risk-driven prototypes is developed and then the final product is produced by a waterfall method.
Rapid Application Development (RAD) emphasizes speed by combining some aspects of the evolutionary and spiral approaches. It succeeded very well in optimizing speed but developed a reputation for lower quality.
Radical Programming is a progression of RAD thinking that emphasizes the organization of the project into small, tightly knit development groups. Radical development projects utilize the strength of small teams effectively, but fail to scale when those teams require a greater degree of collaboration.
The Adaptive process (Highsmith, 2000) is an iterative model that attempts to break out of the optimizing paradigm, emphasizing adaptation as a mechanism to embrace the unpredictable nature of complex systems. The underlying difference is that optimization is a process of refining the perfect solution for a fixed set of conditions, whereas adaptation seeks to maximize change-tolerance to survive in our dynamic real world. The adaptive management model emphasizes a more collaborative leadership style than the traditional command and control management that characterizes most optimizing processes.
The Formal process raises the planning methodology to a highly abstract level, formalizing the requirements in symbolic representation and then using that model to drive the code generation. The learning curve is very high and the methodologies are quite abstract.
Change-tolerance (Maintainability)
Change-tolerance is defined as the ability of software to survive change. Change tolerant software is maintainable, meaning it can easily accommodate maintenance and bug fixes without breaking. It is enhanceable, meaning it can easily accept changes required by changing business requirements, external changes, or environmental changes. It is also modifiable, meaning that it can be adapted and changed to serve completely new purposes.
Change-tolerance is the true test of quality. It is often far better to have software that does not work but is change-tolerant, than software that works perfectly for the moment, but is too fragile to tolerate change. Change-tolerant software will have a far longer product lifetime, require fewer generational revisions, and ultimately provide the greatest return on investment.
Many projects mix life-cycle approaches or create their own hybrids. A project manager may mandate a waterfall flow from project specification to development, then evolutionary iteration between development and testing. He may mix and match features of each.
No matter what life-cycle model is adopted, it is important to realize that they all should ultimately follow the same progression of logical phases identified previously. Analysis should come before architecture, design before development. The difference is largely in how much of the project is following that logical progression at any given time.
Any approach can suffer if the logical phases are not followed in sequence. When the sequence is violated, decisions are made prematurely and often by the wrong people.
Given the range of choices and their subtle but profound differences, choosing a life-cycle approach is not a simple task.