Product Metrics for Software - CINVESTAVertello/swe/sesion19.pdfMeasurement process Formulation. The...

Product Metrics for SoftwareProduct Metrics for Software

Eduardo Rodriguez‐Tello, PhD 1© Cinvestav‐Tamaulipas 2009 ‐ 2012

ContentContentSoftware qualitySoftware quality

Metrics for the analysis model

Metrics for the design modelMetrics for the design model

Metrics for source code

Metrics for testing

Metrics for maintenance

Software Engineering 2Eduardo Rodriguez‐Tello, PhD © Cinvestav‐Tamaulipas 2009 ‐ 2012

McCall’s triangle of qualityMcCall s triangle of quality


A commentA comment

McCall’s quality factors were proposed in theMcCall s quality factors were proposed in theearly 1970s

They are as valid today as they were in that timey y y

I ’ lik l h f b il f hIt’s likely that software built to conform to thesefactors will exhibit high quality well into the 21stcentury, even if there are dramatic changes intechnologytechnology


Measures, metrics and indicatorsMeasures, metrics and indicators

A measure provides a quantitative indication of theA measure provides a quantitative indication of theextent, amount, dimension, capacity, or size of someattribute of a product or processattribute of a product or process

The IEEE glossary defines a metric as “a quantitativemeasure of the degree to which a system, component,or process possesses a given attribute”p p g

An indicator is a metric or combination of metrics thatprovide insight into the software process a softwareprovide insight into the software process, a softwareproject, or the product itself


Measurement principlesMeasurement principles

The objectives of measurement should be established beforeThe objectives of measurement should be established beforedata collection begins

Each technical metric should be defined in an unambiguousEach technical metric should be defined in an unambiguousmanner

Metrics should be derived based on a theory that is valid for theMetrics should be derived based on a theory that is valid for thedomain of application (e.g., metrics for design should drawupon basic design concepts and principles and attempt toupon basic design concepts and principles and attempt toprovide an indication of the presence of an attribute that isdeemed desirable)deemed desirable)

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


Measurement processMeasurement processFormulation. The derivation of software measures and metricsFormulation. The derivation of software measures and metricsappropriate for the representation of the software that is beingconsidered

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

Analysis. The computation of metrics and the application ofmathematical toolsmathematical tools

Interpretation. The evaluation of metrics results in an effort togain insight into the quality of the representationgain insight into the quality of the representation

Feedback. Recommendations derived from the interpretation ofd t t i t itt d t th ft tproduct metrics transmitted to the software team


Goal‐oriented software measurementGoal oriented software measurementThe Goal/Question/Metric Paradigm/ / g

(1) establish an explicit measurement goal that is specific to the processactivity or product characteristic that is to be assessed(2) define a set of questions that must be answered in order to achieve(2) define a set of questions that must be answered in order to achievethe goal, and(3) identify well‐formulatedmetrics that help to answer these questions

