Software Measurement

Muhammad Rabee Shaheen, Ph.D

Metrics assumptions
} The relationship exists between what we can measure
and what we want to know. We can only measure
internal attributes but are often more interested in
external software attributes.
Predictor vs. Control Metrics
} Control or Process metrics:
} Support process management
} Ex. Avg. effort, time required to repair defects
} Predictor or product metrics:
} Associated with the software itself
} Internal attributes: LOC, CC,..
Product Metrics
} Dynamic metrics:
} Collected during a program execution, system testing, or after
the system has gone into use
} Ex. #bug reports, time taken to complete a computation
} Static metrics:
} Collected during the representations of the system
} Ex. Code size, CC
Dynamic Metrics Static Metrics

Assess the
Assess the complexity,
efficiency and understandability
reliability of a and
program maintainability of
a program
Fan-in/Fan-out

A method
Length of identifiers
} Average length of identifiers (names of variables, classes,
methods, …)
} The longer the identifiers, the more likely they are to
be meaningful and hence the more understandable
the program
Function Points
} Introduced by Alan Albrecht of IBM (1979)
} 2003, ISO standard
} Probably the best approach to cost estimation (function
point analysis - FPA)
} assumes that the effort required to develop a piece of
software depends on what the software does (#functions
it implements)
} The larger number of FPs the more functionality
} Function Point Analysis is a method of using FP-s to break
down applications into smaller components
Function Points …
} Objectives:
} Measure software by quantifying the functionality requested by
and provided to the customer.
} Measure software development and maintenance
independently of technology used for implementation.
} Measure software development and maintenance consistently
across all projects and organizations.
} Benefits:
} The ability to accurately estimate:
} Project cost
} Project duration
} Project staffing size
Function Points …
} What to count:
} Number of external inputs (transactional types)
} External outputs (report types)
} Logical internal files (nonphysical)
} External interface files (files accessed by the application but not
maintained or updated by it)
} External inquiries
} Example:
} #data input screens
} #data display screens
} #database tables
} #reports
} #interfaces with other software systems
Function Points …

Data Element Type

Function Points …
Function Points …

RETS Data Element Types (DETs)

1-19 20-50 51+
1 L L A
2 to 5 L A H
6 or more A H H

Complexity Points
Low 7
Average 10
High 15

RET (Repeatable data element types): User

recognizable subgroup of data elements
Function Points …

DET
Function Points …
} Example:
} Develop a system which allows customers to report bugs in
a product. These reports will be stored in a file and
developers will receive a daily report with new bugs which
they need to solve. Customers will also receive a daily status
report for bugs which they submitted. Management can
query the system for a summary info of particular months.

External
External Inputs
Inquiries Logical
External Internal Files
Outputs
Function Points …
} #External inputs = 1
} #Logical internal files = 1
} #External outputs = 2
} #External inquiries = 1
Function Points …
} Example:
} An information system that allows the user to browse information and
update information held in a database. The system holds information
about the employees in an organization. A screen is to be implemented
that allows information about a single employee to be displayed.This is one
of the function points of the system. Because this is a small task and we
can visualize the implementation, we predict with some confidence that
the effort required will be I person month. This includes clarifying the
requirements, creating the specification, testing and validation. Obviously
there will be other screens available to users, for example, a screen to
change the details of an employee. The number of functions is measured
by the number of screens available to the user and the development effort
is proportionate.Thus for 6 screens,we estimate 6 person months
Halstead Metric (1977)
} A program is considered to be a collection of tokens.
} Tokens are either operators or operands.
} Operands were tokens that had a value (typically variables
or constants).
} Everything else is an operator (commas, parenthesis,
arithmetic operators)
} Halstead did not count declarations, input or output
statements, or comments do not count as tokens
} Most organizations currently count all parts of a
program.
Halstead Metric …
} Count unique operators (n1)
} Count unique operands (n2)
} Length of the program (N) = total count of operators and
operands
} Estimate of length is defined as (Est N = n1*log2n1 +
n2*log2n2)
z = 0;
while x > 0 n1 (= ; while > + - print () )= 8
z = z + y; n2 (z x 0 y 1) = 5
x = x -1 N (operand+operator) = 11 + 14 = 25
end-while;
print(z);
Halstead Metric …
} Halstead metric could be used to estimate the program
volume, difficulty and effort
} Volume V = N * log2(n1+n2)
} Difficulty D = (n1/2) * (total #operands/n2)
} Effort E = D * V

} Difficulty is related to the difficulty of the program to

understand (through code reviewing, maintenance, …)
} Effort could used to estimate actual coding time using:
} Time required to program T = E / 18 seconds
Last word about measurement
} A lot of metrics
} Most at source code level è too late
} Some are difficult to calculate
} No standard metric
} Using existing metrics could help at maximizing the quality
attributes