EXPERIENCES WITH THE SPIRAL MODEL AS APROCESS MODEL GENERATOR

BARRY BOEHM, TRW INC.

Introduction

A good many of the problems on software projects arise frommismatches between the process model used by the project and theproject's real-world process drivers: budget, schedule, availablecommercial off-the-shelf (COTS) software, customer standards, usermission or technology uncertainties, etc. The primary processmodeling approach to date for avoiding these mismatches has beento try to develop the perfect process model: one which will work wellfor any combination of process drivers.

Our position in this paper is that a good process model generatorwould be nearly as effective as the perfect process model, and muchmore likely to be achievable. A process model generator is atechnique which operates on a project's process drivers as inputs toproduce a process model for the project which is tailored to itsparticular process drivers.

We have had several experiences in using the Spiral Model [Boehm,1988] as a process model generator. Our initial experience ingenerating a process model for the TRW Quantum Leap program wasreported in the previous workshop [Boehm-Belz, 1988]. Oursubsequent experiences have generated some significantly differentprocess models for avionics, command-control, exploratory researchprojects, and small fourth-generation language (4GL) based systems.

Below, we provide a short summary of the use of the spiral model asa process model generator, and a summary of the various processmodel generation experiences in terms of a Process Model DecisionTable showing the critical process driver conditions under which themost familiar process models (e.g., Waterfall [Royce, 1970],evolutionary development [McCracken-Jocks on, 1982], transform[Balzer-Cheatham-Green, 1988]) are the most appropriate choice of aprocess model for a particular software project.

The Soiral Model As a Process Model Generator

Figure 1 shows the extension of the spiral model which applies thespiral cycle paradigm (elaborate objectives, constraints, andalternatives; identify and resolve risks; refine specifications andplans) to both the software product and the software process. Thesteps below describe the application of these steps to the definitionof the most appropriate process model for the project:

Determine Process Obiectives and Constraints These constitute theproject's process drivers. Some examples are to develop a product­engineered version of the software in 18 months; to ensure that theproduct will satisfy a given class of users; use COTS softwarewherever possible.

Identify Process Model Alternatives. These would include thecurrently familiar process models such as the Waterfall Model,incremen tal development, and prototypin g/ev 01utionarydevelopment; plus mixes of process models that might better fitCOTS-dominated software systems.

Evaluate Process Model Alternatives with Respect to Obiectives andConstraints: Identify Risks. In many cases, this evaluation willproduce a clear, low-risk choice of a particular process model whichfits the process drivers. In other cases, potentially attractivealternatives may have risks of a mismatch to the process drivers:e.g., an attractive COTS-oriented solution may have major risks withrespect to the COTS product's maturity, performance, or scalability tolarge systems.

Analyze Risks. In the example above, the risk analysis could involvereference-checking the COTS product, or benchmarking it forperformance, scalability, and/or ease of adaptation.

Use Risk Analysis Results to Determine the Proiect-Tailored ProcessM ode I. This involves integrating the best mix of process modelalternatives to satisfy the project's process drivers. This step mayproduce a process model for the entire life cycle, or it may produce aprocess plan for the next phase, deferring portions of subsequentprocess decisions until the next round of the spiral.

A Process Model Decision Table: Critical Process Drivers

CUMULA TIVE

COST

hj "<. r;e (.

REFINED SPIRAL MODEL OF SOFTWAREPROCESS

---'---'PROGRESS

rl/nOUGU

STEPS

DETERMINE

OBJEClIVES.

. Al TEnNA liVES,

CONSTRAINrS

REVIEW COMMITMENTPARTITION

DEVElOP. VERIFY

NEXl·LEVEl

PROCESS PLANS

EVALUATE PROCESS

ALTERNA TlVES;

IDENTIFY, RESOLVE

PROCESS RISKS

DETERMINE PROCESS

OBJECllVES, Al HA·NA liVES, CONST RAINTS

PLAN

NEX T PIIASES

IMPLEMEN·

T A TlON

EVALUATE ALTERNATIVES;

IDENTIFY, RESOLVE RISKS

II

I INTEGRA· II I liON AND II ACCEPTANCE TES r ITEST II . II

DEVelOP, VERIFY

NEX I-LEVEl P/IODUCT

OPERA TlONAL

PROTOTYPE

BENCHMARKS---~DET AilED

DESIGN

-T--I CODE

UNIT ITEST I

