The Spiral Model – The Ultimate Guide to the SDLC

Barry W. Boehm is a mathematician and TRW Professor of Software Engineering, Computer Science Department Director, USC Center for Software Engineering. He started working as a Programmer-Analyst at General Dynamics in 1955 and switched to the Rand Corporation four years later where he was Head of the Information Sciences Department until 1973. From 1973 to 1989 he served as Chief Scientist of the Defense Systems Groupworked at TRW. Afterward he served until 1992 within the U.S. Department of Defense as Director of the Defense Advanced Research Projects Agency (DARPA) Information Science and Technology Office, and as Director of the DDR&E Software and Computer Technology Office.

He is known for his many contributions to software engineering including “the Constructive Cost Model (COCOMO), the Spiral Model of the software process, the Theory W (win-win) approach to software management and requirements determination and two advanced software engineering environments: the TRW Software Productivity System and Quantum Leap Environment.” He defined the Spiral Model in his 1986 article “A Spiral Model of Software Development and Enhancement.” The Spiral Model is a risk based approach which combines characteristics of evolutionary prototyping with the Waterfall Model. As envisioned by Boehm, the Spiral Model is intended for large, complex projects with durations of 6 months to 2 years. This iterative model influenced Model-Based Architecture and Software Engineering (MBASE) and Extreme Programming.

The United States Army adopted the Spiral Model for the development and upgrades of its Future Combat Systems (FCS) modernization program. Officially launched in 2003, FCS was foreseen to equip troops with manned and unmanned vehicles connected through an extraordinarily fast and flexible real-time battlefield network. The project was apportioned to four 2-year development spirals. Spiral 1 was scheduled to begin in FY2008 and deliver prototypes for use and evaluation. Following a successful Spiral 1 evaluation, Spiral 2 was scheduled to commence in FY2010. Production deployment as planned for 2015.

In August 2005, Boeing announced the completion of the project’s first major milestone, the Systems of Systems Functional Review. Boeing Company and Science Applications International Corporation (SAIC) we’re co-leads for the systems integration, coordinating more than 550 contractors and subcontractors in 41 states. By October 2005, the Pentagon recommended delaying the FCS project due to the high cost impact of the Iraq War, Hurricane Katrina relief efforts and the anticipation of future budget reductions. Budget cuts did arise and the project was canceled in June 2009. While the Spiral Model is suited for large projects, it never had the chance to prove its benefits in the intricate $3B interoperable, distributed combat related mission.

Today the Spiral Model has found a welcome home in the gaming industry. The large (>$3M) projects and continuously shifting goals of gaming systems development and resolutions achieved through evolutionary prototyping has created a demand for the process. For every spiral’s iteration, there are four activity quadrants which are:

1. Determine objectives, alternatives and constraints:
   1. System requirements are defined in as much detail as possible and include artifacts for functionality, performance, hardware/software interfaces, key success metrics, etc.
   2. Alternatives such as build vs. buy, can we reuse existing components or do we sub-contract are examined
   3. Constraints such as cost, schedule and interfaces are addressed
2. Identify and resolve risks, evaluate alternatives:
   1. All possible and available alternatives for developing a cost effective project are evaluated and strategies developed to determinate their use
   2. Identify and resolve all the possible risks in the project such as lack of experience, new technology, tight schedules, poor process, etc.
   3. Resolve any found risks and uncertainties. Subset reviews may be commissioned to investigate other process models until all high risk situations are resolved
3. Development and test: Prototype the system from the preliminary design. Follow the usual pattern of create and review design, code, inspect code and test
4. Plan the next iteration:
   1. Review the first prototype for strengths, weaknesses, and risks
   2. Elicit the requirements for the second prototype
   3. Plan and design the second prototype;
      1. Create the project plan
      2. Document the configuration management plan
      3. Construct a test plan
      4. Devise an installation plan

As the spirals progress and development intensifies, increasingly detailed system elaborations are defined, culminating in incremental releases of the system’s operational capability. A couple of the major problems with this approach are that spirals may continue indefinitely and each spiral is its own waterfall. It is iterative in terms of the delivery of evolutionary prototypes and linear in terms of how those prototypes are evaluated for risk and constructed. For the most part it’s best to avoid long-term project commitments due to potential changes in business priorities.