1

COSC 4406COSC 4406

Software Software EngineeringEngineering

Haibin Zhu, Ph.D.Haibin Zhu, Ph.D.Dept. of Computer Science and mathematics, Nipissing University, Dept. of Computer Science and mathematics, Nipissing University,

100 College Dr., North Bay, ON P1B 8L7, Canada, 100 College Dr., North Bay, ON P1B 8L7, Canada, haibinz@nipissingu.ca, http://www.nipissingu.ca/faculty/haibinz, http://www.nipissingu.ca/faculty/haibinz

2

Lecture 12Lecture 12 Product Metrics for Product Metrics for

SoftwareSoftware

3

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

McCall’s McCall’s Quality FactorsQuality Factors

Correctness: The extent to which a program satisfies its Correctness: The extent to which a program satisfies its specification and fulfils the customer’s mission objectives.specification and fulfils the customer’s mission objectives.

Reliability: The extent to which a program can be expected Reliability: The extent to which a program can be expected to perform its intended function with required precision.to perform its intended function with required precision.

Efficiency: The amount of computing resources and code Efficiency: The amount of computing resources and code required by a program to perform its functions.required by a program to perform its functions.

Integrity: The extent to which access to software or data Integrity: The extent to which access to software or data by unauthorized persons can be controlled.by unauthorized persons can be controlled.

Usability: The effort required to learn, operate input for, Usability: The effort required to learn, operate input for, and interpret output of a program.and interpret output of a program.

Maintainability: The effort required to locate and fix an Maintainability: The effort required to locate and fix an error in a program.error in a program.

4

McCall’s McCall’s Quality FactorsQuality Factors Flexibility: The effort required to modify an Flexibility: The effort required to modify an

operational program.operational program. Testability: The effort required to test a program to Testability: The effort required to test a program to

ensure that it performs its intended functions.ensure that it performs its intended functions. Portability: The effort required to transfer the Portability: The effort required to transfer the

program from one hardware and/or software system program from one hardware and/or software system environment to another.environment to another.

Reusability: The extent to which a program [or part of Reusability: The extent to which a program [or part of the program] can be reused in other applications.the program] can be reused in other applications.

Interoperability: The effort required to couple one Interoperability: The effort required to couple one system to another. system to another.

5

6

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.

ISO 9126 Quality FactorsISO 9126 Quality Factors

Functionality: suitability, accuracy, Functionality: suitability, accuracy, interoperability, compliance and security.interoperability, compliance and security.

Reliability: maturity, fault tolerance, recoverability.Reliability: maturity, fault tolerance, recoverability. Usability: understandability, learnability, Usability: understandability, learnability,

operability. operability. Efficiency: time behavior, resource behavior.Efficiency: time behavior, resource behavior. Maintainability: analyzability, changeability, Maintainability: analyzability, changeability,

stability, testability. stability, testability. Portability: adaptibility, installability, conformance, Portability: adaptibility, installability, conformance,

replaceability. replaceability.

7

8

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

9

Measurement Measurement PrinciplesPrinciples

The objectives of measurement should be The objectives of measurement should be established before data collection begins;established 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 Metrics should be derived based on a theory that is valid for the domain of application (e.g., is valid for the domain of application (e.g., metrics for design should draw upon basic design metrics for design should draw upon basic design concepts and principles and attempt to provide concepts and principles and attempt to provide an indication of the presence of an attribute that an indication of the presence of an attribute that is deemed desirable);is deemed desirable);

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

10

Measurement ProcessMeasurement Process

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

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

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

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

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

11

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 that is specific to

the process activity or product characteristic that is to be the process activity or product characteristic that is to be assessedassessed

(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 {the environment in which the measurement

takes place}.takes place}.

12

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

how to derive the metric, and its computation should not how to derive the metric, and its computation should not demand inordinate effort or timedemand inordinate effort or time

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

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

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

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

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

13

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

14

Analysis MetricsAnalysis Metrics

