TITLE: Thoughts on OO metrics RESPONSE: ed@bse.com (Edward V. Berard), 28 Jan 95 Some people have been asking me for information on metrics for object-oriented software engineering. So, I put together this short note and a very abbreviated bibliography. I hope you find this information useful. -- Ed ============================================================================ Metrics for Object-Oriented Software Engineering by Edward V. Berard "Since the measuring device has be 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] Prologue Software 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 programming language is the best, the stupid things that managers do to "ruin" projects, and who's methodology works in what situations. What Are Software Engineering 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. Software engineering metrics are units of measurement that are used to characterize: - software engineering products, e.g., designs, source code, and test cases, - software engineering processes, e.g., the activities of analysis, designing, and coding, and - software engineering people, e.g., the efficiency of an individual tester, or the productivity of an individual designer. If used properly, software engineering metrics can allow us to: - quantitatively define success and failure, and/or the degree of success or failure, for a product, a process, or a person, - identify and quantify improvement, lack of improvement, or degradation in our products, processes, and people, - make meaningful and useful managerial and technical decisions, - identify trends, and - make quantified and meaningful estimates. Over the years, I have noticed some common trends among software engineering metrics. Here are some observations: - A single software engineering metric in isolation is seldom useful. However, for a particular process, product, or person, 3 to 5 well-chosen metrics seems to be a practical upper limit, i.e., additional metrics (above 5) do not usually provide a significant return on investment. - 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 software engineering, or a specific software 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. For example, there are the "terrible H's," i.e., the Heisenberg effect and the Hawthorne effect. - Metrics can be harmful. More properly, metrics can be misused. Object-oriented software engineering metrics are units of measurement that are used to characterize: - object-oriented software engineering products, e.g., designs, source code, and test cases, - object-oriented software engineering processes, e.g., the activities of analysis, designing, and coding, and - object-oriented software engineering people, e.g., the efficiency of an individual tester, or the productivity of an individual designer. 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, Ada's packages, and 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: - the basic unit will no longer be the subprogram, but rather the object, 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,": - 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. - 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. - 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 Ada software (i.e., Structured Analysis/Structured Design, Object-Oriented Design (Booch), and Jackson System Development). They found that the object-oriented solutions, when compared to the other solutions: - 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: - weighted methods per class: This focuses on the complexity and number of methods within a class. - depth of inheritance tree: This is a measure of how many layers of inheritance make up a given class hierarchy. - number of children: This is the number of immediate specializations for a given class. - coupling between object classes: This is a count of the number of other classes to which a given class is coupled. - 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. - 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. I, myself, have 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. Conclusion Metrics are a necessary part of any engineering effort. They guide both managerial and technical decisions. However, they must not be handled in a sloppy manner, because their misuse can cause great harm. Bibliography [ANSI/IEEE, 1984]. ANSI/IEEE Std 729-1983: Glossary of Software Engineering Terminology, IEEE, New York, New York, 1984. [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, New York, New York, 1985. [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, N. Fenton, A. Melton, and R. Whitty, "A Philosophy of Software Measurement," Journal of Systems and Software, Vol. 12, No. 3, July 1990, pp. 277 - 281. [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), New York, New York, 1980. [Basili and Reiter, 1979]. V. Basili and R. Reiter, "Evaluating Automatable Measures of Software Models," IEEE Workshop on Quantitative Software Models, Kiamesha, New York, 1979, pp. 107 - 116. [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]. C.A. Behrens, "Measuring the Productivity of Computer Systems Development," IEEE Transactions on Software Engineering, Vol. SE-9, No. 6, November 1983, pp. 648 - 651. [Berard, 1983]. E.V. Berard, "Engineering Ada: Halstead's Metrics and Ada," Ada Letters, Vol. 3, No. 3, November/December 1983, pp. 33 - 44. [Berard, 1984]. E.V. Berard, "Engineering Ada: Halstead's Metrics and Ada -- Part II," Ada Letters, Vol. 3, No. 5, March/April 1984, pp. 44 - 49. [Berard, 1993]. E.V. Berard, Essays on Object-Oriented Software Engineering, Volume 1, Prentice Hall, Englewood Cliffs, New Jersey, 1993. [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, Silver Spring, Maryland, 1980, pp. 218 - 231. [Boehm, 1981]. B. W. Boehm, Software Engineering Economics, Prentice Hall, Englewood Cliffs, New Jersey, 1981. [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, New York, New York, 1985, pp. 46 - 52. [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, V.E. Church, and W.W. Agresti, "An Empirical 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, Englewood Cliffs, New Jersey, 1990. [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, Menlo Park, California, 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, New York, New York, 1981, pp. 81 - 85. [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, Englewood Cliffs, New Jersey, 1989. [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, Englewood Cliffs, New Jersey, 1990. [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, Boston, Massachusetts, 1991. [Fenton, 1991]. N.E. Fenton, Software Metrics: A Rigorous Approach, Chapman and Hall, New York, New York, 1991. [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., Cambridge, Massachusetts, 1977. [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 Ada Technology, March 4-7, 1991, pp. 120 - 127. [Grady, 1992]. R.B. Grady, Practical Software Metrics for Project Management and Process Improvement, Prentice Hall, Englewood Cliffs, New Jersey, 1992. [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, Englewood Cliffs, New Jersey, 1987. [Halstead, 1977]. M.H. Halstead, Elements of Software Science, Elsevier, North-Holland, New York, 1977. [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, Boston, Massachusetts, 1993. [Horgan et al., 1994]. J.K. Horgan, S. London, and M.R. Lyn, "Achieving 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, New York, New York, 1986. [Jones, 1991]. C. Jones, Applied Software Measurement: Assuring Productivity and Quality, McGraw-Hill, Inc., New York, New York, 1991. [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 Oman, 1994]. T.M. Khoshgoftaar and P. Oman, "Software 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, Baltimore, Maryland, 1993, pp. 52 - 60. [Li et al., 1991]. W. Li, S. Henry and C. Selig, "Measuring Ada Design to Predict Maintainability," Proceedings of the Ninth Annual National Conference on Ada Technology, March 4-7, 1991, pp. 107 - 113. [Lieberherr and Holland, 1989]. K.J. Liberherr and I.M. Holland, "Assuring Good 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, Reading, Massachusetts, 1987. [Lorenz and Kidd, 1994]. M. Lorenz and J. Kidd, Object-Oriented Software Metrics, Prentice Hall, Englewood Cliffs, New Jersey, 1994. [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, New York, New York, 1985, pp. 388 - 394. [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, London, United Kingdom, 1993. [Myers, 1975]. G. J. Myers, Reliable Software through Composite Design, Van Nostrand Reinhold Company, New York, New York, 1975. [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, New York, New York, 1985, pp. 70-75. [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, San Antonio, Texas, October 1-4, 1990, pp. 181 - 196. [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 Ada Technology, March 4-7, 1991, pp. 114 - 119. [Putnam and Myers, 1992]. L. Putnam and W. Myers, Measures for Excellence: Reliable Software on Time, Within Budget, Prentice Hall, Englewood Cliffs, New Jersey, 1992. [Rains, 1991]. E. Rains, "Function Points In an Ada Object-Oriented Design?", OOPS Messenger, Vol. 2, No. 4, October 1991, pp. 23 - 25. [St. Dennis et al., 1986]. R. St. Dennis, P. Stachour, E. Frankowski, E. Onuegbe, "Measurable Characteristics of Reusable Ada Software," Ada Letters, Vol. VI, 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, New York, New York, 1991. [Troy and Zweben, 1981]. D.A. Troy and S.H. Zweben, "Measuring the Quality 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]. S.A. Whitmire, "Object-Oriented Measurement of Software," The Encyclopedia of Software Engineering, Volume 2, J.J. Marciniak, Editor, John Wiley and Sons, New York, New York, 1994, pp. 737 - 739. [Wild, 1991]. F.H. Wild, III, "Managing Class Coupling," Unix Review, Vol. 9, No. 10, October 1991, pp. 45 - 47.