Chapter 23 - Product Metrics for Software Overview This chapter describes the use of product metrics in the software

quality assurance process. Software engineers use product metrics to help them assess the quality of the design and construction the software product being built. Product metrics provide software engineers with a basis to conduct analysis, design, coding, and testing more objectively. Qualitative criteria for assessing software quality are not always sufficient by themselves. The process of using product metrics begins by deriving the software measures and metrics that are appropriate for the software representation under consideration. Then data are collected and metrics are computed. The metrics are computed and compared to pre established guidelines and historical data. The results of these comparisons are used to guide modifications made to wor! products arising from analysis, design, coding, or testing. "efinitions #easure $ provides a quantitative indication of the e%tent, amount, capacity, or si&e of some attribute of a product or process #easurement $ act of determining a measure #etric $ statistic that relates individual measures to one another 'ndicator $ metric or combination of metrics that provide insight into the software process, software project, or the product itself to ma!e things better

(enefits of Product #etrics ). *ssist in the evaluation of the analysis and evaluation model +. Provide indication of procedural design comple%ity and source code comple%ity ,. -acilitate design of more effective testing #easurement Process *ctivities Formulation $ derivation of software measures and metrics appropriate for software representation being considered Collection $ mechanism used to accumulate the date used to derive the software metrics Analysis $ computation of metrics Interpretation $ evaluation of metrics that results in gaining insight into quality of the wor! product

Feedback $ recommendations derived from interpretation of the metrics is transmitted to the software development team

#etrics .haracteri&ation and /alidation Principles * metric should have desirable mathematical properties The value of a metric should increase when positive software traits occur or decrease when undesirable software traits are encountered 0ach metric should be validated empirically in several conte%ts before it is used to ma!e decisions

#easurement .ollection and *nalysis Principles ). *utomate data collection and analysis whenever possible +. 1se valid statistical techniques to establish relationships between internal product attributes and e%ternal quality characteristics ,. 0stablish interpretive guidelines and recommendations for each metric 2oal Oriented Software #easurement 32Q#4 * goal definition template can be used to define each measurement goal 2Q# emphasi&es the need ). establish e%plicit measurement goal specific to the process activity or product characteristic being assessed +. define a set of questions that must be answered in order to achieve the goal ,. identify well formulated metrics that help to answer these questions

*ttributes of 0ffective Software #etrics Simple and computable 0mpirically and intuitively persuasive .onsistent and objective .onsistent in use of units and measures Programming language independent Provide an effective mechanism for quality feedbac!

5equirements #odel #etrics -unction based metrics

o -unction points Specification quality metrics 3"avis46 o Specificity o .ompleteness

*rchitectural "esign #etrics Structural comple%ity 3based on module fanout4 "ata comple%ity 3based on module interface inputs and outputs4 System comple%ity 3sum of structural and data comple%ity4 #orphology 3number of nodes and arcs in program graph4 "esign structure quality inde% 3"SQ'4

OO "esign #etrics Size3population, volume, length, functionality4 Complexity 3how classes interrelate to one another4 Coupling 3physical connections between design elements4 Sufficiency 3how well design components reflect all properties of the problem domain4 Completeness 3coverage of all parts of problem domain4 Cohesion 3manner in which all operations wor! together4 Primitiveness 3degree to which attributes and operations are atomic4 Similarity 3degree to which two or more classes are ali!e4 Volatility 3li!elihood a design component will change4

.lass Oriented #etrics .hidamber and 7emerer 3.74 #etrics Suite o weighted metrics per class 38#.4 o depth of inheritance tree 3"'T4 o number of children 39O.4 o coupling between object classes 3.(O4 o response for a class35-.4 o lac! of cohesion in methods 3:.O#4 ;arrison, .ounsel, and 9ithi 3#OO"4 #etrics Suite o method inheritance factor 3#'-4 o coupling factor 3.-4 o polymorphism factor 3P-4 :oren& and 7idd

o o o o

class si&e 3.S4 number of operations overridden by a subclass 39OO4 number of operations added by a subclass 39O*4 speciali&ation inde% 3S'4

.omponent :evel "esign #etrics .ohesion metrics 3data slice, data to!ens, glue to!ens, superglue to!ens, stic!iness4 .oupling metrics 3data and control flow, global, environmental4 .omple%ity metrics 3e.g. cyclomatic comple%ity4

Operation Oriented #etrics *verage operation si&e 3OSavg4 Operation comple%ity 3O.4 *verage number of parameters per operation 39Pavg4 1sing 8eb*pp "esign #etrics 's the 8eb*pp interface usable< *re the aesthetics of the 8eb*pp pleasing to the user and appropriate for the information domain< 's the content designed to impart the most information for the least amount of effort< 's navigation efficient and straightforward< ;as the 8eb*pp architecture been designed to accommodate special goals and objectives of users, content structure, functionality, and effective navigation flow< *re the 8eb*pp components designed to reduce procedural comple%ity and enhance correctness, reliability, and performance<

8eb*pp 'nterface #etrics :ayout appropriateness :ayout comple%ity :ayout region comple%ity 5ecognition comple%ity 5ecognition time Typing effort #ouse pic! effort

Selection comple%ity .ontent acquisition time

*esthetic 3graphic layout4 metrics 8ord count (ody te%t percentage 0mphasi&ed body te%t = Te%t positioning count Te%t cluster count :in! count Page si&e 2raphic percentage 2raphics count .olor count -ont count

.ontent #etrics Page wait Page comple%ity 2raphic comple%ity *udio comple%ity /ideo comple%ity *nimation comple%ity Scanned image comple%ity

9avigation #etrics Page lin! comple%ity .onnectivity .onnectivity density

;alstead>s Software Science 3Source .ode #etrics4 Overall program length Potential minimum algorithm volume *ctual algorithm volume 3number of bits used to specify program4 Program level 3software comple%ity4

:anguage level 3constant for given language4

Testing #etrics #etrics that predict the li!ely number of tests required during various testing phases o *rchitectural design metrics o .yclomatic comple%ity can target modules that are candidates for e%tensive unit testing o ;alstead effort #etrics that focus on test coverage for a given component o .yclomatic comple%ity lies at the core of basis path testing

Object Oriented Testing #etrics 0ncapsulation o :ac! of cohesion in methods 3:.O#4 o Percent public and protected 3P*P4 o Public access to data members 3P*"4 'nheritance o 9umber of root classes 39O54 o -an in 3-'94 o 9umber of children 39O.4 o "epth of inheritance tree 3"'T4

#aintenance #etrics Software #aturity 'nde% 3'000 Standard ?@+.) )?@@4 S#' approaches ).A as product begins to stabili&e