Observations on Estimation

• Estimation of resources, cost, and schedule for a

software engineering effort requires
– experience
– access to good historical information (metrics)
– the courage to commit to quantitative predictions
when qualitative information is all that exists

• Estimation carries inherent risk and this risk leads to

uncertainty
Project Complexity
• Project complexity has a strong effect on the uncertainty inherent in
planning.
• Complexity, however, is a relative measure that is affected by familiarity
with past effort

Project Size
• As size increases, the interdependency among various elements of the
software grows rapidly.

Degree of Structural uncertainty

• It also has an effect on estimation risk.
• Structure refers to the degree to which requirements have been solidified,
the ease with which functions can be compartmentalized, and the
hierarchical nature of the information that must be processed.
 Project Planning Task Set-I
• Establish project scope

• Determine feasibility

• Analyze risks
– Risk analysis is considered

• Define required resources

– Determine require human resources
– Define reusable software resources
– Identify environmental resources
 Project Planning Task Set-II
• Estimate cost and effort
– Decompose the problem
– Develop two or more estimates using size, function points,
process tasks or use-cases
– Reconcile the estimates

• Develop a project schedule

– Scheduling is considered.
• Establish a meaningful task set
• Define a task network
• Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms
 Software scope and feasibility
• Software scope describes
– the functions and features that are to be delivered to end users;
– the data that are input and output;
– the “content” that is presented to users as a consequence of using the
software; and
– the performance, constraints, interfaces, and
– reliability that bound the system.

• Scope is defined using one of two techniques:

1. A narrative description of software scope is developed after
communication with all stakeholders.
2. A set of use cases is developed by end users.
Time—Will the project’s time-to-market beat the competition? Resources
—Does the organization have the resources needed to succeed?
 Resources
number software
tools
skills hardware

people
environment network
location resources

project

reusable
software
OTS new
components components

full-experience part.-experience
components components
 RESOURCES

3 major categories of software engineering resources

1. people,
2. reusable software components, and
3. the development environment(hardware and software tools).

Each resource is specified with four characteristics:

4. description of the resource,
5. a statement of availability,
6. Time when the resource will be required, and
7. duration of time that the resource will be applied.

The last two characteristics can be viewed as a time window.

 Human Resources
• For relatively small projects (a few person-months), a single
individual may perform all software engineering tasks,
consulting with specialists as required.

• For larger projects, the software team may be geographically

dispersed across a number of different locations.

• Hence, the location of each human resource is specified.

• The number of people required for a software project can be

determined only after an estimate of development effort
 Reusable software resources
• Reusability—that is, the creation and reuse of software building
blocks.
• Such building blocks, often called components, must be
cataloged for
– easy reference,
– standardized for easy application, and
– validated for easy integration
• 4 software resource categories
1. Off-the shelf components
2. Full-experience components
3. Partial-experience components
4. New components
Off-the-shelf components.
• Existing software that can be acquired from a third party or from a past project.
• COTS (commercial off-the-shelf) components are purchased from a third party, are
ready for use on the current project, and have been fully validated.

Full-experience components.
• Existing specifications, designs, code, or test data developed for past projects that
are similar to the software to be built for the current project.

Partial-experience components.
• Existing specifications, designs, code, or test data developed for past projects that
are related to the software to be built for the current project but will require
substantial modification.

New components.
• Software components must be built by the software team specifically for the needs
of the current project.
 Environmental Resources
• The environment that supports a software project, often called
the software engineering environment (SEE), incorporates
hardware and software.

• Hardware provides a platform that supports the tools (software)

required to produce the work products that are an outcome of
good software engineering practice.

• When a computer-based system (incorporating specialized

hardware and software) is to be engineered, the software team
may require access to hardware elements being developed by
other engineering teams.
 Software project estimation
• Software project estimation can be transformed from a black
art to a series of systematic steps that provide estimates with
acceptable risk.
• To achieve reliable cost and effort estimates, a number of
options arise:
1. Delay estimation until late in the project
2. Base estimates on similar projects that have already been
completed.
3. Use relatively simple decomposition techniques to generate
project cost and effort estimates.
4. Use one or more empirical models for software cost and effort
estimation.
 Decomposition Techniques
