1. Measurement of Software
Software Metrics
Measurement of Software
Needs some updating
Copyright © Curt Hill

2. Introduction
Engineering is all about the production of new and reliable items
Engineering must be built upon the foundations laid by science
Inherent in this is the notion of measurement
Consider the next definition
Copyright © Curt Hill

3. Wikipedia Definition
Engineering is the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes and organizations
Copyright © Curt Hill

4. Quote by W Thomson William Thomson (Lord Kelvin):
When you measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science.
Copyright © Curt Hill

5. Engineering Fields
Software Engineering is much different than many other forms of engineering
It is not built on the firm laws of Physics
We cannot measure the dimensions, the mass, the velocity, the electrical resistance or many other physical quantities
Therefore we struggle to quantify anything about software
Copyright © Curt Hill

6. Quality Our goal is to measure the quality of our product
If we are making bolts we might measure lengths, precision of the threads or tensile strength of many such bolts
Then use statistics to compute an index of quality
There it is easy, but in software it is somewhat more difficult
Copyright © Curt Hill

7. Quote from W.E. Deming
The problem inherent in attempts to define the quality of a product, almost any product, were stated by the master Walter A. Shewhart. The difficulty in defining quality is to translate future needs of the user into measurable characteristics, so that a product can be designed and turned out to give satisfaction at a price that the user will pay. This is not easy, and as soon as one feels fairly successful in the endeavor, he finds that the needs of the consumer have changed, competitors have moved in, etc
Copyright © Curt Hill

8. What is a software metric?
One definition: a standard of measure of a degree to which a software system or process possesses some property.
Quality may be unmeasurable, but we can amass metrics that would contribute to quality
Copyright © Curt Hill

9. Attempts
There have been a number of attempts get a grip on software quality
These include:
McCall’s quality factors
HP’s FURPS
ISO 9126 quality factors
These attempt to characterize the factors of quality
Brief consideration of these three follow
Copyright © Curt Hill

10. McCall’s There are several areas that this deals with:
Correctness
Reliability
Efficiency
Portability
Among others
Some of these are quite difficult to quantify
Thus they develop checklist and measures that contribute to these
McCall, Richards and Walters: Factors in Software Quality
Copyright © Curt Hill

11. HP FURPS FURPS is an acronym for
Functionality
Usability
Reliability
Performance
Supportability
Similar to McCall’s we do not see objective reproducible metrics
Copyright © Curt Hill

12. ISO 9126 Similar attributes: Functionality Reliability Usability
Efficiency
Maintainability
Portability
Copyright © Curt Hill

13. The problems
Until we have sophisticated formal methods that can determine if code meets its specifications and requirements we cannot directly measure most of these quality attributes
Instead we narrow the investigation to those metrics that can take as input the source code and produce a number that may be meaningfully interpreted
Copyright © Curt Hill

14. Attributes What characteristics would we like for a metric? Quantified
We produce a number
Objective
The metric should be computed in an objective way
Independent observers can agree that a particular metric value is correct
Uniform
The source data for the process is uniform
Copyright © Curt Hill

15. Metric Activities
Considering which metrics may be helpful in a particular project
Collecting the data
Computing the metric using the gathered data
Interpreting the results of the computation
Applying the number to the project
Copyright © Curt Hill

16. Individual Consideration
What metrics have been proposed?
How are they used?
What are their strengths and weaknesses?
You have already seen the first two
Copyright © Curt Hill

17. Lines Of Code (LOC) AKA SLOC
Some would not call this a metric, but this is the most universal
A program processes the source code and count lines
Typically eliminates blank lines
Not all languages allow blank lines
Often eliminates comments as well
The unit of measure for project size and programmer productivity is LOC or KLOC
Copyright © Curt Hill

18. LOC May be the most objective and least valuable Easy to compute
Says nothing about:
Correctness
Complexity
May be most useful in ratios with other measures
Copyright © Curt Hill

19. Cyclomatic Complexity
Measures linearly independent paths through code
Fairly easy to compute
Interpretation is relatively easy as well
We have covered this one adequately elsewhere
Copyright © Curt Hill

20. Halstead Complexity
Halstead Complexity counts a number of basic items from source code
It then computes several results from these base counts
All of these come from the source code and would thus be easy for a compiler or static analyzer to count and then compute
Copyright © Curt Hill

21. Basic Counts n1 the number of distinct operators
Operators include:
Function names, statement types
Arithmetic, comparison etc
Grouping: () []
n2 = the number of distinct operands
Variables, parameters and constants
N1 = the total number of operators
N2 = the total number of operands
The lower case n is actually a Greek eta
Copyright © Curt Hill

22. Computed Measures Program vocabulary: n = n1 + n2
Program length: N = N1 + N2
Calculated program length:  =n1log2 n1 + n2log2 n2
Volume: V=N log2 n
Difficulty: 𝐷= 𝑛 1 2 × 𝑁 2 𝑛 2
Effort:  E = DV
Calculated program length N is supposed to have a ^ over it
Copyright © Curt Hill