A summary of experiences to date in using the spiral model as aprocess model generator is the Process Model Decision Table shownas Table 1. It shows how certain key characteristics of the system'sobjectives, constraints, and alternatives determined during the earlyspiral model cycles can be used to establish the most effectiveprocess model for the project. These key characteristics, or CriticalProcess Drivers, are:

• Growth Envelope. This refers to the likely limits of asystem's size and diversity over the course of its life cycle.A limited growth envelope implies a low risk of usinglimited-domain solution approaches such as COTS products,transform capabilities or fourth generation languages (4GL's).

• Understandin~ of Requirements. The lower the level ofsystem requirements understanding, the more essential areprocess models emphasizing prototyping and evolutionarydevelopment, as opposed to a requirements specification­driven process model such as the waterfall which has a highrisk of developing correct software to the wrongrequire men ts.

• Robustness. Systems which need to be highly robust anderror-free encounter high risks from informal processmodels such as evolutionary prototyping. More rigorousprocess models such as the waterfall reduce these risks,although they may need to be preceded by less formalphases addressing requirements-understanding orarc hi te c ture -u n d er stan di n g ri sk s .

• Available Technology. If technology such as COTS,transform, or 4GL capabilities cover a system's growthenvelope, it determines the most attractive process modelfor a system. A related process model is the "capabilities­to-requirements" model, in which the availability ofpowerful, easy-to-adapt capabilities or reusablecomponents strongly influences the system requirements .

• Architecture Understanding. The lower the level of systemarchitecture understanding, the higher the risk of a pure

i~6/~ I.

Software Process Model Decision Table

OBJECTIVES, CONSTRAINTS

AL TERNATIVES

GROWTH

UNDERSTANDING A VAILABLEARCHITECTUREMODELEXAMPLE

ENVELOPE

OF REQUIREMENTSROBUSTNESSTECHNOLOGYUNDERSTANDING

LIMITED

COTSBUY COTSSIMPLE INVENTORY CONTROL

LIMITED

4GL, TRANSFORMTRANSFORM ORSMALL BUSINESS - DP

EVOLUTIONARY

APPLICATION

DEVElOPMENTLIMITED

LOWLOW LOWEVOLUTIONARYADVANCED PATTERN RECOGNITION

PROTOTYPE

LIMITED TO

HIGHHIGH HIGHWATERFALLREBUILD OF OLD SYSTEM

LARGELOW

HIGH RISK REDUCTIONCOMPLEX SITUATION ASSESSMENT

FOLLOWED BYHIGH

LOWWATERFALLHIGH· PERFORMANCE AVIONICS

LIMITED TO

LOWLOW TO HIGHEVOLUTIONARYNEW DECISION SUPPORT SYSTEM

MEDIUM

MEDIUM DEVElOPMENT

LIMITED TO

LARGEMEDIUM TO HIGHCAPABILITIES-TO·ElECTRONIC PUBLISHING

LARGE

REUSABLEREQUIREMENTS

COMPONENTSVERY LARGE

RISK REDUCTIONAIR TRAFFIC CONTROL

PLUS WATERFALL

MEDIUM TO

LOWMEDIUMPARTIAL COTSLOW TO MEDIUMSPIRALSOFTWARE SUPPORT

LARGE

ENVIRONMENT

Conditions for Additional Complementary Process Model Options

• DESIGN-TO-COST OR SCHEDULE

• INCREMENTAL DEVElOPMENT

(ANY ONE CONDITION IS SUFFICIENT)

FIXED BUDGET OR SCHEDULE AVAILABLE

EARLY CAPABILITY NEEDED

LIMITED STAFF OR BUDGET AVAILABLE

DOWNSTREAM REQUIREMENTS POORLY UNDERSTOOD

HIGH-RISK SYSTEM NUCLEUS

LARGE TO VERY LARGE APPLICATION

REOUIRED PHASING WITH SYSTEM INCREMENTS

level of architecture understanding lowers a risk ofevolutionary development: that the system evolves Indirections that the architecture cannot support.

There are additional critical processs drivers such as budget andschedule limitations and the existence of a high-risk system nucleus,which lead to other process model alternatives such as incrementaldevelopment and desigh-to-cost. These critical process drivers andprocess model alternatives are treated differently than the others inTable 1, since incremental development and design-to-cost can beused in concert with rather than in place of any of the other processmodel alternatives.

Process Model Decision Table Contents

The Process Model Decision Table shown as Table 1 shows the resultsof applying the spiral model paradigm to the Critical Process Driversto determine the most appropriate process model for variouscombinations of Critical Process Drivers. The process modelsgenerated in Table 1 are:

