14/Mar/2020

CMU-CS 462:
Software Measurement Measuring Internal Product Attributes:
and Analysis Software Size

Spring 2019-2020
Nguyen Duc Man
E: mannd@duytan.edu.vn
T: 0904235945

14/Mar/2020 1 14/Mar/2020 2

1 2

1
 14/Mar/2020

Contents Software Size Metrics:Summary

Requirement
1. Software size
Length Design
2. Size: Length (code, specification, LOC
Code
design) Halstead’s
Function point
3. Size: Reuse Software
Functionality Feature point
4. Size: Functionality (function size
Use-case point
point, feature point, object
Object point
point, use-case point)
Complexity Cyclomatic complexity
5. Size: Complexity
Reuse level

Reuse Reuse frequency

Reuse density
14/Mar/2020 3 14/Mar/2020 4

3 4

2

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.
14/Mar/2020 5 14/Mar/2020
5 6
14/Mar/2020
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.
6
3
 14/Mar/2020

Software Size: Length Length: Code – LOC /1

◼ 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.
◼ 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.

14/Mar/2020 7 14/Mar/2020 8

7 8

4
 14/Mar/2020

Length: Code – LOC /2 Length: Code – LOC /3

Variations of LOC: ◼ Measurement Unit: Lines of Source Code
◼ Count of physical lines including blank lines.
Statement Type Includes Excludes
◼ Count of all lines except blank lines and comments. Executable X
◼ Count of all statements except comments Non-executable
(statements taking more than one line count as only Declarations X
one line). Compiler Directives X

◼ Count of all lines except blank lines, comments, Comments X

declarations and headings. On their own lines X

◼ Count of only executable statements, not including On lines with source code X

exception conditions. Banners and nonblank spacers X

Blank (empty) comments X
Blank Lines X

14/Mar/2020 9 14/Mar/2020 10

9 10

5
 14/Mar/2020

Length: Code – LOC /4 Length: Halstead’s Work /1

◼ Advantages of LOC ◼ Maurice Halstead’s Theory (1971~1979):

◼ Simple and automatically measurable ◼ A program P is a collection of tokens, composed
◼ Correlates with programming effort (& cost) of two basic elements: operands and operators
◼ Operands are variables, constants, addresses
◼ Disadvantage of LOC
◼ Vague definition ◼ Operators are defined operations in a
programming language
◼ Language dependability if … else a, b, x
(language constructs) + - > = ; 100
◼ Not available for early planning main()
◼ Developers’ skill dependability goto
◼ Encouraging “sumo” development!

14/Mar/2020 11 14/Mar/2020 12

11 12

6
 14/Mar/2020

Length: Halstead’s Work /2 Length: Halstead’s Work /3

◼ Number of distinct operators in the program (μ1) ◼ Program length is the total number of occurrences of
operators and operands:
◼ Number of distinct operands in the program (μ2) N = N1 + N2
◼ Total number of occurrences of operators in the ◼ Program volume is the number of mental comparisons
program (N1) needed to write a program of length N
◼ Total number of occurrences of operands in the V = N log 2  = (N1 + N 2 ) log 2 (1 + 2 )
program (N2) ◼ Program level (L):
1 2 
L =V* V or L= =  2
◼ Program vocabulary (μ) D 1 N2
μ = μ1 + μ2 ◼ where V * is the minimum size potential volume (i.e.,
minimal size of implementation) and D is program difficulty

14/Mar/2020 13 14/Mar/2020 14

13 14

7
 14/Mar/2020

Length: Halstead’s Work /4 Length: Halstead’s Work /5

◼ Program length is the total number of occurrences ◼ Time required for developing program P is
of operators and operands: the total effort divided by the number of
N = N1 + N2 elementary discriminations per second
◼ Program estimated length (Nˆ)
T = E
Nˆ = 1 log2 1 + 2 log2 2
◼ Effort required to generate program P: number of ◼ In cognitive psychology β is usually a
elementary discriminations number between 5 and 20
V 1 N2 Halstead claims that β=18
E = V D = =  N log 2  ◼
L 2 2
14/Mar/2020 15 14/Mar/2020 16

15 16

8
 14/Mar/2020

Length: Halstead’s Work /6

