26
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Software Engineering: A Practitioner’s Approach, Software Engineering: A Practitioner’s Approach, 6/e 6/e Chapter 15 Chapter 15 Product Metrics for Product Metrics for Software Software copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

Embed Size (px)

Citation preview

Page 1: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1

Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e

Chapter 15Chapter 15Product Metrics for Product Metrics for

SoftwareSoftware

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

Page 2: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2

McCall’s Triangle of McCall’s Triangle of QualityQuality

MaintainabilityMaintainability

FlexibilityFlexibility

TestabilityTestability

PortabilityPortability

ReusabilityReusability

InteroperabilityInteroperability

CorrectnessCorrectness

ReliabilityReliabilityEfficiencyEfficiency

IntegrityIntegrityUsabilityUsability

PRODUCT TRANSITIONPRODUCT TRANSITIONPRODUCT REVISIONPRODUCT REVISION

PRODUCT OPERATIONPRODUCT OPERATION

Page 3: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3

A A CommentComment

McCall’s quality factors were proposed in theMcCall’s quality factors were proposed in theearly 1970s. They are as valid today as they wereearly 1970s. They are as valid today as they werein that time. It’s likely that software built to conform in that time. It’s likely that software built to conform to these factors will exhibit high quality well intoto these factors will exhibit high quality well intothe 21st century, even if there are dramatic changesthe 21st century, even if there are dramatic changesin technology.in technology.

Page 4: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4

Measures, Metrics and Measures, Metrics and IndicatorsIndicators

A A measuremeasure provides a quantitative indication of provides a quantitative indication of the extent, amount, dimension, capacity, or size the extent, amount, dimension, capacity, or size of some attribute of a product or processof some attribute of a product or process

The IEEE glossary defines aThe IEEE glossary defines a metricmetric as “a as “a quantitative measure of the degree to which a quantitative measure of the degree to which a system, component, or process possesses a given system, component, or process possesses a given attribute.”attribute.”

An An indicatorindicator is a metric or combination of is a metric or combination of metrics that provide insight into the software metrics that provide insight into the software process, a software project, or the product itself process, a software project, or the product itself

Page 5: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5

Measurement Measurement PrinciplesPrinciples

The objectives of measurement should be established The objectives of measurement should be established before data collection begins;before data collection begins;

Each technical metric should be defined in an Each technical metric should be defined in an unambiguous manner;unambiguous manner;

Metrics should be derived based on a theory that is valid Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles should draw upon basic design concepts and principles and attempt to provide an indication of the presence of and attempt to provide an indication of the presence of an attribute that is deemed desirable);an attribute that is deemed desirable);

Metrics should be tailored to best accommodate specific Metrics should be tailored to best accommodate specific products and processes [BAS84]products and processes [BAS84]

Page 6: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6

Measurement ProcessMeasurement Process

FormulationFormulation.. The derivation of software measures and metrics The derivation of software measures and metrics appropriate for the representation of the software that is being appropriate for the representation of the software that is being considered.considered.

Collection.Collection. The mechanism used to accumulate data required to derive the The mechanism used to accumulate data required to derive the formulated metrics.formulated metrics.

AnalysisAnalysis.. The computation of metrics and the application of mathematical The computation of metrics and the application of mathematical tools.tools.

InterpretationInterpretation.. The evaluation of metrics results in an effort to gain The evaluation of metrics results in an effort to gain insight into the quality of the representation.insight into the quality of the representation.

Feedback.Feedback. Recommendations derived from the interpretation of product Recommendations derived from the interpretation of product metrics transmitted to the software team.metrics transmitted to the software team.

Page 7: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7

Goal-Oriented Software Goal-Oriented Software MeasurementMeasurement

The Goal/Question/Metric ParadigmThe Goal/Question/Metric Paradigm (1) establish an explicit measurement (1) establish an explicit measurement goalgoal that is specific to the that is specific to the

process activity or product characteristic that is to be assessedprocess activity or product characteristic that is to be assessed (2) define a set of (2) define a set of questionsquestions that must be answered in order to that must be answered in order to

