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.
Within the software development process, many metrics are that are all connected. Software metrics
are similar to the four functions of management: Planning, Organization, Control, or Improvement.
Classification of Software Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics: These are the measures of various characteristics of the software product. The
two important software characteristics are:
1. Size and complexity of software.
2. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics: These are the measures of various characteristics of the software development
process. For example, the efficiency of fault detection. They are used to measure the characteristics of
methods, techniques, and tools that are used for developing software.

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.
Project metrics: Project metrics are the metrics used by the project manager to check the project's
progress. Data from the past projects are used to collect various metrics, like time and cost; these
estimates are used as a base of new software. Note that as the project proceeds, the project manager
will check its progress from time-to-time and will compare the effort, cost, and time with the original
effort, cost and time. Also understand that these metrics are used to decrease the development costs,
time efforts and risks. The project quality can also be improved. As quality improves, the number of
errors and time, as well as cost required, is also reduced.
Advantage of Software Metrics
Comparative study of various design methodology of software systems.
For analysis, comparison, and critical study of different programming language concerning their
characteristics.
In comparing and evaluating the capabilities and productivity of people involved in software
development.
In the preparation of software quality specifications.
In the verification of compliance of software systems requirements and specifications.
In making inference about the effort to be put in the design and development of the software systems.
In getting an idea about the complexity of the code.
AD
In taking decisions regarding further division of a complex module is to be done or not.
In guiding resource manager for their proper utilization.
In comparison and making design tradeoffs between software development and maintenance cost.
In providing feedback to software managers about the progress and quality during various phases of
the software development life cycle.
In the allocation of testing resources for testing the code.
AD
AD
Disadvantage of Software Metrics
The application of software metrics is not always easy, and in some cases, it is difficult and costly.
The verification and justification of software metrics are based on historical/empirical data whose
validity is difficult to verify.
These are useful for managing software products but not for evaluating the performance of the
technical staff.
The definition and derivation of Software metrics are usually based on assuming which are not
standardized and may depend upon tools available and working environment.

Most of the predictive models rely on estimates of certain variables which are often not known
precisely.

Size Oriented Metrics

LOC Metrics

It is one of the earliest and simpler metrics for calculating the size of the computer program.
It is generally used in calculating and comparing the productivity of programmers. These
metrics are derived by normalizing the quality and productivity measures by considering the
size of the product as a metric.

Following are the points regarding LOC measures:

1. In size-oriented metrics, LOC is considered to be the normalization value.

 2. It is an older method that was developed when FORTRAN and COBOL programming
were very popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-
months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more
productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. LOC method of measurement does not apply to projects that deal with visual (GUI-
based) programming. As already explained, Graphical User Interfaces (GUIs) use
forms basically. LOC metric is not applicable here.
9. It requires that all organizations must use the same method for counting LOC. This is
so because some organizations use only executable statements, some useful
comments, and some do not. Thus, the standard needs to be established.
10. These metrics are not universally accepted.

Based on the LOC/KLOC count of software, many other metrics can be computed:

a. Errors/KLOC.

b. $/ KLOC.

c. Defects/KLOC.

d. Pages of documentation/KLOC.

e. Errors/PM.

f. Productivity = KLOC/PM (effort is measured in person-months).

g. $/ Page of documentation.

Advantages of LOC

1. Simple to measure

Disadvantage of LOC
 1. It is defined on the code. For example, it cannot measure the size of the specification.
2. It characterizes only one specific view of size, namely length, it takes no account of
functionality or complexity
3. Bad software design may cause an excessive line of code
4. It is language dependent
5. Users cannot easily understand it

6. Functional Point (FP) Analysis

7. Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and
it has been further modified by the International Function Point Users Group
(IFPUG). FPA is used to make estimate of the software project, including its
testing in terms of functionality or function size of the software product.
However, functional point analysis may be used for the test estimation of the
product. The functional size of the product is measured in terms of the
function point, which is a standard of measurement to measure the software
application.
8. Objectives of FPA
9. The basic and primary purpose of the functional point analysis is to measure
and provide the software application functional size to the client, customer,
and the stakeholder on their request. Further, it is used to measure the
software project development along with its maintenance, consistently
throughout the project irrespective of the tools and the technologies.
10. Following are the points regarding FPs
11. 1. FPs of an application is found out by counting the number and types of
functions used in the applications. Various functions used in an application
can be put under five types, as shown in Table:
12. Types of FP Attributes

Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

