This document discusses various software quality metrics including lines of code count, defect density as it relates to size, cyclomatic complexity, fan-in/fan-out, and other structural and data complexity metrics. It provides empirical data on the relationship between size and defects, defines key metrics like cyclomatic complexity, and discusses how these metrics can help evaluate software quality and estimate testing effort.

1. Software Quality Management
Unit – IV
G. Roy Antony Arnold
Asst. Prof. / CSE

2. • The li
h lines of code ( OC) count i usually f
f d (LOC) is ll for
executable statements.
• LOC count represents the program size and
complexity, it is not a surprise that
.
• More recent studies point to a curvilinear
relationship between lines of code and defect
rate:

4. Maximum Source Average Defect per
Lines of Modules 1,000 Source Lines
63 1.5
100 1.4
158 0.9
251 0.5
398 1.1
630 1.9
1000 1.3
>1000 1.4

5. • Wh
When module size b
d l i becomes very l large, the
h
complexity increases to a level beyond a
programmer s
programmer's immediate span of control and total
comprehension.
• The curvilinear model between size and defect
density sheds new light on software quality
engineering. It implies that there may be an
g g p y
optimal program size that can lead to the lowest
defect rate.
• Such an optimum may depend on language,
project, product, and environment; apparently
many more empirical i
i i l investigations are needed.
ti ti d d

6. • Halstead (1977) distinguishes software
science from computer science.
• The premise of software science is that any
programming task consists of selecting and
arranging a finite number of program
“tokens”, which are
tokens
.
• A computer program, according to software
di f
science,
.

7. • Th primitive measures of H l t d' software science
The i iti f Halstead's ft i
are
• Based on these primitive measures, Halstead
developed a system of equations expressing
and other
features such as development effort and the projected
number of faults in the software.

8. Vocabulary,
Length,
Length,
Volume,
Level,
Difficulty,
Difficulty
Effort,
Faults,

9. • The measurement of cyclomatic complexity b
h f l i l i by
McCabe (1976) was designed
(maintainability).
• It is the classical graph theory cyclomatic
number,
.
• To determine the paths, the program
procedure is represented
.

10. • The general formula to compute cyclomatic
p y
complexity is:
• Wh
Where,
V(G) – Cyclomatic Number of G
( ) y
e – Number of edges
n – Number of nodes
n Number of nodes
p – Number of unconnected parts of the graph

11. • If we count the edges, nodes, and
disconnected parts of the graph,
• The iteration test in a looping statement is
The iteration test in a looping statement is
counted as one binary decision. In the
preceding simple example, since there are
two binary decisions, M = 2 + 1 = 3
• The cyclomatic complexity metric is
additive. The complexity of several graphs
additive The complexity of several graphs
considered as a group is equal to the sum
g p p
of the individual graphs' complexities.

13. needing detailed inspections.
g p
likely to
have a low defect rate and therefore
have a low defect rate and therefore
candidates for development without
detailed inspections.
l
, identify troublesome code, and
estimate testing effort.
estimate testing effort

14. • McCabe's cyclomatic complexity index is a
.
• It does not distinguish different kinds of control
flow complexity such as
p y
.
• In studying the quality and syntactic indicators
among a sample of twenty modules of a COBOL
compiler product
product, found that
at the module level can be estimated
through the following equations:

15. • Lo found that most developers were having difficulty
p g y
mastering the DO WHILE construct.
• As a result, minimizing the use of DO WHILE was one of
the actions the team took to reduce defects in the
compiler product.

16. • St t
Structure metrics try to take into account the
ti t t t k i t t th
.
• The most common design structure metrics
are the
are the , which are
which are
based on the proposed by
(1979) and
(1978):
A count of the modules that call a given
module
: A count of modules that are called by a
given module
given module

17. • I l d l ith l f i
In general, modules with a large fan‐in are
.
• In contrast, modules that are large and complex are
likely to have a small fan‐in.
structure complexity is
defined as:
• Henry and Selig's work (1990) defines a hybrid form
of their information‐flow metric as
of their information flow metric as
where, C internal complexity of procedure p
where, Cip – internal complexity of procedure p

18. • C d d Gl (1990) d l
Card and Glass (1990) developed a system complexity model
d t l it d l
Ct – System Complexity St – Structural (intermodule)
System Complexity, S Structural (intermodule)
complexity, Dt – Data (intermodule) complexity
• They defined relative system complexity as
n – no. Of modules in the system
• S
Structure complexity is further defined as
l i i f h d fi d
S=
∑ f 2 (i )
n
Where S – Structural Complexity, f(i) – Fan‐out of Module i,
n – no. Of modules in the system

19. • D t C
Data Complexity is further defined as
l it i f th d fi d
Di Data Complexity of Module i, V(i) I/O
Di – Data Complexity of Module i, V(i) – I/O
Variables in module i, f(i) – fan‐out of module i
D – Data (intramodule) Complexity, D(i) – Data
Complexity of module i, n = Number of new
modules in the system