• The decomposition approach uses two different points of view:
1. decomposition of the problem and
2. decomposition of the process.
Software Sizing
The accuracy of a software project estimate is predicated on a number of
things:
(1) the degree to which you have properly estimated the size of the product to
be built;
(2) the ability to translate the size estimate into human effort, calendar time,
and dollars
(3) the degree to which the project plan reflects the abilities of the software
team; and
(4) the stability of product requirements and the environment that supports the
software engineering effort.
 4 Approaches to the sizing problem
Fuzzy logic” sizing.
• It uses the approximate reasoning techniques that are the cornerstone of fuzzy logic.
• The planner must identify the type of application, establish its magnitude on a qualitative scale,
and then refine the magnitude within the original range.
Standard component sizing.
• Software is composed of a number of different “standard components” that are generic to a
particular application area.
• For example, the standard components for an information system are subsystems,
– modules,
– screens,
– reports,
– interactive programs,
– batch programs,
– files,
– LOC and
– object-level instructions
• The project planner estimates the number of occurrences of each standard component and then
uses historical project data to estimate the delivered size per standard component.
 Contd…
Function point sizing.
• The planner develops estimates of the information domain
characteristics.

Change sizing.

• This approach is used when a project encompasses the use of existing

software that must be modified in some way as part of a project.

• The planner estimates the number and type (e.g., reuse, adding code,
changing code, deleting code) of modifications that must be
accomplished.
 Problem-based estimation
• LOC (Lines of Code) and FP (Function Points) data are used in two ways
during software project estimation:
(1) as estimation variables to “size” each element of the software and
(2)as baseline metrics collected from past projects and used in conjunction
with estimation variables to develop cost and effort projections.
• In general, LOC/pm or FP/pm averages should be computed by project
domain.
• That is, projects should be grouped by
– team size,
– application area,
– complexity,
– and other relevant parameters.
• Local domain averages should then be computed.
• When a new project is estimated, it should first be allocated to a domain,
and then the appropriate domain average for past productivity should be
used in generating the estimate.
 Contd…
• Using historical data or (when all else fails) intuition, estimate an
optimistic, most likely, and pessimistic size value for each function or
count for each information domain value.
• An implicit indication of the degree of uncertainty is provided when a
range of values is specified.
• A three-point or expected value can then be computed. The expected value
for the estimation variable (size) S can be computed as a weighted average
of the optimistic (sopt), most likely (sm), and pessimistic (spess) estimates.
For example,

• Once the expected value for the estimation variable has been determined,
historical LOC or FP productivity data are applied
 Example: LOC Approach

Average productivity for systems of this type = 620 LOC/pm.

Burdened labor rate =$8000 per month, the cost per line of code is
approximately $13.
Based on the LOC estimate and the historical productivity data, the total
estimated project cost is $431,000 and the estimated effort is 54 person-
months.
 Example: FP Approach

The estimated number of FP is derived:

FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total estimated
project cost is $461,000 and estimated effort is 58 person-months.
Each of the complexity weighting factors is estimated, and the value
adjustment factor is computed
 Project based Estimation
• The most common technique for estimating a project is to base the estimate
on the process that will be used.
• That is, the process is decomposed into a relatively small set of tasks and
the effort required to accomplish each task is estimated.
• estimate the effort (e.g., person-months) that will be required to
accomplish each software process activity for each software function.
• These data constitute the central matrix of the table
• Average labor rates (i.e., cost/unit effort) are then applied to the effort
estimated for each process activity
• Costs and effort for each function and framework activity are computed as
the last step
• If process-based estimation is performed independently of LOC or FP
estimation, we now have two or three estimates for cost and effort that may
be compared and reconciled.
 Process-Based Estimation Example

Based on an average burdened labor rate of $8,000 per

month, the total estimated project cost is $368,000
and the estimated effort is 46 person-months.
 Estimation with use cases
• Use cases provide a software team with insight into software scope and
requirements
1. Use cases are described using many different formats and styles—
there is no standard form.
2. Use cases represent an external view (the user’s view) of the software
and can therefore be written at many different levels of abstraction.
3. Use cases do not address the complexity of the functions and features
that are described.
4. Use cases can describe complex behavior (e.g., interactions) that
involve many functions and features.

• Use cases can be used for estimation, but only if they are considered within
the context of the “structural hierarchy” that they are used to describe
 Estimation with Use-Cases

Using 620 LOC/pm as the average productivity for systems of this type and
a burdened labor rate of $8000 per month, the cost per line of code is
approximately $13. Based on the use-case estimate and the historical
productivity data, the total estimated project cost is $552,000 and the
estimated effort is 68 person-months.
 Reconciling estimates
