3.

Software Estimation Metrics

1
 Software Metrics
Process and product indicators can be determined by collecting metrics.

Process metrics:
• Process metrics enable a software engineering organization to find the
usefulness of an existing process (i.e., the paradigm, software engineering
tasks, work products, and milestones).
• They enable managers and practitioners to assess what works and what
doesn’t.
• Process metrics are collected across all projects and over long periods of
time.
• Process metrics help long-term software process improvement.

2
 Software Metrics Continued…

Project metrics:

Project metrics enable a software project manager to

– assess the status of an ongoing project,

– track potential risks,

– Uncover problem areas before they go “critical,”
– adjust work flow or tasks

– evaluate the project team’s ability to control quality of

software work products.

3
 Process metrics

The way to improve any process is

– to measure specific attributes of the process,
– develop a set of metrics based on these attributes,
– use the metrics to provide indicators that will lead a policy
for improvement.

4
 Process metrics continued…

The figure below shows Determinants for software quality and

organizational effectiveness.
• In the figure the process resides at the centre of the triangle.
• Three corners of triangle are
– Product
– People
– Technology

5
 Process metrics continued…

• These factors have a profound impact on software quality and the

organizational performance.
– People: The skill set and motivation of the team members are the most
significant factors in quality and performance.
– Product: Complexity of the product also has greater impact on quality and
team performance.
– Technology: also have some impact.

• Process triangle exists within a circle of environmental conditions.

– the development environment (e.g., CASE tools),
– business conditions (e.g., deadlines, business rules),
– customer characteristics (e.g., ease of communication).

6
 Private Process Metrics

• There are “private and public” uses for different types of process
data.
• Individual software engineers might be sensitive to the use of
metrics collected on an individual basis, these data should be
private to the individual .
• These data serve as an indicator for the individual only.

• Examples: private metrics include defect rates (by individual),

defect rates (by module), and errors found during development.
• The “private process data” philosophy match up with the personal
software process approach proposed by Humphrey. 7
 Private Process Metrics continued…

The personal software process :

• is a structured set of process descriptions, measurements, and methods that can help
engineers to improve their personal performance.

• It provides the forms, scripts, and standards that help them estimate and plan their work.

• It shows them how to define processes and how to measure their quality and productivity.

• A fundamental PSP principle is that everyone is different and that a method that is
effective for one engineer may not be suitable for another.

• The PSP helps engineers to measure and track their own work so they can find the
methods that are best for them.

• Humphrey recognizes that software process improvement can and should begin at the
individual level. Private process data can serve as an important driver as the individual
software engineer works to improve.

8
 Public Process Metrics
• Some process metrics are private to the software project team but public to all team
members.

• Examples: defects reported for major software functions (that have been developed by a
number of practitioners), errors found during formal technical reviews, and lines of
code or function points per module and function.

• These data are reviewed by the team to uncover indicators that can improve team
performance.
• Public metrics generally incorporate information that originally was private to
individuals and teams.
• Project level defect rates (absolutely not attributed to an individual), effort, calendar
times, and related data are collected and evaluated in an attempt to uncover indicators
that can improve organizational process performance.

9
 Project Metrics

• Project Metrics and indicators derived from them are used by

project manager and software team.
• Using this they develop workflow and various activities.
• The first application of project metrics on most software
projects occurs during estimation.
• Metrics collected from past projects are used as a basis from
which effort and time estimates are made for current software.
• As soon as technical work begins, other significant project
metrics are also considered.
10
 Project Metrics continued…

• In addition to project metrics, the errors detected during each

task are also tracked.
• The intent of project Metrics is twofold:
– To avoid delays and mitigate potential problems and risks.
– The project metrics are used to assess the product quality on an ongoing
basis and whenever necessary can modify the technical approach to
improve quality.

• As quality improves, defects are minimized, and as the defect

count goes down, the amount of rework required during the
project is also reduced.
• This leads to a reduction in overall project cost.
11
 Software Project Estimation

• Software cost and effort estimation are never exact.

• The variables like human, technical, environmental, political

can affect the ultimate cost of software and the efforts applied
to develop it.
• Software Project Estimation can be transformed from a black
art to a series of systematic steps that provide estimates with
acceptable risk.

12
 Software Project Estimation continued…

• To achieve reliable cost and effort estimates a number of

options arise.
– Delay estimation until late in the project .
– Base the estimates on similar projects that have already been completed.
– Use relatively simple decomposition techniques to generate project cost
and effort estimates.

