Software Size Metrics: Summary

Requirement
Length Design
LOC
Code
Halstead’s
Function point
Software Feature point
Functionality
size
Use-case point
Object point
Complexity Cyclomatic complexity
Reuse level
Reuse Reuse frequency
Reuse density
far@ucalgary.ca 3
 Software Size /1
 Internal product attributes describe a software
product in a way that is dependent only on the
product itself.
 One of the most useful attributes is the size of a
software product, which can be measured statically,
i.e., without executing the system.
 It is necessary to define software size in terms of
more than one internal attributes, each capturing a
key aspect of software size.
 Size measurement must reflect effort, cost and
productivity.
far@ucalgary.ca 4
 Software Size /2
 Software size can be described by length,
functionality, and complexity.
 Length is the physical product size.
 Functionality is a measure of the functions supplied by
the product to the user.
 Complexity is a multi-faceted attribute which can be
interpreted in multiple ways.
 Reuse is also an issue in size, specifically the
amount or size of reuse within a program.

far@ucalgary.ca 5
 Software Size: Length
 Length is the “physical size” of the product.
 In a software development effort, there are three
major development products: specification, design,
and code.
 The length of the specification can indicate how
long the design is likely to be, which in turn is a
predictor of code length.
 Traditionally, code length refers to text-based code
length.

far@ucalgary.ca 6
 Length: Code – LOC /1
 The most commonly used measure of source code
program length is the number of lines of code
(LOC).
 NCLOC: non-commented source line of code or effective
lines of code (ELOC).
 CLOC: commented source line of code.
 By measuring NCLOC and CLOC separately we
can define:
total length (LOC) = NCLOC + CLOC
 The ratio: CLOC/LOC measures the density of
comments in a program.

far@ucalgary.ca 7
 Length: Code – LOC /2
Variations of LOC:
 Count of physical lines including blank lines.

 Count of all lines except blank lines and comments.

 Count of all statements except comments

(statements taking more than one line count as only
one line).
 Count of all lines except blank lines, comments,
declarations and headings.
 Count of only executable statements, not including
exception conditions.

far@ucalgary.ca 8
 Length: Code – LOC /3
 Measurement Unit: Lines of Source Code
Statement Type Includes Excludes
Executable X
Non-executable
Declarations X
Compiler Directives X
Comments X
On their own lines X
On lines with source code X
Banners and nonblank spacers X
Blank (empty) comments X
Blank Lines X

far@ucalgary.ca 9
Length: Code – LOC /4
 Advantages of LOC
 Simple and automatically measurable
 Correlates with programming effort (& cost)

 Disadvantage of LOC
 Vague definition
 Language dependability
 Not available for early planning
 Developers’ skill dependability
 Encouraging “sumo” development!
far@ucalgary.ca 10
Length: Halstead’s Work /1
 Maurice Halstead’s Theory (1971~1979):
 A program P is a collection of tokens, composed
of two basic elements: operands and operators
 Operands are variables, constants, addresses
 Operators are defined operations in a
programming language
if … else a, b, x
(language constructs) + - > = ; 100
main()
goto

far@ucalgary.ca 11
 Length: Halstead’s Work /2
 Number of distinct operators in the program (μ1)
 Number of distinct operands in the program (μ2)
 Total number of occurrences of operators in the
program (N1)
 Total number of occurrences of operands in the
program (N2)

 Program vocabulary (μ)

μ = μ1 + μ2

far@ucalgary.ca 12
 Length: Halstead’s Work /3
 Program length is the total number of occurrences of
operators and operands:
N = N1 + N2
 Program volume is the number of mental comparisons
needed to write a program of length N
( N1 + N 2 ) log 2 ( µ1 + µ2 )
N log 2 µ =
V=
 Program level (L):
1 2 µ2
=
L V V *
or =
L = ×
D µ1 N 2
 where V * is the minimum size potential volume (i.e.,
minimal size of implementation) and D is program difficulty

far@ucalgary.ca 13
 Length: Halstead’s Work /4
 Program length is the total number of occurrences
of operators and operands:
N = N1 + N2
 Program estimated length (N̂ )
=Nˆ µ1 log 2 µ1 + µ2 log 2 µ2
 Effort required to generate program P: number of
elementary discriminations
V µ1 N 2
E =V × D = = × N log 2 µ
L 2µ2
far@ucalgary.ca 14
Length: Halstead’s Work /5
 Time required for developing program P is
the total effort divided by the number of
elementary discriminations per second
T =E
β
 In cognitive psychology β is usually a
number between 5 and 20
 Halstead claims that β=18

far@ucalgary.ca 15
Length: Halstead’s Work /6
 Remaining bugs: the number of bugs left in
the software at the delivery time
2/3
B= E
3000
 Conclusion: the bigger program needs more
time to be developed and more bugs
remained

far@ucalgary.ca 16
Example 1
 For the following C program:
#include<stdio.h>
main()
{
int a ; Operands
scanf (“%d”, &a);
if ( a >= 10 )
if ( a < 20 ) printf ("10 < a< 20 %d\n" , a);
else printf ("a >= 20 %d\n" , a);
else printf ("a <= 10 %d\n" , a);
}

far@ucalgary.ca 17
Example 1 (cont’d)
 Determine number of operators (μ1).
 Determine number of operands (μ2).
 Determine the program length in terms of
the total number of occurrences of operators
(N1) and operands (N2): N = N1 + N2
 Estimate program length

far@ucalgary.ca 18
Example 1 (cont’d)
Operators Number of Operators Number of
occurrences occurrences
# 1 <= 1
include 1 \n 3
stdio.h 1 printf 3
<…> 1 < 3
main 1 >= 2
(…) 7 if … else 2
{…} 1 & 1
int 1 , 4
; 5 %d 4
scanf 1 “…“ 4
μ1 = 20 N1 = 47

far@ucalgary.ca 19
Example 1 (cont’d)
Operands Number of occurrences
a 10
10 3
20 3

μ2 = 3 N2 = 16
μ1 = 20 N1 = 47
Program length: N = N1 + N2 = 63
Program Estimated length:
Nˆ= µ1 log 2 µ1 + µ2 log 2 µ2= 20 log 2 20 + 3log 2 3= 91.1934

far@ucalgary.ca 20
 Example 2
 For the following program calculate Halstead’s (c1)
number of operators; (c2) number of operands; (c3)
program vocabulary; (c4) occurrences of operators
in the program; (c5) occurrences of operands in the
program; (c6) program length; (c7) program
volume; (c8) program estimated length.
1: read x,y,z;
2: type = “scalene”;
3: if (x == y or x == z or y == z) type =“isosceles”;
4: if (x == y and x == z) type =“equilateral”;
5: if (x >= y+z or y >= x+z or z >= x+y) type =“not a
triangle”;
6: if (x <= 0 or y <= 0 or z <= 0) type =“bad inputs”;
7: print type;

far@ucalgary.ca 21
 Example 2 (cont’d)

Operators Operands
read 1 == 5 strings 5
, 2 or 6 x 9
; 7 and 1 y 8
“ … ” 6 >= 3 z 8
= 5 <= 3 0 3
if 4 + 3 type 6
( ) 4 print 1
μ1 = 14 μ2 = 6
N1 = 51 N2 = 39

far@ucalgary.ca 22
 Example 2 (cont’d)
(c1) Number of distinct operators in the program: μ1 = 14
(c2) Number of distinct operands in the program: μ2 = 6
(c3) Program vocabulary: μ = μ1 + μ2 = 20
(c4) Total number of occurrences of operators in the program:
N1 = 51
(c5) Total number of occurrences of operands in the program:
N2 = 39
(c6) Program length: N = N1 + N2 = 90
(c7) Program volume: V = N log2 μ = 90 log2 (20) = 388.9735
(c8) Program estimated length:
Nˆ = µ log µ + µ log µ = 14 log 14 + 6 log 6= 68.81274
1 2 1 2 2 2 2 2

far@ucalgary.ca 23
 Length: Halstead’s Work /7
Critics of Halstead’s work
 Developed in the context of assembly languages and
too fine grained for modern programming
languages.
 The treatment of basic and derived measures is
somehow confusing.
 The notions of time to develop and remaining bugs
are arguable.
 Unable to be extended to include the size for
specification and design.

far@ucalgary.ca 24
 Length: Alternative Methods
 Alternative methods for text-based measurement
of code length:
1) Source memory size: Measuring length in terms of
number of bytes of computer storage required for the
program text. Excludes library code.
2) Char size: Measuring length in terms of number of
characters (CHAR) in program text.
3) Object memory size: Measuring length in terms of an
object (executable or binary) file. Includes library code.
 All are relatively easy to measure (or estimate).

far@ucalgary.ca 25
 Length: Code – Problems /1
 One of the problems with text-based definition of
length is that the line of code measurement is
increasingly less meaningful as software
development turns to more automated tools, such
as:
 Tools that generate code from specifications
 Visual programming tools
 What can be the length measure for objects that are
not textual?
 How can one account for components that are
constructed externally? (library, repository,
inherited functions, design patterns, etc.)

far@ucalgary.ca 26
Length: Code – Problems /2
 The LOC size measurement needs to be
replaced by some other size measures, such
as:
 Object points (as used in COCOMO 2.0), etc.
 Measuring length by taking into account the
reused portion of code.

far@ucalgary.ca 27
 Length: Spec. & Design
 Specification and design documents are usually
composed of logical text (axioms, constraints, etc.)
and diagrams (flow graphs, etc.)
 Define atomic objects to measure textual contents
and graphical contents, e.g.,
Diagram Atomic objects
Data-flow diagram bubbles
Data dictionary Data element
Entity-relationship diagram Objects, relations
State transition diagrams States, transitions

far@ucalgary.ca 28
Length: Prediction
 Theoretically, size of design can be used to
