Metrics…
"Since the measuring
device has been constructed by the observer ...
we have to remember that what we observe is not nature in itself, but
nature exposed to our method of questioning."
-- Werner Karl Heisenberg (1901 - 1976), in
"Physics and Philosophy" [1958]
Introduction…
People seem to have a
love-hate relationship with metrics. On
one hand, they despise and distrust anything that sounds or looks like a
measurement. They are quick to point out
the "flaws" in the arguments of anyone who talks about measuring
software products, software processes, and (especially) software people. On the other hand, these same people seem to
have no problems identifying which software program is the best for the job, and
who's methodology works in what situations.
What Are Metrics…
Metrics are units of
measurement. The term
"metrics" is also frequently used to mean a set of specific
measurements taken on a particular item or process. Metrics are units of measurement that are
used to characterize:
·
Products,
e.g., designs, source code, and test cases
·
Processes,
e.g., the activities of the business and the analysis
·
People, e.g.,
the efficiency of an individual team, or the productivity of an individual
analysis.
If used properly, software engineering metrics can
allow us to…
1.
Quantitatively
define success and failure, and/or the degree of success or failure, for a
product, a process, or a person.
2.
Identify and
quantify improvement, lack of improvement, or degradation in our products,
processes, and people.
3.
Make
meaningful and useful managerial and technical decisions
4.
Identify
trends, and make quantified and meaningful estimates.
Observations…
A single metric in
isolation is seldom useful. However, for
a particular process, product, or person,
Although multiple metrics
must be gathered, the most useful set of metrics for a given person, process,
or product may not be known ahead of time.
This implies that, when we first begin to study some aspect of the
project, we will probably have to use a large (e.g., 20 to 30, or more) number
of different metrics. Later, analysis
should point out the most useful metrics.
Metrics are almost always
interrelated. Specifically, attempts to influence one metric usually have an
impact on other metrics for the same person, process, or product.
To be useful, metrics must
be gathered systematically and regularly -- preferably in an automated manner.
Metrics must be correlated
with reality. This correlation must take
place before meaningful decisions, based on the metrics, can be made.
Faulty analysis
(statistical or otherwise) of metrics can render metrics useless, or even
harmful.
To make meaningful
metrics-based comparisons, both the similarities and dissimilarities of the
people, processes, or products being compared must be known.
Those gathering metrics
must be aware of the items that may influence the metrics they are gathering.
Metrics can be harmful.
More properly, metrics can be misused.
Why Are Object-Oriented Software Engineering
Metrics Different?
OOSE metrics are different because of:
·
localization,
·
encapsulation,
·
information hiding,
·
inheritance,
and
·
object abstraction techniques.
Localization is the process of placing items in
close physical proximity to each other:
·
Functional
decomposition processes localize information around functions.
·
Data-driven
approaches localize information around data.
·
Object-oriented
approaches localize information around objects.
In most conventional software (e.g., software
created using functional decomposition), localization is based on
functionality. Therefore:
·
A great deal
of metrics gathering has traditionally focused largely on functions and
functionality
·
Units of
software were functional in nature, thus metrics focusing on component
interrelationships emphasized functional interrelationships, e.g., module
coupling.
In object-oriented software, however, localization
is based on objects. This means:
·
Although we
may speak of the functionality provided by an object, at least some of our
metrics identification and gathering effort (and possibly a great deal of the
effort) must recognize the "object" as the basic unit of software.
·
Within systems
of objects, the localization between functionality and objects is not a one
to-one relationship. For example, one function may involve several objects, and
one object may provide many functions.
Encapsulation is the packaging (or binding
together) of a collection of items:
Low-level examples of
encapsulation include records and arrays.
Subprograms (e.g.,
procedures, functions, subroutines, and paragraphs) are
mid-level mechanisms for encapsulation.
In object-oriented (and
object-based) programming languages, there are still
larger encapsulating mechanisms, e.g., C++'s classes,
Modula
3's modules.
Objects encapsulate:
knowledge of state, whether statically maintained,
calculated upon demand, or otherwise,
advertised capabilities (sometimes called operations, method
interfaces, method selectors, or method interfaces), and the corresponding
algorithms used to accomplish these capabilities (often referred to simply as methods),
[in the case of
composite objects] other objects,
[optionally]
exceptions,
[optionally]
constants, and
[Most importantly] concepts.
In many object-oriented
programming languages, encapsulation of objects (e.g., classes and their
instances) is syntactically and semantically supported by the language. In others, the concept of encapsulation is
supported conceptually, but not physically.
Encapsulation has two major impacts on metrics:
1.
the basic unit
will no longer be the subprogram, but rather the object,
2.
and we will have to modify our thinking on
characterizing and estimating systems.
Information hiding is the suppression (or hiding) of details.
The general idea is that
we show only that information which is necessary to accomplish our immediate
goals.
There are degrees of
information hiding, ranging from partially restricted visibility to total
invisibility.
Encapsulation and
information hiding are not the same thing, e.g., an
item
can be encapsulated but may still be totally visible.
Information hiding plays a
direct role in such metrics as object
coupling and the
degree of information hiding
Inheritance is a mechanism whereby one object acquires characteristics from one,
or more, other objects.
Some object oriented
languages support only single inheritance, i.e., an object may acquire
characteristics directly from only one other object.
Some object-oriented
languages support multiple inheritance, i.e. an object
may acquire characteristics directly from two, or more, different objects.
The types of
characteristics which may be inherited, and the
specific semantics of inheritance vary from language to language.
Many object-oriented software engineering metrics are based on inheritance,
e.g.:
number of children (number of immediate specializations),
number of parents (number of immediate generalizations),
and
class hierarchy nesting level (depth of a class in an
inheritance hierarchy).
Abstraction is a mechanism for focusing on the
important (or essential) details of a concept or item, while ignoring the
inessential details.
Abstraction is a relative
concept. As we move to higher levels of abstraction
we ignore more and more details, i.e., we provide a more general view of a
concept or item. As we move to lower
levels of abstraction, we introduce more details, i.e., we provide a more
specific view of a concept or item.
There are different types
of abstraction, e.g., functional, data, process, and
object abstraction.
In object abstraction, we
treat objects as high-level entities (i.e., as black boxes).
There are three commonly used (and different) views
on the definition for "class,":
1.
A class is a
pattern, template, or a blueprint for a category of structurally identical
items. The items created using the class are called instances. This is often
referred to as the "class as a `cookie cutter'" view.
2.
A class is a
thing that consists of both a pattern and a mechanism for creating items based
on that pattern. This is the "class
as an `instance factory'" view. Instances
are the individual items that are "manufactured" (created) by using
the class's creation mechanism.
3.
A class is the
set of all items created using a specific pattern, i.e., the class is the set
of all instances of that pattern.
A metaclass is a class whose instances are themselves
classes. Some object-oriented programming languages directly
support user-defined metaclasses.
In effect, metaclasses may be viewed as classes for classes, i.e., to
create an instance, we supply some specific parameters to the metaclass, and these are used to create a class. A metaclass is an
abstraction of its instances.
A parameterized class is a
class some or all of whose elements may be parameterized. New (directly usable) classes may be generated
by instantiating a parameterized class with its required parameters. Templates in C++ and generic classes in Eiffel
are examples of parameterized classes.
Some people differentiate metaclasses and parameterized classes by noting that metaclasses (usually) have run-time behavior, whereas
parameterized classes (usually) do not have run-time behavior.
Several object-oriented software engineering metrics are related to the
class-instance
relationship, e.g.:
number of instances per class per application,
number or parameterized classes per application, and
ratio of parameterized classes to non-parameterized
classes.
Case Studies of
Object-Oriented Software Engineering Metrics
We will break our look at case studies into the following areas:
anecdotal metrics information,
the General Electric Report,
Chidamber and Kemerer's research,
Lorenz's research, and
my own experience.
Anecdotal object-oriented software engineering
metrics information includes:
·
It takes the
average software engineer about 6 months to become comfortable with
object-oriented technology.
·
The average
number of lines of code per method is small, e.g., typically 1-3 lines of code,
and seldom more than 10 lines of code.
·
The learning
time for Smalltalk seems to be on the order of two months for an experienced
programmer.
·
Once a
programmer understands a given object-oriented programming language, he or she
should plan on taking one day per class to (eventually) understand all the
classes in the class library.
·
Object-oriented
technology yields higher productivity, e.g., fewer software engineers
accomplishing more work when compared to traditional teams.
Deborah Boehm-Davis and
Lyle Ross conducted a study for General Electric (in 1984) comparing several
development approaches for
·
were simpler
(using McCabe's and Halstead's metrics)
·
were smaller (using
lines of code as a metric)
·
appeared to be
better suited to real-time applications
·
took less time
to develop
Shyam Chidamer and Chris Kemerer have developed a small metrics suite for object oriented
designs.
The six metrics they have identified are:
1.
weighted methods per class: This focuses on the complexity
and number of methods within a class.
2.
depth of inheritance tree: This is a measure of how many
layers of inheritance make up a given class hierarchy.
3.
number of children: This is the number of immediate
specializations for a given class.
4.
coupling between object classes: This is a count of the
number of other classes to which a given class is coupled.
5.
response for a class: This is the size of the set of
methods that can potentially be executed in response to a message received by
an object.
6.
lack of cohesion in methods: This is a measure of the
number of different methods within a class that reference a given instance
variable.
Mark Lorenz and Jeff Kidd
have published the results of their object-oriented software engineering
metrics work. Some of the more interesting items in their empirical data
include:
·
The ratio of
key (important) classes to support classes seems to be typically 1 to 2.5, and
user interface intensive applications tend to have many more support classes.
·
The average
number of person-days to develop a class is much higher with C++ than it is with
Smalltalk, e.g., 10 days per Smalltalk class and 20 to 30 days per C++ class.
·
The higher the
number of lines of code per method, the less object-oriented the code is.
·
Smalltalk
applications appear to have a much lower average number of instance variables
per class when compared to C++ applications.
Edward V. Berard has worked on object-oriented projects since 1983.
Some observations from some of the projects include:
·
On a very
large (over 1,000,000 lines of code) object-oriented project, all of the source
code was run through a program that reported on the metrics for that software.
Some observations:
·
Over 90% of
all the methods in all of the classes had fewer than 40 lines of code (carriage
returns).
·
Over 95% of
the methods had a cyclomatic complexity of 4 or less.
·
On a small
project (about 25,000 lines of code), staffed by 3 software engineers each
working half-time on the project: The project was completed in six calendar
months, i.e., a total of 9 software engineering months were expended.
·
When the code
was first compiled, 7 compilation errors were found, and no more errors were
found before the code was delivered to the customer.
Bibliography
[ANSI/IEEE,
1984]. ANSI/IEEE Std 729-1983: Glossary of Software Engineering Terminology,
IEEE,
[Albrecht
and Gaffney, 1983]. A.J.
Albrecht and J.E. Gaffney, "Software Function, Source Lines of Code, and
Development Effort Prediction," IEEE Transactions on Software Engineering,
Vol. SE-9, No. 6, November 1983, pp. 639 - 647.
[Arthur,
1985]. L.J. Arthur, Measuring
Programmer Productivity and Software Quality, John Wiley and Sons,
[Baker,
1991]. M.D. Baker,
"Implementing an Initial Software Metrics Program,"
IEEE Proceedings of the
National Aerospace and Electronics Conference, Vol. 3, pp. 1289 - 1294.
[Baker et al, 1990]. A.
Baker, J. Bieman,
[Barnes
and Swim, 1993]. G.M. Barnes
and B.R. Swim, "Inheriting Software Metrics," Journal of
Object-Oriented Programming, Vol. 6, No. 7, November/December 1993, pp. 27 -
34.
[Basili, 1980].
V. R. Basili, Editor, Tutorial on Models and Metrics
for Software
Management and
Engineering, IEEE Computer Society Press (catalog number
EHO-167-7),
[Basili and Reiter, 1979]. V. Basili and R. Reiter,
"Evaluating Automatable
Measures of Software
Models," IEEE Workshop on Quantitative Software
Models,
[Basili and Hutchens, 1983]. V.R. Basili and D.H.
Hutchens, "An Empirical Study
of a Syntactic Complexity Family," IEEE
Transactions on Software
Engineering, Vol. SE-9,
No. 6, November 1983, pp. 663 - 672.
[Basili et al., 1983]. V.R. Basili, R.W. Selby,
Jr. and T.-Y. Phillips, "Metric
Analysis and Data
Validation Across FORTRAN Projects," IEEE
Transactions
on Software Engineering, Vol. SE-9, No. 6, November
1983, pp. 652 - 663.
[Beane et al., 1984]. J. Beane, N. Giddings, and J. Silverman,
"Quantifying
Software Designs,"
Proceedings of the Seventh International Conference on
Software Engineering,
1984, pp. 314 - 322.
[Behrens,
1983].
Development," IEEE
Transactions on Software Engineering, Vol. SE-9, No. 6,
November 1983, pp. 648 -
651.
[Berard, 1983].
E.V. Berard, "Engineering
Letters, Vol. 3, No. 3,
November/December 1983, pp. 33 - 44.
[Berard, 1984].
E.V. Berard, "Engineering
Part II,"
[Berard, 1993].
E.V. Berard, Essays on Object-Oriented Software
Engineering,
Volume 1, Prentice Hall,
[Bieman
et al, 1988]. J. Bieman, A. Baker, P. Clites, D. Gustafson, and A. Melton,
"A Standard
Representation of Imperative Language Programs for Data
Collection and Software
Measures Specification," Journal of Systems and
Software, Vol. 8, No. 1,
January 1988, pp. 13 - 37.
[Bieman and Schultz, 1989]. J. Bieman and J.
Schultz, "Estimating the Number of
Test Cases Required to Satisfy
the All-Do-Paths Testing Criterion," Proceedings
of the Software Testing and Verification Symposium,
TAV3-SIGSOFT89,
December 1989, pp.
179-186.
[Bieman and Ott, 1994]. J.M. Bieman and L.M. Ott, "Measuring Functional
Cohesion," IEEE
Transactions on Software Engineering, Vol. 20, No. 8, August
1994, pp. 644 - 657.
[Boehm
et al., 1980]. B.W. Boehm, J.R.
Brown and M. Lipow, "Quantitative
Evaluation of Software
Quality," Tutorial on Models and Metrics for Software
Management and
Engineering, ed. V.R. Basili, IEEE Computer Society
Press,
[Boehm,
1981]. B. W. Boehm, Software
Engineering Economics, Prentice Hall,
[Bouldin, 1989].
B. Bouldin, "What Are You Measuring? Why Are You
Measuring It?", Software Magazine, Vol. 9, No. 10, August 1989, pp.
30 - 39.
[Brooks,
1987]. F.P. Brooks, Jr.,
"Essence and Accidence of Software
Engineering," IEEE
Computer, Vol. 30, No. 4, April 1987.
[Calvano and McCall, 1985]. J.P. Calvano and J.A.
McCall, "A Framework for
the Measurement of Software Technology," Tutorial
on Software Quality
Assurance A Practical Approach, ed. T.S. Chow, IEEE Computer Society
Press,
[Card et
al., 1985]. D.N. Card, G.T. Page,
and F.E. McGarry, "Criteria for
Software
Modularization," Proceedings of the IEEE Eighth International
Conference on Software
Engineering, August 1985, pp. 372 - 377.
[Card et
al., 1986]. D.N. Card,
Study of Software Design
Practices," IEEE Transactions on Software
Engineering, Vol. 12, No.
2, February 1986, pp. 264 - 271.
[Card
and Agresti, 1988]. D.N. Card and W.W. Agresti,
"Measuring Software
Design Complexity,"
Journal of Systems and Software, Vol. 8, pp. 185 - 197.
[Card
and Glass, 1990]. D.N. Card and
R.L. Glass, Measuring Software Design
Quality,
Prentice Hall,
[Cherniavsky and Smith, 1991]. J.C. Cherniavsky and
C.H. Smith, "On Weyuker's
Axioms for Software Complexity
Measures," IEEE Transactions on Software
Engineering, Vol. 17, No.
6, June 1991, pp. 636 - 638.
[Chidamber and Kemerer, 1991]. S.R. Chidamber and C.F. Kemerer, "Towards a
Metrics Suite for
Object-Oriented Design," OOPSLA '91 Conference
Proceedings, Special Issue
of SIGPLAN Notices, Vol. 26, No. 11, November
1991, pp. 197 - 211.
[Chidamber and Kemerer, 1994]. S.R. Chidamber and C.F. Kemerer, "A Metrics
Suite for Object-Oriented
Design," IEEE Transactions on Software
Engineering, Vol. 20, No.
6, June 1994, pp. 476 - 493.
[Conte
et al., 1986]. S.D. Conte, H.E.
Sunsmore, and V.Y. Shen,
Software
Engineering Metrics and
Models, Benjamin/Cummings,
1986.
[Curtis
et al., 1981]. B. Curtis, S.B.
Sheppard and P. Milliman, "Third Time
Charm: Stronger Prediction
of Performance by Software Complexity Measures,"
Tutorial on Programming
Productivity: Issues for the Eighties, Edited by C.
Jones, IEEE Computer
Society Press,
[Dale
and Van Der Zee, 1992]. C. Dale and H. Van Der
Zee, "Software
Productivity Metrics --
Who Needs Them?", Eurometrics
'92 Proceedings, April
1992, pp. 31 - 43.
[Daskalantonakis,
1992] M.K. Daskalantonakis, "A Practical View of
Software
Measurement and
Implementation Experiences Within Motorola," IEEE
Transactions
on Software Engineering, Vol. 18, No. 11, November 1992, pp.
998 - 1010.
[Dreger, 1989].
J.B. Dreger, Function Point Analysis, Prentice Hall,
Cliffs,
[Duhl and Damon, 1988]. J. Duhl and C. Damon, "A Performance
Comparison of
Object and Relational
Databases Using the Sun Benchmark," OOPSLA '88
Conference Proceedings,
Special Issue of SIGPLAN Notices, Vol. 23, No. 11,
November 1988, pp. 153 -
163.
[Dunn,
1990]. R. H. Dunn, Software
Quality: Concepts and Plans, Prentice
Hall,
[Ejiogu, 1987].
L. O. Ejiogu, "The Critical Issues of Software
Metrics, Part 0:
Perspectives on Software
Metrics," SIGPLAN Notices, Vol. 22, No. 3, March
1987, pp. 59 - 64.
[Ejiogu, 1991].
L.O. Ejiogu, Software Engineering With
Formal Metrics, QED
Technical Publishing
Group,
[Fenton,
1991]. N.E. Fenton, Software
Metrics: A Rigorous Approach,
Chapman
and Hall,
[Fenton,
1994]. N. Fenton,
"Software Measurement: A Necessary Scientific
Basis," IEEE
Transactions on Software Engineering, Vol. 20, No. 3, March
1994, pp. 199 - 206.
[Fichman and Kermerer, 1992]. R. Fichman and C. Kermerer, "Object-Oriented
and Conventional Analysis and Design Methodologies:
Comparison and Critique,"
IEEE Computer, Vol. 25,
No. 10, October 1992, pp. 20 - 39.
[Gilb, 1977].
T. Gilb, Software Metrics, Winthrop Publishers, Inc.,
[Gill
and Kemerer, 1991]. G.K. Gill and C.F. Kemerer,
"Cyclomatic Complexity
Density and Software
Maintenance Productivity," IEEE Transactions on
Software Engineering, Vol.
17, No. 12, December 1991, pp. 1284 - 1288.
[Goodman,
1992]. P. Goodman,
"Implementing Software Metrics Programmes: A
Project-Based Approach,"
Eurometrics '92 Proceedings, April 1992, pp. 147 -
151.
[Gotterbarn, 1991]. D. Gotterbarn, "A Distributed
Compilation Environment --
Lessons Learned,"
Proceedings of the Ninth Annual National Conference on
[Grady,
1992]. R.B. Grady, Practical
Software Metrics for Project
Management and Process
Improvement, Prentice Hall,
[Grady,
1994]. R.B. Grady,
"Successfully Applying Software Metrics," IEEE
Computer, Vol. 27, No. 9,
September 1994, pp. 18 - 25.
[Grady
and Caswell, 1987]. R.B. Grady
and D.L. Caswell, Software Metrics:
Establishing a
Company-Wide Program, Prentice Hall,
[Halstead,
1977]. M.H. Halstead, Elements
of Software Science, Elsevier,
[Harrison
et al., 1982]. W. Harrison, K. Magel, R. Kluczny, and A. DeKock,
"Applying Software
Complexity Metrics to Program Maintenance," IEEE
Computer, Vol. 15, No. 9,
September 1982, pp. 65 - 79.
[Henderson-Sellers,
1992]. B. Henderson-Sellers,
"Modularization and McCabe's
Cyclomatic Complexity," Communications of the ACM, Vol.
35, No. 12,
December 1992, pp. 17 -
19.
[Henry
and Kafura, 1984]. S. Henry and D. Kafura,
"The Evaluation of Software
Systems' Structure Using
Quantitative Software Metrics," Software--Practice
and Experience, Vol. 14, No. 6, June 1984, pp. 561 -
573.
[Hetzel, 1993].
B. Hetzel, Making Software Measurement Work: Building
an
Effective Measurement
Program, QED Technical Publishing Group,
[Horgan et al., 1994]. J.K. Horgan,
Software Quality With Testing Coverage Measures," IEEE Computer, Vol.
27,
No. 9, September 1994, pp.
60 - 69.
[Hufnagel and Brown, 1989]. S.P. Hufnagel and J.C.
Brown, "Performance
Properties of Vertically
Partitioned Object-Oriented Systems," IEEE Transactions
on Software Engineering, Vol. 15, No. 8, August 1989,
pp. 935 - 946.
[Jenson
and Bartley, 1991]. R. Jenson
and J. Bartley, "Parametric Estimation of
Programming Effort: An
Object-Oriented Model," Journal of Systems and
Software, Vol. 15, 1992,
pp. 107 - 114.
[Jones,
1978]. T.C. Jones,
"Measuring Programming Quality and Productivity,"
IBM Systems Journal, Vol.
17, No. 1, 1978, pp. 39 - 63.
[Jones,
1986]. C. Jones, Programming
Productivity, McGraw-Hill Book
Company,
[Jones,
1991]. C. Jones, Applied
Software Measurement: Assuring Productivity
and Quality, McGraw-Hill, Inc.,
[Kemerer and Porter, 1992]. C.F. Kemerer and B.S.
Porter, "Improving the
Reliability of Function
Point Measurement: An Empirical Study," IEEE
Transactions
on Software Engineering, Vol. 18, No. 11, November 1992, pp.
1011 - 1024.
[Keyes,
1992]. J. Keyes, "New
Metrics Needed for New Generation," Software
Magazine, Vol. 12, No. 6,
May 1992, pp. 42 - 56.
[Khoshgoftaar and
Metrics: Charting the
Course," IEEE Computer, Vol. 27, No. 9, September 1994,
pp. 13 - 15.
[Kolewe, 1993].
R. Kolewe, "Metrics in Object-Oriented Design
and
Programming,"
Software Development, Vol. 1, No. 4, October 1993, pp. 53 - 62.
[Lanning
and Khoshgoftaar, 1994]. D.L. Lanning and T.M. Khoshgoftaar,
"Modeling the
Relationship Between Source Code Complexity and
Maintenance
Difficulty," IEEE
Computer, Vol. 27, No. 9, September 1994, pp. 35 - 40.
[Laranjeira, 1990]. L. Laranjeira, "Software Size
Estimation of Object-Oriented
Systems," IEEE
Transactions on Software Engineering, Vol. 16, No. 5, May
1990, pp. 510 - 522.
[Li and
Henry, 1993]. W. Li and S.
Henry, "Maintenance Metrics for the
Object-Oriented
Paradigm," Proceedings of the First International Software
Metrics Symposium,
[Li et
al., 1991]. W. Li, S. Henry and
C. Selig, "Measuring
Maintainability,"
Proceedings of the Ninth Annual National Conference on
[Lieberherr and
Style for Object-Oriented
Programs," IEEE Software, Vol. 6, No. 5, September
1989, pp. 38 - 48.
[Lieberherr and Riel, 1988]. K.J. Liberherr and A.J.
Riel, "Demeter: a CASE
Study of Software Growth Through Parameterized Classes," Journal of
Object-Oriented
Programming, Vol. 1, No. 3, August/September 1988, pp. 8 -
22.
[Lohse and Zweben, 1984]. J.B. Lohse and S.H. Zweben, "Experimental
Evaluation of Software
Design Principles: An Investigation Into the Effect of
Module Coupling on System
Modifiability," Journal of Systems and Software,
Vol. 4, No. 4, November
1984, pp. 301 - 308.
[Londeix, 1987].
B. Londeix, Cost Estimation for Software Development,
Addison
Wesley,
[Lorenz
and Kidd, 1994]. M. Lorenz and
J. Kidd, Object-Oriented Software
Metrics,
Prentice Hall,
[McCabe,
1976]. T.J. McCabe, "A
Complexity Measure," IEEE Transactions on
Software Engineering, Vol.
SE-2, No. 4, October 1976, pp. 243 - 245.
[McCall
et al., 1985]. J. McCall, D.
Markham, M. Stosick and R. McGindly,
"The
Automated Measurement of
Software Quality," Tutorial on Software Quality
Assurance A Practical Approach, ed. T.S. Chow, IEEE Computer Society
Press,
[Miller,
1956]. G. A. Miller, "The
Magical Number Seven, Plus or Minus Two:
Some Limits on our
Capacity for Processing Information," The Psychological
Review, Vol. 63, No. 2,
March 1956, pp. 81 - 97. Reprinted in [Yourdon, 1982],
pp. 443 - 460.
[Möller and Paulish, 1993]. K.H. Möller and D.J. Paulish, Software Metrics: A
Practitioner's Guide to
Improved Product Development, Chapman and Hall,
[Myers,
1975]. G. J. Myers, Reliable
Software through Composite Design, Van
Nostrand Reinhold Company,
[Paige, 1985] M. Paige,
"A Metric for Software Test Planning," Tutorial on
Software Quality Assurance
Practical Approach, Edited by T.S. Chow, IEEE
Computer Society Press,
[Paulish and Carleton, 1994]. D.J. Paulish and A.D.
Carleton, "Case Studies of
Software-Process-Improvement
Measurement," IEEE Computer, Vol. 27, No. 9,
September 1994, pp. 50 -
57.
[Pfleeger et al., 1994]. S.L Pfleeger, N. Fenton,
and S. Page, "Evaluating
Software Engineering
Standards," IEEE Computer, Vol. 27, No. 9, September
1994, pp. 71 - 79.
[Pfleeger and Palmer, 1990]. S.L. Pfleeger and J.D.
Palmer, "Software Estimation
for Object Oriented Systems," Fall International
Function Point Users Group
Conference,
[Pfleeger and Fitzgerald, 1991]. S.L. Pfleeger and J.C.
Fitzgerald, Jr., "A Software
Metrics Database: Support
for Analysis and Decision-Making," Proceedings of
the Ninth Annual National Conference on
pp. 114 - 119.
[Putnam
and Myers, 1992]. L. Putnam and
W. Myers, Measures for Excellence:
Reliable Software on Time,
Within Budget, Prentice Hall,
[Rains,
1991]. E. Rains, "Function
Points In an
OOPS Messenger, Vol. 2,
No. 4, October 1991, pp. 23 - 25.
[St. Dennis et al., 1986].
R. St. Dennis, P. Stachour,
"Measurable
Characteristics of Reusable
No. 2, pp. 41 - 50.
[Stark et
al., 1994]. G. Stark, R.C.
Durst, and C.W. Vowell, "Using Metrics In
Management Decision
Making," IEEE Computer, Vol. 27, No. 9, September 1994,
pp. 42 - 48.
[Symons,
1991]. C.R. Symons, Software
Sizing and Estimating: Mk II FPA,
John
Wiley and Sons,
[
of Structured Designs," Journal of Systems and
Software, Vol. 2, No. 2, June
1981, pp. 113 - 120.
[Weller,
1994]. E.F. Weller, "Using
Metrics to Manage Software Projects," IEEE
Computer, Vol. 27, No. 9,
September 1994, pp. 27 - 33.
[Weyuker, 1988].
E. Weyuker, "Evaluating Software Complexity
Measures," IEEE
Transactions
on Software Engineering, Vol. 14, No. 9, September 1988, pp.
1357 - 1365.
[Whitmire, 1994].
The Encyclopedia of
Software Engineering, Volume 2, J.J. Marciniak,
Editor,
John Wiley and Sons,
[Wild,
1991]. F.H. Wild, III,
"Managing Class Coupling," Unix Review, Vol.
9, No.
10, October 1991, pp. 45 -
47.