Goal definition templateAnalyze {the name of activity or attribute to be measured}for the purpose of {the overall objective of the analysis}with respect to {the aspect of the activity or attribute that is considered}f th i i t f {th l h h i t t i thfrom the viewpoint of {the people who have an interest in themeasurement}in the context of {the environment in which the measurement takesf {place}


Metrics attributesMetrics attributessimple and computable. It should be relatively easy to learn how to derivethe metric, and its computation should not demand inordinate effort or timeempirically and intuitively persuasive. The metric should satisfy theengineer’s intuitive notions about the product attribute under considerationengineer s intuitive notions about the product attribute under considerationconsistent and objective. The metric should always yield results that areunambiguousconsistent in its use of units and dimensions. The mathematicalcomputation of the metric should use measures that do not lead to bizarrecombinations of unitcombinations of unitprogramming language independent. Metrics should be based on theanalysis model, the design model, or the structure of the program itselfan effective mechanism for quality feedback. That is, the metric shouldprovide a software engineer with information that can lead to a higherquality end productq y p


Collection and analysis principlesCollection and analysis principles

Whenever possible data collection and analysisWhenever possible, data collection and analysisshould be automated

Valid statistical techniques should be applied toq ppestablish relationship between internal productattributes and external quality characteristicsattributes and external quality characteristics

Interpretative guidelines and recommendations shouldbe established for each metric


Analysis metricsAnalysis metrics

Function‐based metrics: use the function point as aFunction based metrics: use the function point as anormalizing factor or as a measure of the “size” of thespecificationspecification

Specification metrics: used as an indication of qualityby measuring number of requirements by typeby measuring number of requirements by type


Function‐based metricsFunction based metricsThe function point metric (FP), first proposed by AlbrechtThe function point metric (FP), first proposed by Albrecht[ALB79], can be used effectively as a means for measuring thefunctionality delivered by a systemy y y

Function points are derived using an empirical relationshipbased on countable (direct) measures of software's informationbased on countable (direct) measures of software s informationdomain and assessments of software complexityInformation 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 outputs (EOs)f p ( )number of external inquiries (EQs)number of internal logical files (ILFs)Number of external interface files (EIFs)


Function pointsFunction points


Architectural design metricsArchitectural design metrics

Architectural design metricsArchitectural design metricsStructural complexity = g(fan‐out)

D l i f(i & i bl f )Data complexity = f(input & output variables, fan‐out)

System complexity = h(structural & data complexity)

HK metric: architectural complexity as a function offan‐in and fan‐outfan in and fan out

Morphology metrics: a function of the number ofd l d th b f i t f b tmodules and the number of interfaces between

modules


Metrics for OO designMetrics for OO designWhitmire [WHI97] describes nine distinct and measurable[ ]characteristics of an OO design:

SizeSize is defined in terms of four views: population, volume, length, andfunctionality

ComplexityComplexityHow classes of an OO design are interrelated to one another

CouplingThe physical connections between elements of the OO design

Sufficiency“the degree to which an abstraction possesses the features required of it orthe degree to which an abstraction possesses the features required of it, orthe degree to which a design component possesses features in itsabstraction, from the point of view of the current application”

C l tCompletenessAn indirect implication about the degree to which the abstraction or designcomponent can be reused


Metrics for OO design…Metrics for OO design…CohesionCohesion

The degree to which all operations working together to achieve asingle, well‐defined purpose

PrimitivenessApplied to both operations and classes, the degree to which anpp p , goperation is atomic

SimilarityThe degree to which two or more classes are similar in terms of theirstructure, function, behavior, or purpose

VolatilityMeasures the likelihood that a change will occur


Distinguishing characteristicsDistinguishing characteristics

Berard [BER95] argues that the followingBerard [BER95] argues that the followingcharacteristics require that special OO metrics bedeveloped:developed:

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

E l ti th k i f d t d iEncapsulation—the packaging of data and processing

Information hiding—the way in which information about operationaldetails is hidden by a secure interfacedetails is hidden by a secure interface

Inheritance—the manner in which the responsibilities of one class arepropagated to anotherp p g

Abstraction—the mechanism that allows a design to focus on essentialdetails


Class‐oriented metricsClass oriented metrics

Proposed by Chidamber and Kemerer:Proposed by Chidamber and Kemerer:weighted methods per class

depth of the inheritance treep

number of children

coupling between object classes

response for a class

lack of cohesion in methods

Proposed by Lorenz and Kidd [LOR94]:class size

number of operations overridden by a subclass

number of operations added by a subclass

specialization index


Component‐level design metricsComponent level design metrics

Cohesion metrics: a function of data objects and theCohesion metrics: a function of data objects and thelocus of their definition

Coupling metrics: a function of input and outputp g p pparameters, global variables, and modules called

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


Interface design metricsInterface design metrics

Layout appropriateness: a function of layout entitiesLayout appropriateness: a function of layout entities,the geographic position and the “cost” of makingtransitions among entitiestransitions among entities


Code metricsCode metrics

Halstead’s Software Science: a comprehensiveHalstead s Software Science: a comprehensivecollection of metrics all predicated on the number(count and occurrence) of operators and operands(count and occurrence) of operators and operandswithin a component or program

It should be noted that Halstead’s “laws” have generatedsubstantial controversy, and many believe that theunderlying theory has flaws. However, experimentalverification for selected programming languages has been

f d ( [ ])performed (e.g. [FEL89])


Metrics for testingMetrics for testingTesting effort can also be estimated using metricsTesting effort can also be estimated using metricsderived from Halstead measuresBinder [BIN94] suggests a broad array of designBinder [BIN94] suggests a broad array of designmetrics that have a direct influence on the “testability”of an OO systemof an OO system

Lack of cohesion in methods (LCOM)Percent public and protected (PAP)Percent public and protected (PAP)Public access to data members (PAD)Number of root classes (NOR)Number of root classes (NOR)Fan‐in (FIN)Number of children (NOC) and depth of the inheritance tree( ) p(DIT)


Date post:	27-Jul-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Product Metrics for Software - CINVESTAVertello/swe/sesion19.pdfMeasurement process Formulation. The...

Documents