predict size of code.
 Each project has a design-to-code expansion
ratio. If design is measured by the number of
modules of size si, then:
m
LOC = σ ∑ si
i =1

 σ is the design-to-code expansion ratio

recorded for previous similar projects.

far@ucalgary.ca 29
Measuring Software Size:
Function Point (FP), Feature
Point, Object Point and Use-
case Point
 Review: Software Size
 Size measurement must reflect effort, cost and productivity.
 Size-oriented metrics are direct measures of software and the
process by which it was developed. These metrics include
effort (time), money spent, LOC, pages of documents
created, errors, and number of staff.
 Defining software size in terms of length, functionality, and
complexity, each capturing a key aspect of software size.
 Basic measure for length is LOC. Simple size-oriented
metrics can be generated from LOC, such as:
 Productivity = KLOC / person-month
 Quality = defects / KLOC
 Documentation = pages of documents / KLOC
 etc.

far@ucalgary.ca 32
 Length: Problem with LOC
 Depending on the programmer and/or coding
standards, the "line of code" could be, and usually is,
written on many separate lines:
for (i=0; i<100; ++i)
{
printf("hello");
} /* Now how many lines of code is this? */
 In this example we have:
 4 Physical Lines of Code (is placing braces worth to be estimated?)
 2 Logical Line of Code (What about all the work writing non-statement
lines?)
 1 Comment Line (?)

far@ucalgary.ca
 Function-Oriented Metrics
 Function Point (FP) is a weighted measure of software
functionality.
 The idea is that a product with more functionality will be
larger in size.
 Function-oriented metrics are indirect measures of software
which focus on functionality and utility.
 The first function-oriented metrics was proposed by Albrecht
(1979~1983) who suggested a productivity measurement
approach called the Function Point (FP) method.
 Function points (FPs) measure the amount of functionality in
a system based upon the system specification.

far@ucalgary.ca 34
FP: History
1997 1999 2001 2003
1.0 2.0 2.1 2.2
St. Pierre COSMIC
Full Function Points

1975 1979 1984 1990 1994 1999 2004

IBM Albrecht IFPUG 3.4 IFPUG 4.0 IFPUG 4.1 IFPUG 4.2
Function Point Analysis

1988 1998
Symons UKSMA 1.3.1
Mark II Function Point Analysis

1975 1980 1985 1990 1995 2000

far@ucalgary.ca
 FP: Current Status
 1979: Proposed by Albrecht, at IBM
 1983: Gained popularity, Albrecht’s
IEEE paper
 1986: International FP user group
established (http://www.ifpug.org)
 1990~2004: IFPUG, Guidelines to FP
measurement
 1998: ISO 14143-FSM: Functional Size
Measurement
 1999: IFPUG, FP counting practice
manual, version 4.1
 2004: IFPUG, FP counting practice
manual, version 4.2

far@ucalgary.ca 36
Function Point (FP) Standards
Standard Name Content
ISO/IEC IFPUG 4.1 Unadjusted functional size measurement
method -- Counting practices manual
14143-1:2000
IFPUG Function Points VS 4.1
(unadjusted)
ISO/IEC IFPUG 4.2 Unadjusted functional size measurement
20926:2004 method -- Counting practices manual
IFPUG Function Points VS 4.2
(unadjusted)
ISO/IEC COSMIC-FFP A functional size measurement method
19761:2003 COSMIC Full Function Points Vs. 2.2
ISO/IEC Mark II Function Counting Practices Manual Mark II
20968:2002 Point Analysis Function Points

far@ucalgary.ca
 Function Point (FP) /1
External
External Outputs
Inputs (EO)
(EI)

Function
Point (FP)

External
External Interface files (EIF) Inquiries (EQ)
Internal Logic files (ILF)
far@ucalgary.ca 38
 Function Point (FP) /2
 Function Point (FP) is a weighted measure of
software functionality.
 FP is computed in two steps:
1) Calculating Unadjusted Function point Count (UFC).
2) Multiplying the UFC by a Value Adjustment Factor
(VAF)
 The final (adjusted) Function Point is:
FP = UFC × VAF

far@ucalgary.ca 39
FP Counting Summary
Adjusted
Step 2 Adjusted
Function Points
FP Count Complexity
Adjustment
14 Adjustment Factors
Value Adjustment
Factor (VAF)

Step 1b
Weighted Weighted Weighted Weighted Weigthed Unadjusted
EI + EO + EQ + EIF + ILF = Function Points
(UFP)

Weighting of
L A H L A H L A H functional (technical)
L A H L A H
complexities

Step 1a Unadjusted
# EI # EO # EQ # EIF # ILF and Unweighted
Function Count

far@ucalgary.ca
1. External Inputs (EI)
 External Inputs – IFPUG Definition:
 An external input (EI) is an elementary

process that processes data or control

information that comes from outside
the application boundary
 The primary intent of an EI is to

maintain one or more ILFs and/or to

alter the behavior of the system

 Example:
 Data entry by users
 Data or file feeds by external applications

far@ucalgary.ca
2. External Outputs (EO)
 External Outputs – IFPUG Definition:
 An external output (EO) is an elementary process
that sends data or control information outside the
application boundary
 The primary intent of an external output is to present
information to a user through processing logic other
than, or in addition to, the retrieval of data or control
information
 The processing logic must contain at least one
mathematical formula or calculation, create derived
data, maintain one or more ILFs, or alter the
behavior of the system

 Example:
 Reports created by the application being counted,
where the reports include derived information
far@ucalgary.ca
3. External Inquiries (EQ)
 External Inquiries – IFPUG Definition:
 An external inquiry (EQ) is an elementary
process that sends data or control information
outside the application boundary
 The primary intent of an external inquiry is to
present information to a user through the
retrieval of data or control information from an
ILF or EIF
 The processing logic contains no mathematical
formulas or calculations, and creates no derived
data
 No ILF is maintained during the processing,
nor is the behavior of the system altered
 Example:
 Reports created by the application being
counted, where the report does not include any
derived data

far@ucalgary.ca
4. Internal Logical Files (ILF)
 Internal Logical Files – IFPUG
Definition:
 An ILF is a user-identifiable group of logically
related data or control information maintained
within the boundary of the application
 The primary intent of an ILF is to hold data
maintained through one or more elementary
processes of the application being counted

 Example:
 Tables in a relational database
 Files
 Application control information, perhaps things
like user preferences that are stored by the
application

far@ucalgary.ca
5. Ext. Interface Files (EIF)
 External Interface files – IFPUG
Definition:
 An external interface file (EIF) is a user
identifiable group of logically related data or
control information referenced by the
application, but maintained within the
boundary of another application
 The primary intent of an EIF is to hold data
referenced through one or more elementary
processes within the boundary of the
application counted
 This means an EIF counted for an application
must be in an ILF in another application

 Example:
 As for ILF, but maintained in a different system
far@ucalgary.ca
FP Counting Summary
Adjusted
Step 2 Adjusted
Function Points
FP Count Complexity
Adjustment
14 Adjustment Factors
Value Adjustment
Factor (VAF)

Step 1b
Weighted Weighted Weighted Weighted Weigthed Unadjusted
EI + EO + EQ + EIF + ILF = Function Points
(UFP)

Weighting of
L A H L A H L A H functional (technical)
L A H L A H
complexities

Step 1a Unadjusted
# EI # EO # EQ # EIF # ILF and Unweighted
Function Count

far@ucalgary.ca
 Unadjusted FP Count (UFC)
 A complexity rating is associated with each count according
to function point complexity weights, below:
UFC = 4 N EI + 5 N EO + 4 N EQ + 7 N EIF + 1 N ILF 0
Complexity Weighting Factor
Element Low High
Average
(Simple) (Complex)
External inputs (NEI) 3 4 6
External outputs (NEO) 4 5 7
External inquiries (NEQ) 3 4 6
External interface files (NEIF) 5 7 10
Internal logical files (NILF) 7 10 15
far@ucalgary.ca 47
 FP Counting: Weighting of
Technical Complexity
Elements Complexity Weighting Factor

low average high Sum

External Inputs (EI)

__ x 3 = _____ __ x 4 = _____ __ x 6 = _____ _____

External Outputs (EO)

__ x 4 = _____ __ x 5 = _____ __ x 7 = _____ _____

External Inquiries
__x 3 = _____ __ x 4 = _____ __ x 6 = _____ _____
(EQ)
External Interface
__ x 5 = _____ __ x 7 = _____ __ x10 = _____ _____
Files (EIF)
Internal Logical Files
__ x 7 = _____ __ x10 = _____ __ x15 = _____ _____
(ILF)

Unadjusted Function Points (UFP)

far@ucalgary.ca
 Function Types – Complexity
Assessment
 How to assess complexity?
Data Function Types Transaction Function Types
Internal Logical External External External External
Files (ILF) Interface Files Input Output Inquiry
(EIF) (EI) (EO) (EQ)
Elements REcord Types (RET): User File Type Referenced (FTR):
evaluated recognizable sub groups of data File type referenced by a
for technical elements within an ILF or an EIF. It transaction. An FTR must be an
complexity is best to look at logical groupings Internal Logical File (ILF) or
assessment of data to help identify them. External Interface File (EIF).
Data Element Types (DET): A unique user recognizable, non-recursive
(non-repetitive) field containing dynamic information. If a DET is
recursive then only the first occurrence of the DET is considered not
every occurrence.

far@ucalgary.ca 49
 Complexity Assessment: EI
 Identify number of File Types Referenced (FTR)
 Identify number of Data Element Type (DET)
 Determine complexity weight ( used to calculate
FP count)
#DET
EI
1-4 5-15 > 15
1 low (3) low (3) average (4)
#FTR 2 low (3) average (4) high (6)
>2 average (4) high (6) high (6)

far@ucalgary.ca
 External Input – Example
 Enter a new employee
