Estd.

2000
Software Metric and
Measurement
Created by : Ritin Behl(Reference Software
Engineering (3rd ed.), By K.K Aggarwal &
Yogesh Singh, Copyright © New Age
International Publishers, 2007)

(Rank-band: 151-
200)

1
Topics
Measurement
Definition :- Measure , Measurement , Metric
Software Project Planning
Line of Code (LOC)
Function Point (FP)

2
 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.
3
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)
4
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.

5
 Software Project Planning
After the finalization of SRS, we would like to
estimate size, cost and development time of the
project. Also, in many cases, customer may like to
know the cost and development time even prior to
finalization of the SRS.

6
 Software Project Planning
In order to conduct a successful software project, we
must understand:
▪ Scope of work to be done
▪ The risk to be incurred
▪ The resources required
▪ The task to be accomplished
▪ The cost to be expended
▪ The schedule to be followed

7
 Software Project Planning
Software planning begins before technical work starts, continues as
the software evolves from concept to reality, and culminates only
when the software is retired.
Size estimation

Cost estimation Development time

Resources
requirements

Fig. 1: Activities during

Project
Software Project Planning scheduling

8
 Line of Code
Fig. 2: Function for sorting an
Size Estimation array
1. int. sort (int x[ ], int n)
Lines of Code (LOC) 2. {

3. int i, j, save, im1;

If LOC is simply a count of the 4.

5.
/*This function sorts array x in ascending order */
If (n<2) return 1;
number of lines then figure shown 6. for (i=2; i<=n; i++)
7. {
below contains 18 LOC . 8. im1=i-1;
9. for (j=1; j<=im; j++)
10. if (x[i] < x[j])
When comments and blank 11. {

lines are ignored, the program in 12.

13.
Save = x[i];
x[i] = x[j];
figure 2 shown below contains 17 14. x[j] = save;

LOC. 15.
16.
}
}
17. return 0;
18. }
9
 Line of Code
Furthermore, if the main interest is the size of the program
for specific functionality, it may be reasonable to include
executable statements. The only executable statements in
figure shown above are in lines 5-17 leading to a count of
13. The differences in the counts are 18 to 17 to 13. One
can easily see the potential for major discrepancies for
large programs with many comments or programs written
in language that allow a large number of descriptive but
non-executable statement. Conte has defined lines of code
as:

1
0
 Line of Code
“A line of code is any line of program text that is not a
comment or blank line, regardless of the number of
statements or fragments of statements on the line. This
specifically includes all lines containing program header,
declaration, and executable and non-executable
statements”.

This is the predominant definition for lines of code used

by researchers. By this definition, figure shown above has
17 LOC.

1
1
 Function Count
Function Count
Alan Albrecht while working for IBM, recognized the
problem in size measurement in the 1970s, and developed
a technique (which he called Function Point Analysis),
which appeared to be a solution to the size measurement
problem.

1
2
 Function Point
The principle of Albrecht’s function point analysis (FPA)
is that a system is decomposed into functional units.

▪ Inputs : information entering the system

▪ Outputs : information leaving the system
▪ Enquiries : requests for instant access to
information
▪ Internal logical files : information held within the
system
▪ External interface files : information held by other system
that is used by the system being
analyzed.

13
 Function Points
The FPA functional units are shown in figure given
below:

User

Inquiries

Other
ILF
applications
Inputs
EIF
User
Outputs ILF: Internal logical files
System EIF: External interfaces

Fig. 3: FPAs functional units System

14
 Function Points
Special features

➢ Function point approach is independent of the language,

tools, or methodologies used for implementation; i.e. they
do not take into consideration programming languages,
data base management systems, processing hardware or
any other data base technology.
➢ Function points can be estimated from requirement
specification or design specification, thus making it
possible to estimate development efforts in early phases of
development.

15
 Function Points

➢ Function points are directly linked to the statement of

requirements; any change of requirements can easily
be followed by a re-estimate.
➢ Function points are based on the system user’s
external view of the system, non-technical users of
the software system have a better understanding of
what function points are measuring.

16
 Counting Function Points
Counting function points
Functional Units Weighting factors
Low Average High
External Inputs (EI) 3 4 6
External Output (EO) 4 5 7
External Inquiries (EQ) 3 4 6
External logical files (ILF) 7 10 15
External Interface files (EIF) 5 7 10

Table 1 : Functional units with weighting

factors 17
 Function Counts