achieve the goal, and achieve the goal, and (3) identify well-formulated(3) identify well-formulated metricmetricss that help to answer these that help to answer these

questions.questions. Goal definition templateGoal definition template

AnalyzeAnalyze {the name of activity or attribute to be measured} {the name of activity or attribute to be measured} for the purpose offor the purpose of {the overall objective of the analysis} {the overall objective of the analysis} with respect towith respect to {the aspect of the activity or attribute that is {the aspect of the activity or attribute that is

considered} considered} from the viewpoint offrom the viewpoint of {the people who have an interest in the {the people who have an interest in the

measurement} measurement} in the context ofin the context of {the environment in which the measurement takes {the environment in which the measurement takes

place}.place}.

Page 8: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8

Metrics Metrics AttributesAttributes simple and computable.simple and computable. It should be relatively easy to learn how to derive It should be relatively easy to learn how to derive

the metric, and its computation should not demand inordinate effort or the metric, and its computation should not demand inordinate effort or timetime

empirically and intuitively persuasiveempirically and intuitively persuasive.. The metric should satisfy the The metric should satisfy the engineer’s intuitive notions about the product attribute under engineer’s intuitive notions about the product attribute under considerationconsideration

consistent and objectiveconsistent and objective.. The metric should always yield results that are The metric should always yield results that are unambiguous. unambiguous.

consistent in its use of units and dimensionsconsistent in its use of units and dimensions.. The mathematical The mathematical computation of the metric should use measures that do not lead to bizarre computation of the metric should use measures that do not lead to bizarre combinations of unit. combinations of unit.

programming language independentprogramming language independent.. Metrics should be based on the Metrics should be based on the analysis model, the design model, or the structure of the program itself. analysis model, the design model, or the structure of the program itself.

an effective mechanism for quality feedbackan effective mechanism for quality feedback.. That is, the metric should That is, the metric should provide a software engineer with information that can lead to a higher provide a software engineer with information that can lead to a higher quality end productquality end product

Page 9: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9

Collection and Analysis Collection and Analysis PrinciplesPrinciples

Whenever possible, data collection and analysis Whenever possible, data collection and analysis should be automated;should be automated;

Valid statistical techniques should be applied to Valid statistical techniques should be applied to establish relationship between internal product establish relationship between internal product attributes and external quality characteristics attributes and external quality characteristics

Interpretative guidelines and recommendations Interpretative guidelines and recommendations should be established for each metricshould be established for each metric

Page 10: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10

Analysis MetricsAnalysis Metrics

Function-based metricsFunction-based metrics:: use the function point as use the function point as a normalizing factor or as a measure of the “size” a normalizing factor or as a measure of the “size” of the specificationof the specification

Specification metricsSpecification metrics:: used as an indication of used as an indication of quality by measuring number of requirements by quality by measuring number of requirements by typetype

Page 11: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11

Function-Based MetricsFunction-Based Metrics

The The function point metricfunction point metric (FP), (FP), first proposed by Albrecht [ALB79], can be first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a used effectively as a means for measuring the functionality delivered by a system.system.

Function points are derived using an empirical relationship based on Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and countable (direct) measures of software's information domain and assessments of software complexityassessments of software complexity

Information domain values are defined in the following manner:Information domain values are defined in the following manner: number of external inputs (EIs)number of external inputs (EIs) number of external outputs (EOs)number of external outputs (EOs) number of external inquiries (EQs)number of external inquiries (EQs) number of internal logical files (ILFs)number of internal logical files (ILFs) Number of external interface files (EIFs)Number of external interface files (EIFs)

Page 12: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12

Function PointsFunction Points

Information Domain Value Count simple average complex

Weighting factor

External Inputs (EIs)

External Outputs (EOs)

External Inquiries (EQs)

Internal Logical Files (ILFs)

External Interface Files (EIFs)

3 4 6

4 5 7

3 4 6

7 10 15

5 7 10

=

=

=

=

=

Count total

3

3

3

3

3

Page 13: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13

Function Point CalculationFunction Point Calculation