Employee
ILF:
- Name
- ID Employee with Monthly Payment:
- Birth Date Administration (DB)  Name
- Payment Reference
 ID
Weekly Payment Monthly Payment  Birth Date
- Hourly Rate - Salary Level
- Payment Office
 Payment Reference
 Salary Level

#DET
EI
1-4 5-15 > 15

1 FTR 1 low (3) low (3) average (4)

5 DET #FTR 2 low (3) average (4) high (6)
>2 average (4) high (6) high (6)

far@ucalgary.ca
 EI – Example
 Enter a new employee
Employee
- Name
- ID
ILF:
Employee
with Weekly Payment:
- Birth Date  Name
Administration (DB)
- Payment Reference  ID
 Birth Date
Weekly Payment Monthly Payment  Payment Reference
- Hourly Rate - Salary Level
- Payment Office  Hourly Rate
 Payment Office

#DET
EI
1-4 5-15 > 15
1 low (3) low (3) average (4)
1 FTR
6 DET #FTR 2 low (3) average (4) high (6)
>2 average (4) high (6) high (6)

far@ucalgary.ca
 Complexity Assessment: EO
 Identify number of File Types Referenced (FTR)
 Identify number of Data Element Type (DET)
 Determine complexity weight ( used to calculate
FP count)
#DET
EO
1-5 6-19 > 19
1 low (4) low (4) average (5)
#FTR 2-3 low (4) average (5) high (7)
>3 average (5) high (7) high (7)

far@ucalgary.ca
 EO – Example
 Report of all Employees containing Names and
Birth Dates, sorted by age.

ILF: Employee ≤ 40 Years

- Name Jerome Iginla, 10-02-1966
Rehet Warner, 05-03-1966 1 FTR
- ID 2 DET
- Birth Date ≤ 45 Years
- Payment Reference Chris Chelios, 23-03-1961

#DET
EO
1-5 6-19 > 19
1 low (4) low (4) average (5)
#FTR 2-3 low (4) average (5) high (7)
>3 average (5) high (7) high (7)

far@ucalgary.ca
 Complexity Assessment: EQ
 Identify number of File Types Referenced (FTR)
 Identify number of Data Element Type (DET)
 Determine complexity weight ( used to calculate
FP count)
#DET
EQ
1-5 6-19 > 19
1 low (3) low (3) average (4)
#FTR 2-3 low (3) average (4) high (6)
>3 average (4) high (6) high (6)

far@ucalgary.ca
 EQ – Example
 Report of all employees belonging to Department X
containing Names, Birth Dates, and showing the
ILF: ILF:
“Employee” “Department”
Department Name
 Files (ILF): Employee, Department
 2 FTR: Employee, Department
3 DET: Name (Employee), Birth Date (Employee),
Department Name (Department)
Report
#DET
EQ
1-5 6-19 > 19
1 low (3) low (3) average (4)
#FTR 2-3 low (3) average (4) high (6)
>3 average (4) high (6) high (6)

far@ucalgary.ca
 Complexity Assessment: ILF
 Identify number of Record Types (RET)
 Identify number of Data Element Type (DET)
 Determine complexity weight ( used to calculate
FP count)
#DET
ILF
1-19 20-50 > 50
1 low (7) low (7) average
(10)
#RET 2-5 low (7) average high (15)
(10)
>5 average (10) high (15) high (15)

far@ucalgary.ca
 ILF – Example
Employee
ILF: - Name
“Employee” = - ID
1 RET
4 DET
- Birth Date
- Payment Reference

#DET
ILF
1-19 20-50 > 50
1 low (7) low (7) average (10)

#RET 2-5 low (7) average (10) high (15)

>5 average (10) high (15) high (15)

far@ucalgary.ca
 Complexity Assessment: EIF
 Identify number of Record Types (RET)
 Identify number of Data Element Type (DET)
 Determine complexity weight ( used to calculate
FP count)
#DET
EIF
1-19 20-50 > 50
1 low (5) low (5) average (7)
#RET 2-5 low (5) average (7) high (10)
>5 average (7) high (10) high (10)

far@ucalgary.ca
EIF – Example
Employee
- Name EIF:
- ID Employee
- Birth Date Administration (DB)
Payroll - Payment Reference
Software
Weekly Payment Monthly Payment
- Hourly Rate - Salary Level
- Payment Office

#DET
EIF
2 RET 1-19 20-50 > 50
7 DET
1 low (5) low (5) average (7)
#RET 2-5 low (5) average (7) high (10)
>5 average (7) high (10) high (10)

far@ucalgary.ca
FP Counting Example – GUI
Employee
Name new
First Name
change 3 External Inputs
Street
delete
Postal Code
City close
Birth Date
“close” button does not
count, because it is not
a transaction in its own
right involving access to
1 External Inquiry (input side) ILFs, EIFs

External Input (new, 1 FTR, 7 DET, low) = 3 FP

External Input (change, 1 FTR, 7 DET, low) = 3 FP
12 FP
External Input (delete, 1 FTR, 7 DET, low) = 3 FP
External Inquiry (navigate, 1 FTR, 7 DET, low) = 3 FP

far@ucalgary.ca
FP Counting Summary
Adjusted
Step 2 Adjusted
Function Points
FP Count Complexity
Adjustment
14 Adjustment Factors
Value Adjustment
Factor (VAF)

Step 1b
Weighted Weighted Weighted Weighted Weigthed Unadjusted
EI + EO + EQ + EIF + ILF = Function Points
(UFP)

Weighting of
L A H L A H L A H functional (technical)
L A H L A H
complexities

Step 1a Unadjusted
# EI # EO # EQ # EIF # ILF and Unweighted
Function Count

far@ucalgary.ca
 Value Adjustment Factor (VAF) /1
 Value Adjustment Factor (VAF) (aka. Technical
complexity factors) is a weighted sum of 14
components, given below:
F1 Data Communications F8 On-line Update
F2 Distributed Data Processing F9 Complex Processing
F3 Performance F10 Reusability
F4 Heavily Used Configuration F11 Installation Ease
F5 Transaction Rate F12 Operational Ease
F6 On-line Data Entry F13 Multiple Sites
F7 End-User Efficiency F14 Facilitate Change

far@ucalgary.ca 63
 Value Adjustment Factor (VAF)
1. Data Communications: The data and control information used in the application
are sent or received over communication facilities.
2. Distributed Data Processing: Distributed data or processing functions are a
characteristic of the application within the application boundary.
3. Performance: Application performance objectives, stated or approved by the
user, in either response or throughput, influence (or will influence) the design,
development, installation and support of the application.
4. Heavily Used Configuration: A heavily used operational configuration,
requiring special design considerations, is a characteristic of the application.
5. Transaction Rate: The transaction rate is high and influences the design,
development, installation and support.
6. On-line Data Entry: On-line data entry and control information functions are
provided in the application.
7. End-User Efficiency: The on-line functions provided emphasize a design for
end-user efficiency.

SENG421 (Winter 2006) far@ucalgary.ca 64

 Value Adjustment Factor (VAF)
8. On-line Update: The application provides on-line update for the internal logical
files.
9. Complex Processing: Complex processing is a characteristic of the application.
10. Reusability: The application and the code in the application have been
specifically designed, developed and supported to be usable in other applications.
11. Installation Ease: Conversion and installation ease are characteristics of the
application. A conversion and installation plan and/or conversion tools were
provided and tested during the system test phase.
12. Operational Ease: Operational ease is a characteristic of the application.
Effective start-up, backup and recovery procedures were provided and tested
during the system test phase.
13. Multiple Sites: The application has been specifically designed, developed and
supported to be installed at multiple sites for multiple organizations.
14. Facilitate Change: The application has been specifically designed, developed
and supported to facilitate change.

SENG421 (Winter 2006) far@ucalgary.ca 65

 Value Adjustment Factor (VAF) /2
 Each component is rated from 0 to 5, where 0
means the component is not relevant to the system
and 5 means the component is essential.
 VAF can then be calculated as:
Min = 0
14 Max = 0.7

= 0.65 + 0.01∑ Fj
VAF
j =1

 VAF varies from 0.65 (if all Fj are set to 0) to 1.35

(if all Fj are set to 5)
 Final Function Point is: FP = UFC × VAF

far@ucalgary.ca 66
 FP Example /1a
Specification: Spell Checker
 Checks all words in a document by comparing them
to a list of words in the internal dictionary and an
optional user-defined dictionary
 After processing the document sends a report on all
misspelled words to standard output
 On request from user shows number of words FP Count
processed on standard output
 On request from user shows number of spelling
errors detected on standard output
 Requests can be issued at any point in time while
processing the document file

far@ucalgary.ca
 FP Example /1b
Spell Checker
Doc #Words? #Errors?
name Dic.
name
 Convert spec to a Document
file Spell Checker
diagram User Dictionary
personal
Dictionary
Report #Words #Errors
Specification:
1. Checks all words in a document by comparing them to a list of words in the internal
dictionary and an optional user-defined dictionary
2. After processing the document sends a report on all misspelled words to standard
output
3. On request from user shows number of words processed on standard output
4. On request from user shows number of spelling errors detected on standard output
5. Requests can be issued at any point in time while processing the document file

far@ucalgary.ca
 FP Example /1c
Spell Checker
 Convert spec to a diagram

Inquiries?

Inputs? Outputs?

External file?
Internal file?

far@ucalgary.ca 70
 FP Example /1d
Solution A:
• EI: Doc. name + User Dic. name  2 Doc Dic.
• EO: Report + #Words + #Errors  3 name name

• EQ: -- Document
file Spell Checker
• EIF: Document + User Dictionary  2
User Dictionary
• ILF: Dictionary  1
personal
Dictionary
Report #Words #Errors
Specification:
1. Checks all words in a document by comparing them to a list of words in the internal
dictionary and an optional user-defined dictionary
2. After processing the document sends a report on all misspelled words to standard
output
3. On request from user shows number of words processed on standard output
4. On request from user shows number of spelling errors detected on standard output
5. Requests can be issued at any point in time while processing the document file

