A Unified Metric of Software Complexity:
Measuring Productivity, Quality, and Value
Renato R. Gonzalez
Faculty of Engineeting, Santo Domingo Institute of Technology, Santo Domingo, Dominican Republic
There are different sources of software complexity. A
large set of complexity metrics can measure distinct
program attributes to show different program size indi-
cators. Nevertheless, the size of a program must be
obtained from the overall program complexity based
on the values of all program factors. Based on the
concept that software complexity is a measurement of
the resources expended through the software life cy-
cle, and the fact that a program may be approached
from three distinct perspectives, the complexity fac-
tors are classified into three complexity domains: syn-
tactical, functional, and computational. Each domain
represents the magnitudes of the factors in one of the
three dimensions: length, time, and level or depth.
Using these ideas, in this article we define ordinal
measures of the complexity factors based on discrete
mathematical structures of programs and the informa-
tion content or entropy. transform the different do-
mains of software complexity in linear metric spaces
in order to represent a program by a set of vectors
whose magnitudes and distances represent metrics of
the program components, and define a “unified com-
plexity metric” of the program size and the effort
needed to produce it over the multilinear complexity
space conformed by the three complexity spaces.
These metrics may be used to define a statistical
method that estimates the size of a program and the
effort needed to produce it from the external system
design, the productivity in software projects, and the
quality and value of software products.
1. INTRODUCTION
To pass from art to science, a discipline must be
abridged by quantitative methods. It is necessary to
know about the “essence” of the objects under study
and quantify such essence. Physics became a science
Address correspondence to Prof: Renato R. Gonzalez, Faculty of
Engineering, Santa Domingo Institute of Technology, EPS #P6103,
P.O. Box 02-5261, Miami, FL 33102-5261.
J. SYSTEMS SOFTWARE 1995; 29:17-37
0 1995 by Elsevier Science Inc.
655 Avenue of the Americas, New York, NY 10010
with the notions of matter and measurement of
length, mass, and time; thermodynamic became a
science with the measurements of temperature and
entropy.
It is impossible to carry out this objective until the
right questions are asked. Scientists must know what
to measure before creating a metric of an object.
They must interpret the complex phenomena by
reducing them to elementary events or processes
whose behavior is described by simple laws (Estes,
1982). To define a metric, we must know the context
of the object, its intrinsic nature and components,
the characteristics to be measured, and the space in
which the metric function will operate.
Today’s software applications are more complex
and software failure more critical, potentially result-
ing in economic damage or even threatening the
health or lives of human beings (Basili, 1987). De-
spite the evolution and advance of methods and
tools of design, programming, testing, debugging,
and project management, software engineering is
still more craft than science.
The software industry faces serious problems in
software project management, because it is difficult
to control what cannot be measured. The principal
problems come from the most important character-
istic of software: software is not a physical object but
an intellectual one; its components are hidden, its
interfaces and connections are obscure.
Then, the most fundamental question is “how big
is a program?” But first we must define what “big”
means, at least by comparing one program to an-
other to find out the difference of effort invested.
“Size” is not obvious for software. Metrics must be
objective in the sense that the measurement process
will yield the same result no matter who applies it
(Beizer, 1990).
We can identify seven sources of software com-
plexity. Their correlation and interdependence de-
0164-1212/95/$9.50
SSDI 0164-1212(94)00126-8
18 J. SYSTEMS SOFTWARE
1995; 29~17-31
termine the level of complexity in a software product
(Figure 11, although most metrics measure only one
software complexity factor. Using statistical factors
analysis, researchers have found a huge amount of
common variance among internal complexity met-
rics, such as Halstead software science metric, state-
ment counts, the McCabe cyclomatic number, logi-
cal depth, etc. (Munson and Khoshgoftaar, 1992).
Sixteen metrics selected in this study have been
reduced to five complexity domains: control struc-
ture, size of code, information content, modularity,
and data structure.
This fact would suggest that the software compo-
nents’ size is the primary aspect assessed through
the technical and operational dimensions of many
metrics. As Curtis (1987) pointed out, “the perva-
siveness of the effect of size on software metrics has
made it difficult for most studies to demonstrate that
metrics perform better than lines of code in predict-
ing many criteria.”
Other types of metrics include those called “de-
sign metrics” (Henry and Selig, 1990; Szulewsky
et al., 19841, which measure external software com-
plexity; that is, the level of module coupling using
the control and data connection between system
modules. These metrics were developed from primi-
tive design metrics that are predictive, objective, and
automatable (Zage et al., 1992). But, when describ-
ing the complexity of a software system, we must
take into account both internal complexity of each
Figure 1. Different sources of software complexity.
R. R. Gonzalez
module and external complexity due to module in-
terrelationships (Lew et al., 1988).
2. SOME CONSIDERATIONS FOR BUILDING
A METRIC
From a mathematical perspective a metric is a func-
tion that takes two arguments from certain domains
or spaces and whose returned value represents a
difference between the two arguments. However,
software complexity measurements, often called
“metrics,” are functions that take one argument
whose returned value represents a measurement of
certain aspects of the single argument (Ramamurthy
and Melton, 1988). These measurements are ordinal
quantities of software complexity. By ordinal, we
mean that the metric is intended to order programs
in relation to their complexity, but no conclusions
can be drawn as to the “distance” between two
measures or values (Harrison, 1992).
In this sense, most metrics are incomplete be-
cause they measure only one factor of program
complexity, in spite of a program having different
sources of complexity. The best metric measures the
major quantity of these complexities’ factors to tell
more about the program and to explain better its
complexity. In other cases of looking for this objec-
tive, many metrics are simple linear compounds of
others metrics. Nevertheless, the sum of two or
more measures does not necessarily offer additional
information about program complexity (Munson and
Khoshgoftaar, 1992).
Statistical measurements, such as arithmetic mean,
variance, and covariance, are indicators of certain
relationships among factors, but they are not metrics
in a strict mathematical sense. They tell us some-
thing about certain common characteristics, factor
correlation, and interdependence with some proba-
bility measurement error. However, certain statisti-
cal methods are useful for estimating internal soft-
ware complexity from the software design, a critical
aspect of software project management.
To solve this problem, we attempted to build a
unified software complexity metric that takes into
account the different domains, dimensions, and fac-
tors of software size. This complexity metric must be
useful in three ways: (1) to provide a measurement
that allows comparison of the relative complexity of
two different programs; (2) to take two valves from
an argument and return a measurement of distance
or variation between the two arguments; and (3) to
obtain an indirect measure to estimate and predict
the productivity of the people in software projects
A Unified Metric of Software Complexity J. SYSTEMS SOFTWARE 19
1995; 29~17-37

and the reliability, performance, quality, and value
of the software product.
3. THE DOMAINS AND MAGNITUDE
OF SOFTWARE COMPLEXITY
3.1 Programs and Chunks
Consider a computer program as a combinatorial
activity whose components may be represented as
finite discrete mathematical structures, specially di-
rected graphs, and trees. A directed graph G =
(V, A, cp) consists of a nonempty set V of nodes, a
set of arcs, and a function q from A to the Carte-
sian set I’ x V, so that cp(a) = (u, v), where a E A
and (u, u) E V x I/. A tree is a connected graph
with no cycles. A rooted tree is a directed graph with
a distinct node LI,,such that all nodes are accessible
from c0 (Fisher, 1977). The basic logical structures
are defined by structured programming (sequence,
decision, and iteration) following its purpose of con-
trol complexity through theory and discipline (Mills,
1972). As Dijkstra et al. (1970) argued, “the art of
programming is the art of organizing complexity by
mean of structures.” Figure 2 shows the PASCAL
code of the algorithm to merge two ordered lists as
an example of a program using structured program-
ming.
In this sense, a program can be split into elemen-
tal objects or blocks called chunks, which constitute
an ordered set M = {M,, M2, . . . , Mk}. A chunk is a
sequence of one or more adjacent program state-
ments Mi = {zi, zi+ 1,. . . , zi+,J with the property
that there is no explicit transfer of control to any
statement in the sequence other than zi (Davis and
LeBlanc, 1988). That is, whenever the first statement
of the block is executed, the other statements are
executed in a given order (Weyuker, 1988).
If the program was made by use of structured
programming rules, then zi is the decision point
(ifthenelse, dowhile, or dountil) with transfer of con-
trol in implicit form, or a null statement when the

C:\compiler\pascal>type program.prg

Procedure Merge (Var A, B, C: Array of Integer; m, n:

Integer 1
Var Indexa, Indexb, Indexc, k: Integer;

Begin
Indexa := 1;
Indexb := 1;
Indexc := 1;
While (Indexa <= n and Indexb <= m] do
Begin
If A[Indexa] < B[Indexb] then
Begin
C[Indexcl := A[Indexa];
Indexa := Indexa + 1
End
Else
Begin
Figure 2. Algorithm to merge sorted lists. C[Indexc] := B[Indexb];
Indexb := Indexb + 1
End;
Indexc := Indexc + 1
End; If Indexa > n then
For k = 0 to (m - Indexb) do
Begin
Indexc := Indexc + k;
Indexb := Indexb + k;
C[Indexcl := B[Indexb]
End
Else
For k = 0 to (n - Indexa) do
Begin
Indexc := Indexc + k;
Indexa := Indexa + k;
C[Indexc] := A[Indexa]
End;
End.
20 J. SYSTEMS SOFTWARE
1995; 2917-37
block is a sequence structure. Chunks may contain
other chunks conforming logical nested structures
produced by a stepwise refinement process. In a
nested logical structure, a chunk containing a se-
quence of instructions where zi is the only decision
point is called a teminal chunk. Figure 3 shows the
control flow chart for the program example shown in
Figure 2.
Another important aspect is that the available
evidence strongly suggests that programmers do not
understand programs on a character-by-character or
symbol basis, as suggested by many metrics
(Halstead, 1975). Rather, they assimilate groups of
statements, which have a common function repre-
sented by chunks (Davis and LeBlanc, 1988). From
an operational point of view, these groups of state-
ments make up the execution units of the program;
from a functional point of view, they are the trans-
formation units of input messages in output mes-
sages, and, from a syntactical point of view, they are
the basic objects of the program .handled by the
logical structures of control.
I M
M2
M3
Figure 3. Flow chart of merging sorted lists algorithm M.
R. R. Gonzalez
3.2 Software Complexity
We define software complexity as a measurement of
the resources that must be expended in developing,
testing, debugging, maintenance, user training, oper-
ation, and correction of software products
(Shooman, 1983). The complexity is a property of
the software life cycle, but by measuring the pro-
gram properties as a final product of the develop-
ment process, we might infer the level of complexity
in a software system.
This complexity depends on (1) the nature of the
problem itself, (2) the number of objects created in
the design of the solution (functional modules and
data structures), (3) the interfaces and relationships
among objects, (4) the algorithmic and logical struc-
ture of the programs, (5) methods and tools used in
the development of solutions, (6) programming lan-
guages used to implement solutions, (7) the level of
human expertise involved in the development pro-
cess, (8) the computer hardware and software envi-
ronment, (9) project organization, and (10) project
management.
When we think about computer problems, we see
the software solution not only in one layer but in
several parallel layers or domains, as is suggested in
Section 3.1. These domains have certain degree of
relationship and interdependence, because the same
components of the program play distinct roles in
different domains. This idea may be a powerful tool
in connecting the static text of a program with the
dynamic process it invokes in execution (Mills, 1972).
In this context, a program may be conceived in
three fundamental complexity domains: syntactical,
functional, and computational. Each has three mag-
nitudes itself: length, time, and level. That is similar
to fundamental physical standard magnitudes of
length, time, and mass. Thus, we are facing a multi-
dimensional problem of software complexity
(Figure 4).
Each domain has ordinal measurements in terms
of information content that are based on the en-
tropy of the different magnitudes in order to build a
metric. Using these ideas, in Figure 5 I suggest a
taxonomy of software complexity; the measurements
of factors are explained in the following sections.
3.3 Syntactical Complexity Domain
Program syntax is the structure of an algorithm
represented by program texts in a static way
(Dijkstra et al., 1970). In fact, we define the syntax as
the set of rules or formulas that defines the set of
sentences. The syntactical structure is therefore al-
A Unified Metric of Software Complexity
ways considered auxiliary to a higher purpose in
program specification and coding.
Then, we can represent the syntactical structure
of a program as a context-free grammar g = (V,,
V,, p, M), where V, is a set of chunks as variables
or nonterminal symbols, V, is the set of elemental
instructions or terminal chunks as terminal symbols,
p is the combination of logical control structure as
production rules, and M is the start symbol or
program (Hopcroft and Ullman, 1969). From this
perspective, it is also possible to represent a pro-
gram via Buckus-Nuurform (BNF) notation, as shown
in Figure 6.
Using this definition, we can represent the pro-
gram syntax structure by use of a derivation tree,
also called abstract syntax trees GT = (V, A, q+),
where V = VT u V , and A is the set of arcs such
that
1. cp,(root) = M
2. &ode of outdegree 0) E VT
3. For any node u E V, if the set of immediate
successors of v is nonempty and ordered
v u . . . > vk, then (Pj-(U) + (Pr(U,)
cp:; VJ’. . . cpT(vk) is a production of g (Fisher,
1977). VN is the set of nonterminal chunks or the
internal nodes in the tree, and Vr the leaves,
terminal symbols, or terminal chunks.
This idea is represented in Figure 7.
A controlflow graph G, = (V,, A,, cp,) represents
the logical dependence sequence among chunks.
I 4
Figure 4. Software complexity domains and dimensions.
J. SYSTEMS SOFTWARE 21
1995; 29:17-37
Nodes in V, are terminal chunks, and arcs in A, are
the control paths. Each path is weighted by the
Boolean function of the decisional path
P(X,, x2,. . ., x,,) = x, A x2 A . . . A x,, constituted
by the conjunction of different predicates xi or
decision points, from the root node to the leaf or
terminal chunk in the syntax tree Gr (Figure 8).
Program M has five Boolean functions:
. P” =.x0,
l p, = (x1 A x2) A (X,)
l P2 = (x, A x2)
l P3 = (x, A x5)
l P4 = (x4 A xc)
where x0 = T, x1 = (indexa < n), x2 = (indexb <
m), x3 = (A[indexa] < B[indexb]), x4 = (indexa > n),
X 5 = (0 5 k 5 (m - indexb)), x6 = (0 s k I (n -
indexa)), and xi E {T, F}. Figure 8 shows the control
flow graph and the Boolean functions associated
with each control path. Each pi in G, represents the
logical decision point of the terminal chunk and is
considered as part of the chunk instructions.
The magnitudes of the syntactical domain are as
follows:
The decisional level (L) defines the logical com-
plexity of the program or nesting level and is repre-
sented by the binary tree of the Boolean function p
in disjunctive normal form. The nonterminal nodes
. Avntactical
22 J. SYSTEMS SOFIWARE R. R. Gonzalez
1995; 2917-37

Complexity Domain Complexity Factor Complexity

and Space or Magnitude Measurement
I
Code Length (Ss) - Linguistic information
Content (Ho)

Syntactical lime (Ts) - Linguistic information

Content (Ho)

Decisional Level (La) - Decisional information

Content (Hs)

Dam Chromatic Information

Content (HK)

I Software
Complexity c Cohesiveness FF) -
Structural information
Content (Hd

Functional Coupling (LF) - Structural information

Content (Hg)

Data Length (SC) Chromatic Information

Content (HK)
Computational (EC) Algorithmic Time (Tc) Computational informetion
Content (HQ
I
* Data Hierarchical Level (k) -+Structurai information
Content (Hg)

Figure 5. Taxonomy of software complexity.

in the tree are the logical expressions or predicates
of p, and the leaves or terminal nodes are the
logical values, false or true, of the elemental predi-
cates. The depth of the tree is the length of the
maximum logical path of logical expressions, which
is the logical level of the chunk in the syntactical
structure of the program. Figure 9a shows the pi
binary tree.
Syntactical time CT>is defined by the abstract syn-
tax of a chunk that identifies the meaningful compo-
nents of each syntactical construct or expressions.
An abstract syntax tree represents the components
and subcomponents of the construct. Nonterminal
nodes in the tree are operators, and the leaves or
terminal nodes are the operands (Sethi, 1989). The
Code length 6) is the quantity of code contained
in the terminal chunks based on properties of pro-
gram or specification text without interpreting the
text or ordering of components of the text in chunks.
It is conformed by different operands and operators
of the terminal chunk, that is, the syntax expressions
of decision points and the basic chunk instructions
alike in syntactical time. These are represented by
every node in the abstract syntax tree as shown in
Figure 9b. This magnitude also represents the ab-
stract level of programming language, and so is also
termed linguistic complexity (Beizer, 1990).
3.4 Functional Complexity Domain

operators represent logical time consumption in the
terminal chunks viewed as units of time in the
syntactical expressions, that is, arithmetic operators,
control operators, logical operators, input and out-
put operators, call operators, and functions.
Figure 9b shows the abstract syntax tree for the
while and if instructions in chunk M,, which are
considered decisional point instructions as part of
terminal chunks Mz2, Mzll, and Mz12.
In this domain, we abstract the commonly known
idea of computer program, the “. . . finite set of
functions, called instructions (or module), each with
a finite domain contained in a common set, called
the data space, and a finite range contained in the
Cartesian product of the data space and the pro-
gram, called state space” (Mills, 1972).
The syntactical domain concerns logical structure
and text quantity of chunks, but not relationships
A Unified Metric of Software Complexity J. SYSTEMS SOFIWARE 23
1995: 29~17-37

0 =
M
0 M3

0 =
Ml Zll 212 z13

0M2 = @I @ 1

0M21 = Q&JIG

M211 z 2111 z 2112

o=

M212 22121 22122

o-

0M22 = 2221

0M3 = @I@ Figure 8. Control flow graph G, of G,.

0M31 = C@J
context, data variables acquire a meaningful or se-
z 3111 z 3112 z 3113 mantic interest from the point of view of the module
function, and these take certain values from a de-

0M32 = @I
fined set or data space. This is why it is considered
in a higher level of software design.
The functional program process is constituted of
transformation paths. Each execution path has dif-
23211 z3212 23213
ferent transformation functions, which transform the
input message into an output message (Lew et al.,
Figure 6. BNF notation for program M.
1988). From this abstract point of view of a chunk or
module, interaction and complexity can be charac-
among the chunks. The data variables, for example, terized in terms of information content of a message
are simple logical formalisms of a syntactical struc- passed to the chunk, called chunk coupling, and the
ture. In the functional domain,_ the connections information content of the internal relationships
among chunks are based on the interchange and among the instructions that transform the input
transformation of data and control variables. In this message into an output message, called chunk cohe-
sion.
The magnitudes of functional domains are as fol-
lows:
Functional coupling (L), the logical functional level
of the chunk, measures the complexity produced by
the different input execution paths coming in a
chunk in control flow graph Go. It makes up a
subcontrol flow graph in which the terminal chunk is
in the last position. There is one subcontrol flow
graph per terminal chunk (Figure 10).
Data coupling 6) represents the quantity of infor-
mation handled by a chunk due to the number of
different fields coming in from other chunks and
Figure 7. Syntax tree Gr of program M. going out to other ones, global variables, and data
24 J. SYSTEMS SOFTWARE R. R. Gonzalez
1995; 29:17-37

Gc 2 1 2 8 GC3 2 1 +

h= de pt h of t he t re e

(4

6 Mm

Figure 10. Different subcontrol flow graphs for G,.

connecting two instructions, and cp the assigning

function of arcs to pairs of instructions (Figure 12).

3.5 Computational Complexity Domain

As Wirth (1976) pointed out, “programs, after all,
are concrete formulations of abstract algorithms
(b)
Figure 9. (a) Decisional binary tree of a Boolean function
in G,. (b) Abstract syntax tree for whiZe and if.

structure attributes. The set of modules

or functions
are the functional transformation processes repre-
sented as data flow graphs Gf = (Vr, Af, cp>; the
nodes in Vr are the terminal chunks and the global
data, the arcs in Af are the input and output
messages, and q(a) = (ui, uj>, . a E Af and ui, Vj E
VT (Figure 11).
Cohesiveness (T) is the degree of interaction among
instructions within a chunk. Two instructions have
temporal dependence if the assigning variable or
arguments of the first appears in the expression of
the second. In other words, there is an order of
predecessor-successor in time. Boolean function pi
is viewed as part of chunk instructions; the relation-
ship with the other ones is given by its arguments. w he re
We can represent these relations by use of a struc- di a re da t a st ruc t ure a t t ribut e s a nd
Di a re c ont rol a nd da t a inform a t ion.
tural flow graph G, = (2, A,, 401, where Z is the
ordered set of instructions in the chunk, A, the arcs Figure 11. Data flow graph Cr.
A Unified Metric of Software Complexity J. SYSTEMS SOFIWAKE 25
1995: 29:17-31

time and space: input and output access, size of data

structures, type of traveling on the data structure,
and the execution frequency of instructions needed
0Zll 0 P2
to produce new information or data elements. Con-
sequently, this domain is oriented to software per-
0ZIZ
0 Z221 formance or computational efficiency in the opera-
tional context.
0213 Data structures can be represented by a graph
Cd = (V,, A,, cp), where V, is the set of nodes or
data entities and A, the set of arcs representing the
relationship between nodes or groups of data fields,
such as hierarchical data structure or data relational
model represented in canonical form (Figure 13). A
complex data structure could result in greater de-
pendence between modules because we need more
information to describe the data structure. As an
algorithm is represented by a control flow graph G,,
it travels through the data structures flow graph Cd
following the order of execution control.
Figure 12. Structural flow graphs for instructions of a The three magnitudes of the computational do-
chunk. main are as follows:
The data hierarchical level (L) is the depth of the
data structure represented by the number of differ-
ent paths and the level of data node dependence in
based on particular representations and structures
the data flow graph Cd as a measure of the data
of data.. . . Decisions about structuring data cannot
structure complexity. We need to make more logical
be made without knowledge of the algorithms ap-
and computational decisions to locate a data ele-
plied to the data and that, vice versa, the structure
ment in a data space when the number of data
and choice of algorithms often strongly depend from
relations grows. The hierarchical level of a linear
the structure of the underlying data.”
array, for example, is two; the elements of the array
The computational domain of programs explains
are in the first level and the data type in the second
the consumption of computer resources in terms of
level.
Data length 6) is the degree of data nodes in a
data structure and is equal to the number of arcs
coming in and going out of the data nodes in Cd.
riGizq k Array 1 Therefore, for a data structure graph, the degree of
Data a node represents the number of different fields or
X A
type 0 attributes used by the chunk traveling by different
Data levels of the data hierarchy or different attributes
type
8 used to fetch a particular data entity or data field
group.
Algotithmic time (T) is the amount of work done,
measured by some specific complexity measurement,
which is the number of specified basic operations
performed in the execution of a program (Baase,
1988). Each terminal chunk in a control flow graph
has a computational complexity. It is the time ex-
pended in making the decision, using B function, to
execute basic chunk instructions and the time in-
vested in the execution of these instruction via a
data structure G, of IZ elements or entities. The
complexity is represented by a function f(n) of
Figure 13. Data structure graphs G,. worst-case behavior of the chunk’s algorithm.
26 J. SYSTEMS SOFTWARE R. R. Gonzalez
1995; 29~17-31

4. ENTROPY AS MEASURE OF SOFTWARE sents the magnitudes in three dimensions (length,

COMPLEXITY
4.1 Software Information Content
If we see a program as a discrete information pro-
cess, then we can represent it as a Markov process.
Then it is possible to define a quantity that will
measure, in some sense, how much information is
produced by such a process (Shannon, 1948).
Entropy is a measurement of this class used to
adapt the theoretical notion of measure of uncer-
tainty or variety in certain phenomena. Suppose we
have E = (S, F, P) as an experiment, where S =
{A,, A,, * * *, A,} is a set of elementary events, F is
Bore1 field over S, and P(A,) = pi is a function
assigning real value (0 I pi 5 1, i = 1,2,. . . , n) to
events Aj. Then the entropy of the experiment E is
applied to a finite sample of arbitrary elements of IZ
distinct types, termed entropy classes; the entropy
associated with that sample can be calculated by use
of relative frequencies or number of occurrences in
a particular class as unbiased estimates of their
probabilities pi (Davis and LeBlanc, 1988).
Then,
H = - i Pr 1% P, (1)
r=l
is the entropy value or information content for the
experiment E.
Each event is associated with an object or compo-
nent of the program (chunks, execution paths, data
paths). Entropy is used to measure the information
content of the variety of three aspects of chunks and
data structures in a program: the structure of chunks
and data connections, chunk and data content, and
chunk and data size.
The quantity of decisions taken to solve a problem
concerns the information content of the problem. In
other words, the quantity of decisions is directly
proportional to the problem complexity, that is, the
uncertainty grows when the level of logical decisions
grows.
time, and level) of the terminal chunk i in a particu-
lar domain (syntactical, functional, or computa-
tional) of the program M in the ordering of control
flow graph G,. The vector ei E H3, where H3 is a
three-dimensional space over H, which is the set of
information entropy values.
We define the norm of the vector ei over vector
space E in H, written
IleJl: E + H
which represents the length of the complexity vector
ei or the information content of the chunk i.
The set (E, Ml) is called the complexity vector
space with inner product (Lipschutz, 1970). Then, we
can induce from the norm Ilell, llei - ei+lll, called
the metric over E or distance from e, to ej+ 1,
defined by d: E --, H and represented by the euclid-
ian norm
d(e,, ei+ 1)
= J(Si- si+ 1 y + (ti - tj+J2 + (li - li+lj2 (2)
where d is the amount of information content
needed to produce chunk Mi+ 1 after chunk Iwi, in
the order of control flow graph G, in a particular
domain.
We define the “effort” required to lift some vecto-
rial magnitude lIeill up to some height or level in a
metric space by use of the Newton’s work law as
W= F-DecosO (3)
where W is the effort value, F = lIeill is the force
applied through the distance D, D = Li is the height
or level, and 8 is the vectorial angle formed by the
application of the force. Figure 14 represents the

5. THREE METRIC SPACES FOR THE

THREE DOMAINS

5.1 Definition of Metric Spaces

I define ordinal measures or entropy functions to
the different magnitudes of each domain to obtain a
new space called complexity vector space E with S,
T, and L as variables. The elements of E are called
complexity vectors ei = (si, ti, li), where ei repre- Figure 14. Complexity vectors in E.
A Unified Metric of Software Complexity J. SYSTEMS SOFTWARE 27
1995; 29:17-37

components of a complexity vector in a particular
vectorial space.
By the Euclidean triangular relation among vector
components in Figure 14, we obtain
By substituting equation (4) in equation (31, we
obtain the following efsort equation to the chunk i in
the specific vector space E:
Then, the total effort needed to produce the pro-
gram M is
program M: decisional level, code length, and syn-
tactical time.
S, is the displacement of the chunk in terms of
the linguistic information content as a measurement
of the quantity of code in programs. In Appendix 1,
we obtain the entropy expression H, in formula Al,
which estimates the value of code length for a chunk.
This value depends on the number of different oper-
ators (n,,) and operands (n,,) and its occurrences
viewed as entropy classes. Table 1 shows the occur-
rence of symbols per chunk of program M, and the
values of H&z,r + ns2) are shown in Table 2. The
chunk position is the displacement in relation to the
predecessor chunk in the ordering of control flow
graph G,,

Chunk M, has H,,,(5) = 2.113 = S,, and chunk Mzll

5.2 Syntactical Vector Space E,
Vector complexity space E, is a compound
of vectors esi = (ssi, tsi, lsi> so that
e s2, ...,esm}c E, is an ordered set that
the values of syntax factors o terminal
has H02r1(16) = 3.768; applying formula 7 yields
S S211 = 2.113 + 3.768 = 5.881. Table 2 contains the
values of S, of the chunks in M.
of the set T, is the syntactical time entropy based on linguis-
M, = {e,,, tic information content, like in S,, which measures
represents the quantity of time in terms of the different opera-
chunks in tors (n,,) in chunk i, as explained in Section 3.3. It is

Table 1. Occurrence of Symbols per Chunk in Program M

Frequency per Chunk
Type of
Symbols M 211 M212 M22 M 311 M321

Operands (n,,)
n 1 1 1 2
m 1 1 1
3 3
1 5 1 5
1 2 4
2 3 3
1
1
1

0
Operators (n,y2)
While
For
If

>
<
I
and
:=
t
_
Totals
n,, 4 9 9 2 9 I
ns2 1 7 7 2 I I
N,l 6 15 15 3 16 16
42 3 9 9 2 10 10
28 J. SYSTEMS SOFTWARE R. R. Gonzalez
1995; 29~17-37

Table 2. Syntactical Complexity Values

Types of Types of Boolean Nodes per
Terminal Operands Operators Function Classes in
Chunks n,1 ns2 P P mn,, + n,,) s, lIesill W,i

Ml 4 1 PO 1 2.113 2.113 0.000 0.000 2.113 0.000

M 211 9 7 Pl 1,2,4,4 3.768 5.881 2.725 1.823 6.733 11.816
M 212 9 7 Pl L&4,4 3.768 9.649 2.725 1.823 10.191 18.278
M22 2 2 P2 AT4 1.922 11.571 1.000 1.379 11.696 16.016
M 311 9 7 P3 1,2,4 3.767 15.338 2.646 1.379 15.626 21.464
M 321 7 7 P4 1,2,4 3.551 18.889 2.646 1.379 19.123 26.302
--
65.482 93.876
IlMllJ IlMllse

obtained by applying the expression H&r,,) in Ap-
pendix 1. Table 1 shows the occurrence of operator
symbols, and Table 2 shows the values of informa-
tion content of syntactical time of chunks in pro-
gram M.
L, is the entropy or information content of the
syntax decision level, and it measures the uncer-
tainty of a particular logical value in a predicate as
Boolean function /3 given a set of possible values.
As pointed out in Section 3.3, a Boolean function
may be represented by a binary decision tree (Figure
9). The nodes in the levels of decision of the tree
represent entropy classes used to obtain the value of
entropy by applying the definition of a probability
function (Appendix 3). Table 3 shows the values of
L, derived by use of formula A8 (Appendix 3), which
are the entropy values or decisional information
contents of chunks.
Thus, a chunk in E, is defined by esi, and the
expression
IIMlls = EIle,,lI
i=l
is the sum of vectorial magnitudes that represents
the syntax information entropy volume of the pro-
gram M.
IlMllse = g L,, . Jiq q
I=1
is the total syntactical entropy effort derived by use
of equation 6.
Table 2 shows these entropy values and magni-
tudes for the terminal chunks of program M in the
vectorial space Es.
5.3 Functional Vector Space E,
Vector complexity space Ef is the set of vectors
efi = (sfi, tfi, lfi)sMf c Ef that represents the func-
tional factors of chunks: functional cohesion, data
coupling, and functional coupling.
Sf is the functional chunk position. Because the
chromatic information content H, measures the de-
gree of a node in a graph, it can be used to measure
the information content due to the number of fields
in a data flow graph or data coupling in chunks (Lew
et al., 1988). In Appendix 5, we explain the concepts
of chromatic information content measurement. We
have proved that the maximum chromatic entropy
for a node is 2, based on the fact that it is possible to
(8)
represent the elements (coming in or going out) in
nodes by use of four colors at the most as entropy
classes.
The functional chunk position is given by its data
length and the displacement in relation to the posi-
tion of the predecessor chunk in the ordering given
by the control flow graph G,:
(9)
Sf; = Hq + Sf,,-,, (10)

Table 3. Functional Complexity Values

Data Arcs Chromatic Structural Instructions Structural
Terminal per Classes Chunks Classes per Chunk Classes
Chunks Chunk k per G, of G, in Gi of G, H,(k) S, Ht%iJ H<;b c ) IIe ,c iII WF,
Ml 3 1,Ll 1 1 3 3 1.585 1.585 0.000 0.000 1.585 0.000
M 211 8 494 2 171 3 Ll, 1 1.000 2.585 1.585 1.000 3.193 3.032
M 212 8 474 2 1,l 3 1,1,l 1.000 3.585 1.585 1.000 4.045 3.920
M22 1 1 4 1,2,1 2 171 o.OOfl 3.585 1.000 1.500 4.013 3.886
M 311 7 3,391 5 1,2,1,1 4 371 1.449 5.034 0.811 1.922 5.449 9.800
M 321 7 3,391 5 1,2,1,1 4 391 1.449 6.483 0.811 1.922 6.810 12.557
--
25.095 33.195
IIMIIF IlMll~e
A Unified Metric of Software Complexity
where HJn,,) is the value of chromatic information
content of the chunks coupling i with nfs data fields
coming in and going out.
In the example shown in Figure 2, chunk Iw, has
three data fields going out, so we use three different
colors as entropy classes, then apply formula 5.1
(Appendix V): H,,(3) = -3/3 (log l/3) = 1.585.
Because chunk M2,, has eight data fields,
HKZ1,(8) = -2(4/S log4/8) = 1.000 with two colors
used as minimum entropy classes. Then Sri = 1.585
+ 1.00 = 2.585 is the functional position of the
chunk MI, ,. Table 3 shows the values of Sr derived
by applying formula 10.
L, measures the level of uncertainty from select-
ing between a set of possible paths in control flow
graph G,. The notion of structural information con-
tent explains that the larger the number of nodes in
a class or orbit, the greater the uncertainty that a
particular realization is selected (Lew et al., 1988).
In Appendix 2, we explain the theoretical bases of
the structural entropy. Table 3 contains the value of
Lf derived by use of formula A2.
T[ is the degree of interaction among instructions
or temporal dependence in a chunk as a measure-
ment of cohesiveness. I have represented this rela-
tion by use of a structural flow graph G, in Figure
12, which shows the relationship between instruc-
tions within a chunk. As in Lf, structural informa-
tion content measures the entropy or uncertainty of
this order by mean of orbits as entropy classes of the
instructions’ dependence, as explained in Section
3.4. Table 3 shows the values of Tf by applying
formula 2.1 (Appendix 2).
IIMIIF= t Ile ,,ll (11)
1= I
is the sum of the vectorial magnitudes and repre-
sents the functional Jyntax entropy volume of the
program M.
IIMllFr = 5 L,, . &g iq (12)
I= I
is the totalfinctional entropy effort, derived by use of
effort equation 6.
Table 3 shows these entropy values for the pro-
gram example shown in Figure 2 in vectorial space
E.,.
5.4 Computational Vector Space E,
Vector complexity space is composed of the vectors
eci = (s C,)t C1)1CI) 7which represent the computational
factors of chunks: data length, algorithmic time, and
data structure hierarchical level of chunks.
J. SYSTEMS SOFIWARE 29
1995; 29:17-37
S, represents, in a data structure graph, the de-
gree of a node or the number of different fields in
the data structure, located by the displacement in
the order of the control flow graph. As with data
coupling, we use chromatic information content
H,(n,,) as a measure of entropy or uncertainty,
where n,, is the number of data fields used as input
and output in the data node of the data structure
graph Gd.
SC,= HK,+ s+,, (13)
is the positional equation for each chunk in M.
T, is the time expended in making the decision to
execute the terminal chunk instructions in a particu-
lar execution path. Time is measured by computa-
tional information content, which is the quantity of
information needed to represent the decisional time
consumption.
In Appendix 4, we show that algorithmic complex-
ity may be represented by a decisional tree and, as
with syntactical decisional information content, its
entropy or information content is an asymptote
function bounded by 2. Using this conclusion, we
obtain the values of information content of a typical
function of algorithm complexity shown in Table Al.
L, uses structural information content as a mea-
surement of the number of hierarchical levels of
data dependence. Its value increases as the number
of dependent nodes increases in the data structure
Gd and, in the computational domain, represents the
level of uncertainty in making the decision to locate
a data entity in a data space (Appendix 2). For
example, in an array data structure there are two
levels of decision; then, HC = -2(lj2log l/2) =
1.000 is the information content; in a graph, data
structure is the number of data nodes in different
data paths, and its orbits are entropy classes.
The expression
IIMII, = E lie,, (14)
!=I
represents the computational information content uol-
ume. Using equation 6, we obtain
IlMllc e= 5 L,, . &Fq (15)
I= 1
which is the total computational entropy effort value.
Table 4 shows the computational entropy values of
chunks in the program M.
6. A UNIFIED METRIC AS MEASUREMENT
OF WHOLE COMPLEXITY
We have defined E, as syntactical vector space, Es.
as functional vector space, and E, as computational
30 J. SYSTEMS SOFTWARE R. R. Gonzalez
1995: 29~17-31

Table 4. Computational Complexity Values

Data Chromatic Complexity Data
Terminal Fields per Classes Function Hierarchy
Chunks Chunk k f DL H,(K) S, H$f) llecill wci
Ml 3 1, 1,1 1 l(3) 1.585 1.585 1.479 0.000 2.168 0.000
M 211 8 494 n 2(4) l(2) 1.000 2.585 1.643 4.000 5.038 12.252
A4212 8 494 2(4) l(2) 1.ooo 3.585 1.643 4.000 5.617 15.774
f’422 1 1 2nn- 1 l(l) 0.000 3.585 1.655 0.000 3.944 0.000
M311 8 4,4 n 2(2) l(5) 1.000 4.585 1.643 2.000 5.265 9.741
M 321 8 494 n 2(2) l(5) 1.000 5.585 1.643 2.000 6.156
~-
11.643
28.188 49.410
IlMllc IMIc e

vector space, each in H3, where Z-Z3is a three-linear the metric over E or distance from ei to ei+ I,
vector entropy space. But to obtain a metric that defined by
takes into account all the software complexity fac-
II@(e,i, ef,, eCi) - @(esi+l,efi+l, eci+,)II
tors together, we need to build a unified space of
software complexities. This space is a multilinear = ll@(esi - es,+,, ef, - ef,+,, e, - ecc+)ll
combination of the three complexity spaces, and
=Idet(M,,+l - M,,)I (19)
over this new space we define a new complexity
metric. Then, Es x Ef X E, is called a three-linear which is the total amount of information content
entropy space. Let @ be a map defined by needed to produce chunk Mi+ I after chunk Mi, in
@:E,xEfxE,-+H the ordering of control flow graph G,. Thus

so that IlMlb = E II@ill = E IIWesi, ef,, e,,)II

i=l i=l
Ne,, + es*, ef, e,) = Wesl, ef, e,) + @(e,z, er, e,) (16)
We,, ef, + er,, e,) = Ne,, ef,, e,) + We,, efi, e,) = t ldet04,i)l (20)
I= 1
@(es, ef, eC1+ eC2)= We,, ef, e,,) + We,, ef, eCZ) is the total tensoriul entropy volume and
@Cc.e,, ef, e,) = c.Nesr ef, eJ,
11~11~= 5 II@(esi,ef,,eJ - ~(esi_,,efi_,,e,i_,)II (21)
@(e,,c.e,, e,) = c.We,, ef, eJ, i=l

We,, ef, c.e,) = c.Ne,, e2, e,> is the total entropy effort needed to produce the
program M. These metrics are termed uniJied soft-
@ is a three-linear form over H, or a three-couatiunt
tensor over H. The set of three-covariant tensors
over H we term T,(H), which also is a vector space
over H. If we define a 3 x 3 matrix A4, composed of L
Es x Er x EC
the three complexity vectors of the chunk iVi in Es, t
Ef, and EC as the rows of the matrix, then