• Use one or more empirical models for software cost and effort
estimation.

13
 Observations on Estimation

• Software cost estimation and effort estimation are never be exact.

• There are various factors like Manpower, development environment ,
political environment that can affect the overall cost of project and efforts
taken to develop the project.
• Following are the ways to achieve reliable software project estimation.
– Try to delay estimation until late in the project .

– Use baseline metrics theory i.e. collect accurate estimates of past similar projects.

– Use simple decomposition techniques to obtain cost and effort estimates.

– Use more than one estimation models.

• Software Project Estimation is a form of problem solving and in most cases

problem to be solved is too complex.
• So, we decompose the problem, recharacterize it as a set of smaller
problems. 14
 SOFTWARE MEASUREMENT

• Cost and effort applied are the direct measures of the software
engineering process.
• Products have direct measures like lines of code(LOC)
produced, execution speed, memory size, and defects reported
over some set period of time.
• Products have indirect measures like functionality, quality,
complexity, efficiency, reliability, maintainability, and many
more.
• Software metrics are partitioned into process, project, and
product metrics.
15
 Size-Oriented Metrics

• Size-oriented software metrics are derived by considering

size of the software .
• A table of size-oriented measures is shown in Figure below ,

• The table lists each completed s/w development project and

corresponding measures for that project.

16
 Size-Oriented Metrics continued…
• 12,100 lines of code were developed with 24 person-months of
effort at a cost of $168,000.
• Effort and cost recorded represent not only coding but all s/w
engineering activities i.e. analysis, design, code, and test.
• 365 pages of documentation were developed.
• 134 errors were recorded before the software was released.
• 29 defects encountered after release to the customer.

• 3 people worked on the s/w development for project.

• To develop metrics that can be assimilated with similar metrics
from other projects, LOC is selected as normalization value.
 Size-Oriented Metrics continued…

• From the basic data in the table, a set of simple size-oriented

metrics can be developed .
– Errors per KLOC (thousand lines of code).
– Defects per KLOC.
– $ per LOC.
– Page of documentation per KLOC.

• In addition, other interesting metrics can be computed:

– Errors per person-month.
– LOC per person-month.

– $ per page of documentation.

 Function-Oriented Metrics

• Function-oriented software metrics use a measure of the

functionality as a normalization value delivered by application.
• Functionality is derived indirectly using other direct measures.

• Function-oriented metrics are called function point.

• Function points are derived using an empirical relationship based
on direct measures of software's information domain and
assessments of software complexity.
 Function-Oriented Metrics continued…

• Function points are computed by completing the table shown in

the following figure.
• Five information domain characteristics are determined and
counts are provided in the appropriate table location.
 Function-Oriented Metrics continued…

• Information domain values are defined as below.

– Number of user inputs
– Number of user outputs
– Number of user inquiries.
– Number of files
– Number of external interfaces.
• A complexity value is associated with each count.
• Organizations that use FP methods develop criteria for determining whether
a particular entry is simple, average, or complex.
Complexity S = ( Simple + 4 *Avg + Complex ) / 6
Weighing Factor= count*S
count total= Count 1 * S1 + Count 2 * S2 + ….+ Count i * Si

• Function Points (FP) is computed using following relationship.

FP = count total [0.65 + 0.01 Σ(Fi)]
where count total is the sum of all FP entries obtained
 Function-Oriented Metrics continued…

The Fi (i = 1 to 14) are "complexity adjustment values" based on

responses to the following questions.
1. Does the system require reliable backup and recovery?
2. Are data communications required?

3. Are there distributed processing functions?

4. Is performance critical?

5. Will the system run in an existing, heavily utilized operational environment?

6. Does the system require on-line data entry?

7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?

8. Are the master files updated on-line?

9. Are the inputs, outputs, files, or inquiries complex?

10. Is the internal processing complex?

 Function-Oriented Metrics continued…

11. Is the code designed to be reusable?

12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different
organizations?
14. Is the application designed to facilitate change and ease of use by the
user?

• Each of these questions is answered using a scale that ranges

from 0 (not important or applicable) to 5 (absolutely essential).
• Once function points have been calculated, they are used to
normalize measures for software productivity, quality, and other
• Attributes like Errors per FP., Defects per FP., $ per FP.,Pages of
documentation per FP., FP per person-month.
 Example:
