The Spiral Model Approach
It seems that "spiral development" means different things to different
people. The concept was first described by Barry Boehm
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.
It consists of a spiral divided into four quadrants. Each quadrant represents
a management process, namely: Identify; Design; Construct; and Evaluate.
The system goes through four cycles of these four processes:
- 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.
- First-build cycle derive system requirements, develop logic design,
construct first build, evaluate results. Share results with user.
- Second-build cycle derive subsystem requirements, produce physical
design, construct second build, evaluate results. Share results with user.
- Final-build cycle derive unit requirements, produce final design, construct
final build, test all levels. Seek user acceptance.
- 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
Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer,
11. Dean Muench, The Sybase Development Framework, Sybase,
12. A Guide to the Project Management Body of Knowledge
(PMBOKČ Guide), 2000 Edition, Project Management Institute, PA, 2000, p17