Using the WinWin Spiral Model: A Case Study Computing Practices Fifteen teams used the WinWin spiral model to prototype, plan, specify, and build multimedia applications for USC’s Integrated Library System. The authors report lessons learned from this case study and how they extended the model’s utility and cost-effectiveness in a second round of projects. Barry Boehm t the 1996 and 1997 International Con- Alexander ferences on Software Engineering, three of the six keynote addresses identified Egyed negotiation techniques as the most critical Julie Kwan success factor in improving the outcome Aof software projects. At the USC Center for Software Dan Port Engineering, we have been developing a negotiation- Archita Shah based approach to software system requirements engi- University of neering, architecture, development, and management. Southern Our approach has three primary elements: California • Theory W, a management theory and approach, Ray Madachy which says that making winners of the system’s Litton Data key stakeholders is a necessary and sufficient con- Systems and dition for project success.1 University of • Southern The WinWin spiral model, which extends the spi- California ral software development model by adding Theory W activities to the front of each cycle. The sidebar “Elements of the WinWin Spiral Model” describes The study showed that the WinWin spiral model is these extensions and their goals in more detail. a good match for multimedia applications and is likely • WinWin, a groupware tool that makes it easier to be useful for other applications with similar char- for distributed stakeholders to negotiate mutu- acteristics—rapidly moving technology, many candi- ally satisfactory (win-win) system specifications.2 date approaches, little user or developer experience with similar systems, and the need for rapid comple- In this article, we describe an experimental valida- tion. The study results show that the model has three tion of this approach, focusing on the application of main strengths. the WinWin spiral model. The case study involved extending USC’s Integrated Library System to access • Flexibility. The model let the teams adapt to accom- multimedia archives, including films, maps, and panying risks and uncertainties, such as a rapid pro- videos. The Integrated Library System is a Unix-based, ject schedule and changing team composition. text-oriented, client-server COTS system designed to • Discipline. The modeling framework was suffi- manage the acquisition, cataloging, public access, and ciently formal to maintain focus on achieving circulation of library material. The study’s specific goal three main, or “anchor-point,” milestones: the was to evaluate the feasibility of using the WinWin life-cycle objectives, the life-cycle architecture, and spiral model to build applications written by USC the initial operational capability. (Table A in the graduate student teams. The students developed the sidebar describes these milestones.) applications in concert with USC library clients, who • Trust enhancement. The model provided a means had identified many USC multimedia archives that for growing trust among the project stakeholders, seemed worthy of transformation into digitized, user- enabling them to evolve from adversarial, con- interactive archive management services. tract-oriented system development approaches 0018-9162/98/$10.00 © 1998 IEEE July 1998 33 Elements of the WinWin Spiral Model Since its creation, the spiral model has duce the key product and process objec- been extensively elaborated2 and success- tives, constraints, and alternatives for the The original spiral model1 uses a cyclic fully applied in numerous projects.3,4 next version.6 The model includes a stake- approach to develop increasingly detailed However, some common difficulties led holder WinWin negotiation approach that elaborations of a software system’s defin- USC-CSE and its affiliate organizations to is similar to other team approaches for ition, culminating in incremental releases extend the model to the WinWin spiral software and system definition such as of the system’s operational capability. model described in the main text. gIBIS, Viewpoints, Participatory Design, Each cycle involves four main activities: and Joint Application Design. However, Negotiation front end unlike these and other approaches, we use • Elaborate the system or subsystem’s One difficulty was determining where the stakeholder win-win relationship as the product and process objectives, con- the elaborated objectives, constraints, and success criterion and organizing principle straints, and alternatives. alternatives come from. The WinWin spi- for software and system definition. Our • Evaluate the alternatives with respect ral model resolves this by adding three negotiation guidelines are based on the to the objectives and constraints. activities to the front of each spiral cycle, Harvard Negotiation Project’s techniques.7 Identify and resolve major sources of as Figure A shows.5 product and process risk. Process anchor points • Elaborate the definition of the prod- • Identify the system or subsystem’s key Another difficulty in applying the spiral uct and process. stakeholders. model across an organization’s various pro- • Plan the next cycle, and update the • Identify the stakeholders’ win condi- jects was that the organization has no com- life-cycle plan, including partition of tions for the system or subsystem. mon reference points for organizing its the system into subsystems to be • Negotiate win-win reconciliations of management procedures, cost and schedule addressed in parallel cycles. This can the stakeholders’ win conditions. estimates, and so on. This is because the include a plan to terminate the pro- cycles are risk driven, and each project has ject if it is too risky or infeasible. We have found in experiments with a different risks. In attempting to work out Secure the management’s commit- bootstrap version of the WinWin group- this difficulty with USC-CSE’s industry and ment to proceed as planned. ware tool that these steps do indeed pro- government affiliates using our Cocomo II cost model, we found a set of three process milestones, or anchor points,8 which we 3a. Reconcile win 2. Identify stakeholders' could relate to both the completion of spi- conditions. win conditions. ral cycles and to the organization’s major 3b. Establish next- 1. Identify decision milestones. level objectives, next-level The life-cycle objectives (LCO) and the constraints, and stakeholders. life-cycle architecture (LCA) milestones rat- alternatives. ify the stakeholders’ commitment to a fea- 7. Review and 4. Evaluate product and sible and consistent package of the six key commit. process alternatives. milestone elements shown in Table A for the Resolve risks. LCO anchor point. 6. Validate 5. Define next The LCO version focuses on establishing product level of product a sound business case for the package. It and process and process, need only show that there is at least one fea- definitions. including partitions. sible architecture. The LCA version commits to a single Figure A. How the WinWin spiral model differs from the original spiral model. The new model adds choice of architecture and elaborates it to the front-end activities (blue) that show where objectives, constraints, and alternatives come from. This point of covering all major sources of risk in lets users more clearly identify the rationale involved in negotiating win conditions for the product. the system’s life cycle.8 The LCA is the most toward methods that were mutually supportive MODEL APPLICATION and cooperative. We applied the WinWin spiral model in four cycles: From lessons learned during the case study, we iden- • Cycle 0. Determine the feasibility of an appro- tified several possible enhancements, some of which priate family of multimedia applications. we made. We then used the enhanced model on 16 • Cycle 1. Develop life-cycle objectives (LCO mile- projects in the following year. The second-year pro- stone), prototypes, plans, and specifications for indi- jects overcame many of the weaknesses in the first- vidual applications and verify the existence of at year projects. We are incorporating improvements least one feasible architecture for each application. identified by student critiques and are planning third- • Cycle 2. Establish a specific, detailed life-cycle year projects. Industry is also looking at the WinWin architecture (LCA milestone), verify its feasibil- spiral model. Companies such as Rational Inc. have ity, and determine that there are no major risks in already adopted several elements of the WinWin spi- satisfying the plans and specifications. ral model as part of their project management and • Cycle 3. Achieve a workable initial operational product life-cycle processes. capability (IOC milestone) for each project 34 Computer critical milestone in the software system’s life We found that the LCO and LCA mile- 4. T. Frazier and J. Bailey, “The Costs and cycle. As an analogy, it is similar to the commit- stones are highly compatible with the suc- Benefits of Domain-Oriented Software ment you make in getting married (just as LCO cessful architecture review board practice Reuse: Evidence from the STARS Demon- is like getting engaged and IOC like having your pioneered by AT&T and Lucent Technolo- stration Projects,” IDA Paper P-3191, Insti- first child). gies.9 We used board sessions about 20 per- tute for Defense Analyses, Alexandria, Va., The initial operational capability, or IOC, cent of the time in the first-year projects and 1996. anchor point has three key elements:8 100 percent of the time in the second-year 5. B. Boehm and P. Bose, “A Collaborative Spi- projects, with much better results. ral Software Process Model Based on Theory • Software preparation, including both W,” Proc. Int’l Conf. Software Process, IEEE operational and support software with References CS Press, Los Alamitos, Calif., 1994, pp. 59- appropriate commentary and documen- 1. B. Boehm, “A Spiral Model of Software 68. tation; data preparation or conversion; Development and Enhancement,” Computer, 6. B. Boehm et al., “Software Requirements as the necessary licenses and rights for May 1988, pp.