COVER FEATURE Value-Based Software Engineering: A Case Study The value-based approach to software development integrates value considera- tions into current and emerging software engineering principles and practices, while developing an overall framework in which these techniques compatibly reinforce each other. Barry Boehm he increasing pace of change in the infor- plex project. But it has absolutely nothing to say Li Guo mation technology field makes feedback about the stakeholder value of the system the pro- Huang control essential for organizations to sense, ject is developing. It serves a purpose, but needs to University of evaluate, and adapt to changing value be incorporated into feedback control systems that Southern California T propositions in their competitive market- focus on the real stakeholder value being earned. place. Traditional project feedback control mecha- The value-based software engineering agenda, nisms, such as earned-value systems, can effectively described in the “Accounting for Value in Software control the development efficiency of relatively sta- Engineering” sidebar, seeks to integrate value con- ble projects in well-established value situations. But siderations into current and emerging software these mechanisms are insensitive to the project’s engineering principles and practices, while devel- return-on-investment factors, and they can lead to oping an overall framework in which they com- wasteful misuse of an organization’s scarce resources. patibly reinforce each other. One area that VBSE Neglecting to monitor and control the value that addresses—value-based planning and control— software adds was not too risky when business val- includes principles and practices for extending tra- ues changed slowly and software made minor con- ditional cost, schedule, and product planning and tributions to them. However, such neglect is in- control techniques that also manage the value creasingly risky in today’s world of software-driven delivered to stakeholders. product lines and tornado-driven changes in the information technology marketplace—and will only USING EARNED VALUE become more so. Many IT projects have faithfully Performing feedback control of a large software delivered products on or near their planned bud- project becomes difficult because hundreds of tasks gets and schedules, only to find that the business progress concurrently during development. Some need for the product had largely disappeared, or tasks will be ahead on budget and schedule, that competitors had already captured its planned others behind. Current earned-value systems let market niche. managers of large projects achieve better control A particular anomaly in the monitoring and con- of such complex situations. trol area, the Earned Value Management System,1 Most software cost and schedule estimation provides a useful technique for monitoring and con- models include breakdowns of a project’s budget trolling the cost, schedule, and progress of a com- and schedule by software component, development 0018-9162/03/$17.00 © 2003 IEEE Published by the IEEE Computer Society March 2003 33 Accounting for Value in Software Engineering Developers perform much of current insufficient basis for an engineering disci- herit the system’s objectives and value software engineering practice and pline. Most concerns expressed about the considerations. research in a value-neutral setting, in adequacy of software engineering focus on • Verification and validation. Ensuring which they tend to do the following: the shortfalls in its underlying science. But that a software solution satisfies its it is difficult for a value-neutral approach value objectives, and organizing • treat every requirement, use case, to provide guidance for satisfying the engi- V&V tasks to operate as an invest- object, and defect as equally impor- neering definition of making its products ment activity. tant; useful to people, as this involves dealing • Planning and control. Extending tra- • express and practice methods as with different people’s utility functions or ditional cost, schedule, and product largely logical activities involving value propositions. planning and control techniques to mappings and transformations; include the value delivered to stake- • use earned-value systems to track A value-based software holders. project cost and schedule, but not engineering agenda • Risk management. Developing prin- stakeholder or business value; Progress has been made over the years ciples and practices for identifying, • practice a separation of concerns to integrate some value-oriented perspec- analyzing, prioritizing, and mitigat- that confines software engineers’ tives into software engineering. This ing risk. responsibility to turning software includes approaches such as participatory • Quality management. Prioritizing requirements into verified code; and design, user engineering, cost estimation, desired quality factors with respect • set goals for improving productiv- software economics, software investment to stakeholders’ value propositions. ity or correctness independent of analysis, and software engineering ethics. • People management. Stakeholder stakeholder value considerations. However, these approaches generally have teambuilding and expectations man- been treated as add-on band-aids to base- agement, managing the project’s Given that today’s software has a major line software engineering principles and accommodation of all stakeholders’ influence on system costs, schedule, and practices. The value-based software engi- value propositions throughout the value, and that software decisions inter- neering agenda1 includes the following life cycle, and integrating ethical con- twine inextricably with system-level deci- elements: siderations into daily project practice. sions, we can no longer afford to follow • Principles and practices. These this approach. • Requirements engineering. Develop- include COTS-based systems, rapid Further, value-neutral software engi- ing principles and practices for iden- development, agile methods, high- neering principles and practices cannot tifying a system’s success-critical dependability systems, systems of deal with most sources of software pro- stakeholders, eliciting their value systems, and ethics. ject failure. Major studies such as the propositions with respect to the sys- Standish Group’s CHAOS report (www. tem, and reconciling these value This agenda has been actively pursued standishgroup.com) reveal that value-ori- propositions into a mutually satisfac- by the Economics-Driven Software Engi- ented shortfalls cause most software pro- tory set of objectives for the system. neering Research (EDSER) community ject failures. These shortfalls include lack • Architecting. Reconciling system (www.edser.org). of user input, incomplete or changing objectives with achievable architec- requirements, lack of resources, unrealis- tural solutions. Reference tic expectations, unclear objectives, and • Design and development. Developing 1. B. Boehm, Value-Based Software Engineer- unrealistic time frames. techniques to ensure that the soft- ing, to be published in ACM Software Value-neutral methods also provide an ware’s design and development in- Eng. Notes, Mar. 2003. phase, and task activity. A development team can budgeted cost of work scheduled (BCWS), use these models to set up an earned-value system which equals the sum of the earned values for in which it can consider the estimated cost for each all tasks scheduled to be completed by time T; task as the value earned for the project when the the budgeted cost of work performed (BCWP), task completes. or project-level earned value, which equals the The earned-value system works as follows. sum of the earned values for all tasks actually completed by time T; and the actual cost of the 1. The project team develops a set of tasks neces- project through time T. sary for the project’s completion, and associ- 4. If the BCWP equals or exceeds the BCWS, the ated budgets and schedules for each task. project is on or ahead of schedule. 2. Developers assign each task an earned value 5. If the BCWP equals or exceeds the project cost, (EV) for its completion, usually its task budget. the project is on or ahead of budget. 3. As a project proceeds, the project team reviews 6. If the BCWP is significantly less than the BCWS, three primary quantities at selected times T: the the project cost at time T, or both, the project 34 Computer Yes Develop/ Perform BCWP≥ Yes BCWP≥ update plans, to plans BCWS? cost? BCWS is significantly overrunning its schedule, bud- get, or both, and corrective action must be per- No No formed. Determine corrective actions Figure 1 summarizes the six earned-value feedback process steps. Earned-value system example Figure 1. Earned-value feedback process. The process first determines if the Figure 2 provides an example of how the earned- budgeted cost of work performed (BCWP) is greater than or equal to the budgeted value system can help assess the likely cost to com- cost of work scheduled (BCWS). It next determines if BCWP is greater than or plete a software project and how to track its equal to cost. If both hold true, development proceeds; if either proves false, the progress. For simplicity, we assume that the pro- project team determines corrective actions. ject starts with four sequential tasks: prototypes, analyses, plans, and specs. First, we assign an earned value to each task. We estimate that the completion of prototypes will take two months and $15,000, the analyses