Software Development Methods Become Part of the Profession of Software Engineering

At around the turn of the 1970s to 1980s, two offshoots of the waterfall model became evident in software development. Both answered business s call to be faster. Some companies using the waterfall model took shortcuts to achieve speed. Since lack of speed became apparent toward the end of the life cycle as the projected shipping date approached, often the cuts came in testing.

Task	Look at Chapter 2, Software Engineering Methods. How do software development methods overcome this last described phenomenon ?

One way of increasing the speed of development was to use prototypes as the basis of development (see Figure 8.7).

Figure 8.7: The Evolutionary Development Model.

In this variant, a prototype could be buttressed with additional code and documentation to make it releasable, but this was the first code cut if a budget crunch appeared, leaving only the prototype, with bare documentation.

Another variant on the waterfall model, which actually supported it and found its way into many methods, is the Iterative Model (see Figure 8.8).

Figure 8.8: The Iterative Development Model.

The idea here is that we know what we want to produce, but we plan several iterations of work, each saleable. The problem was the defect spike after the first and other releases, necessitating a schedule slip on Release Two. Each subsequent release also slipped. The added time of these slips could lead to a release that was no longer valuable . However, early value was the main concern, and it would hold up for a few releases.

The emphasis in these later two versions of the Waterfall Software Life Cycle was on repetition. As the 1980s wore on and dissatisfaction with the Waterfall Software Life Cycle, on which most methods were based, came to a head, a new life cycle design came from a trusted source. The trusted source was Barry Boehm [Boehm81]. The new life cycle was the Spiral Model (see Figure 8.9).

Figure 8.9: The Spiral Software Development Model.

The Spiral Model came from a desire to reduce risks, but it was iterative in style (for additional information on the use of this model see Chapter 2). The first pass through specifying, designing, coding, and testing is for a component of the software that we knew least about. Therefore, its configuration, elapsed time for development, and cost are unknown. This component represents the greatest risk (if we know how to do something, it is easy), and it would be completed early in the process! Each spiral has the same activities concentrated on items of increasingly lesser risk.

Task	Describe an evolutionary process behind the Spiral Model.

Steve McConnell immortalized this combination of risk reduction and iteration as a best practice in his Rapid Application Development [McConnell96].

Notice that all the figures traverse the activities of specifying, designing, coding, and testing. Some do this several times. This is because these activities have become the paradigm of software development. We use the concept of paradigm in the way Thomas Kuhn meant it originally in his book [Kuhn62]; that is, not as a way of doing things, but the way. It is more or less true that these four activities, plus the concepts of abstraction and information hiding, served as the basis for iterative methods. When the majority of developers have accepted these four activities, they become a paradigm.