Compute function point, productivity, documentation cost ,cost per function for the following
data:
Number of user inputs = 32
Number of user outputs = 60
Number of inquiries = 24
Number of files =8
Number of external interfaces = 2
Effort = 36.9 p-m
Technical documents = 265 pages
User documents = 122 pages
Cost = $7744/ month
Various processing complexity factors are: Fi = {4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5}
Weighing factor is given as 4,5,4,10,7 resp.

24
25
 Solution:

Measureme Count Weighing factor


FP = Count Total * [0.65 + 0.01 * ⅀(fi)]
nt
Parameter  Fi = {4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5}

⅀(Fi)= 43
Number of 32 4*32=128
user inputs

FP =618 * [0.65 + 0.01 *43]

=667.44
Number of 60 5*60=300
user Outputs

productivity=FP/efforts=667.44/ 36.9 =18.08

Number of 24 4*24=96

Total documentation cost = 265 + 122 = 387
inquiries pages

Cost per function = $7744 / 667.44 FP =
Number of 8 10*8=80
files $11.60 per function
FP = Count-Total * [0.65 + 0.01 *
⅀(fi)] 
Page per function = 387 pages / 667.44 FP =
Number of 2 7*2=14
interfaces
0.58 pages per function.


cost per function= cost/productivity
Count Total
618 = $7744 / 18.08 = $428.31


26
Difference Between Function Point and Lines of Code

27
 Project Scheduling

• Technical project is collection of hundreds of small tasks must occur to accomplish a

larger goal.
• Some tasks are outside the normal and may be completed without any impact on
project completion date.
• Other tasks lie on the "critical” path.
• If these "critical" tasks fall behind schedule, the completion date of the entire
project is put into risk.
• The objective of project manager is to define all project tasks, build a network that
shows their interdependencies, identify the tasks that are critical within the network,
and then track their progress to ensure that delay is recognized "one day at a time."
• Therefore manager must have a schedule that enables the manager to monitor
progress and control the project.
28
 Project Scheduling continued…

• Software project scheduling is an activity that distributes

estimated effort across the planned project duration by allocating
the effort to specific software engineering tasks.
• The schedule evolves over time.
• During early stages a macroscopic schedule is developed.
• This type of schedule identifies all major software engineering
activities and the functions.
• Each entry on the macroscopic schedule is as the project gets
under way.
• Scheduling for software engineering projects can be viewed from
two rather different perspectives. 29
 Project Scheduling continued…

• In the first, an end-date for release of project is established.

• The software organization is constrained to distribute effort

within the prescribed time frame.

• The second view of software scheduling assumes that rough

sequential bounds have been discussed.

• End-date is set by the software engineering organization.

• Effort is distributed to make best use of resources and an end-

date is defined after careful analysis of the software.

• Unfortunately, the first situation is encountered far more

frequently than the second. 30
 Basic Principles to Guide Software Project Scheduling

• Compartmentalization. The project must be compartmentalized into a number of

manageable activities and tasks.
• To accomplish compartmentalization, both the product and the process are decomposed.
• Interdependency. The interdependency of each compartmentalized activity or task must
be determined.

 Some activities cannot commence until the work product produced by another is
available.

 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
(e.g., person-days of effort). In addition, each task must be assigned a start date and a
completion date. These are a function of the interdependencies and whether work will be
conducted on a full-time or part-time basis.
31
 Basic Principles to Guide Software Project Scheduling

• Effort validation. Every project has a defined number of staff members. As

time allocation occurs, the project manager must ensure that no more than
the allocated number of people have been scheduled at any given time.

Example: consider a project that has three assigned staff members (e.g., 3
person-days are available per day of assigned efforts). On a given day, seven
concurrent tasks must be accomplished. Each task requires 0.50 person days
of effort. More effort has been allocated than there are people to do the
work.

• Defined responsibilities. Every task that is scheduled should be assigned to

a specific team member.

32
 Basic Principles to Guide Software Project Scheduling

• Defined outcomes. Every task that is scheduled should have a

defined outcome. For software projects, the outcome is normally
a work product (e.g., the design of a module) or a part of a work
product. Work products are often combined in deliverables.

• 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.

• Each of these principles is applied as the project schedule evolves.

33
 THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT

• In a small software development project, a single person can analyze

requirements, perform design, generate code, and conduct tests.
• As the size of a project increases, more people must become involved.
• There is a common myth believed by many managers in software
development effort: "If we fall behind schedule, we can always add
more programmers and catch up later in the project."
• Unfortunately, adding people late in a project often causes schedules to
slip even further because these people must learn the system, and the
people who teach them are the same people who were doing the work.