FP = count total x [0.65 + 0.01 x ∑ (FFP = count total x [0.65 + 0.01 x ∑ (Fii)])]

The FThe Fi i are value adjustment factors (VAF) are value adjustment factors (VAF) based on based on responses to the following questions:responses to the following questions:

1.1. Does the system require reliable backup and recovery?Does the system require reliable backup and recovery?2.2. Are specialized data communications required to transfer Are specialized data communications required to transfer

information to or from the application?information to or from the application?3.3. Are there distributed processing functions?Are there distributed processing functions?4.4. Is performance criticalIs performance critical5.5. Will the system run in an existing, heavily utilized Will the system run in an existing, heavily utilized

operational environment?operational environment?

Page 14: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14

Function Point Calculation Function Point Calculation (cont’d)(cont’d)

6.6. Does the system require on-line data entry?Does the system require on-line data entry?

7.7. Does the on-line data entry require the input transaction Does the on-line data entry require the input transaction to be built over multiple screens or operations?to be built over multiple screens or operations?

8.8. Are the ILFs updated on-line?Are the ILFs updated on-line?

9.9. Are the inputs, outputs, files, or inquiries complex?Are the inputs, outputs, files, or inquiries complex?

10.10. Is the internal processing complex?Is the internal processing complex?

11.11. Is the code designed to be reusable?Is the code designed to be reusable?

12.12. Are conversion and installation included in the design?Are conversion and installation included in the design?

13.13. Is the system designed for multiple installations in Is the system designed for multiple installations in different organizations?different organizations?

14.14. Is the application designed to facilitate change and for Is the application designed to facilitate change and for ease of use by the user?ease of use by the user?

Page 15: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15

Architectural Design MetricsArchitectural Design Metrics

Architectural design metricsArchitectural design metrics Structural complexity = g(fan-out)Structural complexity = g(fan-out) Data complexity = f(input & output variables, fan-out)Data complexity = f(input & output variables, fan-out) System complexity = h(structural & data complexity) System complexity = h(structural & data complexity)

HK metric:HK metric: architectural complexity as a function architectural complexity as a function of fan-in and fan-outof fan-in and fan-out

Morphology metrics:Morphology metrics: a function of the number of a function of the number of modules and the number of interfaces between modules and the number of interfaces between modulesmodules

Page 16: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16

Metrics for OO Design-IMetrics for OO Design-I Whitmire [WHI97] describes nine distinct and measurable Whitmire [WHI97] describes nine distinct and measurable

characteristics of an OO design:characteristics of an OO design: SizeSize

Size is defined in terms of four views: population, volume, length, and Size is defined in terms of four views: population, volume, length, and functionalityfunctionality

ComplexityComplexity How classes of an OO design are interrelated to one anotherHow classes of an OO design are interrelated to one another

CouplingCoupling The physical connections between elements of the OO designThe physical connections between elements of the OO design

SufficiencySufficiency ““the degree to which an abstraction possesses the features required of it, the degree to which an abstraction possesses the features required of it,

or the degree to which a design component possesses features in its or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.”abstraction, from the point of view of the current application.”

CompletenessCompleteness An indirect implication about the degree to which the abstraction or An indirect implication about the degree to which the abstraction or

design component can be reuseddesign component can be reused

Page 17: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17

Metrics for OO Design-IIMetrics for OO Design-II

CohesionCohesion The degree to which all operations working together to The degree to which all operations working together to

achieve a single, well-defined purposeachieve a single, well-defined purpose PrimitivenessPrimitiveness

Applied to both operations and classes, the degree to Applied to both operations and classes, the degree to which an operation is atomicwhich an operation is atomic

SimilaritySimilarity The degree to which two or more classes are similar in The degree to which two or more classes are similar in

terms of their structure, function, behavior, or purposeterms of their structure, function, behavior, or purpose VolatilityVolatility

Measures the likelihood that a change will occurMeasures the likelihood that a change will occur

Page 18: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18

Distinguishing Distinguishing CharacteristicsCharacteristics

Localization—the way in which information is concentrated in a Localization—the way in which information is concentrated in a programprogram