EI EO EQ EIF ILF

far@ucalgary.ca
 FP Example /1e
Weighting Factor  N =2 (number of EI): document
EI

Element Sim Aver Comp name, user-defined dictionary name

ple age lex  N =3 (number of EO): misspelled
EO
External inputs
(EI)
3 4 6 word report, number-of-words-
External outputs
processed message, number-of-
(EO)
4 5 7 errors-so-far message
External inquiries
3 4 6
 N =0 (number of EQ): --
EQ
(EQ)
 N =2 (number of EIF): document
EIF
External interface
files (EIF)
5 7 10 file, personal dictionary
Internal logical
7 10 15
 N =1 (number of ILF): dictionary
ILF
files (ILF)

UFC = 4×2 + 5×3 + 4×0 + 7×2 + 10×1 = 47

far@ucalgary.ca
 FP Example /1f
Solution B:
• EI: Doc. name + Dic. name  2 Doc #Words? #Errors?
• EO: Report  1 name Dic.
name
• EQ: #Words? + #Errors?  2 Document
file Spell Checker
• EIF: Document + User Dictionary  2
User Dictionary
• ILF: Dictionary  1
personal
Dictionary
Report
Specification:
1. Checks all words in a document by comparing them to a list of words in the internal
dictionary and an optional user-defined dictionary
2. After processing the document sends a report on all misspelled words to standard
output
3. On request from user shows number of words processed on standard output
4. On request from user shows number of spelling errors detected on standard output
5. Requests can be issued at any point in time while processing the document file

EI EO EQ EIF ILF

far@ucalgary.ca
 FP Example /1g
Weighting Factor  N =2 (number of EI): document
EI

Element Sim Aver Comp

ple age lex
name, user-defined dictionary name
External inputs
3 4 6
 N =1 (number of EO): misspelled
EO
(EI)
External outputs
word report
4 5 7
(EO)  N =2 (number of EQ): number-of-
EQ

External inquiries
(EQ)
3 4 6 words-processed message, number-
External interface
5 7 10
of-errors-so-far message
files (EIF)
Internal logical
 N =2 (number of EIF): document
EIF
7 10 15
files (ILF) file, personal dictionary
 N =1 (number of ILF): dictionary
ILF

UFC = 4×2 + 5×1 + 4×2 + 7×2 + 10×1 = 45

far@ucalgary.ca
 FP Example /1h
 Suppose that
F1=F2=F6=F7=F8=F14= 3;
14
F4=F10=5
= 0.65 + 0.01∑ Fj
VAF
TCF and the rest are zero.
j =1

VAF = 0.65 + 0.01(18+10) + 0.93

Solution A: FP = 47 × 0.93 ≈ 44
Solution B: FP = 45 × 0.93 ≈ 42

far@ucalgary.ca
FP Example /1i – Discussion
Which solution is correct?
 Solution A?

 Solution B?

 None of them? (cf. Textbook)

Answer: Solution A is correct!

Why? The difference is because of
correct interpretation of EO and EQ
for the requirement #5

far@ucalgary.ca
Function Points
(IFPUG)
Example 2
 FP: Example /2a
 Consider the following system that processes
various commands from the operator of a chemical
plant. Various interactions of the system with the
operator and internal and external files are shown.
 The system consults two databases for stored
pressure and temperature readings. In the case of
emergency, the system asks the user whether to
send the results to an electronic emergency bulletin
board or not.
 Calculate the unadjusted function point count
(UFC) for this system.

far@ucalgary.ca 78
FP: Example /2b
EI EO EQ EIF ILF

EI EO EQ EIF ILF

far@ucalgary.ca
 FP: Example /2c
 N EI number of external inputs 2
 N EO number of external outputs 3
 N EQ number of external inquiries 1
 N EIF number of external interface files 2
 N ILF number of internal logical files 1

UFC = 4 NEI + 5 NEO + 4 NEQ + 7 NEIF + 10 NILF

UFC = 4x2 + 5x3 + 4x1 + 7x2 + 10x1 = 51

far@ucalgary.ca
 Review: Software Size
 Size measurement must reflect effort, cost and productivity.
 Defining software size in terms of length, functionality, and
complexity, each capturing a key aspect of software size.
 Basic measure for length is LOC.
 Basic measure for functionality is Function Point (FP).
 FP is computed in two steps:
1) Calculating an Unadjusted Function point Count (UFC).
2) Multiplying the UFC by a Value Adjustment Factor (VAF).
The final (adjusted) Function Point is:
FP = UFC × VAF
 FP variations: feature point, object point, use-case point.

far@ucalgary.ca 81
FP vs. LOC /1
 A number of studies have attempted to relate
LOC and FP metrics (Jones, 1996).
 The average number of source code
statements per function point has been
derived from case studies for numerous
programming languages.
 Languages have been classified into different
levels according to the relationship between
LOC and FP.

far@ucalgary.ca 82
FP vs. LOC /2
Language Typical SLOC per FP
1GL Default Language 320
2GL Default Language 107
3GL Default Language 80
4GL Default Language 20
Code generators 15
Assembler 320
C 148
Basic 107
Pascal 90

far@ucalgary.ca 84
FP vs. LOC /3
Language Typical SLOC per FP
C# 59
C++ 60
PL/SQL 46
Java 2 60
Visual Basic 50
Delphi 18
HTML 4 14
SQL 13
Excel 47
Newer Data!
http://www.qsm.com/FPGearing.html

far@ucalgary.ca 85
 Effort Estimation with FP
3500
Effort FPMM (IBM data)

Function Points
3000
estimation
based on 2500
organization- 2000
specific data
1500
from past
projects. 1000
500
Person-Months
0
0 100 200 300 400

far@ucalgary.ca
FP: Advantages – Summary
 Can be counted before design or code
documents exist
 Can be used for estimating project cost,
effort, schedule early in the project life-cycle
 Helps with contract negotiations
 Is standardized (though several competing
standards exist)

far@ucalgary.ca
 FP: Critics
 FP is a subjective measure: affected by the selection
of weights by external users.
 Function point calculation requires a full software
system specification. It is therefore difficult to use
function points very early in the software
development lifecycle.
 Physical meaning of the basic unit of FP is unclear.
 Unable to account for new versions of I/O, such as
data streams, intelligent message passing, etc.
 Not suitable for “complex” software, e.g., real-time
and embedded applications.

far@ucalgary.ca 88
 A Quote from John Munson
 “The most important thing we must know about
derived metrics is that we cannot add apples and
oranges. A new metric simply cannot be derived
from two or more simple metrics. We recognize this
fact in several aspects of our daily life. We do not
recognize this fact in our analysis of software
engineering problems. Consider the case of the city
of Gold Hill, Colorado. Outside the town there is a
sign that reads:”
Gold Hill
 This is really a funny sign. But it is Established 1859

exactly how we define FP!! Elevation

Population
8463
118
Total 10440

Software Engineering Measurement (by John C. Munson)

far@ucalgary.ca 89
Feature Point
 Feature Point /1
 Function points were originally designed to be applied to
business information systems. Extensions have been
suggested called feature points which may enable this
measure to be applied to other software engineering
applications.
 Feature points accommodate applications in which the
“algorithmic complexity” is high such as real-time, process
control, and embedded software applications.
 For conventional software and information systems
functions and feature points produce similar results. For
complex systems, feature points often produce counts about
%20~%35 higher than function points.

far@ucalgary.ca 91
 Feature Point /2
 Feature points are calculated the same way as FPs
with the additions of algorithms as an additional
software characteristic.
 Counts are made for the five FP categories, i.e.,
number of external inputs, external outputs,
inquiries, internal files, external interfaces, plus:
 Algorithm (Na): A bounded computational problem such
as inverting a matrix, decoding a bit string, or handling an
interrupt.

far@ucalgary.ca 92
 Feature Point /3
 Feature points are calculated using:
 Number of external inputs ×4
 Number of external outputs ×5
 Number of external inquiries ×4
 Number of external interface files ×7 
 Number of internal files ×7
 Algorithms ×3 

UFeC = 4 NEI + 5 NEO + 4 NEQ + 7 NEIF + 7 NILF + 3 NA

 The UFeC used in the function point calculation to calculate
the feature points.

far@ucalgary.ca 93
Object Point
 Object Point /1
 Object points are used as an initial measure for size
way early in the development cycle, during
feasibility studies.
 An initial size measure is determined by counting
the number of screens, reports, and third-generation
components that will be used in the application.
 Each object is classified as simple, medium, or
difficult.

far@ucalgary.ca 95
 Object Point /2
 Object point complexity levels for screens.

Number and source of data tables

Number of views Total <4 Total <8 Total 8+
contained <2 servers 2-3 servers >3 servers
<2 clients 3-5 clients >5 clients
<3 Simple Simple Medium
3-7 Simple Medium Difficult
8+ Medium Difficult Difficult

far@ucalgary.ca 96
 Object Point /3
 Object point complexity levels for reports.

Number and source of data tables

Number of views Total <4 Total <8 Total 8+
contained <2 servers 2-3 servers >3 servers
<2 clients 3-5 clients >5 clients
0-1 Simple Simple Medium
2-3 Simple Medium Difficult
4+ Medium Difficult Difficult

far@ucalgary.ca 97
 Object Point /3
 The number in each cell is then weighted and summed to get
the object point.
 The weights represent the relative effort required to
implement an instance of that complexity level.
 Complexity level for object point:
Object Type Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL component - - 10

New object points = (object points) × (100 – r) / 100

Assuming that % r of the objects will be reused from
previous projects.

far@ucalgary.ca 98
 How to Calculate OP?
