Introduction | The PMI's Guide to the PMBoK | The "Waterfall" Process
The Systems Engineering Approach | The Spiral Model Approach | PART 2

The Spiral Model Approach

It seems that "spiral development" means different things to different people. The concept was first described by Barry Boehm[10] as an iterative waterfall in which each iteration provides increasing software capability. This concept is shown in Figure 3.

Figure 3: Spiral Development (Boehm 1988)

However, today others may use the term to mean "Rapid Prototyping", or even "Anything but waterfall". For the record, A "spiral" model of software development is described by Muench.[11] It consists of a spiral divided into four quadrants. Each quadrant represents a management process, namely: Identify; Design; Construct; and Evaluate.[12] The system goes through four cycles of these four processes:

1. Proof-of-concept cycle — define the business goals, capture the requirements, develop a conceptual design, construct a "proof-of-concept", establish test plans, conduct a risk analysis. Share results with user.
2. First-build cycle — derive system requirements, develop logic design, construct first build, evaluate results. Share results with user.
3. Second-build cycle — derive subsystem requirements, produce physical design, construct second build, evaluate results. Share results with user.
4. Final-build cycle — derive unit requirements, produce final design, construct final build, test all levels. Seek user acceptance.

Good features

• In this approach, the entire application is built working with the user.
• Any gaps in requirements are identified as work progresses into more detail.
• The process is continued until the code is finally accepted.
• The diagrammatic representation, i.e. the spiral, does convey very clearly the cyclic nature of the process.
• And it also conveys the progression through the project life span.

Not so good features

• This approach requires serious discipline on the part of the users.
• If the users are not responsible for the schedule and budget, as very often they are not, executive control can be difficult.
• For a software developer working under a firm-price contract, it may be impossible.
• The model depicts four cycles. However, if cycles are added indefinitely for "just one more tweak" then eventually, as Cantor says, "Everyone gives up in frustration!"
• He might have added "Or, the time and money runs out."

All things are possible, but some are less likely in practice. The problem here is that authority and responsibility are divided making executive control difficult. Under these circumstances the spiral can become a project that just keeps going round in circles.

To be continued

In Part 2 of this paper we will take a look at Rapid Prototyping and then move on to examine why "linearity" really doesn't work for IS department software development. We will also look at some of the "people" problems associated with software development and try to suggest some answers — considering that the answers have probably been around for a long time, if only we would look at them!

The Systems Engineering Approach

Part 2

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page