UNIT 6 SOFTWARE METRICS

1. SOFTWARE METRICS
A software metric is a measure of software characteristics which are measurable or countable.
Software metrics are valuable for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.

Software metrics will be useful only if they are characterized effectively and validated so that
their worth is proven. There are 4 functions related to software metrics:

1. Planning
2. Organizing
3. Controlling
4. Improving

i) Characteristics of software Metrics:

1. Quantitative: Metrics must possess quantitative nature. It means metrics can be expressed in
values.
2. Understandable: Metric computation should be easily understood, and the method of
computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the development of the
software.
4. Repeatable: The metric values should be the same when measured repeatedly and consistent in
nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any programming language.

ii) Classification of Software Metrics:

There are 3 types of software metrics:

1. Product Metrics: Product metrics are used to evaluate the state of the product, tracing risks and
undercover prospective problem areas. The ability of the team to control quality is evaluated.
Examples include lines of code, cyclomatic complexity, code coverage, defect density, and code
maintainability index.
2. Process Metrics: Process metrics pay particular attention to enhancing the long-term process of
the team or organization. Examples include effort variance, schedule variance, defect injection
rate, and lead time.
3. Project Metrics: The project matrix describes the project characteristic and execution
process. Examples include effort estimation accuracy, schedule deviation, cost variance, and
productivity.
o Number of software developer
o Staffing patterns over the life cycle of software
 o Cost and schedule
o Productivity

iii) Types of Metrics

Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed
to be of greater importance to a software developer. For example, Lines of Code (LOC) measure.

External metrics: External metrics are the metrics used for measuring properties that are viewed
to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.

Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource
metrics. For example, cost per FP where FP stands for Function Point Metric.

2. Token count
A program is considered to be 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.

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

The size of the vocabulary of a program which consists of the number of unique tokens to build a
program is defined as:-

n =n1 + n2

Where, n : vocabulary of a program.

n1: number of unique operators

n2: number of unique operands.

 3. DATA STRUCTURE METRICS
The basic set of metrics that captures and calculates the amount of data input to, internally
processed in, and output from software is called Data Structure Metrics.

There are some Data Structure metrics to compute the effort and time required to complete the
project. These metrics are:

1. The Amount of Data: To measure the amount of Data, there are further many different
metrics, and these are:

• Number of variable (VARS): In this metric, the Number of variables used in the
program is counted.
• Number of Operands (η2): In this metric, the Number of operands used in the program
is counted.
η2 = VARS + Constants + Labels
• Total number of occurrence of the variable (N2): In this metric, the total number of
occurrence of the variables are computed

2. The Usage of data within a Module: The measure this metric, the average numbers of live
variables are computed. A variable is live from its first to its last references within the procedure.

3. Program weakness: Program weakness depends on its Modules weakness. If Modules are
weak (less Cohesive), then it increases the effort and time metrics required to complete the
project.

4.There Sharing of Data among Module: As the data sharing between the Modules increases
(higher Coupling), no parameter passing between Modules also increased, As a result, more
effort and time are required to complete the project. So Sharing Data among Module is an
important metrics to calculate effort and time.
 4. INFORMATION FLOW METRICS
Information Flow metrics is the set of metrics that measure the complexity of code by calculating
the passage of information among system components or modules. These metrics are based on the
concept: the simplest systems consist of components. The work done by these components and
how they are fitted together identify the system's complexity.

Terminologies used in IF Metrics

1. Component: The parts or constituents of a decomposed (software) system are called

components.
2. Cohesion: A measure of the degree to which a component performs a single function is called
cohesion. If a component does numerous discrete tasks, it lacks cohesion.
3. Coupling: The degree of linkage between one component to others in the same system is called
coupling. A highly coupled component is linked to many components, whereas a slightly coupled
component is linked to only a few.

Information Flow metrics measure the information flowing among modules of the system. It is
responsive to the complexity due to interconnection among system components. This measure
also includes the complexity of a software module, which is the sum of all the complexities of
the methods present in the module. A procedure contributes complexity due to the following two
factors.

1. The complexity of the process code itself.

2. The complexity due to the process's linkage to other processes. The effect of the first case
has been included through the LOC (Line Of Code) measure. For estimating the second
case, Henry and Kafura have described two terminologies: FAN IN and FAN OUT.

FAN-IN: FAN-IN of a component is a count of the number of other components that can call or
pass information to that component.

FAN -OUT: FAN-OUT of a component is the number of components that are called by or
receive information from that component.
 5. METRICS ANALYSIS
Metrics analysis in software engineering is the process of gathering, measuring, and analyzing data
to assess and improve various aspects of software development. It involves using quantitative and
qualitative metrics to evaluate the performance, quality, and progress of a software project.

Key steps in metrics analysis include:

1. Data Collection: Gathering relevant data from the software development process, such as lines
of code, defects, development time, and user feedback.

2. Measurement: Transforming the collected data into measurable metrics, allowing for objective
analysis.

3. Interpretation: Analyzing the metrics to gain meaningful insights into the project's performance
and health.

4. Benchmarking: Comparing metrics against industry standards or predefined benchmarks to

understand how the project fares in comparison.

5. Continuous Improvement: Using the insights from metrics analysis to make informed decisions
and identify areas for improvement in the development process.

Common software metrics include code complexity, code coverage, defect density, build success
rate, customer satisfaction, and development velocity. Metrics analysis empowers software teams
and stakeholders to make data-driven decisions, identify potential risks, allocate resources
effectively, and optimize development processes.