Express in Numbers

1

• Metrics

Express in Numbers
Measurement provides a mechanism for objective
evaluation
2
Software Crisis

• According to American Programmer, 31.1 of
  computer software projects get canceled before
  they are completed,
• 52.7 will overrun their initial cost estimates
  by 189.
• 94 of project start-ups are restarts of
  previously failed projects. Solution?systematic
  approach to software development and measurement

3
Software Metrics

• It refers to a broad range of quantitative
  measurements for computer software that enable to
• improve the software process continuously
• assist in quality control and productivity
• assess the quality of technical products
• assist in tactical decision-making

4
Measure, Metrics, Indicators

• Measure.
• provides a quantitative indication of the
  extent, amount, dimension, capacity, or size of
  some attributes of a product or process.
• Metrics.
• relates the individual measures in some way.
• Indicator.
• a combination of metrics that provide insight
  into the software process or project or product
  itself.

5
What Should Be Measured?
process
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
size?
function?
6
What Should Be Measured?
process
process metrics
project metrics
measurement
product metrics
Process Software Development Process (requirements
, design, code, test, implementation)
product
What do we
use as a
basis?
size?
function?
7
What Should Be Measured?
process
process metrics
project metrics
measurement
product metrics
product
Product (code, requirements specification,
production software, design documentation, risk
assessment)
What do we
use as a
basis?
size?
function?
8
What Should Be Measured?
process
process metrics
project metrics
measurement
product metrics
product
What do we
Process Metrics give insight into the dynamics
of a given software process enabling project
management to evaluate the efficiency of that
process.
use as a
basis?
size?
function?
9
What Should Be Measured?
process
process metrics
project metrics
measurement
product metrics
product

• Project Metrics
• provide software project management with means to
  measure risk, progress, quality of the project.

What do we
use as a
basis?
size?
function?
10
What Should Be Measured?
process
process metrics
project metrics
measurement
product metrics
product
What do we
Product Metrics provide software developers
means to measure defects, errors, flaws. design
strategies
use as a
basis?
size?
function?
11
Metrics Classification

• Product Metrics
• Size (Function Pts, SLOC, Modules, Subsystems,
  Pages, Documents )
• Error density ( errors/ KSLOC )
• Defect density ( defects/ KSLOC or defects/ FP )
• Quality (Correctness, Maintainability,
  Reliability, Efficiency, Integrity, Usability,
  Flexibility, Testability, Portability,
  Reusability, Availability, Complexity,
  Understandability, Modifiability )

Power Concepts
12
How Is Quality Measured?

• Analysis Metrics
• Function-based Metrics Function Points(
  Albrecht), Feature Points (C. Jones)
• Bang Metric (DeMarco) Functional Primitives,
  Data Elements, Objects, Relationships, States,
  Transitions, External Manual Primitives, Input
  Data Elements, Output Data Elements, Persistent
  Data Elements, Data Tokens, Relationship
  Connections.

13
Source Lines of Code (SLOC)

• Measures the number of physical lines of active
  code
• In general the higher the SLOC in a module the
  less understandable and maintainable the module
  is

14
Function Oriented Metric - Function Points

• Function Points are a measure of how big is the
  program, independently from the actual physical
  size of it
• It is a weighted count of several features of the
  program
• Dislikers claim FP make no sense wrt the
  representational theory of measurement
• There are firms and institutions taking them very
  seriously

15
Analyzing the Information Domain
Unadjusted Function Points
Assuming all inputs with the same weight, all
output with the same weight, Complete Formula
for the Unadjusted Function Points
16
Taking Complexity into Account
Formula
17
Typical Function-Oriented Metrics

• errors per FP (thousand lines of code)
• defects per FP
• per FP
• pages of documentation per FP
• FP per person-month

18
Why Opt for FP Measures?
19
LOC vs. FP

• Relationship between lines of code and function
  points depends upon the programming language that
  is used to implement the software and the quality
  of the design
• Empirical studies show an approximate
  relationship between LOC and FP

20
LOC/FP (average)
Assembly language 320 C 128 COBOL,
FORTRAN 106 C 64 Visual Basic
32 Smalltalk 22 SQL 12 Graphical
languages (icons) 4
21
How Is Quality Measured?

• Design Metrics
• Structural Complexity fan-in, fan-out,
  morphology
• System Complexity
• Data Complexity
• Component Metrics Size, Modularity,
  Localization, Encapsulation, Information Hiding,
  Inheritance, Abstraction, Complexity, Coupling,
  Cohesion, Polymorphism
• Implementation Metrics
• Size, Complexity, Efficiency, etc.

22
Comment Percentage (CP)

• Number of commented lines of code divided by the
  number of non-blank lines of code
