Unit-3

Software Measurement and Metrics: Various Size Oriented Measures: Halestead’s Software
Science, Function Point (FP) Based Measures, Cyclomatic Complexity Measures: Control Flow
Graphs.

Software measurement and metric

• Pressman explained as “A measure provides a quantitative indication of the extent, amount,
dimension, capacity, or size of some attribute of the product or process”.
• Fenton defined measurement as “it is the process by which numbers or symbols are assigned to
attributes of entities in the real world in such a way as to describe them according to clearly
defined rules”.
• Measurement is the act of determine a measure

Software metrics
• Pressman explained as “The metric is a quantitative measure of the degree to which a system,
component, or process possesses a given attribute”.

• Software metrics can be defined as “The continuous application of measurement-based

techniques to the software development process and its products to supply meaningful and
timely management information, together with the use of those techniques to improve that
process and its products.

Categories of Metrics

Project metrics: describe the project

Product metrics: describe the characteristics of the product such as Process characteristics and execution. Examples are:-
metrics:
describe
the
desig effectiven number
perfo porta ess and of staffing
comp n effici reliab quality of pattern cost and producti
size, rman bility, the software schedule vity
lexity, featu ency, ility, develope over the
ce, etc. processes
life cycle
res, that rs
of the
produce
the software
software
product.
Examples
are:

effective number
effort time to ness of of maturity
required produce defect defects of the
in the the removal found process
process product during during
develop testing
ment

Categories of Metrics
1. Product metrics: describe the characteristics of the product such as
• size,
• complexity,
• design features,
 • performance,
• efficiency,
• reliability,
• portability, etc.
2. Process metrics: describe the effectiveness and quality of the processes that produce the
software product. Examples are:

• effort required in the process

• time to produce the product

• effectiveness of defect removal during development

• number of defects found during testing

• maturity of the process

3. Project metrics: describe the project characteristics and execution. Examples are:-

• number of software developers

• staffing pattern over the life cycle of the software

• cost and schedule

• productivity

Product Size can be calculated by different methods like Line of Code, Halstead Software Science
and Function Point etc.

Complexity of the product can be measured using Cyclomatic Complexity method.

Halstead’s Software Science

The major problem with LOC measure is that it is not consistent because some lines are more
difficult to code than others. A program is considered to be a series of tokens and if we count the
number of tokens, some interesting results may emerge. Tokens are classified as either operators
or operands. All software science measures are functions of the counts of these tokens.

Generally, any symbol or keyword in a program that specifies an algorithmic action is considered
an operator, while a symbol used to represent data is considered an operand. Most punctuation
marks are also categorized as operators. Variables, constants and even labels are operands.
Operators consist of arithmetic symbols such as +, -, /, and command names such as "while",
"for", "printf", special symbols such as :=, braces, parentheses, and even function names such as
"eof" (end of file).

Halstead uses these primitive measures to develop expressions for the

- overall program length,

- potential minimum volume for an algorithm,
- the actual volume (number of bits required to specify a program),
- the program level (a measure of software complexity),
- the language level (a constant for a given language), and
- other features such as development effort, development time, and even the projected
number of faults in the software.
The size of the vocabulary of a program, which consists of the number of unique tokens used to
build a program is defined as:

n = n1 + n2 where

n: vocabulary of a program

n1: number of distinct operators that appear in a program / number of unique operators

n2: number of distinct operands that appear in a program / number of unique operands

N1: total number of operator occurrences/ total occurrences of operators

N2: total number of operand occurrences/ total occurrences of operand

It should be noted that V will vary with programming language and represents the volume of
information (in bits) required to specify a program.

Halstead defines a volume ratio L as the ratio of volume of the most compact form of a program
to the volume of the actual program. In actuality, L must always be less than 1. In terms of
primitive measures, the volume ratio may be expressed as

Function-Based Metric
The function point (FP) metric can be used effectively as a means for measuring the functionality
delivered by a system. Using historical data, the FP metric can then be used to

(1) estimate the cost or effort required to design, code, and test the software;
(2) predict the number of errors that will be encountered during testing; and
(3) forecast the number of components and/or the number of projected source lines in the
implemented system.

Number of external inputs (EIs) - Each external input originates from a user or is transmitted
from another application and provides distinct application-oriented data or control information.
Inputs are often used to update internal logical files (ILFs). Inputs should be distinguished from
inquiries, which are counted separately.

Number of external outputs (EOs) - Each external output is derived data within the application
that provides information to the user. In this context external output refers to reports, screens,
error messages, etc. Individual data items within a report are not counted separately.
Number of external inquiries (EQs) - An external inquiry is defined as an online input that results
in the generation of some immediate software response in the form of an online output (often
retrieved from an ILF).

Number of internal logical files (ILFs) - Each internal logical file is a logical grouping of data that
resides within the application’s boundary and is maintained via external inputs.

Number of external interface files (EIFs) - Each external interface file is a logical grouping of data
that resides external to the application but provides information that may be of use to the
application.
Example – The data flow diagram is evaluated to determine a set of key information domain
measures required for computation of the function point metric. Three external inputs—
password, panic button, and activate/deactivate—are shown in the figure along with two
external inquiries—zone inquiry and sensor inquiry. One ILF (system configuration file) is shown.
Two external outputs (messages and sensor status) and four EIFs (test sensor, zone setting,
activate/deactivate, and alarm alert) are also present. These data, along with the appropriate
complexity, are shown in Figure 23.3.
The count total shown in Figure 23.3 must be adjusted using Equation (23.1). For the purposes of
this example, we assume that (Fi) is 46 (a moderately complex product). Therefore,

Cyclomatic Complexity Measures: Control Flow Graphs

Cyclomatic complexity is a software metric that provides a quantitative measure of the logical
complexity of a program. It is also known as structural complexity because it gives internal view
of the code.

When used in the context of the basis path testing method, the value computed for cyclomatic
complexity defines the number of independent paths in the basics set of a program and provides
you with an upper bound for the number of tests that must be conducted to ensure that all
statements have been executed at least once.

Cyclomatic complexity has a foundation in graph theory and provides you with an extremely
useful software metric. Complexity is computed in one of three ways:

1. The number of regions of the flow graph corresponds to the cyclomatic complexity.

2. Cyclomatic complexity V(G) for a flow graph G is defined as

V(G) = E - N + 2P

where E is the number of flow graph edges, N is the number of flow graph nodes and P is
the connected components.

3. Cyclomatic complexity V(G) for a flow graph G is also defined as

V(G) = π + 1

where π is the number of predicate nodes contained in the flow graph G.