Table 2: UFP calculation table
Functional Count Complexit Functional
Units Complexi y Unit Totals
ty Totals
Externa Low x 3 =
l Inputs Average x 4 =
(EIs) High x 6 =
Externa Low x 4 =
l Average x 5 =
Outputs High x 7 =
(EOs)
External Low x 3 =
Average x 4 =
Inquirie High x 6 =
s (EQs)
External Low x 7 =
logical Average x 10 =
Files (ILFs) High x 15 =
External Low x 5 =
Interface Average x 7
Files (EIFs) =
High x 10 =
18
Total Unadjusted Function Point Count
 Formula for UFP
The procedure for the calculation of UFP in mathematical
form is given below:
5 3

UFP  i1 ∑∑ J 1 Z ij

wij the row and j indicates the column of Table 1

Where i indicate

Wij : It is the entry of the ith row and jth column of the table 1
Zij : It is the count of the number of functional units of Type i that
have been classified as having the complexity corresponding to
column j.
19
 Function Points

Organizations that use function point methods develop a criterion

for determining whether a particular entry is Low, Average or High.
Nonetheless, the determination of complexity is somewhat
subjective.

FP = UFP * CAF

Where CAF is complexity adjustment factor and is equal to [0.65

+
0.01 x ΣFi]. The Fi (i=1 to 14) are the degree of influence and are
based on responses to questions noted in table 3.

20
 Function Points
Functions points may compute the following important
metrics:
Productivity = FP / persons-months
Quality = Defects / FP
Cost = Rupees / FP
Documentation = Pages of documentation per FP

These metrics are controversial and are not universally acceptable.

There are standards issued by the International Functions Point User
Group (IFPUG, covering the Albrecht method) and the
United
Kingdom Function Point User Group (UFPGU, covering the MK11
method). An ISO standard for function point method is also being
developed. 21
 Function Points
Table 3 : Computing function points.
Rate each factor on a scale of 0 to 5.
0 1 2 3 4 5

No Average
Influence Incidental Moderate Significant Essential
Number of factors considered ( Fi )

1. Does the system require reliable backup and recovery ?

2. Is data communication 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. Is 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 ?
22
 Example: Function Points
Example: 4.1

Consider a project with the following functional units:

Number of user inputs = 50
Number of user outputs = 40
Number of user = 35
enquiries Number of = 06
user files = 04
Number of external
Assume
interfacesall complexity adjustment factors and weighting factors are
average. Compute the function points for the project.
23
 Software ftroject ftlanning
Solution
We know 5 3
UFP  ∑∑ Zij wij
i1 J 1

UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7
= 200 + 200 + 140 + 60 + 28 = 628
CAF = (0.65 + 0.01 ΣFi)
= (0.65 + 0.01 (14 x 3)) = 0.65 + 0.42 = 1.07
FP = UFP x CAF
= 628 x 1.07 = 672
24
 Example
Example:4.2
An application has the following:
10 low external inputs, 12 high external outputs, 20 low internal
logical files, 15 high external interface files, 12 average external
inquiries, and a value of complexity adjustment factor of 1.10.
What are the unadjusted and adjusted function point counts ?

25
 Example
Solution
Unadjusted function point counts may be calculated using
as:
5 3

UFP  i1 ∑∑ J Zij

1
wij
= 10 x 3 + 12 x 7 + 20 x 7 + 15 + 10 + 12 x
4
= 30 + 84 +140 + 150 + 48
FP = 452
= UFP x CAF
= 452 x 1.10 = 497.2.
26
 Example
Example: 4.3
Consider a project with the following
parameters.
(i) External Inputs:
(a) 10 with low complexity
(b)15 with average complexity
(c) 17 with high complexity
(ii) External Outputs:
(a) 6 with low complexity
(b)13 with high complexity
(iii) External Inquiries:
(a) 3 with low complexity
(b) 4 with average
27
complexity
 Example
(iv) Internal logical files:
 (a) 2 with average complexity
(b)1 with high complexity
(v) External Interface files:
 (a) 9 with low complexity
In addition to above, system requires
i. Significant data communication
ii. Performance is very critical
iii. Designed code may be moderately
reusable
iv. System is not designed for multiple installation in
different organizations.
Other complexity adjustment factors are treated as average. Compute
28
the function points for the project.
 Example…
Solution: Unadjusted function points may be counted using table 2
Functional Count Complexity Complexit Functional
Units y Unit
Totals Totals
Externa 10 Low x 3 30
=
l Inputs 15 Average x 4 60
=
(EIs) 17 High x 6 = 102 192
Externa 6 Low x 4 24
=
l 0 Average x 5 0
=
Outputs 13 High x 7 = 91 115

