Technical Metrics for Software Chapter 18

Chapter Assistance -- Michael Jager January 9, Chapter Outline D Software Quality D A Framework for Technical Software Metrics D Metrics for the Analysis Model D Metrics for the Design Model D Metrics for Source Code D Metrics for Testing D Metrics for Maintenance D Summary

Chapter Assistance -- Michael Jager January 9, Technical Metrics D Are NOT absolute (hence they are open to debate) D Provide us with a systematic way to assess quality D Provide insight into product quality on-the-spot rather than after-the-fact

Chapter Assistance -- Michael Jager January 9, Software Quality D Software requirements are the foundation from which quality is measured. D Specified standards define a set of development criteria that guide the manner in which software is engineered. D There is a set of implicit requirements that often goes unmentioned. D Software quality is a complex mix of factors that will vary across different applications and the customers who request them.

Chapter Assistance -- Michael Jager January 9, McCall’s Software Quality Factors Maintainability Flexibility Testability Portability Reusability Interoperability Correctness Reliability Usability Integrity Efficiency Product Operation Product Revision Product Transition

Chapter Assistance -- Michael Jager January 9, HP’s FURPS D F unctionality - evaluate the feature set and capabilities of the program D U sability - aesthetics, consistency, documentation D R eliability - frequency and severity of failures D P erformance - processing speed, response time, resource consumption, throughput, efficiency D S upportability - maintainability testability, compatibility, ease of installation

Chapter Assistance -- Michael Jager January 9, Transition to a Quantitative View D Previous slides described qualitative factors for the measurement of software quality D Everyday quality measurements D gymnastics, wine tasting, talent contests D side by side comparisons D quality judged by an expert in the field D Quantitative metrics don’t explicitly measure quality, but some manifestation of quality

Chapter Assistance -- Michael Jager January 9, The Challenge of Technical Metrics D Each quality measurement takes a different view of what quality is and what attributes in a system lead to complexity. D The goal is to develop measures of different program attributes to use as indicators of quality. D Unfortunately, a scientific methodology of realizing this goal has not been achieved.

Chapter Assistance -- Michael Jager January 9, Measurement Principles D Formulation - derivation of software metrics appropriate for the software being considered D Collection - accumulating data required to derive the formulated metrics D Analysis - computation of metrics and application of mathematical tools D Interpretation - evaluation of metrics in an effort to gain insight into the quality of the system D Feedback - recommendations derived from the interpretation of metrics

Chapter Assistance -- Michael Jager January 9, Attributes of Effective Software Metrics D Simple and computable D Empirically and intuitively persuasive D Consistent and objective D Consistent in units and dimensions D Programming language independent D Effective mechanism for quality feedback

Chapter Assistance -- Michael Jager January 9, Function Based Metrics D The Function Point (FP) metric can be used as a means for predicting the size of a system (derived from the analysis model). D number of user inputs D number of user outputs D number of user inquiries D number of files D number of external interfaces

Chapter Assistance -- Michael Jager January 9, Function Point Metric Weighting Factor MEASUREMENT PARAMETERcountsimpleaveragecomplextotal number of user inputs3 x346= 9 number of user outputs2 x457= 8 number of user inquiries2 x346= 6 number of files1 x71015= 7 number of external interfaces4 x5710= 20 count - total 50 Overall implemented size can be estimated from the projected FP value FP = count-total  (   F i )

Chapter Assistance -- Michael Jager January 9, The Bang Metric D Used to predict the application size based on the analysis model. D The software engineer first evaluates a set of primitives unsubdividable at the analysis level. D With the evaluation of these primitives, software can be defined as either function-strong or data- strong. D Once the Bang metric is computed, past history must be used to predict software size and effort.

Chapter Assistance -- Michael Jager January 9, Metrics for Requirements Quality D Requirements quality metrics - completeness, correctness, understandability, verifiability, consistency, achievability, traceability, modifiability, precision, and reusability - design metric for each. See Davis. D E.g., let n r = n f + n nf, where D n r = number of requirements D n f = number of functional requirements D n nf = number of nonfunctional requirements

Chapter Assistance -- Michael Jager January 9, Metrics for Requirements Quality D Specificity (lack of ambiguity) D Q = n ui /n r D n ui - number of requirements for which all reviewers had identical interpretations D For completeness, D Q = n u /(n i  n s ) D n u = number of unique function requirements D n i = number of inputs specified D n s = number of states specified

Chapter Assistance -- Michael Jager January 9, High-Level Design Metrics D Structural Complexity D S(i) = f 2 out (i) D f out (i) = fan-out of module i D Data Complexity D D(i) = v(i)/[f out (i) +1] D v(i) = # of input and output variables to and from module i D System Complexity D C(i) = S(i) + D(i)

Chapter Assistance -- Michael Jager January 9, High-Level Design Metrics (Cont.) D Morphology Metrics D size = n + a D n = number of modules D a = number of arcs (lines of control) D arc-to-node ratio, r = a/n D depth = longest path from the root to a leaf D width = maximum number of nodes at any level

Chapter Assistance -- Michael Jager January 9, Morphology Metrics a bcde f g ij k l hmn pq r sizedepthwidtharc-to node ratio

