Chapter One

Basics of Software Metrics

Measurement
• Measurement is fundamental to any engineering
discipline
• Software Metrics - Broad range of measurements for
computer software
• Software Process - Measurement can be applied to
improve it on a continuous basis
• Software Project - Measurement can be applied in
estimation, quality control, productivity assessment &
project control
• Measurement can be used by software engineers in
decision making.
Page 2
Definitions
• Measure: Quantitative indication of the extent,
amount, dimension, capacity or size of some attribute
of a product or process

• Measurement: The act of determining a measure

• Metric: A quantitative measure of the degree to which

a system, component, or process possesses a given
attribute (IEEE Standard Glossary of Software
Engineering Terms) Page 3
Definitions

• Indicator: An indicator is a metric or

combination of metrics that provide insight
into the software process, a software project
or the product itself.

Page 4
Neglect of Measurement in Software Engineering

• We fail to set measurable targets for our software

products

• We fail to understand and quantify the component

cost of software projects

• We do not quantify or predict the quality of the

products we produce

• Too much reliance

Page 5
Why Do We Measure?
• To indicate the quality of the product
• To assess the productivity of the people who
produce the product
• To assess the benefits derived from new software
engineering methods and tools
• To form a baseline for estimation
• To help justify requests for new tools or additional
training

for Project Managers, Developers…

Page 6
Types of Metrics
1. Process Metrics: Describe the characteristics of the product
• Such as size, complexity, design features, performance, and
quality level
2. Product Metrics: Can be used to improve software
development and maintenance.
• Examples: the effectiveness of defect removal during
development, the pattern of testing defect arrival, and the
response time of the fix process
3. Project Metrics: Describe the project characteristics and
execution.
• Examples include the number of software developers, the
staffing pattern over the life cycle of the software, cost,
schedule, and productivity.
Page 7
Process Metrics
• Process metrics are measures of the software
development process, such as
– Overall development time
– Type of methodology used
• Process metrics are collected across all projects and
over long periods of time.
• Their intent is to provide indicators that lead to long
term software process improvement.

Page 8
 Process Metrics & Software Process
Improvement
• To improve any process, the rational way is:
– Measure Specific attributes of the process

– Derive meaningful metrics from these attributes.

– Use these metrics to provide indicators.

– The indicators lead to a strategy for improvement.

Page 9
Factors Affecting Software Quality

Page 10
 How to Measure Effectiveness of a Software
Process
• We measure the effectiveness of a software process indirectly
• We derive a set of metrics based on the outcomes that can be
derived from the process
• Outcomes include
– Errors uncovered before release of the software
– Defects delivered to and reported by end-users
– Work products delivered (productivity)
– Human effort expended
– Calendar time expended
– Conformance to schedule

Page 11
Project Metrics (1)
• Project Metrics are the measures of Software Project and
are used to monitor and control the project.

• They enable a software project manager to:

✓Minimize the development time by making the

adjustments necessary to avoid delays and potential
problems and risks.

✓Assess product quality on an ongoing basis & modify

the technical approach to improve quality.
Page 12
Project Metrics (2)

• Used in estimation techniques & other technical work.

• Metrics collected from past projects are used as a basis from
which effort and time estimates are made for current software
project.
• As a project proceeds, actual values of human effort &
calendar time expended are compared to the original
estimates.
• This data is used by the project manager to monitor & control
the project.

Page 13
Product metrics

• Product metrics are measures of the software product

at any stage of its development, from requirements to
installed system.

• Product metrics may measure:

– The complexity of the software design

– The size of the final program

– The number of pages of documentation produced

Page 14
Scope of Software Metrics
• Cost and effort estimation
• Productivity measures and model
• Data collection
• Quantity models and measures
• Reliability models
• Performance and evaluation models
• Structural and complexity metrics
• Capability – maturity assessment
• Management by metrics
• Evaluation of methods and tools
Page 15
Components of a productivity model

Page 16
Software quality model

Page 17
Normalization of Metrics
• For normalization we have 2 ways
– Size-Oriented Metrics
– Function Oriented Metrics

Page 18
Size-Oriented Metrics

• Based on the “size” of the software produced

Page 19
• From the above data, simple size oriented metrics can be
developed for each Project
• Errors per KLOC
• $ per KLOC
• Pages of documentation per KLOC
• Errors per person-month
• LOC per person-month
• Advantages of Size Oriented Metrics
– LOC can be easily counted
– Many software estimation models use LOC or KLOC as input.
• Disadvantages of Size Oriented Metrics
– LOC measures are language dependent, programmer dependent
– Their use in estimation requires a lot of detail which can be difficult to
achieve.
• Useful for projects with similar environment Page 20
Function-Oriented Metrics

• Based on “functionality” delivered by the software

• Functionality is measured indirectly using a measure

called function point.

• Function points (FP) - derived using an empirical

relationship based on countable measures of software
& assessments of software complexity

Page 21
Steps In Calculating FP

1. Count the measurement parameters.

2. Assess the complexity of the values.

3. Calculate the raw FP

