Lecture 14 ( metrics)

Dr. Sheela Ramanna

Applied Computer Science
University of Winnipeg
 Introduction and Terminology
Competencies and Definitions, SDLC Chap.1 and 3 Jan 7
Selecting SDLC -- Review of Process Models Chap. 4 Jan 12
Process Models Jan 14
Planning and Organization
Project Teams and Roles --Team Selection Chap.6, 12, 29 Jan. 19

Project Planning and WBS – Proj.Proposal/Charter Chap.7 and 8 Jan. 21

Tasks, Activities -- Project Plan Creation +Review Chap. 9 Jan. 26

Quiz 1 Jan. 28
Software Sizing – Size Estimation Models Chap.10 Feb. 2
Software Sizing – Size Estimation Models Feb 4
Estimating Duration and Cost Chap. 11 Feb 9
Estimating Duration and Cost Feb.11
Reading Week Break Feb. 14-20
Problem Solving Class – Sizing and Estimation Feb. 23
Quiz 2 Feb. 25

Scheduling – PERT/CPM Scheduling Models Chap. 14 and 15 Mar. 2

Requirements Specification—Creating SSR Chap. 16 and 17 Mar. 4
Problem Solving Class -PERT Mar. 9
Risk Management – Quantitative Risk Assessment Chap. 18 Mar. 11
Software Metrics –Product and Process Metrics Chap. 21 Mar.16
Software Metrics Metrics Continued Chap. 21 Mar. 18
Problem Solving Class -Metrics Mar. 23
V&V- Testing strategies, test coverage and path Chap. 23 Mar. 25
measures
Monitoring and Control
Project Tracking and Control Chap. 25 Mar. 30
SQA and SCM Chap. 30, 31 April 1
Problem Solving (V&V) + Review April 6
 Measurement - Motivation

1. Understanding
• What is happening during development and
maintenance?
• Establish baselines
2. Control
• Using baselines, monitor product and process
3. Improvement
• Based on measurements, improve the quality of
product/process
 Software Quality
 How is quality defined and measured in a coherent way?
1. Expectations of Quality
• User View -> Team (Developer) View -> Actual
Measurements
2. Use of the Product (SW)
• Operational, Transition or Revision

Quality Models have been defined keeping these two

perspectives in mind
 McCall Software Quality Model

Operability
Usability Training
Communicativeness
I/O Volume
Intregrity
I/O Rate
Access Control
Product Operation Efficiency Access Audit
Storage Efficiency
Execution Efficiency
Correctness
Traceability
Completeness
Reliability Accuracy
Error Tolerance
Consistency Measures
Product Revision Maintainability
Simplicity

Conciseness
Testability Instrumentation
Expandability
Flexibility Generality
Self-descriptiveness

Product Revision Reuseability Modularity

Machine
Independence
Portability S/W-S
independence
Comms
Commonality
Interoperability
Data Communality

Use Factor (External) Criteria(developer)

 Factors (External Attributes)
• Quality from a user’s perspective
• Examples: Reliability, usability or maintainability
• Too high-level
 Criteria
• Developers/Team view of quality
• Examples: Accuracy, Consistency
 Metrics (Internal Attributes)
• Actual measurement
 Simpler view

# of procedure
Maintainability parameters

Cyclomatic complexity

Reliability

Program Size (LOC)

Portability
# of error messages

Usability
Length of the user
manual
External Attributes
Internal Attributes (Metrics)
(User view)
 Measuring Internal Attributes
 Metrics for the Analysis Model
• Predicting size (FP, LOC, Bang- Model Blitz)
 Metrics for the Design Model
• Focuses on the Architectural Structure and
effectiveness of modules
• Suggests reusability/testability
• Specific Metrics:
 Cyclomatic Complexity (Thomas McCabe) and
Information Flow Complexity
 Metrics for Source Code
 Halstead’s Software Science
 Models of Software- Design Model
 Modeling of software is an essential stage in
establishing assessment criteria for internal
attributes
 Model is the image of certain structures in
reality
 Formal Models:
 Flow Graphs = (E, N, s, t) where N = {nodes}, E=
{edges}, and s,t  N.
 Structure Charts are also used as models for
software.
 Program Model A = (n1,n2, N1, N2) where n1, n2 are
operators and operands, N1 and N2 represent totals
 Design Model Metrics
 For internal attributes, we must consider the
structure of software. This includes three parts:
 Control Flow
 sequence of instructions, iterative and looping nature of
programs
 Flowgraph (model)
 Metric ( McCabe’s complexity)
 Data Flow
 Trailof a data item as it is created and handled by a
program
 Structure Charts (model)
 Metric -Information Flow Complexity (Henry-Kafura)
 Data Structure
 Organization of the data independent of the program
Representation of Program Flow
Graph
 Control Flow Constructs