13. All these parameters are then individually assessed for complexity.
 14. The FPA functional units are shown in Fig:

15.
16. 2. FP characterizes the complexity of the software system and hence can be
used to depict the project time and the manpower requirement.
17. 3. The effort required to develop the project depends on what the software
does.
18. 4. FP is programming language independent.
19. 5. FP method is used for data processing systems, business systems like
information systems.
20. 6. The five parameters mentioned above are also known as information
domain characteristics.
21. 7. All the parameters mentioned above are assigned some weights that have
been experimentally determined and are shown in Table
22. Weights of 5-FP Attributes

Measurement Parameter Low Average

1. Number of external inputs (EI) 7 10

2. Number of external outputs (EO) 5 7

3. Number of external inquiries (EQ) 3 4

4. Number of internal files (ILF) 4 5

5. Number of external interfaces (EIF) 3 4

 23. The functional complexities are multiplied with the corresponding weights
against each function, and the values are added up to determine the UFP
(Unadjusted Function Point) of the subsystem.
24.

25. Here that weighing factor will be simple, average, or complex for a
measurement parameter type.

26. FP = Count-total * [0.65 + 0.01 * ∑(fi)]

= Count-total * CAF
27. where Count-total is obtained from the above Table.
28. CAF = [0.65 + 0.01 *∑(fi)]
29. and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment
value/ factor-CAF (where i ranges from 1 to 14). Usually, a student is provided with
the value of ∑(fi)
30. Also note that ∑(fi) ranges from 0 to 70, i.e.,

0 <= ∑(fi) <=70

and CAF ranges from 0.65 to 1.35 because

a. When ∑(fi) = 0 then CAF = 0.65

b. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35

Based on the FP measure of software many other metrics can be computed:

a. Errors/FP

b. $/FP.
 c. Defects/FP

d. Pages of documentation/FP

e. Errors/PM.

f. Productivity = FP/PM (effort is measured in person-months).

g. $/Page of Documentation.

8. LOCs of an application can be estimated from FPs. That is, they are
interconvertible. This process is known as backfiring. For example, 1 FP is equal to
about 100 lines of COBOL code.

9. FP metrics is used mostly for measuring the size of Management Information

System (MIS) software.

10. But the function points obtained above are unadjusted function points (UFPs).
These (UFPs) of a subsystem are further adjusted by considering some more General
System Characteristics (GSCs). It is a set of 14 GSCs that need to be considered. The
procedure for adjusting UFPs is as follows:

a. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0

to 5. (b) If a particular GSC has no influence, then its weight is taken as 0 and if
it has a strong influence then its weight is 5.

b. The score of all 14 GSCs is totaled to determine Total Degree of Influence

(TDI).

c. Then Value Adjustment Factor (VAF) is computed from TDI by using the
formula: VAF = (TDI * 0.01) + 0.65

Remember that the value of VAF lies within 0.65 to 1.35 because

a. When TDI = 0, VAF = 0.65

b. When TDI = 70, VAF = 1.35

c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP

Example: Compute the function point, productivity, documentation, cost per

function for the following data:
 1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month

Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.

Solution:

Measurement Parameter Count Weig

1. Number of external inputs (EI) 24 * 4 = 96

2. Number of external outputs (EO) 46 * 4 = 18

3. Number of external inquiries (EQ) 8 * 6 = 48

4. Number of internal files (ILF) 4 * 10 = 4

5. Number of external interfaces (EIF) Count-total → 2 * 5

378

So sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43

FP = Count-total * [0.65 + 0.01 *∑(f i)]

= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408

Total pages of documentation = technical document + user document

= 265 + 122 = 387pages
Documentation = Pages of documentation/FP
= 387/408 = 0.94

Differentiate between FP and LOC

FP LOC

1. FP is specification based. 1. LOC is an analogy based.

2. FP is language independent. 2. LOC is language dependent.

3. FP is user-oriented. 3. LOC is design-oriented.

4. It is extendible to LOC. 4. It is convertible to FP (backfiring)