• Multiple estimates that must be reconciled to produce a single
estimate of effort, project duration, or cost

• Widely divergent estimates can often be traced to one of two

causes:
(1) the scope of the project is not adequately understood or has
been misinterpreted by the planner, or
(2) productivity data used for problem-based estimation
techniques is inappropriate for the application, obsolete or has
been misapplied
 Empirical Estimation Models
• The empirical data that support most estimation models are derived from a
limited sample of projects.

• An estimation model should be calibrated to reflect local conditions.

• The model should be tested by applying data collected from completed

projects, plugging the data into the model, and then comparing actual to
predicted results.

• If agreement is poor, the model must be tuned and retested before it can be
used.
 Structure of Estimation models
• A typical estimation model is derived using regression analysis on data
collected from past software projects

• where A, B, and C are empirically derived constants, E is effort in person-

months, and ev is the estimation variable (either LOC or FP).
 COCOMO II Model
• COCOMO, for COnstructive COst MOdel.
• The original COCOMO model became one of the most widely used and
discussed software cost estimation models in the industry.
• It has evolved into a more comprehensive estimation model, called
COCOMOII
• COCOMO II address the following areas:
Application composition model.
• Used during the early stages of software engineering, when prototyping of
user interfaces, consideration of software and system interaction, assessment
of performance, and evaluation of technology maturity are paramount.
Early design stage model.
• Used once requirements have been stabilized and basic software architecture
has been established.
Post-architecture-stage model.
• Used during the construction of the software.
 Contd..
• Three different sizing options are available as part of the model hierarchy:
1. object points,
2. function points, and
3. lines of source code.
• The object point is an indirect software measure that is computed using
counts of the number of
(1) screens (at the user interface),
(2) Reports, and
(3) components likely to be required to build the application.
• When component-based development or general software reuse is to be
applied, the percent of reuse (%reuse) is estimated and the object point
count is adjusted

• where NOP is defined as new object points

 Contd..
• To derive an estimate of effort based on the computed NOP value, a
“productivity rate” must be derived

• Once the productivity rate has been determined, an estimate of project

effort is computed using
 The software Equation
• The software equation [Put92] is a dynamic multivariable model that
assumes a specific distribution of effort over the life of a software
development project

• The software equation has two independent parameters:

(1) an estimate of size (in LOC) and
(2) an indication of project duration in calendar months or years.
 Estimation for object oriented projects
• Software cost estimation methods with a technique that has been designed
explicitly for OO software

1.Develop estimates using effort decomposition, FP analysis, and any other

method that is applicable for conventional applications.
2. Using the requirements model, develop use cases and determine a count.
Recognize that the number of use cases may change as the project
progresses.
3. From the requirements model, determine the number of key classes
4. Categorize the type of interface for the application and develop a multiplier
for support classes
5. Multiply the total number of classes (key + support) by the average
number of work units per class
6. Cross-check the class-based estimate by multiplying the average number of
work units per use case.
 Specialized Estimation Techniques
Estimation for Agile Development
• Estimation for agile projects uses a decomposition approach that encompasses the
following steps:
1. Each user scenario (the equivalent of a mini use case created at the very start of
a project by end users or other stakeholders) is considered separately for
estimation purposes.
2. The scenario is decomposed into the set of software engineering tasks that will
be required to develop it.
3a. The effort required for each task is estimated separately. Note: Estimation can
be based on historical data, an empirical model, or “experience.”
3b. Alternatively, the “volume” of the scenario can be estimated in LOC, FP, or
some other volume-oriented measure (e.g., use-case count).
4a. Estimates for each task are summed to create an estimate for the scenario.
4b. Alternatively, the volume estimate for the scenario is translated into effort
using historical data.
5. The effort estimates for all scenarios that are to be implemented for a given
software increment are summed to develop the effort estimate for the
increment.
 Contd..
• This estimation approach serves two purposes:

(1) to be certain that the number of scenarios to be included in

the increment conforms to the available resources, and

(2) to establish a basis for allocating effort as the increment is

developed.
 Estimation for WebApp Projects
• A modified function point measure, coupled with the steps outlined, can be
used to develop an estimate for the WebApp