34
 THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT continued…

• While teaching, no work is done, and the project falls further

behind.
• In addition to the time it takes to learn the system, more people
increase the number of communication paths and the
complexity of communication throughout a project.
• Although communication is absolutely essential to successful
software development, every new communication path requires
additional effort and therefore additional time.

35
 THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT continued…

Example 1:
• Consider four software engineers, each capable of producing 5000 LOC/year when
working on an individual project.
• When these four engineers are placed on a team project, six potential
communication paths are possible.
• Each communication path requires time that could otherwise be spent developing
software.
• We shall assume that team productivity (when measured in LOC) will be reduced by
250 LOC/year for each communication path, due to the overhead associated with
communication.
• Therefore, team productivity is 20,000 - (250 x 6) = 18,500 LOC/year—7.5 percent
less than what we might expect. 36
 THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT continued…

Example 2
• The one-year project on which the team is working falls behind
schedule, and with two months remaining, two additional people are
added to the team.
• The number of communication paths escalates to 14. The productivity
input of the new staff is the equivalent of 840 x 2 = 1680 LOC for the
two months remaining before delivery.
• Team productivity now is 20,000 + 1680 - (250 x 14) = 18,180 LOC/year.

The relationship between the number of people working on a

software project and overall productivity is not linear.
37
 An Empirical Relationship

• The number of delivered lines of code L, is related to effort and

development time by the equation:

L = P x E1/3 t4/3
• where E is development effort in person-months, P is a productivity
parameter that reflects a variety of factors that lead to high-quality
software engineering work (typical values for P range between 2,000
and 12,000), and t is the project duration in calendar months.
• Rearranging this software equation, we can arrive at an expression
for development effort E:

E = L3 / (P3 t4) 38
 An Empirical Relationship continued…

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

for development effort E:

E = L3 / (P3 t4)

where E is the effort expended (in person-years) over the entire

life cycle for software development and maintenance and t is
the development time in years.
• The equation for development effort can be related to development
cost by the inclusion of a burdened labor rate factor ($/person-year).
• This leads to some interesting results.

39
 An Empirical Relationship continued…

• Consider a complex, real-time software project estimated at 33,000

LOC, 12 person-years of effort. If 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 yields:
• E = L3 / (P3 t4 ) ~ 3.8 person-years
• This implies that, by extending the end-date six months, we can reduce
the number of people from eight to four.
• Benefit can be gained by using fewer people over a somewhat longer
time span to accomplish the same objective.
40
 Effort Distribution

• A recommended distribution of effort across the definition and development

phases is often referred to as the 40–20–40 rule.

• 40% of all effort is allocated to front-end analysis and design. A similar

percentage is applied to back-end testing. 20 percent of effort for coding.

• This effort distribution should be used as a guideline only.

• The characteristics of each project must dictate the distribution of effort.

• Work expended on project planning is rarely more than 2–3 percent of effort.

• Requirements analysis may comprise 10–25 percent of project effort.

41
 Effort Distribution continued…

• Effort on analysis or prototyping is directly proportional to project size and

complexity.
• A range of 20 to 25 percent of effort to software design.
• Time expended for design review and subsequent iteration must also be
considered.
• Testing and subsequent debugging can account for 30 – 40 percent of
software development effort.
• The criticality of the software often dictates the amount of testing that is
required.

42
 SCHEDULING
• Scheduling of different engineering activities can use available project
scheduling tools and techniques.
• Following are project scheduling tools and techniques.
– Program evaluation and review technique (PERT)
– Critical path method (CPM)

• These are project scheduling methods that can be applied to the software
development process.
• Both tools use the data and information received from the earlier
developments.
• Both tools allow to determine the critical path, duration of the projects and
time estimates for the individual activity, efforts taken, duration.
 TIMELINE CHARTS

• When creating a software project schedule, the planner begins with a

set of tasks.
• If automated tools are used, the work breakdown is input as a task
network or task outline. Effort, duration, and start date are then input
for each task. In addition, tasks may be assigned to specific individuals.
• As a result a timeline chart, also called a Gantt chart, is generated.
• A timeline chart can be developed for the entire project. Also separate
charts can be developed for each project function or for each
individual working on the project.
• Figure illustrates the format of
a timeline chart.
• All project tasks are listed in
the left-hand column.
• The horizontal bars indicate
the duration of each task.
• When multiple bars occur at
the same time on the calendar,
task concurrency is implied.
• The diamonds indicate
milestones.
• Figure illustrates project tables .
• Once the information necessary for the generation of a timeline chart has
been input, software project scheduling tools produce project tables.
• Project tables is a tabular listing of all project tasks, their planned and
actual start- and end-dates, and a variety of related information.
• Used in conjunction with the timeline chart, project tables enable the
project manager to track progress.
 Tracking the Schedule

