Software Cost Option Strategy Tool (S-COST

Approved for public release.Distribution unlimited.Center for Software EngineeringComputer Science Department University of Southern California Los Angeles, CA 90089-0781University of Southern CaliforniaCenter for SoftwareEngineeringCSETechnical ReportUSC/CSE-96-TR-500April 1996To Appear in COMPSAC’96(The 20th International Computer Softwareand Application Conference)Software Cost Option Strategy Tool (S-COST)Barry BoehmHoh InAcknowledgements : This research is sponsored by the Advanced Research Projects Agency (ARP A) throughRome Laboratory under contract F30602-94-C-0195 and by the Affiliates of the USC Center for Software Engineer-ing. The current Affiliates are Aerospace Corporation, Air Force Cost Analysis Agency , AT&T, Bellcore, DISA,Electronic Data Systems Corporation, E-Systems, Hughes Aircraft Company, Interactive Development Environ-ments, Institute for Defense Analysis, Jet Propulsion Laboratory, Litton Data Systems, Lockheed Martin Corporation,Loral Federal Systems, Motorola Inc., Northrop Grumman Corporation, Rational Software Corporation, Rockwell International, Science Applicatons International Corporation, Software Engineering Institute (CMU), Software Pro-ductivity Consortium, Sun Microsystems, Inc., Texas Instruments, TRW, U.S. Air Force Rome Laboratory, U.S.Army Research Laboratory, and Xerox Corporation.Software Cost Option Strategy Tool (S-COST)Barry Boehm and Hoh In(boehm, hohin)@Computer Science DepartmentCenter for Software EngineeringUniversity of Southern CaliforniaLos Angeles, CA 90089-0781, U.S.A.AbstractThe process of resolving cost-requirements conflicts is difficult because of incompatibilities among stakeholders’ interests and priorities, complex cost-requirements dependencies, and an exponentially increasing option space for larger systems. This paper describes an exploratory knowledge-based tool, the Software Cost Option Strategy Tool (S-COST), for assisting stakeholders to surface appropriate cost-resolution options, to visualize the options, and to negotiate a mutually satisfactory balance of requirements and cost.S-COST operates in the context of the USC-CSE WinWin system (a groupware support system for determining software and system requirements as negotiated win conditions), QARCC (a support system for identifying conflicts in quality requirements), and COCOMO (COnstructive COst estimation MOdel). Initial analyses of its capabilities indicate that its semiautomated approach provides users with improved capabilities for addressing cost-requirements issues.1. MotivationA critical success factor in requirements engineering is the balance of requirements commitments with available cost resources. Many software systems have come to grief due to a combination of commitments to costly but low-utility requirements (gold-plating), and/or inadequate budgets for high-utility requirements.The resolution process for such cost conflicts is complex due to:•Complex tradeoffs among cost and other attributes.•Difficulties in coordinating multiple stakeholders’interests and priorities.•Complex dependencies.Every requirements decision affects cost. Some requirements decisions may be not compatible with others.•Exponentially increasing option space.For very large software systems, both highly manual and highly automated approaches have difficulty in coping with the proliferation of candidate options for developing the system.Given the overall scarcity of software expertise and the complexity of cost conflict resolution, it is worth trying to capture such expertise and make it more broadly available via automated aids for cost conflict resolution.At least three major capabilities are necessary to resolve cost conflicts among requirements:•A general capability to surface and negotiate cost conflicts and risks among requirements.The USC-CSE WinWin system[4,5] provides an example of such a capability.•Capabilities to support the resolution of cost conflicts with functional quality requirements based on early information.The following aids provide examples of such capabilities.-Aids for identifying cost conflicts with functionalrequirements.The COCOMO (COnstructive COstestimation MOdel) [7] provides an example of sucha capability.-Aids for identifying cost conflicts with qualityrequirements based on early information. TheQARCC (Quality Attribute Risk and Conflict Con-sultant) tool [8] provides an example of such a capa-bility.•Capabilities to generate, visualize, and negotiate potential resolution options for cost conflicts.The S-COST described in this paper operates on the win conditions captured by the WinWin system and the results of COCOMO and QARCC analyses to provide such a capability.2. ContextS-COST operates in the context of the USC-CSE WinWin system (Section2.1) and the QARCC tool (Section2.2) to extend their capabilities.2.1 WinWinWinWin is a groupware support system for determining software requirements as negotiated win conditions. It is based on the WinWin Spiral Model, which uses the stakeholder win-win Theory W [2] to generate the objectives, constraints, and alternatives needed by the Spiral Model. WinWin assists the identified stakeholders in identifying and negotiating issues (i.e., conflicts among their win conditions), since the goal of Theory W, “Make everyone a winner,” involves stakeholders identifying their win conditions (sector 2 in Figure1), and reconciling conflicts among win conditions (sector 3).Figure 2 shows the negotiation model used by WinWin, in terms of its primary schemas and the relationships between them. Stakeholders begin by entering their WinConditions, using a schema provided by the WinWin system. If a conflict among stakeholders’ Win Conditions is determined, an Issue schema is composed, summarizing the conflict and the Win Conditions it involves.For each Issue, stakeholders prepare candidate Option schemas addressing the Issue. Stakeholders then evaluate the Options, iterate some, agree to reject others, and ultimately converge on a mutually satisfactory (i.e., win-win) Option. The adoption of this Option is formally proposed and ratified by an Agreement schema, including a check to ensure that the stakeholders’ iterated Win Conditions are indeed covered by the Agreement.Our experience with WinWin usage indicates that, as applications reach the size of several dozen Win Conditions, it becomes hard for stakeholders to identify the likely conflicts among them. Thus, we have been experimenting with automated aids such as QARCC and S-COST to help stakeholders identify Issues and formulate Options for resolving them.Figure 1. The WinWin Spiral Model 2.2 QARCCQARCC is an exploratory knowledge-based tool for identifying potential conflicts and risks among quality requirements early in the software life cycle.QARCC uses the “Attributes” portion of WinWin’s domain taxonomy to identify potential quality attributes conflicts. As stakeholders enter Win Conditions, they identify which domain taxonomy elements are relevant.An example domain taxonomy is shown in Figure 3. Suppose a stakeholder enters a Win Condition schema and puts “Assurance” in the Taxonomy Elements slot. QARCC will then draw on its knowledge base to analyze potential conflicts between Assurance and other quality attributes. It will then notify the affected stakeholders of the potential conflicts.To determine which stakeholders to notify of a potential conflict between Assurance and (say) Interoperability, QARCC uses the Stakeholder/Quality-Attribute Relationships shown in Figure4. In this case, QARCC would notify the Interoperator and User stakeholders of the potential conflict, as they are the stakeholders generally most concerned with Interoperability.Figure 2. WinWin Negotiation Model3. S-COST overviewS-COST extends WinWin and complements QARCC by using an additional software cost knowledge base related to another component of WinWin: the COnstructive COst MOdel, or COCOMO [7]. S-COST uses the COCOMO cost drivers, cost estimates, and related experience base to sharpen QARCC’s identification of cost-conflict Issues. It also suggests in-depth cost-conflict resolution Options, and provides Option visualization and negotiation aids to help stakeholders resolve the cost-conflict Issues.The S-COST concept of operation in shown in Figure 5. Using the WinWin system, stakeholders enter their new Win Conditions. These may involve functions,quality goals or constraints. As shown in Screen 1 of Figure 6, Win Condition schemas have attributes such as Priority and domain Taxonomy Elements. For Win Conditions with quality attribute and cost/schedule Taxonomy Elements, QARCC examines its architectural and process strategies [8] to search for potential conflicts.For example, Layering the architecture to meet the Portability Win Condition in Screen 1 of Figure 6 produces likely conflicts with Cost/Schedule and Performance (Screen 2 of Figure 6; in the initial version of QARCC,Figure 4. Stakeholder / Quality-Attribute&Portability &scheduleFigure 5. S-COST Concept of OperationCost and Schedule were combined into Development Affordability, and Performance was called Efficiency).QARCC then generates a draft Issue identifying this potential conflict for stakeholders to consider (Screen 3 of Figure 6).Continuing with the scenario in Figure 5, once stakeholders are presented with a set of draft Issues from QARCC involving cost, they can then use COCOMO to analyze the potential cost conflicts identified. If the resulting estimated cost exceeds the target cost, a stakeholder enters this as a WinWin Issue whose solution needs to be negotiated by the stakeholders.As indicated in Figure 5, S-COST operates on the Issue and COCOMO estimate information to:•Suggest options for resolving cost issues;•Notify affected stakeholders of their availability andimplications;•Provide visualization and negotiation aids for cost issue/option resolution.After the stakeholders converge on a mutually satisfactory (win-win) combination of options, they draft a WinWin Agreement schema, and follow WinWin’s procedures for voting on and adopting the Agreement.The next Section discusses the portions of the S-COST knowledge base supporting cost-resolution option generation and stakeholder notification. Section 5 then illustrates these and S-COST’s option visualization and negotiation support capabilities via an example.Figure 6. An Example of QARCCScreen 2: Potential by QARCCScreen 1: A new Win Condition entered by Stakeholderconflicts identified Screen 3:A draft Issue suggested by QARCC4. Primary cost options and stakeholder relationsTable 1 shows the top-level option strategies for resolving cost (and most schedule) issues. The strategies are primarily based on analysis of COCOMO cost drivers [7] whose labels are shown in column 2 of Table 1.•Reduce/defer functionality,which reduces cost byreducing the program (KDSI) and/or database (DATA)size, at least for the Initial Operational Capability (IOC).•Reduce/defer quality,which reduces cost by relaxing reliability (RELY) or performance (TIME) constraints,or by forgoing the complexities (CPLX) of providing graceful degradation, information security, etc.•Improve tools, techniques or platform,via a platform that is more powerful (TIME, STOR), stable (VIRT), or responsive (TURN); or via better software tools (TOOL) or practices (MODP).•Relax the delivery schedule constraint (SCED).Table 1. The Attributes of Cost-Resolution OptionStrategies•Improve personnel capabilities,via more capable teamsof analysts and programmers (ACAP , PCAP); stronger applications, platform, or language experience (AEXP ,VEXP, LEXP), or equivalent but lower-cost personnel ($K/MM).•Reuse software assets,by reusing or adopting more software assets (ADSI), with lower levels of design,code, or integration modification (DM, CM, IM).•Increase budget.This can be justified if the current Win Condition budget is insufficient to generate a critical-mass competitive product, or if the return on investment (ROI) is sufficiently increased. Of course, this option strategy cannot be used if added funds are not available (These points illustrate the option strategy’s Pros and Cons shown in columns 3 and 4 of Table 1).Reducing reliability or performance may be acceptable options for some stakeholders but not for others. S-COST uses the cost option/stakeholder relationships in Figure 4 to notify the appropriate stakeholders of options which may have first-order consequences for them. For each of the options in Table 1, Figure 4 shows the stakeholders who would generally be directly concerned with the exercise of the option. Thus, for example, “Increase budget” can potentially affect any of the stakeholders by providing them more capability, but the directly-concerned stakeholder is the Customer, who must find a way to justify and obtain the budget increase.5.S-COST visualization and negotiation aidsThe S-COST visualization and negotiation aids will be illustrated with respect to a satellite data processing scenario. In the scenario, the user, customer, and developer of a system called Strikeware have negotiated a $5 million,16-month upgrade to add Satellite Surveillance data services to a Mission Data Integration Facility (MDIF).The Strikeware user has determined that it will be important to add weather data services to the MDIF upgrade. A COCOMO estimate of the resulting added software indicates a $6.66 M cost and 17.6 month schedule, but the customer is strongly constrained to keep to the original $5M cost and 16 month schedule.Figure 7. Cost Option / Stakeholder RelationshipsS-COST has several capabilities to help the user,customer, and developer determine cost reduction options,visualize their impact on the problem situation, and negotiate a new win-win solution. For example, the Visualization window for option generation in Figure 8shows the cost reduction target of $5M as a w mark. It uses data on the priorities of the stakeholders’ functional module win conditions, and the corresponding COCOMO estimates of the module’s cost contribution, to produce a display of module cost contributions by priority.Using this display, the stakeholders could simply agree to drop or defer the lowest-priority modules until the cost target is reached. But there may be better options, such as splitting a module into higher and lower priority modules via the Operations button; or adjusting other cost drivers such as personnel capability and experience, improved tools, or software reuse via the Strategies button. Or, if justified and feasible, the customer could increase the budget, raising the target cost in the Target Cost field (Figure 8).5.1 Visualization window features for optiongenerationThe S-COST Visualization window in Figure 8 has a number of option strategies and display aids for stakeholders. Some selected features are highlighted below.Function Elements (FEs) in the FE window (right top)are sorted by the priority using “Sort-by-Priority”, one of the Operations buttons, based on the user-determined FEs.COCOMO-estimated cost and schedule appear in the left window,Status Area , along with User’s Id & Role, Priority of Option, and target cost & schedule. The OperationsFigure 8. Visualization Window for Optionwbutton is available to enable stakeholderrs to split, merge,insert, delete, and sort FE(s), as well as select_all,unselect_all, import, and export from/to COCOMO.The Strategies button brings up a menu containing the cost resolution strategies described in Table 1. Each strategy has parameters which can be defined or adjusted once the strategy has been selected. Figure 9 shows an example of applying a “Reduce/defer functionality”Strategy option. Option Strategies are prepared to defer 6KDSI of Query/Display (New) functionality and 9KDSI of MDIF Priority Upgrades functionality. The Pros & Cons area shows the potential positive and negative aspects of the option. If the stakeholder establishes this as an Option to be addressed in the WinWin system, the Pros & Cons will be included in the Option schema.5.2 Visualization window features for optionnegotiationAnother visualization aid (obtained via the Negotiation Aid button in Figure 8) provides the Option Strategy list (Figure 10), which summarizes the status of negotiating a combination of Option Strategies suggested by the various stakeholders. The Options can be displayed in order of originating stakeholders, the Option Strategies’ priority , or the type of the Option Strategy via the Options button.Stakeholders can revise their options after considering other stakeholders’ strategies and their priorities. This helps stakeholders reach a win-win combination of Cost-Resolution Strategies.The stakeholders continue to interact with S-COST and each other until they converge on a win-win cost reduction strategy with no win-lose side effects. At that point, the stakeholders can return to the WinWin system to draft, vote on, and adopt an Agreement resolving the Issue.Figure 9. Aids for Applying Cost-Resolution Strategy6. Related workThe main distinguishing features of the S-COST approach to conflict resolution are the use of the win-win Theory W, the use of domain-independent knowledge, and the emphasis on semiautomated user aids.Most software cost models, including COCOMO,provide numerical estimates which are often optimized based on decision theory, bargaining theory, and game theory, which can result in win-lose situations. Theory W,“Make everyone a winner”, stimulates stakeholders to find mutually satisfactory (i.e., win-win) solutions in generating and negotiating options.S-COST uses domain-independent knowledge in the sense that its cost-reduction strategies are adopted from the domain-independent COCOMO cost estimation model. In contrast, a number of conflict-resolution aids use domain-dependent knowledge for generating options. Examples are Easterbrook’s “Synoptic” tool [10] and Robertson’s “Oz”tool [14]. Such domain-dependent tools often have problems in scaling to complex domains besides their generality problems.S-COST focuses on supporting various stakeholders’collaboration and relies on stakeholders’ skills in converging on agreements involving multiple properties such as cost, functionality, and various quality properties.Tools which attempt to fully represent options and their relationships, such as gIBIS[9], SIBYL[11], and REMAP[12], tend to have scalability problems for complex systems. This is also true for fully-automated option analyzers, such as Robertson’s Oz [14] and Sycara’s PERSUADER[15]. Recently, Ramesh has embedded REMAP in a semiautomated concurrent engineering support system [13] to address such scalability problems.7. ConclusionsWe have done a comparative analysis of the options surfaced by stakeholders in the initial WinWin Strikeware exercise and the options generated and analyzed by S-COST. S-COST provides a more thorough set of candidate cost-resolution options and analysis of their pros and cons.Figure 10. The Option Strategy List WindowOn the other hand, S-COST could not generate situation-specific options, such as the User deciding to break up the Query/Display module into higher and lower priority submodules.Based on these strengths and limitations of automated approaches, we conclude that S-COST’s resulting semi-automated approach is stronger than a heavily manual approach or a heavily automated approach. We plan to continue experimentation with the balance of providing automated option generation and providing visualization and negotiation support for human users, to deal with more complex cost-related option generation and resolution situations.AcknowledgmentsThis research is sponsored by the Advanced Research Projects Agency (ARPA) through Rome Laboratory under contract F30602-94-C-0195 and by the Affiliates of the USC Center for Software Engineering.References[1]Basili, V . and Rombach, H., “Tailoring the software process to project goals and environments,”Proceedings of the ICSE-9, IEEE Computer Society Press, March, 1987, pp. 345-357.[2]Boehm, B. and Ross, R., “Theory W Software Project Management:Principles and Examples,”IEEE TOSE , July 1989, pp. 902-916.[3]Boehm, B., Brown, J., Kaspar, H., Lipow, M., MacLeod, G., and Merritt, M.,Characteristics of Software Quality , TRW Series of Software Technology Report TRW-SS-73-09, 1973.[4]Boehm, B., Bose, P., Horowitz, E., and Lee, M., “SoftwareRequirements As Negotiated Win Conditions,” P roceedings of the First ICRE ‘94, IEEE Computer Society Press, April, 1994, pp. 74-83.[5]Boehm, B., Bose, P., Horowitz, E., and Lee, M.,“SoftwareRequirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach,”Proceedings of ICSE-17, IEEE Computer Society Press, Seattle, April, 1995.[6]Boehm, B., “Some Steps Toward Formal and Automated Aids to Software Requirements Analysis and Design,”Proceedings of IFIP 74, August, 1974, pp. 192-197.[7]Boehm, B.,Software Engineering Economics , Prentice-Hall, 1981.[8]Boehm, B. and In, H., “Identifying Quality-Requirement Conflicts,”IEEE Software , IEEE Comp. Soc. Press, March, 1996, pp. 25-35.[9]Conklin, J. and Begeman, M., “gIBIS: A Hypertext Tool for Exploratory Plicy Discussion”,ACM Transactions on Office Information Systems , V ol. 6, 1988, pp. 303-331.[10]Easterbrook, S., “Handling conflict between domain descriptions with computer-supported negotiation”,Knowledge Acquisition , March,1991, pp. 255-289[11]Lee, J., “SIBYL: A Qualitiative Decision Management System”, In Artificial Intelligence at MIT: Expanding Frontiers , Edited by P.Winston and S. Shellard, MIT Press, Cambridge, 1990.[12]Ramesh, B. and Dhar, V ., “Supporting Systems Development by Capturing Deliberations During Requirements Engineering”,IEEE TOSE , V ol. 18 No.6, 1992, pp. 498-519.[13]Ramesh, B. and Sengupta, K., “Managing Cognitive and Mixed-motive Conflicts in Concurrent Engineering”,Concurrent Engineering , V ol. 18, No. 6, 1992, pp 498-519.[14]Robinson, W.N., and Fickas, S., “Automated Support forRequirements Negotiation”,AAAI-94 Workshop on Models of Conflict Management in Cooperative Problem Solving , 1994, pp. 90-96.[15]Sycara, K., “Problem Restructuring in Negotiations”,Management Science , V ol. 37, No. 10, 1991。