1. Inputs are each input screen or form (for example, CGI or Java), each
maintenance screen, and if you use a tab notebook metaphor anywhere,
each tab.
2. Outputs are each static Web page, each dynamic Web page script (for
example, ASP,ISAPI, or other DHTML script), and each report
(whether Web based or administrative in nature).
3. Tables are each logical table in the database plus, if you are using XML
to store data in a file, each XML object (or collection of XML
attributes).
4. Interfaces retain their definition as logical files (for example, unique
record formats) into our out-of-the-system boundaries.
5. Queries are each externally published or use a message-oriented
interface. A typical example is DCOM or COM external references.
 The Make/Buy Decision
• Software engineering managers are faced with a make/ buy decision that can
be further complicated by a number of acquisition options:
(1) software may be purchased (or licensed) off-the-shelf,
(2)“full-experience” or “partial-experience” software components may be
acquired and then modified and integrated to meet specific needs, or
(3) software may be custom built by an outside contractor to meet the
purchaser’s specifications.

• In the final analysis, the make/buy decision is made based on the following
conditions:
(1) Will the delivery date of the software product be sooner than that for
internally developed software?
(2) Will the cost of acquisition plus the cost of customization be less than the
cost of developing the software internally?
(3) Will the cost of outside support (e.g., a maintenance contract) be less than the
cost of internal support?
 Creating a Decision Tree
• The steps just described can be augmented using statistical
techniques such as decision tree analysis

• The software engineering organization can

(1) build system X from scratch,
(2) reuse existing partial-experience components to construct
the system,
(3) buy an available software product and modify it to meet
local needs, or
(4) contract the software development to an outside vendor.
 Outsourcing
• Software engineering activities are contracted to a third party who does the work at
lower cost and, hopefully, higher quality.
• Software work conducted within a company is reduced to a contract management
activity
• The decision to outsource can be either
1. strategic or
2. tactical.
• At the strategic level
– business managers consider whether a significant portion of all software work can
be contracted to others.
• At the tactical level
– a project manager determines whether part or all of a project can be best
accomplished by subcontracting the software work.
• Positive
– cost savings can usually be achieved by reducing the number of software people
and the facilities (e.g., computers, infrastructure) that support them
• Negative
– a company loses some control over the software that it needs
 Project Scheduling
• Software project scheduling is an action that distributes
estimated effort across the planned project duration by
allocating the effort to specific software engineering tasks
• Two rather different perspectives.
– In the first View
• an end date for release of a computer-based system has
already (and irrevocably) been established.
• The software organization is constrained to distribute
effort within the prescribed time frame.
– The second view
• software scheduling assumes that rough chronological
bounds have been discussed but that the end date is set
by the software engineering organization
 Basic Principles
Compartmentalization.
– The project must be divided into a number of manageable activities and tasks.
– To accomplish this, both the product and the process are refined.
Interdependency.
– The interdependency of each compartmentalized activity or task must be determined.
– Some tasks must occur in sequence, while others can occur in parallel.
– Other activities can occur independently.
Time allocation.
– Each task to be scheduled must be allocated some number of work units
Effort validation.
– Every project has a defined number of people on the software team.
– As time allocation occurs, you must ensure that no more than the allocated number of
people has been scheduled at any given time.
Defined responsibilities.
– Every task that is scheduled should be assigned to a specific team member.
Defined outcomes.
– Every task that is scheduled should have a defined outcome.
Defined milestones.
– Every task or group of tasks should be associated with a project milestone.
– A milestone is accomplished when one or more work products has been reviewed for
quality and has been approved.
 Relationship between people and effort
• The Putnam-Norden-Rayleigh (PNR) Curve provides an indication of the
relationship between effort applied and delivery time for a software project.

• The curve indicates a minimum value to that indicates the least cost for
delivery (i.e., the delivery time that will result in the least effort expended).

• As we move left of to (i.e., as we try to accelerate delivery), the curve rises

nonlinearly.

• we assume that a project team has estimated a level of effort Ed will be

required to achieve a nominal delivery time td that is optimal in terms of
schedule and available resources.

• Although it is possible to accelerate delivery, the curve rises very sharply to

the left of td.
 Effort and Delivery Time

Effort
Cost
Ea = m (td4 / ta4)

Impossible Ea = effort in person-months

region td = nominal delivery time for schedule
to = optimal development time (in terms of cost)
ta = actual delivery time desired
Ed

Eo

td to development time
Tmin = 0.75T d
 Contd..
• In fact, the PNR curve indicates that the project delivery time
cannot be compressed much beyond 0.75td.

