1. Software Measurement & Metrics

2. A Quote on Measurement
“When you can measure what you are speaking about and express it in
numbers, you know something about it; but when you cannot measure,
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.”
LORD WILLIAM KELVIN (1824 – 1907)

3. Reasons to Measure To characterize in order to
Gain an understanding of processes, products, resources, and environments
Establish baselines for comparisons with future assessments
To evaluate in order to
Determine status with respect to plans
To predict in order to
Gain understanding of relationships among processes and products
Build models of these relationships
To improve in order to
Identify roadblocks, root causes, inefficiencies, and other opportunities for improving product quality and process performance

4. Categories of Software Measurement
Two categories of software measurement
Direct measures
Software process (cost, effort, etc.)
Software product (lines of code produced, execution time, defects reported over time, etc.)
Indirect measures
Software product (functionality, quality, complexity, efficiency, reliability, maintainability, etc.)
Project metrics can be consolidated to create process metrics for an organization

5. Establishing a Metrics Baseline
By establishing a metrics baseline, benefits can be obtained at the software process, product, and project levels
Baseline data must have the following attributes
Data must be reasonably accurate (guesses should be avoided)
Data should be collected for as many projects as possible
Measures must be consistent (e.g., a line of code must be interpreted consistently across all projects)
Past applications should be similar to the work that is to be estimated

6. Software Metrics Baseline Process
Engineering
Process
Measures
Software
Project
Data
Collection
Metrics
Metrics
Computation
Software
Product
Indicators
Metrics
Evaluation

7. Product Metrics Ensuring the Quality of Product Size Complexity
Structure & Architecture
Product Quality
Defects

8. Product Metrics Size number of elements lines of code
number of documentation pages,
number of test cases
etc
development metrics
time metrics
cost metrics
consumption of resources metrics
size of components
number of modules/objects
average size of components

9. Defects Metrics Defects per unit size Types/Levels
Stages Introduced/Fixed
Defect Discovery Rate
Defect Removal Efficiency
Results
Costs/Efforts for finding& fixing

10. Defect Removal Efficiency
Defect removal efficiency provides benefits at both the project and process level
DRE = E / (E + D)
The ideal value of DRE is 1, which means no defects are found after delivery
DRE encourages a software team to institute techniques for finding as many errors as possible before delivery

11. Failure Intensity Setting FI in terms of reliability
 is failure intensity
R is reliability
t is natural unit (time, etc.)

12. Reliability and Failure Intensity
Reliability for 1 hour
mission time
Failure intensity
1 failure / hour
105 failure / 1000 hours
1 failure / day
10 failure / 1000 hours
1 failure / week
1 failure / month
1 failure / 1000 hours
1 failure / year

13. MTTF and Failure Intensity

14. System Reliability A system usually consists of components.
Components may have
Different reliability
Different dependencies among each other
System reliability is a function of the reliabilities of the (sub-) components and of the relationships between the components.

15. Serial System Reliability
System is composed of n independent serially connected components.
Failure of any component has a cross system effect, i.e., results in failure of the whole system.
A serial system has always smaller reliability than its components. R1 R2
...

16. The system is composed of 4 independent serially connected components
Rsystem = 0.95  0.87  0.82  0.73 =
Serial system reliability is smaller than any individual reliability of the components

17. Parallel System Reliability
System is composed of n independent components connected in parallel. Failure of all components results in the failure of the whole system (principle of active redundancy). R1 R2
...

18. The system is composed of 4 independent components connected in parallel
Rsystem = 1 – ((1 – 0.95)  (1 – 0.87) 
(1 – 0.82)  (1 – 0.73)) =
Parallel system reliability is greater than any individual reliability of the components

19. Metrics for Specification Quality
Requirements in a specification
Specificity (lack of ambiguity)

20. Architectural Design Metrics
For hierarchical architectures (e.g. call and return architectures)
Structural complexity of a module i is defined as,
S (i) = f2 out (i)

21. Architectural Design Metrics
Data complexity provides an indication of the complexity in the internal interface for a module i and is defined as,
where v(i) is the number of input and output variables that are passed to and from module i

22. Architectural Design Metrics
System Complexity is defined as the sum of structural and data complexity,
C(i)=S(i)+D(i)
Increase in these values also increases in the overall architectural complexity

23. Class-oriented Metrics-CK Metrics Suite
Weighted methods per class (WMC)
Depth of inheritance tree (DIT)
Number of children (NOC)
Coupling between object classes (CBO)
Response for a class (RFC)
Lack of cohesion in methods (LCOM)

24. Class Oriented Metrics - The MOOD Metrics Suite
Method inheritance factor (MIF)

25. Halstead metric for source code
n1=number of distinct operators in program
n2= number of distinct operands in program
N1=total number of operator occurrences
N2=total number of operand occurrences
Length N can be estimated as,
Program volume may be defined as,

26. Halstead metric for testing
Program Level PL is expressed as,
Halstead effort e can be computed as,

27. Metrics for Maintenance
IEEE Std recommends Software Maturity Index (SMI)
It provides indication of stability of software product (based on changes that occur for each release of the product)
MT=number of modules in current release
Fc=number of modules in current release that are changed
Fa=number of modules in current release that are added
Fd=number of modules from preceding release that are deleted in current release

28. Metrics for Maintenance
The software maturity index is computed as,
As SMI approaches 1.0, the product begins to stabilize.
SMI used for planning maintenance and release

29. Metrics for Software Quality
Correctness
This is the number of defects per KLOC, where a defect is a verified lack of conformance to requirements
Defects are those problems reported by a program user after the program is released for general use
Maintainability
This describes the ease with which a program can be corrected if an error is found, adapted if the environment changes, or enhanced if the customer has changed requirements
Mean time to change (MTTC) : the time to analyze, design, implement, test, and distribute a change to all users
Maintainable programs on average have a lower MTTC

30. Metrics for Software Quality
Integrity
Threat
Security
Usability

31. Thank you!