We,, er, e,) = detO4,). (17)

It is possible to prove that @ is a three-covariant

tensor over H. Then
Il@Jl= II@(e,i,efi, e,)ll = IdetOQl (18)
is the tensorid norm that represents the unified
entropy of the terminal chunk Mi. Il@illis the infor-
mation content volume (tensotiul complexity volume),
because det function is the volume of parallelepiped
in a three-dimensional vector space represented in
Figure 15 (Mostow and Sampson, 1969).
The set (T,(H), lI@Il>is called complaity multilin-
ear space. Then, we can induce, from the norm 11@11,
J T

Figure 15. Tensorial volume of chunk complexity.

A Unified Metric of Software Complexity .I. SYSTEMS SOFTWARE 31
1995; 29117-37

ware complexity metrics. Table 5 shows the complex- stochastic Markov chain. The likelihood function of
ity values derived by applying the unified metric to X1,X2,..., X,, is defined to be the joint density
program M. function

L(O) = L(O; x,, X*,. ..) X,),

7. APPLICATION OF THE UNIFIED
SOFTWARE METRIC which is considered a function of 0.
If 0” is the value of 0 in 0 that maximizes
7.1 The Best Estimator of Internal Complexity L(O), then O* = ~*(x,,x~,. . . , x,,) is the muximum-
likelihood estimator of 0 for the sample x,, x2, . . . , x,
Based on the concept of the unified software com- (Mood and Graybill, 1974), and it represents the
plexity metric, it is possible to build a statistical minimum complexity volume of the best program
estimator of the llMllT and )JMIIE. This estimator solution to the program M from the infinite space
from the external software design (functional and solution {g,, g,, g,, . . . I. O* Is the lower bound vol-
data structures design) is defined by the following ume of the software complexity for program M.
characteristics:

1. Data structure, control information, and data in-

formation in the design of modules can be used 7.2 Software Productivity Measurement
to estimate the number of chunks in a program, Productivity is concerned with the efficiency of the
the control structure (control flow graph), the resources consumed in producing a given application
data flow graph, and the nesting level of chunks. in a timely manner; as such, it ought not be ignored
in measuring system performance (Scudder and
Information content of the message should be pro-
Kucie, 1991). The principal question in productivity
portional to the uncertainty caused by the decision
is: what are the time and human and computer
statement. The order of magnitude of the informa-
resources to be invested in coding, testing, debug-
tion transferred to a module should be of the same
ging, integrating, and maintenance a program for a
order of magnitude as the cyclomatic number (Lew
quantity of software volume?
et al., 1988). The different combination of control
0 is the quantity of force needed to produce a
information, data information, and data structure
given software from the software design; it is similar
levels should be the same order of nesting level.
to the physics measurement of the work (Newton’s
2. The number and types of operators and operands laws) needed to do something. In this sense, this
as well as the level of language can be used as measurement is independent of the human agent
good estimators of code complexity and space. capacity to make the work. O* may be used to
3. The type of algorithm used in each module and estimate the productivity based in cognitive science
its type of complexity is a good estimator of theories that use the chunk concept to obtain a
computational complexity. measure of the human effort invested to produce a
software system (Miller, 1956; Coulter, 1983;
Let X,, X,, . . . , X,z be IZ random variables that Shneiderman, 1980; Woodfield, 1980).
represent the estimator factors listed in points l-3 Many researchers suggest that it is more difficult
above, and f be a statistical density function of the to develop, test, debug, and maintain programs with
program M derived from the fact that A4 is a deeply nested control structures than those with less
nesting (Belady, 1980; Jensen and Vairavan, 1985;
Harrison and Magel, 1981). Thus, the effort or intel-
Table 5. Values of So&are Complexity lectual work needed to produce a particular chunk
Using the Unified Metric or program is associated with the value IlMllr and
Terminal IIMIIE.
Chunks Idet(M,,)I We know that productivity depends on the ability
M, 0.000 0.000 and capacity of the staff to manage the tools and
M?II 6.764 12.506 methods used to develop a software project (Boehm,
M 212 16.393 0.000 1981). So we need to obtain the intellectual capacity,
ME 20.109 4.486
M 311 20.601 12.984 or intellectual power, of the project staff. This mea-
M x21 26.466 0.000 surement is used to estimate the total effort and
90.333 29.976 time needed to produce and implement a software
IlMllr IlMtiE
product, for example, the volume of software per
32 J. SYSTEMS SOFTWARE
1995: 29~17-37
person-month. Then, we can estimate the total cost
and time of software development.
7.3 Software Quality Measurement
Quality is judged indirectly by focusing on the effec-
tiveness and usefulness of the delivered system in
performing the task for which it was designed (Scud-
der and Kucie, 19911, in other words, how the system
is actually constructed and how it performs as op-
posed to how it should have been built and how it
should perform @need and Merey, 1985).
The components of software quality may be
grouped in two classes:
1. Functional components: usability, correctness,
maintainability, portability, reusability
2. Operational components: reliability, efficiency
and integrity
The functional components are qualitative charac-
teristics that depend on the technical specification of
the software environment (development tools, oper-
ating systems, data base management systems, lan-
guages, etc.) and from the design process. Nowadays,
with CASE and automated software quality assur-
ance tools, this task is more practical, more rapid,
and more automatic @need and Merey, 1985).
The operational components are quantitative char-
acteristics measured from the software execution.
The volume 0 of software is a measure of the
amount of information content needed to operate
the software in optimal way from the perspective of
functional components. In other words, if the design
is accomplished with the functional characteristics
and system requirements (design quality), 0 repre-
sents the quantitative measurement of the opera-
tional quality.
Quality is a virtue of design. The robustness of
software products is more a function of good design
than of on-line control, however stringent the devel-
opment processes. Most software products contain
perturbations of one class or other, usually the re-
sult of a faulty meshing of one component (object)
with corresponding components. Such performance
degradations may result either from something go-
ing wrong in the development process or from an
inherent failure in the design (Taguchi and Clausing,
1990).
We can obtain an index of software operational
quality by
0
R* = IlMllT
R. R. Gonzalez
which is called the robust software quality estimator:
the degree of approximation to the optimal software
solution.
7.4 Software Reliability Measurement
In software reliability, the quantity of code devel-
oped (volume), the number of instructions added or
modified is directly related to the quantity of faults
or coding errors introduced in the software (Muss,
1989). Other authors suggest that the number of
bugs are proportional to the number of decisions in
programs. In this sense, software reliability is strongly
influenced by the level of logical decisions
(Shooman, 1983). We suggest that program fault is
the overall result of total software complexity fac-
tors.
Faults are revealing as a program failure occurs
during the execution due to certain data events not
predicted in design or coding. The data event is a
time-independent random variable. However, the
most important software reliability models devel-
oped to date describe the mean numbers of failures
experienced as a function of time while software is
executed.
Software complexity metrics are related to the
statistical distribution of faults in program modules
(Khoshgoftar et al., 1992). It is assumed that control
of the software is transferred among the modules or
chunks according to a Markov process. Each module
(chunk) has an associated reliability that gives the
probability that the module will operate correctly
when called and will transfer control successfully
when finished (Siegrist, 1988).
The measure of reliability considered is the mean
number of transitions until failure, starting in a
designated initial state. It is possible to build a good
reliability model by use of the operational profile of
the program and assigning a probability distribution
based on the proportional distribution of chunk vol-
ume through the total entropy volume of the pro-
gram. That is because frequency of execution of a
chunk is not the only factor of software failure, but
also the quantity of information content in the
chunks of the program.
7.5 Software Value Measurement
Software value is a measurement of relationship
between effectiveness and the project cost. Effec-
tiveness is the ability to accomplish the overall in-
tended function for which the software was de-
signed. Maximum value is said to be the minimum
A Unified Metric of Software Complexity
number of dollars that must be expended to accom-
plish the desired function or performance. It should
be noted that quality is part of function (Pruett and
Hotard, 1984). Then the expression
represents software value, where C, is the total cost
of software, which is a measure of the software
performance in relation to the development cost.
APPENDIX 1: Linguistic information Content
As we explained in Section 3.3, we can represent the
abstract syntax of instructions in a program or chunk
using an abstract syntax tree, which shows the com-
ponents and subcomponents of the syntactical ex-
pressions. Nonterminal nodes in the tree are opera-
tors, and the leaves or terminal nodes are the
operands, called symbols or tokens of the expres-
sions. Taking each syntax tree of the different ex-
pressions, we obtain II symbols in a chunk or pro-
gram, and we classify the symbols by the occurrence
of different symbol types. If we assume there are t
symbol types in our sample of n tokens, then
I set of all possible permutations of 7~ in G, over G,,
n= En r
I= I
and the relative frequency is
This way, we obtain an empirical distribution of
symbols or tokens within a program or chunk
(Harrison, 19921, where t represents the number of
entropy classes, n, the number of symbols per class,
and f, the probability p, of the class r.
Then, the average amount of information con-
tributed by each symbol in a program is the entropy
function defined over pr:
I f
Ho = - c p, log p, = - c 5 log %
r= I r=l n
This equation represents the linguistic information
content of a program, module, or chunk with t
different symbols. This entropy value is also inter-
preted as the level of linguistic abstraction of a
program written in a particular language.
Table 1 contains the occurrence of symbols per
chunk in example program M. Chunk Mz2 contains
four types of symbols (two operands and two opera-
tors), five total symbols, and the frequency per sym-
bol or entropy classes are (2},{11, (11,111. Then,
HO = -(2/5.log 2/5 + l/5 log l/5 + l/5 log l/5
J. SYSTEMS SOFTWARE 33
1995: 29117-31
+ l/5 log l/5) = 1.922 is its linguistic information
content value.
APPENDIX 2: STRUCTURAL INFORMATION
CONTENT
Definition A2.1. We consider the control flow
graph G,(M) as the basic functional structure of a
program or a segment of a program, where M =
{M,, Mz, . . . , Mm) is the set of nodes or chunks in
G,. Then, it is possible to define a permutation as a
one-to-one function 7r from a subset of M onto
itself. We call all possible permutations over M S,
(Fisher, 1977).
In general, the image of each element under a
permutation rr can be realized by the description
1
M, M, ... M,,
(A21
n-(M,) a(MJ ... TTT(M,)
Definition A2.2. If we have a function r that
transforms G, onto itself, preserving the adjacen-
ties, then we say n is isomorphic. As S, c S, is the
then S, conforms a permutation group named G.
The number of elements in the permutation group
we call order of group or /G/.
Definition A2.3. Let g, and g, be elements in G,
then g,og, is the composition or product of permu-
tations. Suppose g is a permutation of G. We begin
with any M,sM in G, and write CM,, g&M,),
g,(M,), . . . , g,_ ,( M,)) where g,(M,) is the first repe-
tition of Mi. This sequence is called a cycle. Using
the concept in this manner, until all elements of M
occur in cycles with different cycles disjoint, we
obtain the cycle decomposition of G.
Definition A2.4. Let G be an isomorphic permuta-
(Al)
tion group on the set M. An element x in M is said
to be G equivalent to y in M if there exists g in G
such that g(x) = y. We write this x - y. G equiva-
lent is an equivalent relation on M because
it is a reflexive relation because G contains the
identity e(x) = x and for all x in M x N x;
it is symmetric because, if g(x) = y, then there
exists g-’ such that g-‘(y) = g-‘(g(x)) =
e(x) = x;
it is transitive because, if x N y and y 4 z, then
there exist g(.x) = y and h(y) = z, such that
(hog)(x) = h(g(x)) = h(y) = 2.
34 J. SYSTEMS SOFIWARE R. R. Gonzalez
1995; 29:17-37

cannot be permuted because we alter the control

Then, G equivalence partitions M into equivalence
classes called orbits of C.
Definition A2.5. The stabilizer of x in M is G, =
{g E E : g(x) = x}, thus G, c G that individually fix
x. In fact G, is a subgroup of G, because g, h E G,
implies g(x) =x so that (g&r-‘)(x) = g(/z-l(x)) =
g(x) = x and gh-’ E Gx. If C is a G-equivalent
class in M, then /G/ =/C/ /G,/ where x E C.
For any g in the permutation group G on M, let
the set of fixed points be F(g). Thus F(g) = (x f
M : g(x)x} and the number of G-equivalent classes
in M, by Burnside’s theorem (Fisher, 1977) is
(A3)
logic of the program, and nodes A&i and i&12
may be interchanged without altering the control
logic. Then, the information content is Hs =
-((2/5)log2/5 + 3(1/5)log l/5) = 1.922.
APPENDIX 3: Decisional Information Content
Every Boolean function p, as defined in Section 3.3,
may be represented as a binary decisional tree G,,
where p is the root, the. predicates constitute the
internal nodes, and the leaves correspond to the
logical binary values True or False. p is invariant in
relation to the basic operation in the Boolean alge-
bra and may be transformed to a normal disjunctive
form (Fisher, 1977). We consider G, as a complete
binary tree, without losing generality.

where n = 2h+l - 1, h = lo& + 1) - 1 C-47)

M = c, u c, u ***u @/( represent the total number n of nodes in a tree and

its height h, respectively,

Definition A2.6. The structural information con- Dejinitiun A3.2. We define the entropy classes as
tent of the G, is defined by the entropy relation the numbers of decisions in the different levels of
the decisional tree (2’, i = 1,2,. . . , h). Then, the de-
Hc(Gc) = - tpilogpi (A4) cisional information content is defined by the en-
i=l tropy function
where k is the number of equivalent classes or
orbits, pj = ki/m, ki is the number of nodes in the H,(G,) = W-0
i=o
class Ci, and m is the number of chunks in M (set
of nodes in G,). This equation is transformed in
The maximum entropy is obtained when n = k,
because there is only one element per orbit. In other H, = log n - $rcn + l)log(n + 1) - 2n]
words, there is no possibility to interchange ele-
ments in G,, and so the n elements are fixed. Then, = 2 + log tI 1 + ; log(n + 1)
( 1
1
HE = -; log z = logk=log($b(g)~) and from the last two terms of the equation we
obtain the inequality
log(n f 1)
- log IGI = log n (AS
[(1+;1
logln + 1) - log II I
1 (n + 1)
The minimum entropy value is obtained when we
have one orbit or class for the n elements. In other and
words, it is possible to do a total interchange of the logh -t- 1) h+l
n elements in G,. Then H,12- =2-_ (A91
2h+’
n+l
k k
Hc = - k log k =logl = log c IF(g)1 using formula A7. Applying L’Hopital rule in equa-
LSEG tion A9, we get
- log IGI = 0 646) lim Ha = 2
h-sm

In Figure 10, the subgraph Gc3i1 of chunk M,,,
has five nodes,. The isomorphic permutation group
G is composed of {go, g,, ) as permutation functions.
There are four orbits; the equivalent classes are
(11, {21,{1),{1), because nodes M,, I&, and M3i,
This result demonstrates that the entropy of the
decisional logical process in a program is a asintote
function upper bounded by 2.
Figure 9a represents the decisional binary tree of
the Boolean function PI. It has four entropy classes
A Unified Metric of Software Complexity J. SYSTEMS SOFIWARE 35
1995; 29~17-37

because the depth of the tree is 3 and has 11 nodes

or different decisions. The number of elements by
class are {I), {Z), (41, and {4}, because we have one
H,(f(n))
T
decision in level 0, two decisions in level 1, and four
decisions in levels 2 and 3, respectively. Then,
H,( p,) = -(l/11 log l/11 + 2/11 log 2/11+
2(4/11)log4/11) = 1.823 is the decisional informa-
tion content of the Boolean function &.

APPENDIX 4: Computational Information Content

Definition A4.1. As we say in Section 3.5, each

Figure Al. Computational information content of a com-
terminal chunk in a control flow graph G, has a plexity function f(n).
computational complexity, which is the time invested
in making decision to execute basic instructions us-
ing a data structure of IZ elements and the time
expended in the execution of its basic instructions Equation All is the proportion of the entropy frame
that conform the chunk. The complexity is repre- area for the algorithmic complexity function f(n)
sented by a function f(n) of worst-case behavior of operating over a data structure of II entities. It
the chunk’s algorithm. represents the computational information content of
From the above definition, we can represent the the chunk whose algorithmic complexity function is
algorithmic complexity as a decisional process used f(n).
to execute the basic instructions in a program. To Table Al shows the values of computational infor-
execute a chunk, it is necessary to make a logical mation content of some typical complexity functions
decision. In other words, the decision points in the based on the numerical approximation of formula
program control the processing of the IZ data ele- All with certain correction factors.
ments in a data structure. The quantity of decision is
given by the complexity function f(n), or the amount
of decisions made to do the work. APPENDIX 5: Chromatic Information Content
Then, doing h = f(n) in the decisional binary tree
represented by formula A9 in Appendix 3, we obtain
f(n) + 1 Definition A5.2. An arc coloring of a graph
l&(fh)) = 2 - 2f(n)+, . (AlO) G(M, A, cp) is an assignment of colors to its arcs in
As with decisional information content, computa- A such that no two adjacent arcs have the same
tional information content is upper bounded by 2 color. Using n colors to assign one color to each arc
when the value of complexity function grows, be- in A, we obtain II coloring of a graph G, which
cause f(n) is a nondecreasing function. conforms a partition of A in 12 independent sets
We define a measurement to quantify the value of called color classes.
computational entropy. The measurement is the
proportion of the area occupied by the complexity
function in the entropy frame as shown in Figure Table Al. Information Content of Typical Function of
Al. Algorithmic Complexity
We elect f(n,) such that for all f(n) > f<n,) we
Complexity
have H,(f(n))c(2 - 6,2 + S), where E, S > 0. The Function H,*(f)
entropy frame is an area of 2 N,, where N, = f<n,>. f 6 = 10-x
Then 1 1.419
N/2 I .636
N 1.643
2N+ 1 1.655
N.lo N 1.665
and 24 1.688
N2 1.722
Nfbl) + 1
Hs*cfcn,>= 2 - ;/ N-7 1.844
E
2f(n)-l df (All) NN 1.961
F0
36 .I.SYSTEMS SOFTWARE
1995; 29:17-37
Definition A5.2. The chromatic number of the
graph G is the smallest natural number k I n for
which G has a k coloring or K(G). Then the chro-
matic information content H,(G) of G is defined by
k Estes, W. K., Models of Learning, Memory and Choice:
H,(G) = - &logpi (AM
i=l
where k is the number of equivalent classes or k
coloring in G used as entropy classes, pi = ki/m, ki
is the number of arcs in the color class i, and m is
the number of arcs in A.
Furthermore, Guthrie’s conjecture (Toranzos,
1976) states that if G is a planar graph, then
K(G) 5 4. In other words, with only four colors, it is
possible to color the arcs of any graph G. Then,
from the chromatic information content equation
A12, and doing K, = m/4, H,(G) I 2.
For example, if we have a node in M with three
arcs coming in or going out of A, then we can use
three color classes as a minimum number, and then
H,(3) = - 3(1/3>log l/3 = 1.585 is its chromatic in-
formation content. A node with seven arcs can use
three color classes (31, (31, and (1); then H, (7) =
-(2(3/7)log 3/7 + 17 log l/7) = 1.449.
ACKNOWLEDGMENTS
I wish to thank Professor Wilfrido Fiallo for his insightful
suggestions and his important assistance that have helped to
improve this work.
REFERENCES
Baase, S., Computer Algorithms: Introduction to Design and
Analysis, Addison-Wesley, 1988.
Basili, V. R., Selby, R. W., and Hutchens, D. H., Experi-
mentation in Software Engineering, IEEE Trans. Soft-
ware Eng. SE-12, 733-743 (1986).
Basili, V. R., and Rombach, H. D., Implementing Quanti-
tative SQA: A Practical Model, IEEE Software, Sep-
tember 1987.
Beizer, B., Software Testing Techniques, Van Nostrand
Reinhold, New York, 1990.
Belady, B. L. A., Software geometry, in Proceedings of the
1980 International Computer Symposium, 1980.
Boehm, B. W., Software Engineering Economy, Prentice-
Hall, Englewood Cliffs, NJ, 1981.
CotC, V., Bourque, P., Oligny, S., and Rivard, N., Software
Metrics: An Overview of Recent Results, J. Syst. Soft-
ware 8, 121-131 (1988).
Coulter, N. S., Software Science and Cognitive Psychology,
IEEE Trans. Software Eng. SE-9, 166-171 (1983).
Curtis, B., Foundations for a Measurement Discipline,
Quality Time, IEEE Software (1987).
R. R. Gonzalez
Davis, J. S., and LeBlanc, R. J., A Study of the Applicabil-
ity of Complexity Measures, IEEE Trans. Software Eng.
SE-14, 1366-1372 (1988).
Dijkstra, E. W., Dahl, 0. J., and Hoare, C. A., Structured
Programming, Academic Press, New York, 1970.
Selected Papers, Praeger Publishers, 1982, pp. 23-24.
Fisher, J. L., Application-OrientedAlgebra: An Introduction
to Discrete Mathematics, Harper and Row, 1977.
Halstead, M. H., Toward a theoretical basis for estimating
programming effort, in Proceedings of the ACM Confer-
ence, 1975.
Halstead, M. H., Elements of Software Science, Elsevier
North-Holland, New York, 1977.
Harrison, W., An Entropy-Based Measure of Software
Complexity, IEEE Trans. Software Eng. 18 (1992).
Harrison, W., and Magel, K., A Complexity Measure Based
on Nesting Level, SZGPLAN Not. 63-74 (1981).
Henry, S., and Selig, C., Predicting Source Code Complex-
ity at the Design Stage, IEEE Software 7 (1990).
Hopcroft, J. E., and Ullman, J. D., Formal Languages and
Their Relation to Automata, Addison-Wesley, 1969.
Jensen, H. A., and Vairavan, K., An Experiment Study of
Software Metrics for Real-Time Software, IEEE Trans.
Software Eng. SE-11, 231-234 (1985).
Khoshgoftar, T. M., Bhattacharya, B. B., and Richardson,
G. D., Predicting Software Error, During Development,
Using Nonlinear Regression Models: A Comparative
Study, IEEE Trans. Reliability 41 (1992).
Lew, K. S., Dillon, T. S., and Forward, K. E., Software
Complexity and Its Impact on Software Reliability IEEE
Trans. Software Eng. SE-14,1645-1655 (1988).
Lipschutz, S., General Topology, McGraw-Hill, 1970,
pp. 111-119.
McCabe, T. J., A Complexity Measure, IEEE Trans. Soft-
ware Eng. SE-2, 308-320 (1976).
Miller, G. A., The Magical Number Seven, Plus or Minus
Two: Some Limits on Our Capacity to Processing Infor-
mation, Psychol. Rev. 63 (1956).
Mills, H. D., Mathematical Foundations for Structured
Programming, IBM Report FSC 72-6012, 1972.
Mood, A. M., Graybill, F. A., and Boes, D. C., Introduction
to the Theory of Statistics, McGraw-Hill, 1974.
Mostow, G. D., and Sampson, J. H., Linear Algebra,
McGraw-Hill, 1969, pp. 259-260.
Munson, J. C., and Khoshgoftaar, T. M., Measuring Dy-
namic Program Complexity, IEEE Software (1992).
Muss, J. D., Tools for Measuring Software Reliability,
IEEE Spectrum 39-42 (1989).
Pruett, J. M., and Hotard, D. G., The Value of Value
Analysis, Zndust. Manag. (1984).
Ramamurthy, B., and Melton, A., A Synthesis of Software
Science Measures and Cyclomatic Number, IEEE Trans.
Software Eng. SE-14 (1988).
Scudder, R. A., and Kucie, A. R., Productivity Measures
for Information Systems, Infor. Manage. 20 (1991).
Sethi, R., Programming Languages: Concepts and Con-
structs, Addison-Wesley, 1989, pp. 383-388.
A Unified Metric of Software Complexity J. SYSTEMS SOFTWARE 37
1995; 29~17-37

Shannon, C., A Mathematical Theory of Communication, Toranzos, F. A., Introduction a la Teoria de Grafos, The
Bell Syst. Tech. J. 27, 379-423, 623-654 (1948). General Secretariat of the Organization of American
Schneiderman, B., Software Psychology, Wintrop, Cam- States (OAS), Washington, D.C., 1976, pp. 53.
bridge, MA, 1980. Weyuker, E. J., Evaluating Software Complexity Mea-
Shooman, M. L., Software Engineering: Design, Reliability sures, ZEEE Trans. SofnYare Eng. SE-14 (1988).
and Management, McGraw Hill, New York, 1983, Wirth, N., Program Development by Stepwise Refinement,
pp. 150-151. Commun. ACM (1971).
Siegrist, K., Reliability of Systems with Markov Transfer Wirth, N., Algorithims + Data Structures = Programs,
of Control, II, IEEE Trans. Software Eng. SE-14 (1988). Prentice-Hall, 1976.
Sneed, H. M., and Merey, A., Automated Software Quality
Woodfield, S. N., Enhanced Effort Estimation by Extend-
Assurance, IEEE Trans. Sofhvare Eng. SE-11, 909-916
ing Basic Programming Model to Include Modularity
(1985).
Factors, Ph.D. Thesis, Department of Computer Sci-
Szulewski, P. A., Sodano, N. M., Rosner, A. J., and
ence, Purdue University, 1980.
DeWolf, J. B., Automating Software Design Metrics,
Zage, W. M., Zage, D. M., Bhargava, M., and Gaumer, D.,
RADC-TR-84-27, Rome Air Development Center,
Design and Code Metrics Through a Diana Based Tool,
Rome, NY, 1984.
SECC-TR-109-P, Software Engineering Research Cen-
Taguchi, G., and Clausing, D., Robust Quality, Harvard
ter, Purdue University, 1992.
Bus. Rev. (1990).