• If we attempt further compression, the project moves into “the

impossible region” and risk of failure becomes very high.
•
• The PNR curve also indicates that the lowest cost delivery
option, to=2td.

• The implication here is that delaying project delivery can

reduce costs significantly.
 Contd…
• The number of delivered lines of code (source statements), L, is related to
effort and development time by the equation:

• Rearranging this software equation, we can arrive at an expression for

development effort E:

• EXAMPLE
• If LOC=33000, eight people are assigned to the project team, the project
can be completed in approximately 1.3 years.
• If, however, we extend the end date to 1.75 years, the highly nonlinear
nature of the model described in equation given below.
 Effort Distribution
• A recommended distribution of effort across the software process is often
referred to as the 40–20–40 rule.

– 40% - allocated to front-end analysis and design.

– 40% - back-end testing.
– We can correctly infer that coding (20 percent of effort) is deemphasized

• Customer communication and requirements analysis may comprise 10 to

25 percent of project effort

• A range of 20 to 25 percent of effort is normally applied to software design

• A range of 15 to 20 percent of overall effort can be achieved.

• Testing and subsequent debugging can account for 30 to 40 percent of

software development effort
Defining a task set for the software project
Software project types
1. Concept development projects
• New business concepts or applications
2. New application development projects
• Specific customer request
3. Application enhancement projects
• Existing project undergoes major modification
4. Application maintenance projects
• Correct, adapt or extend the existing one
5. Reengineering projects
• Rebuilding an existing one as whole
 A task set example
• Actions in concept development projects
– Concept scoping
• Overall scope of the project
– Preliminary concept planning
• Ability to undertake the work implied
– Technology risk assessment
• Risk associated as part of the project scope
– Proof of concept
• Demonstrates the viability of new technology
– Concept implementation
• Marketing reviewed by the customer
– Customer reaction
• Feedback from the customer
Refinement of software engineering actions

1.1 Concept scoping determines the overall

scope of the project.
Task definition: Task 1.1 Concept Scoping
1.1.1 Identify need, benefits and potential customers;
1.1.2 Define desired output/control and input events that drive the application;
Begin Task 1.1.2
1.1.2.1 FTR: Review written description of need
FTR indicates that a formal technical review (Chapter 26) is to be conducted.
1.1.2.2 Derive a list of customer visible outputs/inputs
1.1.2.3 FTR: Review outputs/inputs with customer and revise as required;
endtask Task 1.1.2
1.1.3 Define the functionality/behavior for each major function;
Begin Task 1.1.3
1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2;
1.1.3.2 Derive a model of functions/behaviors;
1.1.3.3 FTR: Review functions/behaviors with customer and revise as required;
endtask Task 1.1.3
1.1.4 Isolate those elements of the technology to be implemented in software;
is refined to 1.1.5 Research availability of existing software;
1.1.6 Define technical feasibility;
1.1.7 Make quick estimate of size;
1.1.8 Create a Scope Definition;
endTask definition: Task 1.1
Define a Task Network

I.5a
I.3a
Concept
Tech. Risk
Implement.
Assessment

I.1 I.2 I.3b I.4 I.5b I.6

Proof of Concept Integrate Customer
Concept Concept Tech. Risk
Concept Implement. a, b, c Reaction
scoping planning Assessment

I.3c I.5c
Tech. Risk Concept
Assessment Implement.

Three I.3 tasks are Three I.3 tasks are

applied in parallel to applied in parallel to
3 different concept 3 different concept
functions functions
 Timeline Charts
Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
 Use Automated Tools to Derive a Timeline Chart
Work tasks week 1 week 2 week 3 week 4 week 5
I.1.1 Identify need and benefits
Meet with customers
Identify needs and project constraints
Establish product statement
Milestone: product statement defined
I.1.2 Define desired output/control/input (OCI)
Scope keyboard functions
Scope voice input functions
Scope modes of interaction
Scope document diagnostics
Scope other WP functions
Document OCI
FTR: Review OCI with customer
Revise OCI as required;
Milestone; OCI defined
I.1.3 Define the functionality/behavior
Define keyboard functions
Define voice input functions
Decribe modes of interaction
Decribe spell/grammar check
Decribe other WP functions
FTR: Review OCI definition with customer
Revise as required
Milestone: OCI defintition complete
I.1.4 Isolate software elements
Milestone: Software elements defined
I.1.5 Research availability of existing software
Reseach text editiong components
Research voice input components
Research file management components
Research Spell/Grammar check components
Milestone: Reusable components identified
I.1.6 Define technical feasibility
Evaluate voice input
Evaluate grammar checking
Milestone: Technical feasibility assessed
I.1.7 Make quick estimate of size
I.1.8 Create a Scope Definition
Review scope document with customer
Revise document as required
Milestone: Scope document complete
 Schedule Tracking