• Usually 20 indicates adequate commenting for C
  or Fortran code
• The higher the CP value the more maintainable the
  module is

23
Size Oriented Metric - Fan In and Fan Out

• The Fan In of a module is the amount of
  information that enters the module
• The Fan Out of a module is the amount of
  information that exits a module
• We assume all the pieces of information with the
  same size
• Fan In and Fan Out can be computed for functions,
  modules, objects, and also non-code components

24
Computing Fan In and Fan Out

• Usually
• Parameters passed by values count toward Fan In
• External variables used before being modifies
  count toward Fan In
• External variables modified in the block count
  toward Fan Out
• Return values count toward Fan Out
• Parameters passed by reference depend on their
  use...

25
Simple Example of Fan In / Fan Out
defineltstdio.hgt defineltmath.hgt fan-in
fan-out int globalInVar 9 int
globalOutVar float Simple(float x, float y)
2 int a float z z sqrt( x y
globalInVar) 1 globalOutVar
int(z2) 1 return z
1 --------------------------
3 2
26
Size Oriented Metric - Halstead Software Science
Types n n1 n2
27
Flow Graph
if (a) X() else Y()
Predicate Nodes
a
Y
X
28
Size Oriented Metric - Cyclomatic Complexity
Flow Graph Notation
29
Cyclomatic Complexity (Def)

• V(G) Regions in the Graph
• V(G) Independent Paths in the Graph
• V(G) E - N 2 where E number of edges and N
  number of nodes
• V(G) P 1 P number of predicated nodes
  (i.e., if, case, while, for, do)

30
McCabe Cyclomatic Complexity (CC)

• Measure of a module control flow complexity based
  on graph theory
• Uses control structures to create a control flow
  matrix, which in turn is used to generate a
  connected graph
• The complexity of the graph is the complexity of
  the module

31
McCabes Metric

• Smaller the V(G) the simpler the module.
• Modules larger than V(G) 10 are a little
  unmanageable.
• A high cyclomatic complexity indicates that the
  code may be of low quality and difficult to test
  and maintain

32
Orthogonal Object-Oriented Metrics(OOOM)

• Focuses on measuring less to gather the same
  information, buy using a reduced metrics suite
• Indented to focus on the 3 main factors of OO
  design
• Inheritance
• Polymorphism
• Encapsulation

33
Kang Cohesion

• Variation of Paige Jones Cohesion
• Cohesion value of a method
• Measured by variables affected in the method.

34
Paige Jones Cohesion

• Used extensively in the 1980s
• Effectively measured good design in structured
  programming.
• Modified by Kang for OO Design 1995

35
Paige Jones Cohesion

• Functional
• Sequential
• Communicational
• Procedural
• Temporal
• Logical
• Coincidental

36
Paige Jones Cohesion

• Functional
• All elemens of module contribute to one and only
  one task
• Sequential
• Outputs of one module serve as input data to the
  next module
• Communicational
• Elements contribute to activities that use the
  same input or output data

37
Paige Jones Cohesion

• Procedural
• Elements of a module are involved in different
  and possibly unrelated activities in which
  control flows from each activity to the next
• Temporal
• Elements of a module are involved in activities
  that are related in time
• Logical
• Elements of a module contribute to activities of
  the same general category but are conditionally
  dependent on the input

38
Paige Jones Cohesion

• Coincidental
• Elements contribute to activities with no
  meaningful relationship

39
Kang OO Cohesion

• Functional
• Only one output exists for the module
• Example
• Public void deposit (double amount)
• balance balance - amount
•  
•  

40
Kang OO Cohesion

• Sequential
• One output is dependent on the other output
• Example
• public double withdraw (double amount, double
  fee)
• amount fee
• if (amount lt 0) System.out.println (Error
  withdraw invalid)
• else if (amount gt balance)
• System.out.println (Error Insufficient
  funds.)
• else balance balance amount
• return balance

41
Kang OO Cohesion

• Communicational
• Two outputs are dependent on a common input
•  
• public void addCD (String title, String artist,
  double cost, int tracks)
• if (count collection.length) increaseSize
  ( )
• collection count new CD (title, artist,
  cost, tracks)
• totalCosts cost
• count

42
Kang OO Cohesion

• Iterative
• Two outputs are iteratively dependent on the same
  input
• void formDet (float Equations23, float
  x22, float y22, float D22)
• for (int Row 0 Row lt 2 Row)
• for (int Col 0 Col lt 2 Col)
• xRowCol EquationsRowCol
• yRowCol EquationsRowCol
• DRowCol EquationsRowCol

43
Kang OO Cohesion

• Conditional
• Two outputs are conditionally dependent on the
  same input