Sequence If-Then Do-While

If-Then-Else

Repeat-Until

Case
Cyclomatic Complexity- McCabe (1976)
 Definition: Cyclomatic complexity is a measure of
the logical complexity of a module and the
minimum effort necessary to code a module.
 Cyclomatic is the number of linearly independent
paths and, consequently, the minimum number of
paths that one should (theoretically) test.
 Advantages
 Quantifies the logical (algorithmic) complexity
 Measures the minimum effort for testing
 Guides the testing process
 Useful for finding sneak paths within the logic
 Aids in verifying the integrity of control flow
 Used to test the interactions between code
constructs
Cyclomatic Complexity- Method 1
 Measure of logical
complexity of a program 1
1
 CC(G) = e – n + 2 2 3
2
 e is the # of edges 3 4
 n is the # of nodes 5
4

5
7
 G is the Flowgraph 6
6
 The CC number actually 8
7
9
measures the number of
linearly independent 8

paths through G CC(G) = 9-8+2

=3
Cyclomatic Complexity- Method 2

 CC(G) = D + 1 where D
is the D is number of
decision (predicate)
nodes
 CC provides a
quantitative measure
of testing difficulty
DE=2

 CC(G) = 2 + 1 v(G) = 2+1 =3

McCabe’s Cyclomatic Complexity – Method 3

CC(G) = the number of digraph regions

- where region is number of enclosures in the digraph

- Studies indicate distinct relationships between CC and

number of errors in source code
- Still in use today!
Cyclomatic Number of
Fundamental Control Structures
e n v(G)

n n 1 2 1

n
n n
4 4 2
n

n n n 3 3 2
 Software Module Example
1.procedure sort (var
x: array; n: integer); 1
2.var i, j, temp:
integer; 2

3. begin
3
4.for i:= 2 to n do
5.for j:= 1 to i do 12 4
6.if x[i] < x[j]
7.begin 5 7

8.temp:= x[i]; 6 8
9.x[i]:= x[j];
10. x[j]:= temp; 9
11. end 11
12. end 10
Example: sort(x,n)

1
e = 14
2 n = 12
regions = 4
R4 3

1
4
2
R1
5 7

6 8
R2 R3
9

11
10
McCabe’s Cyclomatic Complexity

Example: sort(x,n)

(1) CC= e - n + 2 = 14 - 12 + 2 = 4

(2) CC= D + 1 = 3 + 1 = 4

(3) CC = the number of digraph regions = 4

  The higher the complexity the more bugs. The
more bugs the more security flaws

 Cyclomatic Complexity & Reliability Risk

1 – 10 Simple procedure, little risk
11- 20 More Complex, moderate risk
21 – 50 Complex , high risk
>50 Untestable, VERY HIGH RISK
 Steps for Calculating Cyclomatic
Complexity

 Foreach module, designers/programmers must

create a flow chart/diagram depicting control
flow of the software
 Convertthe Control Flow Diagram into an
equivalent flow graph
 Calculatethe Cyclomatic Complexity for each
flow graph using McCabe’s Formula
Structure Chart Model - Information
Flow

Consists of:
-Modules (e.g., A, B)
-Input/Output
Resources
-Call Hierarchy
-Data Flow (e.g, a,b)
-Circles (global
variables)
 Properties of Structure Charts

 Structured Design seeks to conquer the

complexity of large systems by means of
partitioning the system into black boxes and
organizing the black boxes into hierarchies
 Applicable to call-return Architectures
 Global Variables (external coupling)
 Parameters (data coupling)
 Fan-in
 Fan-out
Span of Control
 The number of modules invoked by a module defines
its span of control.
 Modules with large spans of control cost more to
develop and maintain and generally give rise to more
faults.
 Coupling is an indication of the interconnections
between modules, functions or classes.
High coupling indicates higher interdependence (shared vars,
calls)
Loose coupling is when components act independently
of each other.
Fan-In and Fan-Out
FIFO is effectively the number of lines into and
out of a module at the design level.
Fan-In is a measure of module dependencies,
those modules to which the one investigated is
a server.
A high Fan-In suggests re-use.
Fan-Out suggests that the module investigated
requires many servers and devolves its work
elsewhere.
Complexity = Length * (Fan-in * Fan-out)2
FIFO
a

b c

d e f g

Module FI FO FIFO
a 0 3 0
b 1 3 3
c 2 2 4
d 1 0 0
e 2 1 2
f 3 2 6
g 2 0 0
Local Information Flow
A module can have many data flows into and out of it.
The greater the number of flows between modules, they
higher they are coupled. Flows may be through
parameter passing or use of globals or shared files.
Local Information Flows occur when a module passes
a parm to another module. Here A passes x to B.

x
A B
<A,x,B>
Global Information Flow

If module B returns a result y back to A, the local

