Abstract
The Value-Based Software Engineering (VBSE) agenda described
in the preceding article has the objectives of integrating value considerations
into current and emerging software engineering principles
and practices, and of developing an overall framework in
which they compatibly reinforce each other. In this paper, we
provide a case study illustrating some of the key VBSE practices,
and focusing on a particular anomaly in the monitoring and control
area: the “Earned Value Management System”. This is a most
useful technique for monitoring and controlling the cost, schedule,
and progress of a complex project. But it has absolutely nothing
to say about the stakeholder value of the system being developed.
The paper introduces an example order-processing software
project, and shows how the use of Benefits Realization
Analysis, stakeholder value proposition elicitation and reconciliation,
and business case analysis provides a framework for stakeholder-
earned-value monitoring and control.
Keywords: value, risk, software economics, software life cycle,
software management, requirements, architecting, software metrics,
earned value, business case analysis, monitoring and control,
stakeholder win-win
1. Introduction
The Value-Based Software Engineering (VBSE) agenda described
in [6] has the objectives of integrating value considerations
into current and emerging software engineering principles
and practices, and of developing an overall framework in which
they compatibly reinforce each other.
One of these areas is value-based planning and control, including
principles and practices for extending traditional cost,
schedule, and product planning and control techniques to include
planning and control of the value delivered to stakeholders.
Current approaches for software planning and control, such as
those in the Software Capability Maturity Model [19] focus on the
monitoring and control of the project’s planned commitments,
efforts, costs, schedules, technical activities, risks, product sizes,
and critical computer resources. They do not address the monitoring
and control of the reasons for which the project was established,
or of the actual value likely to be realized by the project’s
results.
Recent updates such as the Capability Maturity Model-
Integrated (CMMI) [1, 20] make some progress toward valuebased
project definition and planning. But their project monitoring
and control processes remain focused largely on monitoring
project progress with respect to execution plans.
Neglecting to monitor and control with respect to the value
added by software was not too risky when business values
changed slowly and software was a minor contributor to business
values. However, such neglect is increasingly risky in today’s
(and tomorrow’s) world of software-driven product lines and tornado-
driven [18] changes in the information technology marketplace.
Many projects have faithfully delivered products on or near
their planned budgets and schedules, only to find out that the business
need for the product has largely disappeared, or that competitors
have already captured its planned market niche.
A particular anomaly in the monitoring and control area is the
“Earned Value Management System” [2]. It is a most useful technique
for monitoring and controlling the process of a complex
project. But it has absolutely nothing to say about the stakeholder
value of the system being developed. It serves a purpose, but
needs to be incorporated into feedback control systems which focus
on the real stakeholder value being earned.
In section 2, we summarize how current earned value systems
are used for feedback control of software development. In sections
3 and 4, we provide an alternative approach for project feedback
control which focuses on the actual stakeholder value likely
to be earned by completing the project. Section 3 provides a
framework for monitoring and controlling for value in terms of the
DMR Benefits Realization Approach and on business case analysis,
using an order processing system as an example. Section 4
elaborates on the value-based feedback control mechanisms and
illustrates them via the example. Section 5 presents the conclusions
and promising directions for future research and development.
2. Using “Earned Value” for Feedback Control of
Software Development
Performing feedback control of large software projects becomes
very difficult, because there will be hundreds of tasks going
on concurrently. Some tasks will be ahead on budget and schedule;
others will be behind. Current “earned value” [12] systems
enable large-project managers to achieve better visibility and control
of such complex situations.
Most software cost and schedule estimation models include
breakdowns of a project’s budget and schedule by software component,
development phase, and task activity. This enables a project
to set up an Earned Value system in which the estimated cost
for each task can be considered as the value earned for the project
when the task is completed.
The Earned Value System works as follows:
1. The project develops a set of tasks necessary for completion,
and associated budgets and schedules for each.
2. Each task is assigned an earned value (EV) for its completion,
usually its task budget.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 1
3. As a project proceeds, three primary quantities are reviewed
at selected times T:
a. The Budgeted Cost of Work Scheduled (BCWS): the
sum of the EV’s of all tasks scheduled to be completed
by time T.
b. The Budgeted Cost of Work Performed (BCWP), or
project level earned value: the sum of the EV’s of all
tasks actually completed by time T.
c. The actual cost of the project through time T.
4. If the BCWP (budgeted cost of work performed) is equal to or
greater than the BCWS (budgeted cost of work scheduled),
then the project is on or ahead of schedule.
5. If the BCWP is equal to or greater than the project cost, then
the project is on or ahead of budget.
6. If the BCWP is significantly less than the BCWS and/or the
project cost at the time T, then the project is significantly
overrunning its schedule and/or its budget, and corrective action
needs to be performed.
The six steps are summarized in the earned value feedback
process shown in Figure 1.
Figure 1. “Earned Value” Feedback Process
2.1 An Earned Value System Example
Figure 2 provides an example to explain how the Earned
Value System can help us to assess the project progress and likely
cost to complete a software project. For simplicity, we assume
that the project starts with four sequential tasks: prototypes, analyses,
plans and specs.
The first step is to assign an earned value to each task. We
estimate that the completion of prototypes will take 2 months and
$15,000, the analyses one month and $10,000, the plans one
month and another $10,000, and the specs one month and
$15,000. Therefore, the cumulative earned value we can get after
successfully finishing the four tasks is $50,000.
Let’s take a snapshot at the end of the fourth month to assess
the status and actual cost of the project as shown in Table 1. At
the end of the fourth month, we are scheduled to complete the first
three tasks which are prototypes, analyses and plans, so that the
cumulative BCWS (EVscheduled) is $35,000. However, we have
only finished the prototypes and analyses at the end of the fourth
month which only gave us a BCWP (EVperformed) of $25,000.
In this case, BCWP ($25,000) < BCWS ($35,000), which
means that we are behind schedule at the end of the fourth month.
On the other hand, the actual cost to finish the prototypes is
$14,000 and the actual cost to complete the analyses is $6,000.
Thus the cumulative actual cost of work performed is $20,000,
which indicates that the actual cost is below our budget for the
first two tasks.

Download full report
http://portal.acmft_gateway.cfm?id=638776&type=pdf