1. Estimate the number of “screens” of the system and the approximate
number of data entries for each screen (called view).
2. Estimate the number of “reports” that will be generated by the system
(including any output file, writing to database, etc.) and the approximate
number of data entries for each report (called view).
3. For each “screen” and “report” and their corresponding views, use
Tables (previous pages) to determine whether that screen or report is
“simple”, “medium” or “difficult”.
4. Weight the screens and reports using the weight table and sum them up
to get the OP number.
5. If you have any acquired component, give it the weight of 10 and add it
to the OP.
6. If you have any part of your system reused from a previous generation,
define a percentage of reuse and then adjust the value of OP accordingly.

far@ucalgary.ca 99
Effort Estimation with OP
 Formula:
Effort [Person-Month] = OP / PROD
 How to measure PROD?
Developer Very Low Low Average High Very High
Experience/Skills
(Nominal)
PROD 4 7 13 25 50

 Example:
Effort [Person-Month] = 13 / 13 = 1
Assuming average experience and 0% reuse.
 Example: OP
 Suppose that you have
 4 screens, 2 of them simple (weight 1) and 2 of them medium
(weight 2)
 3 reports, 2 of them simple (weight 2) and 1 medium (weight 5),
then the total number of OP is:
OP = 2×1 + 1×2 + 2×2 + 1×5 = 13
 If you have any acquired component, give it the weight 10
and add it to the OP.
 If you have any part of your system reused from a previous
generation, define a percentage of reuse (say 10%) and then
adjust the value of OP accordingly.
OPnew = 13 × (100-10)/100 = 11.7

far@ucalgary.ca 101
 Example 2
 Determine object points for a smart vending machine
assuming that the system is average size (total number of
clients-servers is less than 8) using the following data:
Screens Views (Data Items)
User Screens
S1. Buying Screen Amount of coins to insert,
selection
Administrator Screens
S2. Inventory Update Inventory input update (20 data
items)
S3. Change Update Change infrared input update (4
data items)

far@ucalgary.ca 102
Example 2 (cont’d)
Reports Views (Data Items)
User Reports
R1. Display money entered Amount of money entered
R2. Not enough money entered Insufficient funds
R3. Returning change Amount of change
R4. Out of stack message Out of stock
R5. No change message No change
R6. Selection Approved Release selection signal
Administrator Reports
R7. Machine Report Inventory (20 data items),
change information (4 data
items)

far@ucalgary.ca 103
Example 2 (cont’d)

Simple Medium Difficult

S1 S3 S2
R1 R2 R3 R4 R5 R6 None R7

OP = (1×1) + (1×2) + (1×3) + (2×6) + (5×0) + (8×1)

OP = 26

Effort = 26/13 = 2 person month

far@ucalgary.ca 104
Use-Case Point
 Use-Case Point /1
 Function Point is a method to <<uses>>
Library
measure software size from a
requirements perspective. Student

 Use-Case is a method to develop

requirements. Use Cases are used
to validate a proposed design and to
ensure it meets all requirements.

Question: How to use Use-Cases to

measure function point and vice-versa?

far@ucalgary.ca 106
 Use-Case Point /2
Question: How to use Use-Cases to
measure function point and vice-versa?

Two methods:
1. Identify and weight actors and use-cases
2. Count the inputs, outputs, files and data inquiries
from use-cases (using the use-case definition and
activity diagram).

far@ucalgary.ca 107
Use Case Point /3
 Use Case Point Estimation has its origin in the
work by Gustav Karner (1993)
 Process:
1. Identify and weight Actors ( UAW)
2. Identify and weight Use Cases ( UUCW)
3. Calculate Unadjusted Use Case Points ( UUCP =
UAW + UUCW)
4. Calculate Value Adjustment Factor ( VAF)
5. Calculate (Adjusted) Use Case Points
 UCP = UUCP * VAF
 Use Case Point: Actors
 For each Actor, determine whether the actor is
simple, average or complex.
 A simple actor represents another system with a
defined Application Programming Interface (API).
Use Case [weight: 1]
Actor
 An average actor is either another system that
interacts through a protocol (HTTP, FTP, user-
defined, etc.), a data store (files, DBs, etc.) or a
person interacting through a text-based interface.
[weight: 2]
 A complex actor is a person interacting through a
graphical user interface (GUI).
[weight: 3]
 Use Case Point: Use Cases
 For each Use Case, determine whether it is
simple, average or complex.
 A simple use case contains up to 3 transactions.
[weight: 5]
 An average use case contains 4-7 transactions.
Use Case
Actor [weight: 10]
 A complex use case contains more than 7
transactions. [weight: 15]
 Note: The original Use Case Point method
suggested to count only transactions of the main
(success) scenarios. Some researchers propose
to include in the counting also alternate
(extensions) and exception (error) transaction
sequences.
Example: ATM
 Actors:
 Visa Cardholder:
complex (interacts via
GUI)
 Visa AS:
average (interacts via
communication
protocol)

far@ucalgary.ca 111
Example: ATM
 Use Case:
 “Withdraw money
using a Visa card”
complex (more than 7
transactions, even
without counting
extensions or
exceptions)

 UAW = 3 + 2 = 5
 UUCW = 15

far@ucalgary.ca 112
 Use-Case Point /2
 We must count the inputs, outputs, files and data
inquiries from use-cases.
 Function points become evident using the use-case
definition and activity diagram for the use-case.
Each step within the activity diagram can be a
transaction (inputs, outputs, files and data inquiries).

<<uses>>
Library

Student

far@ucalgary.ca 113
 Examining Use Case Scenario
 Use Case might be further refined via
Activity and Interaction Diagrams
 Examining Use Case definition and Activity
and/or Interaction diagrams can also lead to
FP count.
 How?

SENG421 (Winter 2006) far@ucalgary.ca 114

Use-Case Definition
 A typical use-case definition document
consists of:
 Use Case name
Use Case
Actor
 Actor name

Use-Case Definition
 Objective
 Preconditions
 Results (Post-conditions)
 Detailed description (actions & responses)
 Exceptions and alternative courses

far@ucalgary.ca 115
Use-Case Definition Worksheet

far@ucalgary.ca 116
 Example: Activity Diagram
[ delete course ] Activity
Delete Course
Decision
[ add course ]
Select
Course

Synchronization Bar (Fork) Concurrent threads

Check Check
Schedule Pre-requisites
Transition

Guard Condition Synchronization Bar (Join)

(Concurrent thread)
[ checks completed ] [ checks failed ]

Assign to Resolve
course conflicts

[ student added to the course ]

Update
schedule

far@ucalgary.ca 117
 Example 1: Use-Case Scenario
But these are not independent from the “Find”
Use-Case: Library input, so they are actually data attributes for
“Find”
Scenario:
1. The user may enter a book’s ISBN number, student ID, or student
name (input × 3)
2. The user will press “Find” (input × 1)
3. If the user enters a book ISBN number (input × 1)
• The system will display information related to that book and write the
results to a file (output × 1) (internal file × 1)
4. If the user entered a student name or student ID (input × 2)
• The system will return a list of all books on the waiting list for that student
and write the results to a file (output × 1) (internal file × 1)
• The user can select one book from the list (external inquiry × 1)
• The system will search the database by ISBN number (external file × 1)
• The system will display information related to that book and available date
and will write the results to a file (output × 1) (internal file × 1)
Together they will
qualify as 1 output
far@ucalgary.ca 118
 Example 2
 Dr. X, a recent graduate from a medical university, is
starting her medical practice in a small town. She is
planning to hire a receptionist. She approaches software
company Y to build a software system to manage the
patients’ appointments. The following is her problem
description (next two slides).
 Suppose that you are the analyst in charge of estimating
the cost of this system and you base your estimation of the
function point (FP) count for this system.
 Calculate the unadjusted function point count (UFC) for
the system assuming the average weight for all entries.

far@ucalgary.ca 119
 Example 2 (cont’d)
 When a patient calls for an appointment, the receptionist will
ask the patient’s name or patient’s ID number and will
check the calendar and will try to schedule the patient as
early as possible to fill in vacancies. If the patient is happy
with the proposed appointment, the receptionist will enter
the appointment with the patient name and purpose of
appointment. The system will verify the patient name and
supply supporting details from the patient records,
including the patient’s ID number. After each appointment
the Dr. X will mark the appointment as completed, add
comments, and then schedule the patient for the next visit if
appropriate.
input
output
query
far@ucalgary.ca 120
 Example 2 (cont’d)
 The system will answer queries by patient name, by patient
ID and by date. Supporting details from the patient’s
records are displayed along with the appointment
information. The receptionist can cancel appointments. The
receptionist can print out a notification list for making
reminder calls 2 days before appointments. The system
includes the patient’s phone numbers from the patient
records. The receptionist can also print out daily and
weekly work schedules with all the patients.

Note that we have to again ask ourselves whether

these qualify for EI, EO, EQ, EIF and ILF.

far@ucalgary.ca 121
 Note that we have to again ask ourselves whether
these qualify for EI, EO, EQ, EIF and ILF.

Example 2 (cont’d)
Type Description No. Weight Weighted value
Patient name, Patient ID number,
Inputs (EI) Appointment completed, Appointment 5 4 20
purpose, Cancel appointment
Comments, Calendar, Supporting details,
Outputs (EO) Appointment Information, Notification 7 5 35
List, Daily schedule, Weekly schedule,
Check calendar, Query by name, Query
Queries (EQ) by ID, Query by date, Verify patient, 6 4 24
Available Appointment
Internal files
Patients’ data record 1 10 10
(ILF)
External files
-- 0 7 0
(EIF)
Total UFC 89

far@ucalgary.ca 122
Recent Approaches
 Recent approaches to size measurement and
estimation include:
 Decomposition
 Expert opinion
 Analogy
 Class-code expansion