• Buv COTS. This is a simple process model often overlookedin the enthusiasm to design and build something new, orbecause of the inertia involved in applying administrativeprocedures designed for custom-developed software.

• Tra nsfo rm. This model uses the specification rather thanthe design or code as the basis for evolution, and relies onthe availability of a capability to automatically transformthe specifications into design and code [Balzer-Cheatham­Green, 1983]. If such a capability spans the system'sgrowth envelope, the transform model is most appropriate.

• Evolutionary Development. This involves developing aninitial approximation to a desired software product, andevolving it into the desired product based on usagefeedback [McCracken-Jackson, 1982]. This is a highlyeffective, low-risk approach if the system's growthenvelope is covered by a 4GL, or if the systemrequirements are poorly understood in a situation wherethe architecture is well-understood (a low risk that thesystem will evolve into a configuration poorly supportedby the architecture).

system will evolve into a configuration poorly supportedby the architecture).

• Evolutionary Prototyving. This model is similar toevolutionary development, except that a prototyp-qualitysystem (low robustness) is acceptable, and the systemarchitecture is generally poorly understood.

• Waterfall. The sequential requirements-design-code-test-maintain model [Royce, 1970].

• Risk Reduction/Waterfall. The waterfall model, precededby one or more phases focussed on reducing the risks ofpoorly understood requirements or architecture, technologyuncertainties, potential performance or robustnessshortfalls, etc.

• Capabilities-to-Requirements. This model reverses theusual requirements-to-capabilities sequence interest in thewaterfall and related models. It begins with an assessmentof the envelope of capabilities available from COTS or otherreusable components, and then involves adjusting therequirements wherever possible to capitalize on theexisting capabilities.

• Incremental Development. This involves organizing thedevelopment into a series of increments of functionalcapability rather than a single-shot development. This isthe preferred approach under various conditions shown inTable 1, such as the existence of a high-risk system nucleus,which should be developed and proven in an initialincrement before investing in applications softwaredependent on the nucleus.

• Design to Cost or Design to Schedule. This approachinvolves prioritizing the desired system capabilities andorganizing the architecture to facilitate dropping lower­priority capabilities as one finds that their developmentdoes not fit within one's available budget or schedule. Asmentioned above, this approach and incrementaldevelopment can be used in concert with the other processmodels in Table 1.

are well-understood but sufficiently ambitious that there is only alow level of understanding with respect to the best architecturalalternative for achieving the objectives. This means that there is ahigh risk of proceeding with a waterfall-type model without someprevious risk reduction activities to ensure an appropriatearchitecture and an achievable level of performance. However, thehigh robustness objective means that there is a high risk of applyinga less rigorous approach such as evolutionary prototyping orevolutionary development. Also, there are currently no availableCOTS products, transform capabilities, or 4GL's which cover theapplication.

Given these risk patterns in the system objectives and alternatives,the best process model involves a two-phase approach: a riskreduction phase to analyze, simulate, and/or prototype alternativearchitectures, followed by a rigorous waterfall-model phase once thepreferred architecture is determined. Further, if there wereadditional process drivers such as a limited budget or a series of pre­planned product improvements, an incremental development and/ora design-to-cost approach would also be appropriate.

References

[Balzer-Cheatham-Green, 1983]. R. Balzer, T. E. Cheatham, and C.Green, "Software Technology in the 1990' s: Using a New Paradigm,"Computer. Nov. 1983, pp. 39-45.

[Boehm, 1988]. B. W. Boehm, "A Spiral Model of SoftwareDevelopment and Enhancement", Computer. May 1988, pp. 61-72.

[Boehm-Belz, 1988]. B.W. Boehm and F. C. Belz, "Applying Process

Programming to the Spiral Model," Proceedings. 4th Software ProcessWorkshop IEEE/ACM, May 1988.

[McCracken-Jackson, 1982]. D. D. McCracken and M. Jackson, "LifeCycle Concept Considered Harmful", ACM Software Engineering Notes.April 1982, pp. 29-32.

[Radice et aI, 1985]. R. A. Radice et aI, "A Programming ProcessArchitecture," IBM Systems Journal. Vol. 24, No.2, 1985, pp. 79-90.

[Royce, 1970]. W. W. Royce, "Managing the Development of LargeSoftware Systems: Concepts and Techniques," Proc. WESCON. August,1970. Also in Proceedings ICSE 9. April 1987.