Function-based metricsFunction-based metrics:: use the function point as a use the function point as a normalizing factor or as a measure of the “size” of the normalizing factor or as a measure of the “size” of the specificationspecification Function points are a measure of the size of computer Function points are a measure of the size of computer

applications and the projects that build them. The size is applications and the projects that build them. The size is measured from a functional, or user, point of view. It is measured from a functional, or user, point of view. It is independent of the computer language, development independent of the computer language, development methodology, technology or capability of the project team methodology, technology or capability of the project team used to develop the application. used to develop the application.

http://ourworld.compuserve.com/homepages/softcomp/http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm#WhatAreFunctionPointsfpfaq.htm#WhatAreFunctionPoints

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

15

Function-Based MetricsFunction-Based Metrics

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

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

Information domain values are defined in the following Information domain values are defined in the following manner: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)

16

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

*

*

*

*

*

FP = count total*[0.65 + 0.01*∑(Fi)]

Fi : http://www.ifpug.com/fpafund.htm

17

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

*

*

*

*

*

2

3

2

1

4

9

8

6

7

20

50

Suppose *∑(Fi) = 46, thenFP = count total*[0.65 + 0.01*∑(Fi)] = 50*[0.65+0.01*46] = 56

18

General System Characteristic (0-5) Brief Description

1. Data communications How many communication facilities are there to aid in the transfer or exchange of information with the application or system?

2. Distributed data processing How are distributed data and processing functions handled?

3. Performance Was response time or throughput required by the user?

4. Heavily used configuration How heavily used is the current hardware platform where the application will be executed?

5. Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.?

6. On-Line data entry What percentage of the information is entered On-Line?

7. End-user efficiency Was the application designed for end-user efficiency?

8. On-Line update How many ILF’s are updated by On-Line transaction?

9. Complex processing Does the application have extensive logical or mathematical processing?

10. Reusability Was the application developed to meet one or many user’s needs?

11. Installation ease How difficult is conversion and installation?

12. Operational ease How effective and/or automated are start-up, back-up, and recovery procedures?

13. Multiple sites Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?

14. Facilitate change Was the application specifically designed, developed, and supported to facilitate change?

19

Metrics for specification Metrics for specification QualityQuality

The number of requirements: nThe number of requirements: nrr = n = nff +n +nnf nf

nnff is the number of function req. is the number of function req. nnnf nf is the number of non-functional req. is the number of non-functional req.

Specificity: QSpecificity: Q11= n= nuiui /n /nr r

nnuiui is the number of req. that all reviewers have the same is the number of req. that all reviewers have the same interpretation.interpretation.

Completeness: QCompleteness: Q22= n= nuu /[n /[ni i *n*nss]] nnuu is the number of unique function req. is the number of unique function req. nnii is the number of inputs defined (implied) by the req. is the number of inputs defined (implied) by the req. nnss is the number of states defined. is the number of states defined.

Degree of validation: QDegree of validation: Q33= n= ncc /[n /[nc c +n+nnvnv]] nncc is the number of req. that have been validated as correct. is the number of req. that have been validated as correct. nnnvnv is the number of req. that have not yet been validated. is the number of req. that have not yet been validated.

20

Architectural Design MetricsArchitectural Design Metrics

Architectural design metricsArchitectural design metrics Structural complexity: S(i) = fStructural complexity: S(i) = f22

fan-outfan-out (i)(i)

Data complexity: D(i) = v(i)/[fData complexity: D(i) = v(i)/[ffan-outfan-out (i)+1](i)+1]

System complexity: C(i) = S(i)+D(i)System complexity: C(i) = S(i)+D(i) 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 Size = n (number of nodes )+a (number of arcs)Size = n (number of nodes )+a (number of arcs) Arc-to-node ratio: r = a/nArc-to-node ratio: r = a/n

21

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

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

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

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 the degree to which an abstraction possesses the features

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

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

abstraction or design component can be reusedabstraction or design component can be reused

22

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

23

Distinguishing Distinguishing CharacteristicsCharacteristics

Localization—the way in which information is Localization—the way in which information is concentrated in a programconcentrated in a program

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

about operational details is hidden by a secure about operational details is hidden by a secure interfaceinterface

