HOW TO MAKE A V-SHAPED SPIRAL -- AND VICE VERSA

by Dwayne Phillips

The waterfall, with its specify-test structure, is the fundamental process model in software. The spiral process is better suited for projects with risks and unknowns. It, too, has a strong specify-test structure when viewed in the proper format.

PAT VS. MIKE

Pat, an aspiring project manager, is beginning a project full of unknowns and risks. She wants to use a spiral process [1]. Her management, however, does not like the "spiral" concept; they always use the waterfall process, with its specify-test structure. Pat needs a way to show her management that the spiral process has the structure and testing framework they want.

Mike, an upper manager, is afraid of Pat's spiral process idea. It sounds too much like "hacking" code. There is no structure to the spiral and not enough real testing. Pat, however, has shown good judgment in the past, and this project does have higher-than-average risk and unknowns. Pat is enthusiastic about the spiral, and enthusiasm often carries a project. Nevertheless, Mike needs to see the specify-test structure the company has always used successfully.

This is not a generation gap -- it is a communication gap. Pat and Mike both want the project to succeed for the company, but they cannot see how the other's process model will meet their expectations.

THE WATERFALL AND THE V-CHART

Figure 1 shows the traditional waterfall process. The tail end is longer than usually shown to emphasize testing activities. Figure 2 shows the waterfall bent into a V-chart.

The V-chart emphasizes the specify-test structure of projects. Each test on the right side of the V corresponds to a specification on the left. For example, the low-level (or detailed) design specifies what the software units should do. Testing the units verifies that they perform as specified. Figure 2 shows the basic v-chart.

The waterfall process (V-chart) has its advantages and disadvantages (see [2, 4] and others). One advantage is that waterfall projects are easy to manage. Another is that the V-chart representation clearly shows the testing and how testing verifies the requirements and design. Mike wants these advantages.

The waterfall process, however, is weak when there are risks and unknowns. It is easy to spend time and money on requirements and design, only to find that the system does not work during integration and testing (see [3] for one costly example). Pat is afraid of this.

THE SPIRAL PROCESS

The spiral process [1] is a series of cycles that reduce risk through analysis, prototyping, building, and evaluating. Figure 3 shows the basic spiral. Work begins at the center and winds outwards through a series of cycles. Each cycle has four quadrants that (1) set the goals and limits of the cycle, (2) learn about risks via experiments, (3) build a limited product, and (4) plan for the next cycle (for more discussion, see [2, 4]).

The spiral process has its advantages and disadvantages, too. It is an excellent process for high-risk projects. It emphasizes having and exploring alternative routes to products. These activities help the developers work through unknowns without committing resources prematurely.

A disadvantage of the spiral process is that it is harder to manage. Project managers must make many unusual decisions. "Which alternative design has the lowest risk? Have we prototyped enough to understand the alternatives? Was the last cycle worth the effort? Should we stop the project?" The spiral process can also be wasteful if the people involved know the product well [3].

The biggest disadvantage for Mike is that the spiral just does not look right. He can find familiar terms in the picture, but they are all twisted. This is a radical departure from the company's V-charts and seems too risky to try.

A V-SHAPED SPIRAL

Fortunately, the spiral process and the waterfall process can be expressed in the same terms. Figure 4 shows how to close the communication gap between Pat and Mike. This V-chart contains the sequence of tasks from the spiral of Figure 3. Please note that Boehm's spiral is not just a waterfall twisted around a point. There is more to the spiral, as the following discussion should make clear. The V-shaped spiral is a visual tool to close a gap. [Though not discussed here, iterative and evolutionary processes can also be shown in the V-chart form.]

Each block on the left side of the V-chart comprises the first three quadrants of a cycle and the last quadrant of the previous cycle.

Concept of Operations/Implementation

The first block on the left side contains the activities that produce a concept of operations. The concept of operations is a specification for the operations of the software. It bounds the problem and describes how the software will enable the users.

The highest block on the right side of the V-chart is implementation. This is a test. It answers the questions, "Does the software implementation meet the specification of the concept of operations?" and "Does it satisfy the users?"

Requirements Phase/Acceptance Test

