Scribd
Upload
49 views

Subject: SPM

This document discusses software size metrics. It describes various metrics used to measure software size both internally, such as lines of code (LOC), and externally, such as functionality and complexity. LOC counts the number of physical lines in the code and is the most commonly used size metric. Halstead's software science theory also measures size based on the number of unique operands and operators. The document provides examples of calculating metric values for sample code and discusses criticisms of LOC and Halstead's metrics in modern programming.

Uploaded by

shahwar
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
49 views

Subject: SPM

This document discusses software size metrics. It describes various metrics used to measure software size both internally, such as lines of code (LOC), and externally, such as functionality and complexity. LOC counts the number of physical lines in the code and is the most commonly used size metric. Halstead's software science theory also measures size based on the number of unique operands and operators. The document provides examples of calculating metric values for sample code and discusses criticisms of LOC and Halstead's metrics in modern programming.

Uploaded by

shahwar
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

Subject: SPM

Lecture 9
Software Metrics
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
Metrics
• Quantifiable measures that could be used to
measure characteristics of a software system or
the software development process OR
• Quantitative measure of degree to which a system,
component or process possesses a given attribute. “A
guess about a given attribute.”
– E.g., Number of errors found per person hours expended
• Required for effective management
• Managers need quantifiable information, and
not subjective information
Questions

• How big is the program?


– Huge!!
• How close are you to finishing?
– We are almost there!!
• Can you, as a manager, make any useful
decisions from such subjective information?
• Need information like, cost, effort, size of
project.
Motivation for Metrics
• Estimate the cost & schedule of future projects

• Evaluate the productivity impacts of new tools and


techniques

• Improve software quality

• Forecast future staffing needs

• Anticipate and reduce future maintenance needs


Types of Measures
• Direct Measures (internal attributes)
– Cost, effort, LOC, speed, memory

• Indirect Measures (external attributes)


– Functionality, quality, complexity, efficiency, reliability,
maintainability
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.

Size measurement must reflect effort and cost

External product attributes that can be measured with


respect to how the product or process relates to its
environment through its behaviour. E.g. Quality
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.(Complexity is inferred by
measuring the number of linearly independent paths
through the program. )
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.
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.
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 lines except blank lines, comments,


declarations and headings.
Count of only executable statements, not including
exception conditions.
Length: Code - LOC /3
Advantages of LOC
Simple and automatically measurable
Many existing estimation models use LOC
Correlates with programming effort (& cost)
Disadvantage of LOC
Vague definition
Language dependability
Not available for early planning
Developers’ skill dependability

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.
Operators are defined operations in a
programming language
if … else a, b, x
(language constructs) + -> = ; 100
main()
goto

11
Length: Halstead’s Work /2
Number of distinct operators in the program (n1)
Number of distinct operands in the program (n2)
Total number of occurrences of operators in the
program (N1)
Total number of occurrences of operands in the
program (N2)

Program vocabulary (n)


n = n 1 + n2
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 comparisons
needed to write a program of length N
V = N log 2 n
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^=nlog n1 +n 2 log n 2
1
Effort required to generate program P:
=
n1N2 × N log n 2
2n2
D (PROGRAM DIFFICULTY)= 1/L
For a program, as the volume V increases, the program level L decreases and the difficulty
D increases.
L (Program level):The maximum value for program level, L, is 1.
A program with L = 1 is said to be written at the highest possible level (i.e. with
minimum size): L = ( 2 n2 ) / ( n1 N2 )
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
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
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);
}
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
Example 1 (cont’d)
Operands Number of occurrences
a 10
10 3
20 3

n2 = 3 N2 = 16
n1 = 20 N1 = 47
Program length: N = N1 + N2 = 63
Program Estimated length:
N^ =n 1
log 2 n1 +n 2 log2 n 2 = 20 log 2 20 + 3log 2 3=91.1934
Example 1 (cont’d)
E=V*D= 20*16 * 63log223
2*3

E=V*D= 15177.7

Time Required to program(seconds)=E/=843 sec


Here =18

Remaining Bugs

B=0.19
Example 2
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 notions of time to develop and remaining bugs
are arguable.
Unable to be extended to include the size for
specification and design.
Length: Code - Problems
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

How can one account for components that are


constructed externally? (library, repository,
inherited functions)

You might also like