(EOs)
External 3 Low x 3 9
=
4 Average x 4 16
=
Inquirie 2 High x 6 = 12 37

s (EQs)
Externa 0 Low x 7 0
=
l 2 Average x 10 20
=
logical
Files (ILFs) 1 High x 15 = 15 35
External 9 Low x 5 = 45
Interface 0 Average x 7 0
Files (EIFs) =
0 High x 10 = 0 45
29
Total Unadjusted Function Point Count 424
 Example ..
14

∑i1

Fi 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41
CAF = (0.65 + 0.01 x ΣFi)
= (0.65 + 0.01 x 41)
= 1.06
FP = UFP x CAF
= 424 x 1.06
= 449.44

Hence FP = 449
30
Complexity Metrics
 Not a measure of computational complexity
 Measures psychological complexity, specifically structural
complexity; that is, the complexity that arises from the structure
of the software itself, independent of any cognitive issues.
 Many complexity metrics exist: H. Zuse lists over 200 in his 1990
taxonomy.
 Complexity metrics can be broadly categorized according to the
fundamental software attribute measures on which they are
based:
 software science parameters
 control-flow
 data-flow
 information-flow
 hybrid

31
Halstead Metrics
 Software Science is generally agreed to be the beginning of
systematic research on metrics as predictors for qualitative
attributes of software.
 Proposed by Maurice Halstead in 1972 as a mixture of
information theory, psychology, and common sense.
 These are linguistic metrics.
 Based on four measures of two fundamental software
attributes, operators and operands:
 n1 - number of unique operators
 n2 - number of unique operands
 N1 - total number of operators
 N2 - total number of operands

32
Halstead Metrics
 Halstead conjectures relationships between these
fundamental measures and a variety of qualitative
attributes:
 Length: N = N + N
1 2
 Estimate of N=n1 log n1 + n2 log n2
 Vocabulary: n = n + n
1 2
 Volume: V = N*lg(n)
 Level: L = (2*n )/(n N )
2 1 2
 Difficulty: D = 1/L
 Effort: E = V * D
 Halstead also defines a number of other attributes:
 potential volume, intelligence content, program purity,
language level, predicted number of bugs, predicted number of
seconds required for implementation

33
Question : Find the value of( n1,n2, N1, N2, h,
N,V, E,)

34
Solution

35
Exercise

36
Solution

37
Cyclomatic Complexity
 Cyclomatic Complexity, v(G), is a measure of the amount of control
structure or decision logic in a program.
 Studies have shown a high correlation between v(G) and the
occurrence of errors and it has become a widely accepted indicator
of software quality.
 Based on the flowgraph representation of code:
 Nodes - representing one or more procedural statements
 Edges - the arrows represent flow of control
 Regions - areas bounded by edges and nodes; includes the area outside
the graph
 Cyclomatic Complexity is generally computed as:
 v(G) = number of regions in the flowgraph
 v(G) = number of conditions in the flowgraph + 1
 v(G) = number of edges - number of nodes + 2
 v(G)= e-n+2

38
Cyclomatic Complexity
Cyclomatic complexity can be used to
Determine the maximum number of test cases
to ensure that all independent paths through
the code have been tested.
Ensure the code covers all the decisions and
control points in the design.
Determine when modularization can decrease
overall complexity.
Determine when modules are likely to be too
buggy.

39
Cyclomatic Complexity Thresholds
1-10
A simple module, without much risk
11-20
More complex, moderate risk
21-50
Complex, high risk
Greater than 50
Untestable, very high risk

[From SEI reports]

40
Flow graph notation for a program

41
Converting Code to Graph
CODE FLOWCHART GRAPH

if expression1 then T F
expr1 n1 For a strongly connected graph:
statement2 ?
else Create a virtual edge
(a) statement3
statm2 statm3 n2 n3
to connect the END node
end if
statement4 to the BEGIN node
statm4 n4

switch expr1
1 3
case 1: expr1
statement2 ? n1
case 2: 2
(b) statm3
statm2 statm3 statm4 n2 n3 n4
case 3:
statm4
end switch n5
statm5 statm5

statm1
do n1
statement1
T
(c) while expr2 expr2
n2
end do ?
statement3 F
n3
statm3

42
43
EXAMPLE

44
Solution

45
Solution contd..
In this example

CC = number of edges – number of nodes + 2

CC = 14 – 12 + 2

=4

46
Question

47
FLOWGRAPH

48
Question

49