far@ucalgary.ca 123
 1. Decomposition
 In many cases, the measurement or estimation problem is too
complex to be considered in one piece.
 As a result, the measurement or estimation problem is
decomposed or partitioned into smaller, more manageable
problems.
 By decomposing the problem, measurement or estimation
can by performed in a stepwise fashion.

(Remember the GQM technique)

far@ucalgary.ca 124
 2. Expert Opinion /1
 Expert opinion refers to predictions made by experts
based on past experience.
 The technique is based on combination of individual
predictions.
 The result is a group estimate arrived at by
consensus. The group estimate is typically a better
overall estimate than any individual prediction.
 In general, the expert opinion approach to
estimation can result in very accurate estimates,
however it is entirely dependent on the experience
of the expert.

far@ucalgary.ca 125
 2. Expert Opinion /2
 Example: Wideband Delphi Technique
 A group of experts is each given the program’s specifications and an
estimation form.
 They meet to discuss the product and any estimation issues.
 They then each anonymously complete the estimation forms
 The estimates are given to the estimate coordinator, who tabulates the
results and returns them to the experts.
 Only each expert’s personal estimate is identified; all others are
anonymous.
 The experts meet to discuss the results, revising their estimates as
appropriate.
 The cycle continues until the estimates converge to an acceptable
range.

far@ucalgary.ca 126
 3. Analogy
 Analogy is a more formal approach to expert opinion also
referred to as the Fuzzy-Logic Method or Case-based
Method.
 Estimators compare the proposed project with one or more
past project cases. Differences and similarities are identified
and used to adjust the estimate.
 The estimator will typically identify the type of application,
establish an initial prediction, and then refine the prediction
within the original range.
 The accuracy of the analogy approach is dependent on the
availability of a case-base of project information.

far@ucalgary.ca 127
 4. Class–Code Expansion
 In the design phase, boundary
classes are usually expanded by Analysis Classes
Description
the ratio of 1 to 2 and control
Boundary class
classes are expanded by the ratio
of 2 to 3, respectively. The entity
classes are usually expanded to a Control class
subsystem having 4 to 8 design
classes. Entity class
 An average design class in Java
has 20 methods, each method
having 10 to 20 lines of code.

far@ucalgary.ca 128
Example
 Using class-code expansion
Model Description
Boundary
: Main

class
: MaintainProjectData

: ProjectPrompt Control class

: User : ProjectData
: MetricsDatabase

Entity class
: ProjectMetrics : MaintainProjectMetrics

: EnterQuery : RunQuery

: QueryResults

far@ucalgary.ca 129
 Example (cont’d)
 Calculate total software size in LOC, assuming total
size is 1.5 × methods LOC
 Calculate total development cost.
Analysis classes No. Total Total Total LOC
classes Operations
Boundary class 6 Min 16 Min 320 1.5 × 320 × 10 = 4,800
(minimum)
min (× 1) 6
Max 29 Max 580
max (× 2) 12
1.5 × 320 × 20 = 9,600
Control class 3
min (× 2) 6 1.5 × 580 × 10 = 8,700
max (× 3) 9
1.5 × 580 × 20 = 17,400
Entity class 1 (maximum)
min (× 4) 4
max (× 8) 8

far@ucalgary.ca 130
Measuring
Software Reuse
 Software Size: Reuse /1
 Reuse measures how much of a product was copied or
modified.
 Measurement of size must also include some method of
counting reused products.
 It is difficult to define formally what is meant by reused
code. Whole programs can be reused without modification,
but it is more common to reuse some part of code (a module,
function, or procedure).
 The extent of reuse is defined as follows (Software
Productivity Consortium, 1995):
 Reused verbatim: code in the unit was used without any changes
 Slightly modified: fewer than 25% of lines of code in the unit were
modified
 Extensively modified: 25% or more of lines of code were modified
 New: none of the code comes from a previously constructed unit

far@ucalgary.ca 132
 Software Size: Reuse /2
 Reuse needs a repository of
reusable components repository

 Reuse metrics
 Reuse Level: percentage of
source source source
different items coming from a
given source in a repository.
 Reuse Frequency: percentage of
item item item
references to items from a given
source in a repository.
 Reuse Density: normalized
number of items from a given
source in a repository.

far@ucalgary.ca 133
 Software Size: Comparison

Criteria LOC Halstead’s FP OP

Applicable to early stages
No
(requirement phase) of No Yes Yes
(may be)
software development?
Subjective measure? No No Yes Yes
Derivable from system
No No Yes Yes
requirements?
Language dependable? Yes Yes No No
Has clear and understandable
Yes No No No
physical meaning?

far@ucalgary.ca 135
 Software Size Metrics: Summary
Requirement
Length Design
LOC
Code
Halstead’s
Function point
Software Feature point
Functionality
size
Use-case point
Object point
Complexity Cyclomatic complexity
Reuse level
Reuse Reuse frequency
Reuse density
far@ucalgary.ca 136
References
 [Alb79] A.J. Albrecht: Measuring application Development Productivity, Proc.
IBM Application Development Joint SHARE/GUIDE Symposium, pp. 83-92,
1979.
 [AlG83] A.J. Albrecht, and J.E. Gaffney: Software Function, Source Lines of
Code and Development Effort Prediction: A Software Science Validation, IEEE
Trans. Software Engineering, 9(6):639-648, 1983.
 [Hal77] M. H. Halstead: Elements of Software Science, Operating, and
Programming Systems Series Volume 7. New York, NY: Elsevier, 1977.
 [Jon96] C. Jones: Applied Software Measurement, McGraw-Hill, 1996.
 [Longstreet] Function Points Analysis Training Manual (110 Pages) (by David
Longstreet, www.SoftwareMetrics.com).
 [Par92] R. E. Park: Software Size Measurement: A Framework for Counting
Source Statements, Technical Report, CMU/SEI-92-TR-020, 1992. (available at
URL: http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr20.92.pdf)
far@ucalgary.ca 138
SENG 421:
Software Metrics
Measuring Internal Product Attributes:
Structural Complexity
(Chapter 6)
Department of Electrical & Computer Engineering, University of Calgary

B.H. Far （far@ucalgary.ca）

http://www.enel.ucalgary.ca/People/far/Lectures/SENG421/06/
Problem Statement
 How complex is the following program?
1: read x,y,z;
2: type = “scalene”;
3: if (x == y or x == z or y == z) type =“isosceles”;
4: if (x == y and x == z) type =“equilateral”;
5: if (x >= y+z or y >= x+z or z >= x+y) type =“not a triangle”;
6: if (x <= 0 or y <= 0 or z <= 0) type =“bad inputs”;
7: print type;

 Is there a way to measure it?

It has something to do with
program structure (branches,
nesting) & flow of data
far@ucalgary.ca 2
Contents
 Software structural measurement
 Control-flow structure
 Structural complexity: cyclomatic complexity
 Data flow and data structure attributes
 Architectural measurement

far@ucalgary.ca 3
 Software Complexity Metrics
Depth of nesting
Code
Cyclomatic complexity

Morphological measures
Complexity
Metrics Cohesion
Architecture

Coupling

Information flow complexity

Data structure complexity

far@ucalgary.ca 4
 How to Represent Program
Structure?
Software structure can have 3 attributes:
 Control-flow structure: Sequence of
execution of instructions of the program.
 Data flow: Keeping track of data as it is
created or handled by the program.
 Data structure: The organization of data
itself independent of the program.

far@ucalgary.ca 5
Goal & Questions …
 Q1: How to represent “structure” of a
program?
 A1: Control-flow diagram

 Q2: How to define “complexity” in terms of

the structure?
 A2: Cyclomatic complexity; depth of nesting

far@ucalgary.ca 6
Basic Control Structure /1
 Basic Control Structures (BCSs) are set of
essential control-flow mechanisms used for
building the logical structure of the program.
 BCS types:
 Sequence: e.g., a list of instructions with no
other BCSs involved.
 Selection: e.g., if … then … else.
 Iteration: e.g., do … while ; for … to … do.

far@ucalgary.ca 7
Basic Control Structure /2
 There are other types of BCSs, (may be
called advanced BCSs), such as:
 Procedure/function/agent call
 Recursion (self-call)
 Interrupt
 Concurrence

far@ucalgary.ca 8
 Control Flow Graph (CFG) /1
 Control flow structure is usually modeled by a directed
graph (di-graph)
CFG = {N, A}
 Each node n in the set of nodes (N) corresponds to a
program statement.
 Each directed arc (or directed edge) a in the set of arcs (A)
indicates flow of control from one statement of program to
another.
 Procedure nodes: nodes with out-degree 1.
 Predicate nodes: nodes with out-degree other than 1 and 0.
 Start node: nodes with in-degree 0.
 Terminal (end) nodes: nodes with out-degree 0.

far@ucalgary.ca 9
Control Flow Graph (CFG) /2
Definition [FeR97]:
 A flowgraph is a directed graph
in which two nodes, the start
node and the stop node, obey
special properties: the stop node
has out-degree zero, and the start
node has in-degree zero. Every
node lies on some path from the
start node to the stop node.
CFG Example 1
start

S=0
i=1 T F

i < (n+1)
Yes No

S = S + ai

Print S
i=i+1
end

far@ucalgary.ca 11
 CFG Example 2
a
if a then 1 2
if b then X b c
Y 3
while e do U 10
X 4
else V
5 12
if c then Y 13 11
repeat V until d 6
endif d
U 7 e
endif 14
8 9
 Control Flow Graph /2
 The control flow graph CFG = {N, A} model for a
program does not explicitly indicate how the control
is transferred. The finite-state machine (FSM)
model for CFG does.
=
M { N , Σ, δ , n0 , F }
N set of nodes; Σ set of input symbols (arcs)
δ transition function
( p, a ) q ; p, q ∈ N and a ∈ Σ
δ=
n0 ∈ N starting node and F ⊆ N set of terminal node(s)