Inheritance—the manner in which the responsibilities Inheritance—the manner in which the responsibilities of one class are propagated to anotherof one class are propagated to another

Abstraction—the mechanism that allows a design to Abstraction—the mechanism that allows a design to focus on essential detailsfocus on essential details

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

24

Object-Oriented Object-Oriented MetricsMetrics

1)1) Average Method Size (Line of Code-LOC):Average Method Size (Line of Code-LOC): It should be less than 8 It should be less than 8 LOC for Smalltalk and 24 LOC for C++.LOC for Smalltalk and 24 LOC for C++.

2)2) Average Number of Methods per ClassAverage Number of Methods per Class: It should be less than 20.: It should be less than 20. Bigger averages Bigger averages indicate too much responsibility in too few classes.indicate too much responsibility in too few classes.

3)3) Average Number of Instance Variables per Class:Average Number of Instance Variables per Class: It should be less than 6. It should be less than 6. More instance variables indicate that one class is doing too more than it should. More instance variables indicate that one class is doing too more than it should.

4)4) Class Hierarchy Nesting Level (Depth of Inheritance-DIT)Class Hierarchy Nesting Level (Depth of Inheritance-DIT): It should be : It should be less than 6, starting from the framework classes or the root class.less than 6, starting from the framework classes or the root class.

5)5) Number of Subsystem/Subsystem RelationshipsNumber of Subsystem/Subsystem Relationships: It should be less than the : It should be less than the number in metric 6.number in metric 6.

6)6) Number of Class/Class Relationships in Each Subsystem:Number of Class/Class Relationships in Each Subsystem: It should be It should be relatively high. This relates to high cohesion of classes in the same subsystem. If one or more classes relatively high. This relates to high cohesion of classes in the same subsystem. If one or more classes in a subsystem do not interact with many of the other classes, they might be better placed in another in a subsystem do not interact with many of the other classes, they might be better placed in another subsystem. subsystem.

7)7) Instance Variable UsageInstance Variable Usage:: If groups of methods in a class use different sets of If groups of methods in a class use different sets of instance variables, examine the design closely to see if the class should be split into multiple classes instance variables, examine the design closely to see if the class should be split into multiple classes along those “service” lines.along those “service” lines.

8)8) Average Number of Comment Lines (Per MethodAverage Number of Comment Lines (Per Method): It should be greater ): It should be greater than 1.than 1.

9)9) Number of Problem Reports:Number of Problem Reports: It should be low. It should be low. 10)10) Number of Times Class is ReusedNumber of Times Class is Reused: A class should be redesigned if it is not : A class should be redesigned if it is not

reused in a different application.reused in a different application. 11)11) Number of Classes and Methods Thrown awayNumber of Classes and Methods Thrown away: It should occur at a steady : It should occur at a steady

rate throughout most of the development process. If this is not occurring, it is probably doing an rate throughout most of the development process. If this is not occurring, it is probably doing an incremental development rather than an iterative OO development. incremental development rather than an iterative OO development.

Proposed by Lorenz in 1993:Proposed by Lorenz in 1993:

25

Some OO Metrics for Six Projects

Metric Project A (C++)

Project B (C++)

Project C (C++)

Project D (IBM Smalltalk)

Project E (OTI Smalltalk)

Project F (Digital Smalltalk)

Number of Class 5,741 2,513 3,000 100 566 492

Methods per Class

8 3 7 17 36 21

LOC per Method

21 19 15 5.3 5.2 5.7

LOC per Class 207 60 100 97 188 117

Max DIT 6 NA 5 6 8 NA

Average DIT NA NA 3 4.8 2.8 NA

26

The CK OO Metrics Suite The CK OO Metrics Suite

Metric 1: Weighted Methods per Class (WMC)Metric 1: Weighted Methods per Class (WMC) WMC = ∑CWMC = ∑Cii, where, C, where, Cii is the complexity of method i is the complexity of method i