• The project schedule provides a road map for a software project

manager.
• Project schedule defines the tasks and milestones that must be tracked
and controlled as the project proceeds.
• Tracking can be accomplished in a number of different ways:
– Conducting periodic project status meetings in which each team member reports
progress and problems.
– Evaluating the results of all reviews conducted throughout the software engineering
process.
– Determining whether formal project milestones have been accomplished by the
scheduled date.
– Comparing actual start-date to planned start-date for each project task listed in the
resource table.
– Meeting informally with practitioners to obtain their subjective assessment of progress
to date and problems on the horizon.
– Using earned value analysis to assess progress quantitatively.
47
 Tracking the Schedule continued…

• Control is employed by a software project manager to administer project

resources, cope with problems, and direct project staff.

• If things are going well, control is light. But when problems occur, the project

manager must exercise control to find a way of deal with problems as

quickly as possible.

• once a problem is identified, additional resources may be focused on the

problem area, staff may be redeployed or the project schedule can be

redefined.

48
 Tracking the Schedule continued…

Time-Boxing
• After facing severe deadline pressure, experienced project managers

sometimes use a project scheduling and control technique called time-boxing.

• The time-boxing strategy recognizes that the complete product may not be

deliverable by the predefined deadline.

• Therefore, an incremental software paradigm is chosen and a schedule is

derived for each incremental delivery. .

• The tasks associated with each increment are then time-boxed.

49
 Tracking the Schedule continued…

• This means that the schedule for each task is adjusted by working backward

from the delivery date for the increment.

• A “box” is put around each task. When a task hits the boundary of its time box

(plus or minus 10 percent), work stops and the next task begins.

• The initial reaction to the time-boxing approach is often negative: “If the work

isn’t finished, how can we proceed?”

• The answer lies in the way work is accomplished. By the time the time-box

boundary is encountered, it is likely that 90 percent of the task has been

completed. The remaining 10 percent, although important, can be delayed until the

next increment or be completed later if required.

• Rather than becoming “stuck” on a task, the project proceeds toward the delivery date.
50
 EARNED VALUE ANALYSIS
• Earned Value Analysis (EVA) is a technique for performing quantitative
analysis of progress.
• Humphrey discusses earned value in the following manner:
– The earned value system provides a common value scale for every task. The total
hours to do the whole project are estimated, and every task is given an earned
value based on its estimated percentage of the total.
– Earned value is a measure of progress. It enables us to assess the “percent of
completeness” of a project using quantitative analysis.

• Fleming and Koppleman [FLE98] argue that Earned value analysis “provides
accurate and reliable readings of performance from as early as 15 percent
into the project.”

51
 EARNED VALUE ANALYSIS continued…

To determine the earned value, the following steps are performed:

1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented
in the schedule. During the estimation activity, the work (in person-hours or person-days) of

each software engineering task is planned. Hence, 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.

2. The BCWS values for all work tasks are summed to derive the budget at completion, BAC.
Hence,

BAC = (BCWSk) for all tasks k

3. 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.
52
 EARNED VALUE ANALYSIS continued…

• The distinction between the BCWS and the BCWP is that BCWS represents
the budget of the activities that were planned to be completed and BCWP

represents the budget of the activities that actually were completed.

• 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.
• An SPI value close to 1.0 indicates efficient execution of the project schedule.
• SV is simply an absolute indication of variance from the planned schedule.
53
 EARNED VALUE ANALYSIS continued…

• 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.
• It is also possible to compute the actual cost of work performed, ACWP. The
value for 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.

54
 EARNED VALUE ANALYSIS continued…

• It is then possible to compute Cost performance index, CPI = BCWP/ACWP

• Cost variance, CV = BCWP – ACWP

• A CPI value close to 1.0 provides a strong indication that the project is within
its defined budget. CV is an absolute indication of cost savings or shortfall at a
particular stage of a project.
• Earned value analysis illuminates scheduling difficulties before they might
otherwise be apparent.
• This enables the software project manager to take corrective action before a
project crisis develops.

55