Chapter Assistance -- Michael Jager January 9, AF Design Structure Quality Index u S1 = total number of modules u S2 = # modules dependent upon correct data source or produces data used, excl. control u S3 = # modules dependent upon prior processing u S4 = total number of database items u S5 = # unique database items u S6 = # of database segments u S7 = # modules with single entry & exit

Chapter Assistance -- Michael Jager January 9, AF Design Structure Quality Index u D 1 = 1 if arch design method used, else 0 u D 2 = 1 - (S2/S1) -- module independence u D 3 = 1 - (S3/S1) -- independence of prior processing u D 4 = 1 - (S5/S4) -- database size u D 5 = 1 - (S6/S4) -- DB compartmentalization u D 6 = 1 - (S7/S1) -- Module entrance/exit

Chapter Assistance -- Michael Jager January 9, u DSQI =  w i D i, where the w i are weights totaling 1 which give the relative importance u The closer this is to one, the higher the quality. u This is best used on a comparison basis, i.e., with previous successful projects. u If the value is too low, more design work should be done. AF Design Structure Quality Index

Chapter Assistance -- Michael Jager January 9, Component-Level Design Metrics D Cohesion Metrics D Coupling Metrics D data and control flow coupling D global coupling D environmental coupling D Complexity Metrics D Cyclomatic complexity D Experience shows that if this > 10, it is very difficult to test

Chapter Assistance -- Michael Jager January 9, Cohesion Metrics u Data slice - data values within the module that affect the module location at which a backward trace began. u Data tokens - Variables defined for a module u Glue Tokens - The set of tokens lying on multiple data slices u Superglue tokens - The set of tokens on all slices u Stickiness - of a glue token is proportional to number of data slices that it binds u Strong Functional Cohesion SFC(i) = SG(i)/tokens(i)

Chapter Assistance -- Michael Jager January 9, Coupling Metrics D Data and control flow coupling D d i = number of input data parameters D c i = number of input control parameters D d 0 = number of output data parameters D c 0 = number of output control parameters D Global coupling D g d = number of global variables used as data D g c = number of global variables used as control D Environmental coupling D w = number of modules called (fan-out) D r = number of modules calling the module under consideration (fan-in) D Module Coupling:m c = 1/ (d i + 2*c i + d 0 + 2*c 0 + g d + 2*g c + w + r) D m c = 1/( ) =.33(Low Coupling) D m c = 1/(5 + 2* * ) =.02 (High Coupling)

Chapter Assistance -- Michael Jager January 9, Interface Design Metrics D Layout Entities - graphic icons, text, menus, windows,. D Layout Appropriateness D absolute and relative position of each layout entity D frequency used D cost of transition from one entity to another D LA = 100 x [(cost of LA-optimal layout) / (cost of proposed layout)] D Final GUI design should be based on user feedback on GUI prototypes

Chapter Assistance -- Michael Jager January 9, Metrics for Source Code D Software Science Primitives D n 1 = the number of distinct operators D n 2 = the number of distinct operands D N 1 = the total number of operator occurrences D N 2 = the total number of operand occurrences Length: N = n 1 log 2 n 1 + n 2 log 2 n 2 Volume: V = Nlog 2 (n 1 + n 2 )

Chapter Assistance -- Michael Jager January 9, Metrics for Source Code ( Cont. ) SUBROUTINE SORT (X,N) DIMENSION X(N) IF (N.LT.2) RETURN DO 20 I=2,N DO 10 J=1,I IF (X(I).GE.X(J) GO TO 10 SAVE = X(I) X(I) = X(J) X(J) = SAVE 10 CONTINUE 20 CONTINUE RETURN END OPERATOR COUNT 1 END OF STATEMENT 7 2 ARRAY SUBSCRIPT 6 3 = 5 4 IF( ) 2 5DO 2 6, 2 7END OF PROGRAM 1 8.LT. 1 9.GE. 1 10GO TO 10 1 n 1 = 10 N 1 = 28 n 2 = 7 N 2 = 22

Chapter Assistance -- Michael Jager January 9, Metrics for Testing D Analysis, design, and code metrics guide the design and execution of test cases. D Metrics for Testing Completeness D Breadth of Testing - total number of requirements that have been tested D Depth of Testing - percentage of independent basis paths covered by testing versus total number of basis paths in the program. D Fault profiles used to prioritize and categorize errors uncovered.

Chapter Assistance -- Michael Jager January 9, Metrics for Maintenance D Software Maturity Index (SMI) D M T = number of modules in the current release D F c = number of modules in the current release that have been changed D F a = number of modules in the current release that have been added D F d = number of modules from the preceding release that were deleted in the current release SMI = [M T - (F c + F a + F d )] / M T

Chapter Assistance -- Michael Jager January 9, Summary D Software metrics provide a quantitative way to asses the quality of product attributes. D A software metric needs to be simple, computable, persuasive, consistent, and objective. D The function point and bang metrics provide quantitative means for evaluating the analysis model. D Metrics for design consider high-level, component level, and interface design issues.

Chapter Assistance -- Michael Jager January 9, Summary D Interface design metrics provide an indication of layout appropriateness for a GUI. D Using the number of operators and operands present in the code provides a variety of metrics to assess program quality. D Using the metrics as a comparison with known successful or unsuccessful projects is better than treating them as absolute quantities.