Metric 2: Depth of Inheritance Tree (DIT)Metric 2: Depth of Inheritance Tree (DIT) Metric 3: Number Of Children (NOC)Metric 3: Number Of Children (NOC) Metric 4: Coupling Between Object classes (CBO)Metric 4: Coupling Between Object classes (CBO) Metric 5: Response For Class (RFC) Metric 5: Response For Class (RFC) Metric 6: Lack of Cohesion On Methods (LCOM)Metric 6: Lack of Cohesion On Methods (LCOM)

Proposed by Chidamber and Kemerer, Proposed by Chidamber and Kemerer, 9494::

27

Productivity in Terms of Number of Classes per PY

Metric Project A (C++)

Project B (C++)

Project C (C++)

Project D (IBM Smalltalk)

Project F (Digital Smalltalk)

PY 100 35 90 2 10

Classes per PY 57.4 71.8 33.3 50 49.2

Classes per PM 4.8 6 2.8 4.2 4.1

Methods per PM

8 18 20 71 86

LOC per PM 168 342 300 376 456

LOC per PH 1.05 2.14 1.88 2.35 2.85

28

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)

29

Interface Design MetricsInterface Design Metrics

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

Cohesion metric: measures the relative connection Cohesion metric: measures the relative connection of a on-screen content to other on-screen content. of a on-screen content to other on-screen content. If data presented on a screen belongs to a single major If data presented on a screen belongs to a single major

data object, UI cohesion for that screen is high. data object, UI cohesion for that screen is high. If many different types of data or content are presented If many different types of data or content are presented

and these data are related to different data objects, UI and these data are related to different data objects, UI cohesion is low.cohesion is low.

30

Code MetricsCode Metrics

Halstead’s Software Science:Halstead’s Software Science: a a comprehensive collection of metrics all comprehensive collection of metrics all predicated on the number (count and predicated on the number (count and occurrence) of operators and operands within occurrence) of operators and operands within a component or programa 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 generated substantial controversy, and many believe that the underlying theory has flaws. believe that the underlying theory has flaws. However, experimental verification for selected However, experimental verification for selected programming languages has been performed (e.g. programming languages has been performed (e.g. [FEL89]).[FEL89]).

31

CodeCode

nn1 1 :the number of distinct operators that appear :the number of distinct operators that appear in a programin a program

nn2 2 : the number of distinct operands …: the number of distinct operands …

NN1 1 : the total number of operator occurrences: the total number of operator occurrences

NN2 2 :the total number of operand occurrences:the total number of operand occurrences

Length: N = nLength: N = n11loglog22nn1 1 ++ nn22loglog22nn22

Volume: NlogVolume: Nlog22(n(n11+n+n22))

Volume ratio: L = 2/nVolume ratio: L = 2/n1 1 * n* n22/ N/ N22

32

Metrics for TestingMetrics for Testing

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

Binder [BIN94] suggests a broad array of design metrics Binder [BIN94] suggests a broad array of design metrics that have a direct influence on the “testability” of an OO that have a direct influence on the “testability” of an OO system. 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) (Multiple Inheritance). Fan-in (FIN) (Multiple Inheritance). Number of children (NOC) and depth of the inheritance tree Number of children (NOC) and depth of the inheritance tree

(DIT).(DIT).

33

Metrics for MaintenanceMetrics for Maintenance

The number of modules:The number of modules: MMT T : ~: ~ in the current releasein the current release

FFcc: ~ that have been changed in the current release: ~ that have been changed in the current release

FFa a : ~ that have been added~~: ~ that have been added~~

FFd d : ~ that have been deleted~~ from the preceding : ~ that have been deleted~~ from the preceding releaserelease

Software maturity index: SMI = [MSoftware maturity index: SMI = [MT T --

(F(Fcc+F+Faa+F+Fdd)]/ M)]/ MTT

34

SummarySummary

Software QualitySoftware Quality Measure, Measurement, and MetricsMeasure, Measurement, and Metrics Metrics for AnalysisMetrics for Analysis Metrics for DesignMetrics for Design Metrics for Source CodeMetrics for Source Code Metrics for TestingMetrics for Testing Metrics for Maintenance Metrics for Maintenance