Information flow is <B,y,A>.

y
A B

DS C

Global Flows occur when a module writes to a global data

structure and another reads from it.
<A,DS,C> states that A writes to the data structure, C reads from
it.
Local and Global Flows

B C D

File E
<A,x,B> <A,y,C> <A,z,D>
<B,xx,E> <C,yy,B> <C,yy,D>
<D,zz,A> <E,File,B> <E,File,A>
Information Flow Calculation
Fan-In and Fan-Out does not distinguish between
local and global flows. The IF metric is a summation of
all data flows.
To calculate the information flow, calculate FIFO as
before and then compute IF:

Module Fi Fo FIFO IF
A 2 3 6 36
B 3 1 3 9
C 1 2 2 4
D 2 1 2 4
E 1 1 1 1
Henry- Kafura (1981) Measure

Information Flow Complexity(M) = Length (M) x  (fan-in(M) x fan-out(M)) 

2

IFC(A) = length(A) * 36
IFC(B) = length(B) * 9
IFC(C) = length(C) * 4
IFC(D) = length(D) * 4
IFC(E) = length(E) * 1
Metrics for Source Code Halstead (1977)

 Composite measures of software complexity based

on
 common sense,
 information theory and
 psychology.

 The measures are derived after the code is

developed
 Very primitive measures
 Used by many for the prediction of maintenance
effort
Metrics for Source Code Halstead

 They are based on the following counts

 UOP is the # of distinct or unique operators that
appear in a program
 UOD is the # of distinct or unique operands that
appear in a program
 OP is the total # of operators occurrences (used)
 OD is the total # of operands occurrences (used)
Halstead’s Metrics

 The Halstead length (LTH) = OP+OD

 The Halstead Vocabulary (VOC) = UOP+UOD
 The Halstead Difficulty (DIF) =
(UOP/2) * (OD/UOD)
Example
 int x = 1 + 2;
 Operators (3): =, +, ;
 Operands (4) : int, x, 1 and 2
 LTH is OP+OD
 =7
 VOC is UOP+UOD
 =7
 DIF is (UOP/2) * (OD/UOD)
 3/2 *(4/4)
 = 1.5
Example
 int x = x + 1;
 Operators (3): =, +, ;
 Operands (4) : int, x, 1, but UOD (3)
 LTH = 7
 VOC = 6
 DIF is (UOP/2) * (OD/UOD)
 3/2 *(4/3)
 = 1.99
Other Primitive Metrics
 Ex: int x = y +1;
 Halstead Volume (VOL) = LTH * log2(VOC)
= 7 * log2(7)
 Halstead Effort (or mental EFF)
= DIF * VOL
= 1.5* 19.6 = 29.4
• Time = Effort/18 =29.4/18 ( 2 secs)
 Halstead Bugs (BUG) = VOL/3000 or
EFF^(2/3)/3000
Operators
! % & * + , -
./ ; < > ? ^ |
~ = >= <= == != >>
<< += -= *= /= %= &=
^= |= >>= <<= && || ++
-- -> return size of enum struct delete
continue new break union

if (…) … if (…) … else

switch (……) default:

case <label>: goto <label>

do … while (…) while (…) …do

for (… ; …; …) this->

[] {}

<function name>( ) ( ) in any other cases not covered

… ‘?’ … ‘ ‘: …
 Operands

Variables and identifiers

Constants (numeric literal/string)
Function names when used during calls
 Sample Counts
Java method operators counts operands counts
class list01 { 1 class 1 list01 1
public static void main(String[] args) { 2 public 1 args 1
int thisList[] = new int[3]; 3 static 1 thisList 3
4 void 1 3 1
for (int i=0;i<thisList.length; i++) { 5 main 1 i 6
thisList[i] = i; 6 String 1 0 1
System.out.println(thisList[i]); 7 int 3
}//for 8 new 1
}//main 9 length 1
}//list01 10 System.out.println 1
11 for 1
12 [] 5
13 {} 3
14 = 3
15 ; 5
16 () 3
17 < 1
18 ++ 1
19 . 3
20 // 3
UOP = 20 OP = 40
UOD = 6 OD =
13
At the class level
 Halstead Length (C_LTH) is the total of
all the lengths in the methods
 Halstead Volume (C_VOL) is the total
of all the volumes in the methods
 Halstead Bugs (C_BUG) = C_VOL/3000
 Halstead Effort (C_EFF) = is the total
of all the effort in the methods
 Halstead Vocabulary is not calculated
 Halstead Difficulty is not calculated
 References

 Managing the Software Process by Watt

Humphrey, Addison Wesley, 1990
 A framework for Software Measurement by
Horst Zuse, DeGruyter, 1998
 Software Metrics by P. Fenton and S.Fleeger,
PWS Publishing, 1997.