◼ Remaining bugs: the number of bugs left in

the software at the delivery time
B=E
2/ 3

3000
◼ Conclusion: the bigger program needs more
time to be developed and more bugs
remained

14/Mar/2020 17 14/Mar/2020 18

17 18

9
 14/Mar/2020

Example 1 Example 1 (cont’d)

◼ For the following C program: ◼ Determine number of operators (μ1).

#include<stdio.h> ◼ Determine number of operands (μ2).
main()
{ ◼ Determine the program length in terms of
int a ; Operands the total number of occurrences of operators
scanf (“%d”, &a);
if ( a >= 10 ) (N1) and operands (N2): N = N1 + N2
if ( a < 20 ) printf ("10 < a< 20 %d\n" , a);
else printf ("a >= 20 %d\n" , a); ◼ Estimate program length
else printf ("a <= 10 %d\n" , a);
}

14/Mar/2020 19 14/Mar/2020 20

19 20

10
 14/Mar/2020

Example 1 (cont’d) Example 1 (cont’d)

Operators Number of Operators Number of
occurrences occurrences Operands Number of occurrences
# 1 <= 1
a 10
include 1 \n 3
10 3
stdio.h 1 printf 3
20 3
<…> 1 < 3
main 1 >= 2
(…) 7 if … else 2 μ2 = 3 N2 = 16
{…} 1 & 1 μ1 = 20 N1 = 47
int 1 , 4 Program length: N = N1 + N2 = 63
; 5 %d 4 Program Estimated length:
scanf 1 “…“ 4 Nˆ= 1 log2 1 + 2 log2 2 = 20 log2 20 + 3log2 3 = 91.1934
μ1 = 20 N1 = 47

14/Mar/2020 21 14/Mar/2020 22

21 22

11
 14/Mar/2020

Example 2 Example 2 (cont’d)

◼ For the following program calculate Halstead’s (c1)
number of operators; (c2) number of operands; (c3)
program vocabulary; (c4) occurrences of operators Operators Operands
in the program; (c5) occurrences of operands in the read 1 == 5 strings 5
program; (c6) program length; (c7) program , 2 or 6 x 9
volume; (c8) program estimated length. ; 7 and 1 y 8
1: read x,y,z; “ … ” 6 >= 3 z 8
2: type = “scalene”;
= 5 <= 3 0 3
3: if (x == y or x == z or y == z) type =“isosceles”;
4: if (x == y and x == z) type =“equilateral”; if 4 + 3 type 6
5: if (x >= y+z or y >= x+z or z >= x+y) type =“not a ( ) 4 print 1
triangle”;
6: if (x <= 0 or y <= 0 or z <= 0) type =“bad inputs”; μ1 = 14 μ2 = 6
7: print type;
N1 = 51 N2 = 39

14/Mar/2020 23 14/Mar/2020 24

23 24

12
 14/Mar/2020

Example 2 (cont’d) Example 2 (cont’d)

(c1) Number of distinct operators in the program: μ1 = 14 (c6) Program length: N = N1 + N2 = 90
(c2) Number of distinct operands in the program: μ2 = 6 (c7) Program volume: V = N log2 μ = 90 log2 (20) = 388.9735
(c3) Program vocabulary: μ = μ1 + μ2 = 20 (c8) Program estimated length:
(c4) Total number of occurrences of operators in the program: Nˆ= 1 log2 1 + 2 log2 2 = 14 log2 14 + 6 log2 6 = 68.81274
N1 = 51
(c5) Total number of occurrences of operands in the program:
N2 = 39

14/Mar/2020 25 14/Mar/2020 26

25 26

13
 14/Mar/2020

Length: Halstead’s Work /7

Critics of Halstead’s work

◼ Developed in the context of assembly languages and
Work in group 4 : Discuss and answer the following question.
too fine grained for modern programming
(Làm việc nhóm 4 sinh viên, thảo luận và trả lời câu hỏi sau)
languages.
◼ The treatment of basic and derived measures is Is Lines of Code is a Bad Metric or a Good Metric? (10 mins)
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.

14/Mar/2020 27 14/Mar/2020 28

27 28

14