The next block on the left side of the V-chart is the requirements phase. It begins in the fourth quadrant of the first cycle. Before planning this phase, Pat will evaluate the results of the first cycle and decide to proceed with or stop the project. Will the concept of operations lead to a product that is usable and affordable? Will the benefit justify the cost?

Each block on the left side of the V-chart begins with such an evaluation. This is a business test. The project has high risk and unknowns, and progress through the cycles produces knowledge about these. Has the project revealed something to indicate that the cost of completion is too high?

If the requirements phase continues, Pat plans this phase and the remaining phases of the project. These plans are short and changeable to avoid committing too many resources in ignorance. The objective of this cycle is a requirements document; the constraints are the time and money allowed; and the alternatives are different sets of capabilities for the software. The project analyzes the risk in each alternative and uses prototypes to learn about them. This knowledge helps in writing the requirements document. Validating the requirements is a test by inspection and analysis. This test is not often performed in a waterfall project.

The corresponding block on the right side of the V-chart is the acceptance test. This tests the software against the requirements. It answers the question, "Does the software do everything specified in the requirements?"

Design Phase/Integration and Test

The next block on the left side of the V-chart is the design phase. It begins by evaluating or testing the project to date to decide whether to proceed or stop. This answers the question, "Will it be worth it to build the software per the requirements?" The objective of the design phase is a software product design. There are always several solutions (designs) available. Pat's team analyzes the risk of each solution and uses prototypes to test the ideas. This knowledge helps point to one solution, and the team creates the software product design. Validation and verification test that design by inspection and analysis.

The corresponding block on the right side of the V-chart is the integration and test. The software product design specifies the external nature of the software components in the product. The integration and test phase tests the components against the specification. It answers the question, "Do the components perform the operations specified by the software product design?"

Build Phase/Unit Test

The final block on the left side of the V-chart is the build phase. This is similar to a waterfall project. It begins with the evaluation of the project and the decision to proceed or stop. If Pat proceeds, the first activity is to plan the integration and test activities. The objective is to design the details, write the code, and perform all testing. There are several ways to do these tasks. The project analyzes the risk in each alternative and builds an operational prototype to show the users. The final task in this block is the detailed design.

The corresponding block on the right side of the V-chart is the unit test. The detailed design specifies what each software unit is to do. The unit test verifies that each software unit performs to that specification.

Code

The bottom of the V-chart is where the programmers write the software units. This point is the same in the V-charts of both Figures 2 and 4. The programmers implement the algorithms specified in the detailed design.

The right side of the V-chart performs the tests already described. These tests correspond to the specifications on the left side of the V-chart. The spiral process shown in Figure 3 contains the same specify and test elements as the V-chart shown in Figure 2.

YOU SAY "TO-MAY-TO," I SAY "TO-MAH-TO"

The V-shaped spiral of Figure 4 gives both Pat and Mike what they want. It has the shape and structure familiar to Mike. It includes all the specification and testing he wants.

The V-shaped spiral also pleases Pat. She has all the risk analysis, prototyping, and proceed-or-stop activities she needs to manage the high risk and unknowns of her project.

In effect, Mike has said, "You've shown me a V-chart with all its specifications, tests, milestones, and so on, so you can call it a spiral if you like."

In turn, Pat has said, "You've let me use a spiral process, so I'll call it a waterfall and draw it in a V-chart if you like."

CONCLUSION

The waterfall and spiral process models are both good when employed on the proper types of projects [3]. Many organizations require or strongly encourage project managers to use the waterfall and V-chart. The nature of some projects, however, points to a spiral process. The spiral process can be expressed in terms of a V-chart. This satisfies the mandate of management and gives the project what it needs to succeed.

REFERENCES

1. Boehm, B. "A Spiral Model for Software Development and Enhancement." IEEE Computer, Vol. 21, no. 5 (May 1988), pp. 61-72.

2. McConnell, S. Rapid Development. Redmond, WA: Microsoft Press, 1996.

3. Phillips, D. "People, Process, and Product." American Programmer, Vol. 8, No. 1 (January 1995), pp. 15-20.

4. Pressman, R. Software Engineering: A Practitioner's Approach, 4th ed. New York: McGraw-Hill, 1997.