• public boolean checkSelfIn ( )
• if (this.isAvailable ( ))
• //this object cannot be checked out
• System.out.println (Error my_callNumber
  is not checked out)
• return false
• else
• my_dueDate null
• my_availability true
• return true

44
Chidamber and Kemerer Metrics

• Weighted methods per class (WMC)
• Depth of inheritance tree (DIT)
• Number of children (NOC)
• Coupling between object classes (CBO)
• Response for class (RFC)
• Lack of cohesion metric (LCOM)

45
Weighted methods per class (WMC)

• ci is the complexity of each method Mi of the
  class
• Often, only public methods are considered
• Complexity may be the McCabe complexity of the
  method
• Smaller values are better
• Perhaps the average complexity per method is a
  better metric?

The number of methods and complexity of methods
involved is a direct predictor of how much time
and effort is required to develop and maintain
the class.
46
Depth of inheritance tree (DIT)

• For the system under examination, consider the
  hierarchy of classes
• DIT is the length of the maximum path from the
  node to the root of the tree
• Relates to the scope of the properties
• How many ancestor classes can potential affect a
  class
• Smaller values are better

47
Number of children (NOC)

• For any class in the inheritance tree, NOC is the
  number of immediate children of the class
• The number of direct subclasses
• How would you interpret this number?
• A moderate value indicates scope for reuse and
  high values may indicate an inappropriate
  abstraction in the design

48
Coupling between object classes (CBO)

• For a class, C, the CBO metric is the number of
  other classes to which the class is coupled
• A class, X, is coupled to class C if
• X operates on (affects) C or
• C operates on X
• Excessive coupling indicates weakness of class
  encapsulation and may inhibit reuse
• High coupling also indicates that more faults may
  be introduced due to inter-class activities

49
Response for class (RFC)

• Mci of methods called in response to a message
  that invokes method Mi
• Fully nested set of calls
• Smaller numbers are better
• Larger numbers indicate increased complexity and
  debugging difficulties

If a large number of methods can be invoked in
response to a message, the testing and debugging
of the class becomes more complicated
50
Lack of cohesion metric (LCOM)

• Number of methods in a class that reference a
  specific instance variable
• A measure of the tightness of the code
• If a method references many instance variables,
  then it is more complex, and less cohesive
• The larger the number of similar methods in a
  class the more cohesive the class is
• Cohesiveness of methods within a class is
  desirable, since it promotes encapsulation

51
Class-Oriented Metrics
24.4 Class-Oriented Metrics
Proposed by Lorenz and Kidd LOR94

• class size
• number of operations overridden by a subclass
• number of operations added by a subclass
• specialization index

52
Class-Oriented Metrics
24.4 Class-Oriented Metrics
The MOOD Metrics Suite

• Method inheritance factor
• Coupling factor
• Polymorphism factor

53
24.5 Operation-Oriented Metrics
Chapter 24. Technical Metrics for Object-Oriented
Systems
Proposed by Lorenz and Kidd LOR94

• average operation size
• operation complexity
• average number of parameters per operation

54
References

• Chidamber, S. R. Kemerer, C. F., A Metrics
  Suite for Object Oriented Design, IEEE
  Transactions on Software Engineering, Vol. 20,
  6, June 1994.
•  
• Hitz, M. and Montazeri, B. Chidamber and
  Kemerers Metrics Suite A Measurement Theory
  Perspective, IEE Transaction on Software
  Engineering, Vol. 22, No. 4, April 1996.
•  
• Lacovara , R.C., and Stark G. E., A Short Guide
  to Complexity Analysis, Interpretation and
  Application, May 17, 1994.
  http//members.aol.com/GEShome/complexity/Comp.htm
  l
• Tang, M., Kao, M., and Chen, M., An Empirical
  Study on Object-Oriented Metrics, IEEE
  Transactions on Software Engineering,
  0-7695-0403-5, 1999.
• Tegarden, D., Sheetz, S., Monarchi, D.,
  Effectiveness of Traditional Software Metrics
  for Object-Oriented Systems, Proceedings 25th
  Hawaii International Confernce on System
  Sciences, January, 1992, pp. 359-368.
• Principal Components of Orthogonal
  Object-Oriented Metrics
• http//satc.gsfc.nasa.gov/support/OSMASAS_SEP01/Pr
  incipal_Components_of_Orthogonal_Object_Oriented_M
  etrics.htm
• Software Engineering Fundamentals
• by Behforhooz Hudson, Oxford Press, 1996
• Chapter 18 Software Quality and Quality
  Assurrance
• Software Engineering A Practioner's Approach
• by Roger Pressman, McGraw-Hill, 1997