far@ucalgary.ca 13
Example: FSM Model
 Finite state machine model for the increment
and add example

start check increment add print end

far@ucalgary.ca 14
Control Flow Graph /3
Sequence
Selection
Iteration
Procedure/
function call
Recursion
Interrupt Concurrence

far@ucalgary.ca 15
Common CFG Program Models

far@ucalgary.ca 16
Prime Flow Graphs
 Prime flow graphs are flow graphs that cannot be
decomposed non-trivially by sequencing and nesting.
 Examples (according to [FeP97]):
 Pn (sequence of n statements)

 D0 (if-condition)

 D1 (if-then-else-branching)

 D2 (while-loop)

 D3 (repeat-loop)

 Cn (case)
 Sequencing & Nesting /1
 Let F1 and F2 be two flowgraphs. Then, the
sequence of F1 and F2, (shown by F1; F2) is a
flowgraph formed by merging the terminal node of
F1 with the start node of F2.

far@ucalgary.ca 18
 Sequencing & Nesting /2
 Let F1 and F2 be two flowgraphs. Then, the nesting
of F2 onto F1 at x, shown by F1(F2) is a flowgraph
formed from F1 by replacing the arc from x with the
whole of F2.

far@ucalgary.ca 19
S-structured Graph
 A family S of prime flowgraphs is called S-
structured graph (or S-graph) if it
satisfies the following recursive rules:
1) Each member of S is S-structured.
2) If F and G are S-structured flowgraphs, so is
the sequences F;G and nesting of F(G).
3) No flowgraph is S-structured unless it can be
generated by finite number of application of the
above (step 2) rules.

far@ucalgary.ca 20
 S-Structured Graph – Example
 SD = {P1, D0, D2}
 The class of SD-graphs is the class of flow graphs that is
called D-structured (or simply: structured) in the Structured
Programming literature
 Böhm and Jacopini (1966) have shown that every algorithm
can be encoded as an SD-graph (i.e., as a sequence or nesting
of statements, if-conditions and while-loops)
 Although SD is sufficient in this respect, normally if-then-
else structures (D1) and repeat-loops (D3) are included in SD.
 Prime Decomposition
 Any flow graph can be uniquely decomposed into a hierarchy
of sequencing and nesting primes, called “decomposition
tree”. (Fenton and Whitty, 1991)
Hierarchical Measures
 The decomposition tree is
enough to measure a
number of program
characteristics, including:
 Nesting factor (depth of
nesting)
 Structural complexity
 etc.

far@ucalgary.ca 23
Depth of Nesting /1
 Depth of nesting n(F) for a flowgraph F can
be expressed in terms of:
 Primes:
n(P1) = 0 ; n(P2) = n(P3) = … = n(Pk) =1
n(D0) = n(D1) = n(D2) = n(D3) = 1
 Sequences:
n(F1;F2;…;Fk) = max(n(F1), n(F2), …, n(Fk))
 Nesting:
n(F(F1,F2,…,Fk)) = 1+ max(n(F1), n(F2), …, n(Fk))

far@ucalgary.ca 24
 Depth of Nesting /2
Example:
F= D1((D0;P1;D2), D0(D3))

x2
n(F) = 1 + max(x1, x2)
x1= max(1,0,1) x1

x2= 1 + max(1) = 2
n(F)= 1+ max(1,2) Smaller depth of nesting
n(F)= 3 indicates less complexity in
coding and testing

far@ucalgary.ca 25
Cyclomatic Complexity
Cyclomatic Complexity
 A program’s complexity can be measured by
the cyclomatic number of the program
flowgraph.
 The cyclomatic number can be calculated in
2 different ways:
 Flowgraph-based
 Code-based

far@ucalgary.ca 27
 Cyclomatic Complexity /1
 For a program with the program flowgraph G, the
cyclomatic complexity v(G) is measured as:
v(G) = e - n + 2p
 e : number of edges
 Representing branches and cycles
 n : number of nodes
 Representing block of sequential code
 p : number of connected components
 For a single component, p=1

far@ucalgary.ca 28
 Cyclomatic Complexity /2
 For a program with the program flowgraph G, the
cyclomatic complexity v(G) is measured as:
v(G) = 1 + d
 d : number of predicate nodes (i.e., nodes with out-degree
other than 1)
 d represents number of loops in the graph

 or number of decision points in the program

i.e., The complexity of primes depends only on

the predicates (decision points or BCSs) in
them.

far@ucalgary.ca 29
 Cyclomatic Complexity: Example
v(G) = e - n + 2p
v(G) = 7 - 6 + 2 × 1
v(G) = 3 Predicate
nodes
(decision
Or points)

v(G) = 1 + d
v(G) = 1 + 2 = 3

far@ucalgary.ca 30
Example: Code Based
#include <stdio.h>
main()
{
int a ;
scanf (“%d”, &a);
if ( a >= 10 )
if ( a < 20 ) printf ("10 < a< 20 %d\n" , a);
else printf ("a >= 20 %d\n" , a);
else printf ("a <= 10 %d\n" , a);
}

v(G) = 1+2 = 3

far@ucalgary.ca 31
Example: Graph Based

v(G) = 16 – 13 + 2 = 5

or

v(G) = 4 +1 = 5

far@ucalgary.ca 32
 01. import java.util.*;
02. public class CalendarTest

Example 1
03. {
04. public static void main(String[] args)
05. {
06. // construct d as current date
07. GregorianCalendar d = new GregorianCalendar();
08. int today = d.get(Calendar.DAY_OF_MONTH);
09. int month = d.get(Calendar.MONTH);

 Determine 10. // set d to start date of the month

11. d.set(Calendar.DAY_OF_MONTH, 1);
12. int weekday = d.get(Calendar.DAY_OF_WEEK);
13. // print heading
cyclomatic 14. System.out.println("Sun Mon Tue Wed Thu Fri Sat");
15. // indent first line of calendar
16. for (int i = Calendar.SUNDAY; i < weekday; i++ )

complexity for 17. System.out.print(" ");

18. do
19. {
20. // print day
the following 21. int day = d.get(Calendar.DAY_OF_MONTH);
22. if (day < 10) System.out.print(" ");
23. System.out.print(day);

Java program: 24. // mark current day with *

25. if (day == today)
26. System.out.print("* ");
27. else
28. System.out.print(" ");
29. // start a new line after every Saturday
30. if (weekday == Calendar.SATURDAY)
31. System.out.println();
v = 1+d 32. // advance d to the next day
33. d.add(Calendar.DAY_OF_MONTH, 1);
34. weekday = d.get(Calendar.DAY_OF_WEEK);
35. }
v = 1+6 = 7 36. while (d.get(Calendar.MONTH) == month);
37. // the loop exits when d is day 1 of the next month
38. // print final end of line if necessary
39. if (weekday != Calendar.SUNDAY)
40. System.out.println();
41. }
42. }

SENG421 (Winter 2006) far@ucalgary.ca 33

 Example 2
 Determine
cyclomatic
complexity for the
following flow
diagram:
v = 1+d v = 1+2 = 3
or
v=e–n+2
v = 11 – 10 + 2 = 3

SENG421 (Winter 2006) far@ucalgary.ca 34

 Example 3A
 Two functionally
equivalent programs that
are coded differently
 Calculate cyclomatic
complexity for both
VA = 7
VB = 1
There is always a trade-off between
control-flow and data structure.
Programs with higher cyclomatic
complexity usually have less complex
data structure. Apparently program B
requires more effort that program A.

SENG421 (Winter 2006) far@ucalgary.ca 35

 Cyclomatic Complexity: Critics
 Advantages:
 Objective measurement of complexity
 Disadvantages:
 Can only be used at the component level
 Two programs having the same cyclomatic complexity
number may need different programming effort
 Same requirements can be programmed in various ways
with different cyclomatic complexities
 Requires complete design or code visibility

far@ucalgary.ca 38
 Software Architecture /1
 A software system can be
represented by a graph,
S = {N, R}
 Each node n in the set of nodes
(N) corresponds to a subsystem.
 Each edge r in the set of
relations (R) indicates a relation
(e.g., function call, etc.)
between two subsystems.

far@ucalgary.ca 39
Morphology
 Morphology refers to the overall shape of the
software system architecture.
 It is characterized by:
 Size: number of nodes and edges
 Depth: longest path from the root to a leaf node
 Width: number of nodes at any level
 Edge-to-node ratio: connectivity density
measure

far@ucalgary.ca 40
 Morphology: Example
Size:
12 nodes
15 edges

Depth: 3

Width: 6

e/n = 1.25

far@ucalgary.ca 41
 Tree Impurity /1
 The tree impurity measures m(G) how much the
graph is different from a tree
 The smaller m(G) denotes the better design

far@ucalgary.ca 42
Tree Impurity /2
 Tree impurity can be defined as:
number of edges more than spanning tree
m (G ) =
maximum number of edges more than spanning tree
2 ( e − n + 1)
m (G ) =
( n − 1)( n − 2 )
 Example:
m(G1) = 0 m(G2) = 0.1 m(G3) = 0.2
m(G4) = 1 m(G5) = 1 m(G6) = 1

far@ucalgary.ca 43
Complexity Measures:
Cohesion
Components & Modules
 A module or component is a bounded
sequence of program statements with an
aggregate identifier.
 A module usually has two properties:
 Nearly-decomposability property: the ratio of
data communication within the module is much
(at least 10 times) more than the communication
with the outside.
 Compilablity property: a module should be
separately compilable (at least theoretically).

far@ucalgary.ca 46
 Software Architecture
 A modular or C1
component-based
system is a system that
all the elements are
partitioned into different
components.
 Components do not share
any element. There are C2
only relationships across
the components. C3