23. Example We will next look at a piece of code
We should count up the basics:
n1 the number of distinct operators
n2 = the number of distinct operands
N1 = the total number of operators
N2 = the total number of operands
Then check if it agrees with following slide
The following had a cyclomatic complexity of 6
Copyright © Curt Hill

24. Consider this code
int f1, f2, total=0, counter=1; while(!infile){ cin >> f1 >> f2 if(f1==0){ total+=f1; counter++; } else if(f2 == 0){ cout << total<<counter; counter = 0; } else total -= f2;
cout << f1 << f2;
} // end while
cout << counter;
Copyright © Curt Hill

25. Halstead Counts n1 the number of distinct operators
int = while ! >> {} () if == else += ++ << -= 14
n2 = the number of distinct operands
f1 f2 total counter 1 infile cin cout 0 9
N1 = the total number of operators 28
N2 = the total number of operands 29
Copyright © Curt Hill

26. Halstead Computations
Program vocabulary: n = n1 + n2
23 = 14+9
Program length: N = N1 + N2
57 =
Calculated program length:
Volume: V=N log2 n
Difficulty: 𝐷= 𝑛 1 2 × 𝑁 2 𝑛 2
Effort:  E = DV
See halstead.xls
Copyright © Curt Hill

27. Discussion
Cyclomatic complexity is easy to compute, but Halstead is tedious
Only to be done without a program for tutorial purposes
What do you think?
How do these relate to code complexity?
Copyright © Curt Hill

28. Additional Halstead Calculations
Several estimates were derived from these numbers
Estimated time to program
T = E/18 in seconds
For above code 323 about 5.3 minutes
Estimated number of bugs
𝐵= 𝐸 or 𝑉 3000 or
Copyright © Curt Hill

29. Lets Try One More void bubble(int t[], unsigned int size) {
unsigned int i; bool done;
do {
done = true;
for(i = 0;i<size-1;i++) {
if(t[i] > t[i+1]) {
swap(t[i],t[i+1]);
done = false;
} // end of if
} // end of for
} // end of do
while (!done);
return; }
Copyright © Curt Hill

30. Halstead Criticisms
The largest criticism is that Halstead correlates with LOC
LOC is very easy to measure, so why would we go to the trouble?
We may have to investigate this further
But not today
Copyright © Curt Hill

31. OO
Both Cyclomatic Complexity and Halstead were created before object orientation became popular
These can be applied to objects by applying them to individual methods
There are other measures that are specifically designed for the unique characteristics of OO
Copyright © Curt Hill

32. OO Metrics Weighted Methods per Class (WMC)
Sum of method cyclomatic complexities
The larger the number the more impact on descendent classes
Depth of Inheritance Tree (DIT)
The deeper the tree the harder to understand
Number of Children (NOC)
Descendent classes
Also an indication of reuse since derivatives are a form of reuse
These from Chidamber & Kemerer's Metics Suite Chidamber and Kemerer(1994) : A Metrics Suite for Object Oriented Design, IEEE Trans. Software Eng., vol 20, no 6, June, pp , 1994. 
CF:
Copyright © Curt Hill

33. OO Metrics Again Coupling Between Object classes (CBO)
Count of classes that this class is coupled with
A class is coupled when a method accesses other method’s classes
Response For a Class (RFC)
Number of methods invoked for tasks of the class
Larger means more complex
These from Chidamber & Kemerer's Metics Suite Chidamber and Kemerer(1994) : A Metrics Suite for Object Oriented Design, IEEE Trans. Software Eng., vol 20, no 6, June, pp , 1994. 
CF:
Copyright © Curt Hill

34. OO Metrics Again Lack of Cohesion in Methods (LCOM)
Number of methods that use an instance variable
Low cohesion suggests refactoring the object and implies complexity
Copyright © Curt Hill

35. Function Points Start with user requirements
Each requirement is categorized into one of five classes
Inputs
Outputs
Inquiries
Internal files
External interfaces
Next each is evaluated for complexity
Simple, average or complex
Copyright © Curt Hill

36. Points For each class, obtain a count
Given a type and a complexity we obtain a point score by multiplying the count by lookup from table
Class\Complexity
Simple
Average
Complex
Inputs 3 4 6
Outputs 5 7
Inquiry
Internal Files 10 15
External Interfaces CF
Copyright © Curt Hill

37. Commentary
Function points may be related to cost estimates, quality estimates and productivity
There are several versions of this that may be applied
COSMIC
FiSMA
IFPUG
Mark II
NESMA
All of these have ISO standards
Copyright © Curt Hill

38. Others Bugs per line of code Comment density
Computed when the project is complete or near complete
May be used to evaluate the developer more than the code
Comment density
Design Structure Quality Index
DSQI
Copyright © Curt Hill

39. Finally
We may have to revisit some of these in an exercise or programming project
Copyright © Curt Hill