4. Rate the complexity factors to produce the complexity

adjustment value (CAV) CAV=  Fi i = 1 to 14

5. Calculate the adjusted FP as follows:

FP = raw FP x [0.65 + 0.01 x CAV]

Page 22
Function Point Metrics

Parameter Count Simple Average Complex

Inputs x 3 4 6 =
Outputs x 4 5 7 =
Inquiries x 3 4 6 =
Files x 7 10 15 =
Interfaces x 5 7 10 =

Count-total (raw FP)

Page 23
Software information domain values
• Number of user inputs
• Number of user outputs
• Number of user inquiries
• Number of files
• Number of external interfaces

Page 24
 Rate Complexity Factors

• For each complexity adjustment factor, give a

rating on a scale of 0 to 5
0 - No influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

Page 25
 Complexity Adjustment Factors
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 online data entry?
7. Does the online data entry require the input transaction
to be built over multiple screens or operations?

Page 26
 Complexity Adjustment Factors(Continue…)

8. Are the master files updated online?

9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
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?

Page 27
Complexity Adjustment Value

• The rating for all the factors, F1 to F14, are summed

to produce the complexity adjustment value (CAV)

• CAV is then used in the calculation of the function

point (FP) of the software

Page 28
Example of Function-Oriented Metrics
• Errors per FP • Productivity = Functionality / Effort
= FP / person-month
• Defects per FP
• Quality = Errors / Functionality
• Payment per FP = Errors / FP

• Cost = $ / FP
• Pages of documentation per FP
• Documentation = pages / FP
• FP per person month

Page 29
FP Characteristics

• Advantages: language independent, based on data

known early in project, good for estimation

• Disadvantages: calculation complexity, subjective

assessments, FP has no physical meaning (just a
number)

Page 30
Qualities of a good metric
• Simple, precisely definable: so that it is clear how the
metric can be evaluated;
• Objective, to the greatest extent possible;
• Easily obtainable (i.e. At reasonable cost);
• Valid: the metric should measure what it is intended to
measure; and
• Robust: relatively insensitive to (intuitively)
Insignificant changes in the process or product.

Page 31
 Types of Software Measurements
• Direct measures: Easy to collect
– Size of source code (measured by LOC)
– Schedule of the testing process (measured by elapsed time in
hours)
– Number of defects discovered (measured by counting defects)
– Time a programmer spends on a project (measured by months
worked): Effort
– Memory size
– Execution speed
– Cost

Page 32
Types of Software Measurements (2)
• Indirect measures/ derived
– More difficult to assess & can be measured indirectly only.

– Quality, Functionality, Complexity, Reliability, Efficiency,

Maintainability etc.

Page 33
 Measurement for Prediction
• For allocating the appropriate resources to the project, we need
to predict the effort, time, and cost for developing the project.

• The measurement for prediction always requires a mathematical

model that relates the attributes to be predicted to some other
attribute that we can measure now.

• Hence, a prediction system consists of a mathematical model

together with a set of prediction procedures for determining the
unknown parameters and interpreting the results.

Page 34
Measurement Scales and Scale Types

• Nominal

• Ordinal

• Interval

• Ratio

• Absolute

Page 35
 Nominal scale type
• This is the most primitive form of measurement.

• Has two major characteristics:

– The empirical relation system consists only of different
classes; there is no notion of ordering among the classes.

– Any distinct numbering or symbolic representation of the

classes is an acceptable measure, but there is no notion of
magnitude associated with the numbers or symbols.

Page 36
 Ordinal scale
• Augments nominal scale with ordering information.
• Three major characteristics
– Empirical relation system consists of classes that are ordered
with respect to the attribute
– Any mapping preserving the ordering (i.e., a monotonic
function) is acceptable
– Numbers represent ranking only, so arithmetic operations have
no meaning
• Set of admissible transformations is set of all monotonic
mappings

Page 37
 Interval scale
• Captures information about size of intervals that
separate classes.

• Three characteristics

– An interval scale preserves order, as with an ordinal

scale.

– An interval scale preserves differences but not ratios.

– Addition and subtraction are acceptable on the

interval scale, but not multiplication and division.
Page 38
 A ratio scale
• A ratio scale has the following characteristics:
– It is a measurement mapping that preserves ordering, the
size of intervals between entities, and ratios between
entities.
– There is a zero element, representing total lack of the
attribute.
– The measurement mapping must start at zero and
increase at equal intervals, known as units.
– All arithmetic can be meaningfully applied to the classes
in the range of the mapping

Page 39
 Absolute scale
• Most restrictive in terms of admissible transformations
• For any two measures, M and M‟, there's only one admissible
transformation (identity transformation), since there's only one way
to make the measurement.
• 4 characteristics
– Measurement is made simply by counting the number of
elements in the entity set
– Attribute always takes the form of “number of occurrences of x
in the entity”
– Only one possible measurement mapping, namely the actual
count
– All arithmetic analysis of the resulting count is meaningful.
• Example: lines of code in a module is an absolute scale measure.
Page 40
Question?