far@ucalgary.ca 47
Component Based System (CBS)
 A component-based system (CBS) can be
defined by a graph, S = {C, Re}
 Each node c in the set of nodes (C)
corresponds to a component.
 Each edge r in the set of relations (Re)
indicates an external relationship between
two components.

far@ucalgary.ca 48
 CBS: Code Complexity
 Code complexity of a C1
component-based system
is the sum of cyclomatic
complexity of its
components
 Example:
 v(C1) = v(C3) = 2 C2
 v(C2) = 1
 v(G) = 2+2+1 = 5 C3

far@ucalgary.ca 49
Concept: Cohesion
 Cohesion describes how strongly related the
responsibilities between design elements can
be described
 The goal is to achieve “high cohesion”
 High cohesion between classes is when class
responsibilities are highly related

far@ucalgary.ca 50
 Cohesion /1
 Cohesion of a module is the extent to which its
individual components are needed to perform some
task.
 Types of cohesion (7 types):
 Functional: The module performs a single function
 Sequential: The module performs a sequence of
functions
 Communicative: The module performs multiple function
on the same body of data

far@ucalgary.ca 51
Cohesion /2
 Types of cohesion (cont’d):
 Procedural: The module performs more than one
function related to a certain software procedure
 Temporal: The module performs more than one function
and they must occur within the same time span
 Logical: The module performs more than one function
and they are related logically
 Coincidental: The module performs more than one
function and they are unrelated

far@ucalgary.ca 52
Examples: Cohesion
PackageA
Course
Class A1 0..*
0..* Schedule CourseOffering
0..4

1 // Create schedule
Student
// Open course
// Close course
// Delete schedule

High package cohesion Low class cohesion

(functional cohesion) (coincidental and
logical cohesion)

far@ucalgary.ca 53
CBS: Cohesion
 Cohesion of a module is the extent to which
its individual components are needed to
perform some task.
 Cohesion for a component is defined in terms
of the ratio of internal relationships to the
total number of relationships.
Rinternal
CH ( Ci ) =
Rinternal + Rexternal

far@ucalgary.ca 54
 CBS: System Cohesion
 System cohesion is the mathematical mean of
cohesion of all its components.
n
1
CH
n
∑ CH ( C )
i =1
i 0 ≤ CH ≤ %100

 The higher system cohesion is better because it

indicates that more job is processed internally.

far@ucalgary.ca 55
 Example: Cohesion
 Cohesion for a component is C1
defined in terms of the ratio of
internal relationships to the
total number of relationships.
Rinternal
CH ( Ci ) =
Rinternal + Rexternal

 Example: C2
 CH(C1) = 2/3
 CH(C2) = 1/3 C3
 CH(C3) = 2/3

far@ucalgary.ca 56
 Example: System Cohesion
 System cohesion is the mathematical mean of
cohesion of all its components.
n
1
CH
n
∑ CH ( C )
i =1
i 0 ≤ CH ≤ %100

 Example:
 CH = ((2/3)+(1/3)+(2/3))/3 = 5/9 = %55

far@ucalgary.ca 57
Complexity Measures:
Coupling
Concept: Coupling
 Coupling describes how strongly one element
relates to another element
 The goal is to achieve “loose coupling”
 Loose coupling between classes is small,
direct, visible, and has flexible relations with
other classes

far@ucalgary.ca 59
 Coupling: Package Dependencies

Packages should not be A B


cross-coupled
Packages in lower
X
layers should not be A
dependent upon Upper
packages in upper Layer
layers

In general, X X
Lower
dependencies should Layer
B

not skip layers (unless

specified by the
architecture)
C

X = Coupling violation
far@ucalgary.ca 60
Coupling: Class Relationships
 Strive for the loosest coupling possible
PackageA PackageA

Class A1 Class A1

- Class A4 Class A2 - Class A4 Class A2

Class A3 Class A3

PackageB PackageB

+ Class B3 + Class B3

- Class B2 - Class B2
+ Class B1 + Class B1

- Class B4 - Class B4

Strong Coupling Loose Coupling

far@ucalgary.ca 61
 Coupling /1
 Coupling is the degree of interdependence among
modules
 Various types of coupling (5 types):
 R0: independence: modules have no communication
 R1: data coupling: modules communicate by parameters
 R2: stamp coupling: modules accept the same record type
 R3: control coupling: x passes the parameters to y and the
parameter passed is a flag to control the behaviour of y.
 R4: content coupling: x refers to inside of y; branches into
or changes data in y.

far@ucalgary.ca 62
Coupling /2
 No coupling: R0
 Loose coupling: R1 and R2
 Tight coupling: R3 and R4

 There is no standard measurement for

coupling!

far@ucalgary.ca 63
CBS: Coupling
 Coupling of a component is the ratio of the
number of external relations to the total
number of relations.
R external
CP ( Ci ) =
Rinternal + Rexternal

far@ucalgary.ca 64
CBS: System Coupling
 System coupling is the mathematical mean
of coupling of all its components.
n
1
CP
n
∑ CP ( C )
i =1
i 0 ≤ CP ≤ %100

 The lower system coupling is better because

it indicates that less effort is needed
externally.

far@ucalgary.ca 65
 Coupling in CBS: Example
 Coupling of a C1
component

R external
CP ( Ci ) =
Rinternal + Rexternal

 Example:
 CP(C1) = 1/3 C2
 CP(C2) = 2/3
 CP(C3) = 1/3 C3

far@ucalgary.ca 66
CBS: System Coupling
 System coupling is the mathematical mean
of coupling of all its components.
n
1
CP
n
∑ CP ( C )
i =1
i 0 ≤ CP ≤ %100

 Example:
 CP = ((1/3)+(2/3)+(1/3))/3 = 4/9 = %45

far@ucalgary.ca 67
 Coupling: Representation /1
 Graph representation of coupling
 Coupling between Number of
modules x and y: interconnections
Coupling type
n
c ( x, y ) = i +
R1 ~ R4

n +1
 i: degree of worst
coupling relation
 n: number of
interconnections

far@ucalgary.ca 68
 Coupling: Representation /2
 Global coupling of a system consists of modules is the
median value of the set of all couplings c(x,y)
C ( S ) Med {c ( x, y ) | ∀x, y ∈ S }
=
 Statistical review:
 Median value: The median value is a measure of central tendency.
The median value is the middle value in a set of values. Half of all
values are smaller than the median value and half are larger. When
the data set contains an odd (uneven) set of numbers, the middle
value is the median value. When the data set contains an even set of
numbers, the middle two numbers are added and the sum is divided
by two. That number is the median value.

far@ucalgary.ca 69
 Example
 The structural modules of a software system and
their interconnections are depicted below. The
arrows depict the coupling between modules.

far@ucalgary.ca 70
Example (cont’d)
a) Determine the coupling between modules.
b) Determine the global system coupling.
CCH = 1 + 1/2 = 1.50
CAE = CBF = 1 + 2/3 = 1.66
CAD = 2 + 1/2 = 2.50
CAB = CCD = CCG = CDJ = 2 + 2/3 = 2.66
CBH = CDI = CEL = 3 + 1/2 = 3.50
CEK = 3 + 3/4 = 3.75
CAC = 4 + 1/2 = 4.50
CBG = 4 + 2/3 = 4.66

1.50 1.66 1.66 2.50 2.66 2.66 (2.66 2.66) 3.50 3.50 3.50 3.75 4.50 4.66
C(S) = (2.66+2.66)/2 = 2.66

far@ucalgary.ca 71
Other Structural Metrics
 Information Flow Measures /1
 Information flow is measured in
terms of fan-in and fan-out of a
component.
 Fan-in of a module M is the
number of flows terminating at
M plus the number of data
structures from which info is
retrieved by M.
 Fan-out of a module M is the
number of flows starting at M
plus the number of data
structures updated by M.

far@ucalgary.ca 73
Information Flow Measures /2
 Information flow complexity (IFC) [Henry-
Kafura, 1981]:
IFC ( M ) =
length ( M ) × ( fan - in ( M ) × fan - out ( M ) )
2

 IFC [Shepperd, 1990]:

IFC ( M ) ( fan - in ( M ) × fan - out ( M ) )
2
=

far@ucalgary.ca 74
 Information Flow Measures /3
 Example

far@ucalgary.ca 75
 Information Flow Measures /4
 Revision of the Henry-Kafura IFC measure:
 Recursive module calls should be treated as normal calls.
 Any variable shared by two or more modules should be
treated as a global data structure.
 Compiler and library modules should be ignored.
 Indirect flow’s should be ignored.
 Duplicate flows should be ignored.
 Module length should be disregarded, as it is a separate
attribute.

far@ucalgary.ca 76
 Data Structure Measurement
 There is always a trade-off between control-flow and data
structure.
 Programs with higher cyclomatic complexity usually have
less complex data structure.
 A simple example for data-structure measurement:

Integers C1 = ni × 1
Strings C2 = ns × 2
Arrays C3 = na × 2 × size of array
Total C = C1 + C2 + C3

far@ucalgary.ca 77
 Example 3B
 Calculate date
structure complexity
for Program A and B
Program A Program B
Integers (ni) C1 = 1 × 1 C1 = 1 × 1
Strings (ns) C2 = 6 × 2 C2 = 6 × 2
Arrays (na) C3 = 0 × 2 × 0 C3 = 1 × 2 × 11
Total 13 35

There is always a trade-off between

control-flow and data structure.
Programs with higher cyclomatic
complexity usually have less complex
data structure. Apparently program B
requires more effort that program A.

SENG421 (Winter 2006) far@ucalgary.ca 78

 Conclusion: Complexity Metrics
Depth of nesting
Code
Cyclomatic complexity

Morphological measures
Complexity
Metrics Cohesion
Architecture

Coupling

Information flow complexity

Data structure complexity

far@ucalgary.ca 79