Encapsulation—the packaging of data and processingEncapsulation—the packaging of data and processing Information hiding—the way in which information about Information hiding—the way in which information about

operational details is hidden by a secure interfaceoperational details is hidden by a secure interface Inheritance—the manner in which the responsibilities of one Inheritance—the manner in which the responsibilities of one

class are propagated to anotherclass are propagated to another Abstraction—the mechanism that allows a design to focus on Abstraction—the mechanism that allows a design to focus on

essential detailsessential details

Berard [BER95] argues that the following characteristics require that special OO metrics be developed:

Page 19: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19

Class-Oriented Class-Oriented MetricsMetrics

weighted methods per classweighted methods per class depth of the inheritance treedepth of the inheritance tree number of childrennumber of children coupling between object classescoupling between object classes response for a classresponse for a class lack of cohesion in methodslack of cohesion in methods

Proposed by Chidamber and KemererProposed by Chidamber and Kemerer::

Page 20: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20

Class-Oriented Class-Oriented MetricsMetrics

class sizeclass size number of operations overridden by a number of operations overridden by a

subclasssubclass number of operations added by a subclassnumber of operations added by a subclass specialization indexspecialization index

Proposed by Lorenz and Kidd [LOR94]:Proposed by Lorenz and Kidd [LOR94]:

Page 21: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21

Class-Oriented MetricsClass-Oriented Metrics

Method inheritance factorMethod inheritance factor Coupling factorCoupling factor Polymorphism factorPolymorphism factor

The MOOD Metrics SuiteThe MOOD Metrics Suite

Page 22: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22

Operation-Oriented Operation-Oriented MetricsMetrics

average operation sizeaverage operation size operation complexityoperation complexity average number of parameters per average number of parameters per

operationoperation

Proposed by Lorenz and Kidd [LOR94]:Proposed by Lorenz and Kidd [LOR94]:

Page 23: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23

Component-Level Design Component-Level Design MetricsMetrics

Cohesion metrics:Cohesion metrics: a function of data objects and a function of data objects and the locus of their definitionthe locus of their definition

Coupling metrics:Coupling metrics: a function of input and output a function of input and output parameters, global variables, and modules calledparameters, global variables, and modules called

Complexity metrics:Complexity metrics: hundreds have been hundreds have been proposed (e.g., cyclomatic complexity)proposed (e.g., cyclomatic complexity)

Page 24: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24

Interface Design MetricsInterface Design Metrics

Layout appropriateness:Layout appropriateness: a function of layout a function of layout entities, the geographic position and the “cost” entities, the geographic position and the “cost” of making transitions among entitiesof making transitions among entities

Page 25: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25

Code MetricsCode Metrics

Halstead’s Software Science:Halstead’s Software Science: a comprehensive a comprehensive collection of metrics all predicated on the collection of metrics all predicated on the number (count and occurrence) of operators and number (count and occurrence) of operators and operands within a component or programoperands within a component or program It should be noted that Halstead’s “laws” have It should be noted that Halstead’s “laws” have

generated substantial controversy, and many believe generated substantial controversy, and many believe that the underlying theory has flaws. However, that the underlying theory has flaws. However, experimental verification for selected programming experimental verification for selected programming languages has been performed (e.g. [FEL89]).languages has been performed (e.g. [FEL89]).

Page 26: These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26

Metrics for TestingMetrics for Testing

Testing effort can also be estimated using Testing effort can also be estimated using metrics derived from Halstead measuresmetrics derived from Halstead measures

Binder [BIN94] suggests a broad array of design Binder [BIN94] suggests a broad array of design metrics that have a direct influence on the metrics that have a direct influence on the “testability” of an OO system. “testability” of an OO system. Lack of cohesion in methods (LCOM). Lack of cohesion in methods (LCOM). Percent public and protected (PAP). Percent public and protected (PAP). Public access to data members (PAD). Public access to data members (PAD). Number of root classes (NOR). Number of root classes (NOR). Fan-in (FIN). Fan-in (FIN). Number of children (NOC) and depth of the inheritance Number of children (NOC) and depth of the inheritance

tree (DIT).tree (DIT).