– conduct periodic project status meetings in which each team member reports
progress and problems.

– evaluate the results of all reviews conducted throughout the software

engineering process.

– determine whether formal project milestones (the diamonds shown in Figure

27.3) have been accomplished by the scheduled date.

– compare actual start-date to planned start-date for each project task listed in the
resource table (Figure 27.4).

– meet informally with practitioners to obtain their subjective assessment of

progress to date and problems on the horizon.

– use earned value analysis (Section 27.6) to assess progress quantitatively.

 Progress on an OO Project-I
• Technical milestone: OO analysis completed
• All classes and the class hierarchy have been defined and reviewed.
• Class attributes and operations associated with a class have been
defined and reviewed.
• Class relationships have been established and reviewed.
• A behavioral model has been created and reviewed.
• Reusable classes have been noted.
• Technical milestone: OO design completed
• The set of subsystems has been defined and reviewed.
• Classes are allocated to subsystems and reviewed.
• Task allocation has been established and reviewed.
• Responsibilities and collaborations (Chapter 9) have been
identified.
• Attributes and operations have been designed and reviewed.
• The communication model has been created and reviewed.
 Progress on an OO Project-II
• Technical milestone: OO programming completed
• Each new class has been implemented in code from the design
model.
• Extracted classes (from a reuse library) have been implemented.
• Prototype or increment has been built.
• Technical milestone: OO testing
• The correctness and completeness of OO analysis and design
models has been reviewed.
• A class-responsibility-collaboration network has been developed
and reviewed.
• Test cases are designed and class-level tests have been conducted
for each class.
• Test cases are designed and cluster testing is completed and the
classes are integrated.
• System level tests have been completed.
 Scheduling for WebApp Projects
• Webapp project scheduling distributes effort
across the planned time line for building each
webapp increment
• It follows the timeline chart
• Each framework action can be adapted in four
ways (a number of increments)
– A task is applied as it is
– A task is eliminated because it is not necessary
– A new task is added
– A task is refined into a number of subtasks
 Earned Value Analysis (EVA)
• Earned value
– is a measure of progress

– enables us to assess the “percent of completeness” of a

project using quantitative analysis

– “provides accurate and reliable readings of performance

from as early as 15 percent into the project.”
 Computing Earned Value-I
• The budgeted cost of work scheduled (BCWS) is determined
for each work task represented in the schedule.

– BCWSi is the effort planned for work task i.

– To determine progress at a given point along the project

schedule,
– the value of BCWS is the sum of the BCWSi values for all
work tasks that should have been completed by that point
in time on the project schedule.
–
• The BCWS values for all work tasks are summed to derive the
budget at completion, BAC. Hence,

BAC = ∑ (BCWSk) for all tasks k

 Computing Earned Value-II
• Next, the value for budgeted cost of work performed (BCWP) is
computed.
– The value for BCWP is the sum of the BCWS values for all
work tasks that have actually been completed by a point in time
on the project schedule.
• “the distinction between the BCWS and the BCWP is that the
former represents the budget of the activities that were planned to
be completed and the latter represents the budget of the activities
that actually were completed.” [Wil99]
• Given values for BCWS, BAC, and BCWP, important progress
indicators can be computed:
• Schedule performance index, SPI = BCWP/BCWS
• Schedule variance, SV = BCWP – BCWS
• SPI is an indication of the efficiency with which the project
is utilizing scheduled resources.
 Computing Earned Value-III
• Percent scheduled for completion = BCWS/BAC
– provides an indication of the percentage of work that
should have been completed by time t.
• Percent complete = BCWP/BAC
– provides a quantitative indication of the percent of
completeness of the project at a given point in time, t.
• Actual cost of work performed, ACWP, is the sum of the effort
actually expended on work tasks that have been completed by
a point in time on the project schedule. It is then possible to
compute
• Cost performance index, CPI = BCWP/ACWP
• Cost variance, CV = BCWP – ACWP