Measuring Software Size:
Function Point (FP), Feature Point,
Object Point and Use- case Point
14/Mar/2020
29
14/Mar/2020
Review: Software Size
◼ Size measurement must reflect effort, cost and productivity.
◼ Size-oriented metrics are direct measures of software (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.
29 14/Mar/2020 30
30
15
 14/Mar/2020

Length: Problem withLOC Function-Oriented Metrics

◼ Depending on the programmer and/or coding ◼ Function Point (FP) is a weighted measure of software
standards, the "line of code" could be, and usually is, functionality.
written on many separate lines: ◼ The idea is that a product with more functionality will be
for (i=0; i<100;++i) larger in size.
{ ◼ Function-oriented metrics are indirect measures of software
printf("hello"); which focus on functionality and utility.
} /* Now how many lines of code is this? */ ◼ The first function-oriented metrics was proposed by Albrecht
◼ In this example we have: (1979~1983) who suggested a productivity measurement
◼ 4 Physical Lines of Code (is placing braces worth to be approach called the Function Point (FP) method.
estimated?) ◼ Function points (FPs) measure the amount of functionality in
◼ 2 Logical Line of Code (What about all the work writing non- a system based upon the system specification.
statement lines?)
◼ 1 Comment Line (?)
14/Mar/2020 31 14/Mar/2020 32

31 32

16
 14/Mar/2020

FP: History FP: Current Status

◼ 1979: Proposed by Albrecht, at IBM
1983: Gained popularity, Albrecht’s
1997 1999 2001 2003
1.0 2.0 2.1 2.2
St. Pierre COSMIC IEEE paper
Full Function Points ◼ 1986: International FP user group
established (http://www.ifpug.org)
1975 1979 1984 1990 1994 1999 2004 ◼ 1990~2004: IFPUG, Guidelines to FP
IBM Albrecht IFPUG 3.4 IFPUG 4.0 IFPUG 4.1 IFPUG 4.2 measurement
Function Point Analysis
◼ 1998: ISO 14143-FSM: Functional Size
Measurement
1988 1998 ◼ 1999: IFPUG, FP counting practice
Symons UKSMA 1.3.1 manual, version 4.1
Mark II Function Point Analysis
◼ 2004: IFPUG, FP counting practice
manual, version 4.2
1975 1980 1985 1990 1995 2000

14/Mar/2020 33 14/Mar/2020 34

33 34

17
 14/Mar/2020

Function Point (FP)Standards Function Point (FP) /1

External
Standard Name Content External Outputs
ISO/IEC IFPUG 4.1 Unadjusted functional size measurement Inputs (EO)
14143-1:2000
method -- Counting practices manual (EI)
IFPUG Function Points VS 4.1
(unadjusted)
ISO/IEC IFPUG 4.2 Unadjusted functional size measurement Function
20926:2004 method -- Counting practices manual
IFPUG Function Points VS 4.2 Point (FP)
(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

External
20968:2002 Point Analysis Function Points
External Interface files (EIF) Inquiries (EQ)
Internal Logic files (ILF)
14/Mar/2020 35 14/Mar/2020 36

35 36

18
 14/Mar/2020

Function Point (FP) /2 FP Counting Summary

◼ Function Point (FP) is a weighted measure of Adjusted
Step 2 Adjusted
software functionality. FP Count Complexity
Function Points

Adjustment
Value Adjustment
◼ FP is computed in two steps: 14 Adjustment Factors
Factor (VAF)

1) Calculating Unadjusted Function point Count (UFC). Step 1b

Weighted Weighted Weighted Weighted Weigthed Unadjusted
2) Multiplying the UFC by a Value Adjustment Factor EI + EO + EQ + EIF + ILF = Function Points
(VAF) (UFP)

Weighting of

◼ The final (adjusted) Function Point is: L A H L A H L A H L A H L A H functional (technical)

complexities

FP = UFC  VAF Step 1a Unadjusted

# EI # EO # EQ # EIF # ILF and Unweighted
Function Count

14/Mar/2020 37 14/Mar/2020 38

37 38

19
 14/Mar/2020

1. External Inputs(EI) 2. External Outputs(EO)

◼ External Outputs – IFPUG Definition:

◼ External Inputs – IFPUG Definition:
◼ An external output (EO) is an
◼ An external input (EI) is an elementary
elementary process that sends data or
process that processes data or control control information outside the
information that comes from outside application boundary
the application boundary
◼ The primary intent of an external output is
◼ The primary intent of an EI is to
to present information to a user through
maintain one or more ILFs and/or to processing logic other than, or in addition
alter the behavior of the system to, the retrieval of data or control
information
◼ Example:
◼ Example:
◼ Data entry by users
◼ Data or file feeds by external applications
◼ Reports created by the application being counted, where the
reports include derived information
14/Mar/2020 39 14/Mar/2020 40

39 40

20
 14/Mar/2020

3. External Inquiries(EQ) 4. InternalLogical Files (ILF)

◼ External Inquiries – IFPUG Definition:
◼ Internal Logical Files – IFPUG
◼ An external inquiry (EQ) is an elementary Definition:
process that sends data or control
◼ An ILF is a user-identifiable group of
information outside the application
logically related data or control information
boundary
maintained within the boundary of the
◼ The primary intent of an external inquiry is to
application
present information to a user through the
◼ The primary intent of an ILF is to hold data
retrieval of data or control information from
maintained through one or more elementary
an ILF or EIF
◼ Example: processes of the application being counted
◼ The processing logic contains no
◼ Tables in a relational database
mathematical formulas or calculations, and
◼ Example: creates no derived data ◼ Files

◼ Reports created by the application being counted, where ◼ Application control information, perhaps things like user
preferences that are stored by the application
the report does not include any derived data
14/Mar/2020 41 14/Mar/2020 42

41 42

21
 14/Mar/2020

5. Ext. InterfaceFiles (EIF) FP Counting Summary

◼ External Interface files – IFPUG
Definition: Adjusted
Step 2 Adjusted
◼ An external interface file (EIF) is a user FP Count Complexity
Function Points

identifiable group of logically related Adjustment

Value Adjustment
data or control information referenced 14 Adjustment Factors
Factor (VAF)
by the application, but maintained
within the boundary of another Step 1b
Unadjusted
application Weighted
EI +
Weighted
EO +
Weighted
EQ +
Weighted
EIF +
Weigthed
ILF = Function Points
◼ The primary intent of an EIF is to hold (UFP)

data referenced through one or more Weighting of

functional (technical)
elementary processes within the L A H L A H L A H L A H L A H
complexities

boundary of the application counted

Step 1a Unadjusted
# EI # EO # EQ # EIF # ILF and Unweighted
Function Count
◼ Example:
◼ As for ILF, but maintained in a different system

14/Mar/2020 43 14/Mar/2020 44

43 44

22
 14/Mar/2020

Unadjusted FP Count(UFC) FP Counting: Weightingof Technical Complexity

◼ A complexity rating is associated with each count according

Elements Complexity Weighting Factor
to function point complexity weights, below:
low average high Sum
UFC = 4N EI + 5N EO + 4N EQ +7N EIF +1 NILF External Inputs (EI)
x 3= x 4= x 6=

Complexity Weighting Factor External Outputs (EO)

x 4= x 5= x 7=
Element Low High External Inquiries
Average (EQ)
x 3= x 4= x 6=
(Simple) (Complex)
External Interface
External inputs (NEI) 3 4 6 x 5= x 7= x10 =
Files (EIF)
External outputs (NEO) 4 5 7 Internal Logical Files
x 7= x10 = x15 =
(ILF)
External inquiries (NEQ) 3 4 6
Unadjusted Function Points (UFP)
External interface files (NEIF) 5 7 10
Internal logical files (NILF) 7 10 15

14/Mar/2020 45 14/Mar/2020 46

45 46

23
 14/Mar/2020

Function Types –Complexity Assessment Complexity Assessment: EI

#DET
◼ How to assess complexity? EI
1-4 5-15 > 15
1 low (3) low (3) average (4)
Data Function Types Transaction Function Types #FTR 2 low (3) average (4) high (6)
Internal Logical External External External External >2 average (4) high (6) high (6)
Files (ILF) Interface Files Input Output Inquiry
(EIF) (EI) (EO) (EQ)
Elements REcord Types (RET): User File Type Referenced (FTR): ◼ Identify number of File Types 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
◼ Identify number of Data Element Type (DET)
assessment of data to help identify them. External Interface File (EIF).
◼ Determine complexity weight (→ used to calculate
Data Element Types (DET): A unique user recognizable, non-recursive
(non-repetitive) field containing dynamic information. If a DET is FP count)
recursive then only the first occurrence of the DET is considered not
every occurrence.

14/Mar/2020 47 14/Mar/2020 48

47 48

24
 14/Mar/2020

External Input –Example EI – Example

◼ Enter a new employee with Weekly
◼ Enter a new employee Payment:
Employee Employee
ILF: ILF: ◼ Name
- Name
- ID Employee
with Monthly Payment: - Name
- ID Employee
- Birth Date
Administration (DB) ◼ Name - Birth Date
Administration (DB) ◼ ID
- Payment Reference - Payment Reference
◼ ID ◼ Birth Date
Weekly Payment Monthly Payment ◼ Birth Date Weekly Payment Monthly Payment
- Hourly Rate - Salary Level - Hourly Rate - Salary Level ◼ Payment Reference
- Payment Office
◼ Payment Reference - Payment Office
◼ Salary Level ◼ Hourly Rate

#DET ◼ Payment Office

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

14/Mar/2020 49 14/Mar/2020 50

49 50

25
 14/Mar/2020

Complexity Assessment: EO EO – Example

#DET
EO
1-5 6-19 > 19 ◼ Report of all Employees containing Names and
1 low (4) low (4) average (5) Birth Dates, sorted by age.
#FTR 2-3 low (4) average (5) high (7) ≤ 40 Years
ILF: Employee
>3 average (5) high (7) high (7) - Name Jerome Iginla, 10-02-1966
- ID Rehet Warner, 05-03-1966 1 FTR
≤ 45 Years 2 DET
- Birth Date
◼ Identify number of File Types Referenced (FTR) - Payment Reference Chris Chelios, 23-03-1961

◼ Identify number of Data Element Type (DET) #DET

EO
◼ Determine complexity weight (→ used to 1-5 6-19 > 19
calculate FP count) 1 low (4) low (4) average (5)
#FTR 2-3 low (4) average (5) high (7)
>3 average (5) high (7) high (7)

14/Mar/2020 51 14/Mar/2020 52

51 52

26
 14/Mar/2020

Complexity Assessment: EQ EQ – Example

#DET ◼ Report of all employees belonging to
EQ
1-5 6-19 > 19 Department X containing Names, Birth
1 low (3) low (3) average (4) ILF: ILF: Dates, and showing the Department Name
#FTR 2-3 low (3) average (4) high (6) “Employee” “Department”
◼ Files (ILF): Employee, Department
>3 average (4) high (6) high (6)
◼ 2 FTR: Employee, Department
3 DET: Name (Employee), Birth Date
◼ Identify number of File Types Referenced (FTR) Report (Employee), Department Name
(Department)
◼ Identify number of Data Element Type (DET) #DET
◼ Determine complexity weight (→ used to calculate EQ
1-5 6-19 > 19
FP count)
1 low (3) low (3) average (4)
#FTR 2-3 low (3) average (4) high (6)
>3 average (4) high (6) high (6)

14/Mar/2020 53 14/Mar/2020 54

53 54

27
 14/Mar/2020

Complexity Assessment: ILF ILF – Example

#DET
ILF
1-19 20-50 > 50 Employee
ILF: - Name
1 low (7) low (7) average
“Employee” = - ID
1 RET
4 DET
(10)
- Birth Date
#RET 2-5 low (7) average high (15) - Payment Reference
(10)
>5 average (10) high (15) high (15)
#DET
ILF
◼ Identify number of Record Types (RET) 1-19 20-50 > 50
1 low (7) low (7) average (10)
◼ Identify number of Data Element Type (DET)
#RET 2-5 low (7) average (10) high (15)
◼ Determine complexity weight (→ used to >5 average (10) high (15) high (15)
calculate FP count)

14/Mar/2020 55 14/Mar/2020 56

55 56

28
 14/Mar/2020

Complexity Assessment: EIF EIF – Example

#DET
EIF Employee
1-19 20-50 > 50 - Name EIF:
- ID Employee
1 low (5) low (5) average (7) - Birth Date
Payroll Administration (DB)
- Payment Reference
#RET 2-5 low (5) average (7) high (10)
Software
>5 average (7) high (10) high (10) Weekly Payment Monthly Payment
- Hourly Rate - Salary Level
- Payment Office

◼ Identify number of Record Types (RET) EIF

#DET
2 RET 1-19 20-50 > 50
◼ Identify number of Data Element Type (DET) 7 DET
1 low (5) low (5) average (7)

◼ Determine complexity weight (→ used to calculate FP #RET 2-5 low (5) average (7) high (10)
>5 average (7) high (10) high (10)
count)

14/Mar/2020 57 14/Mar/2020 58

57 58

29
 14/Mar/2020

FP Counting Example –GUI FP Counting Summary

Employee
Adjusted
Name new Step 2 Adjusted Function Points
First Name FP Count Complexity
change 3 External Inputs Adjustment
Street Value Adjustment
14 Adjustment Factors
Postal Code delete Factor (VAF)
City close
Birth Date Step 1b
“close” button does not Weighted Weighted Weighted Weighted Weigthed Unadjusted
count, because it is not EI + EO + EQ + EIF + ILF = Function Points
a transaction in its own (UFP)
right involving access to Weighting of
1 External Inquiry (input side) ILFs, EIFs L A H L A H L A H L A H L A H functional (technical)
complexities

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

Step 1a Unadjusted
External Input (change, 1 FTR, 7 DET, low) = 3 FP # EIF
12 FP # EI # EO # EQ # ILF and Unweighted
External Input (delete, 1 FTR, 7 DET, low) = 3 FP Function Count
External Inquiry (navigate, 1 FTR, 7 DET, low) = 3 FP

14/Mar/2020 59 14/Mar/2020 60

59 60

30
 14/Mar/2020

Value Adjustment Factor (VAF) /1 Value Adjustment Factor (VAF) /2

◼ Value Adjustment Factor (VAF) (aka. Technical ◼ Each component is rated from 0 to 5, where 0
complexity factors) is a weighted sum of 14 means the component is not relevant to the system
components, given below: and 5 means the component is essential.
◼ VAF can then be calculated as:
F1 Data Communications F8 On-line Update
Min = 0
F2 Distributed Data Processing F9 Complex Processing 14 Max = 0.7
F3 Performance F10 Reusability VAF = 0.65 + 0.01 Fj
F4 Heavily Used Configuration F11 Installation Ease j=1
F5 Transaction Rate F12 Operational Ease
F6 On-line Data Entry F13 Multiple Sites
◼ VAF varies from 0.65 (if all Fj are set to 0) to 1.35
F7 End-User Efficiency F14 Facilitate Change
(if all Fj are set to 5)

14/Mar/2020 61 14/Mar/2020 62

61 62

31
 14/Mar/2020

Summary Software Size: Comparison

Watch the following video and answer the below Criteria LOC Halstead’s FP OP
question. Applicable to early stages No
No Yes Yes
(requirement phase) of (may be)
- https://www.youtube.com/watch?v=Nf8XsGjcDSk software development?
Subjective measure? No No Yes Yes
Derivable from system No No Yes Yes
Q. What are FP analysis steps? requirements?
Language dependable? Yes Yes No No
Has clear and understandable
Yes No No No
physical meaning?

14/Mar/2020 63 14/Mar/2020 64

63 64

32
 14/Mar/2020

Software Size Metrics:Summary References

Requirement
• Albrecht, A. J., & Gaffney, J. E. (1983). Software function, source
Length Design lines of code, and development effort prediction: a software
LOC
Code science validation. IEEE transactions on software engineering,
Halstead’s (6), 639-648.
Function point
Software Feature point
Functionality
size ◼ Function Points Analysis Training Manual (110 Pages)-
Use-case point https://www.softwaremetrics.com/freemanual.htm
Object point ◼ Park, R. E. (1992). Software size measurement: A framework for
Complexity Cyclomatic complexity counting source statements (No. CMU/SEI/92-TR-20). Carnegie-
Reuse level Mellon Univ Pittsburgh PA Software Engineering Inst. (available
at URL:
Reuse Reuse frequency
http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr20.92.pdf
Reuse density )
14/Mar/2020 65 14/Mar/2020 66

65 66

33