1. Software Metrics II Speaker: Jerry Gao Ph.D. San Jose State University email: jerrygao@email.sjsu.edu URL: http://www.engr.sjsu.edu/gaojerry Sept., 2001

2. Topic: Software Metrics II - Technical Metrics for Software - Software Measurement and Technical Software Metrics - Software Quality Metrics - Metrics for the Analysis Model - Metrics for the Design Model - Metrics for Source Code - Metrics for Testing - Metrics for Maintenance Jerry Gao Ph.D.9/2001 Presentation Outline All Rights Reserved

3. Jerry Gao Ph.D.9/2001 Overview of Software Technical Metrics Topic: Software Metrics II - Technical Metrics for Software Technical metrics help software engineers gain insight into the design and construction of the product they build. Objectives of technical metrics: - assist in the evaluation of the analysis and design models - provide an indication of the complexity of procedural design & coding - facilitate the design of more effective testing Technical metrics provide a basis from which analysis, design, coding, and testing can be assessed and evaluated objectively in an quantitative way. Who use it? Software Engineers What are the steps? - Derive software measures and metrics - Collect required data - Compute and analysis based on the guidelines and rules - Gain insights from the results interpretation - Recommendation and feedback

4. Jerry Gao Ph.D.9/2001 Measurement Process Activities Topic: Software Metrics II - Technical Metrics for Software A measurement process can be characterized by five activities: - Formulation: The derivation of software resources and metrics that are appropriate for the representation of the software. - Collection: The mechanism used to accumulate data required to derive the formulated metrics. - Analysis: The computation of metrics and the application of mathematical tools. - Interpretation: the evaluation of metrics results in an effort to gain insight into the quality of the representation. - Feedback: Recommendation derived from the interpretation.

5. Jerry Gao Ph.D.9/2001 Measurement Principles Topic: Software Metrics II - Technical Metrics for Software The formulation principles: - Set up measurement objectives before data collection. - Define technical metrics in an unambiguous manner. - Derive metrics based on a theory that is valid for the domain of application. - Modify metrics to best accommodate specific products and processes. Collection and analysis principles: - Whenever possible, data collection and analysis should be automated. - Valid statistical techniques should be applied to establish relationships between internal product attributes and external quality features. - Interpretative guidelines and recommendations should be established for each metric.

6. Jerry Gao Ph.D.9/2001 The Attributes of Effective Software Metrics Topic: Software Metrics II - Technical Metrics for Software Basic rules: - Easy to understand and practical. - Not to be too complex and esoteric. Basic attributes: - Simple and computable - Empirically and intuitively persuasive - Consistent and objectives - Consistent in its use of units and dimensions - Programming language independent - An effective mechanism for high-quality feedback

7. Jerry Gao Ph.D.9/2001 Metrics for Software Quality Topic: Software Metrics II - Technical Metrics for Software

8. Jerry Gao Ph.D.9/2001 Metrics for the Analysis Model Topic: Software Metrics II - Technical Metrics for Software

9. Jerry Gao Ph.D.9/2001 Metrics for the Design Model - Architecture Design Metrics Topic: Software Metrics II - Technical Metrics for Software Architectural design metrics focus on characteristics of the program architecture with an emphasis on the architectural structure and the effectiveness of modules. These are black-box based metrics, and detailed structures about components are needed. Card and Glass define three software design complexity measures: structural complexity, data complexity, and system complexity Structural complexity: S(i) = f 2 out (i) where f out (i) is the fan-out of module i Data complexity: D(i) = V(i) / [ f out (i) + 1] where V(I) is the number of input and output variables that are passed to and from module i. System complexity: C(i) = S(i) + D(i)

10. Jerry Gao Ph.D.9/2001 Metrics for The Design Model - Morphology Metrics Topic: Software Metrics II - Technical Metrics for Software a cbed fg h klji qrpnm Node Arc width depth

11. Jerry Gao Ph.D.9/2001 Metrics for the Design Model - Architecture Design Metrics Topic: Software Metrics II - Technical Metrics for Software Fenton suggests a number of simple morphology metrics that enable different program architectures to be compared using a set of straightforward dimensions. Size = n + a where n is the number of nodes and a is the number of arcs. For the architecture shown in Figure 19.5. Size = 17 + 18 = 35 Depth = the longest path from the root to a leaf node. Example in Figure 19.5, depth = 4. Width = maximum number of nodes at any one level of the architecture. Example in Figure 19.5, width = 6.

12. Jerry Gao Ph.D.9/2001 Metrics for the Design Model - Component-Level Design Metrics Topic: Software Metrics II - Technical Metrics for Software Component-level design metrics focus on internal characteristics of a software component and include measures of the “three Cs” (a) module cohesion, (b) coupling, and (c ) complexity These metrics require knowledge of the internal working of the components. Cohesion metrics: (define 5 concepts and measures) - To determine the cohesiveness of a module in terms of data and functions Coupling metrics: - To measure the connectivity between modules - To measure the coupling of a module to global data & environment Complexity metrics: - To determine the complexity of program control flow

13. Jerry Gao Ph.D.9/2001 Metrics for the Design Model - Component-Level Design Metrics Topic: Software Metrics II - Technical Metrics for Software Coupling metrics: For data and control flow coupling: d i = number of input data parameters c j = number of input control parameters d 0 = number of output data parameters c 0 = number of output control parameters For global coupling: g d = number of global variables used as data g c = number of global variables used as control For environment coupling: w = number of modules called (fan-out) r = number of modules calling the module under consideration (fan-in) Mc = K/Mwhere K =1, M = d i + (a * C j ) + d 0 + (b* c 0 ) + g d + (c * g c ) + w +r

14. Jerry Gao Ph.D.9/2001 Metrics for the Design Model - Architecture Design Metrics Topic: Software Metrics II - Technical Metrics for Software Fenton suggests a number of simple morphology metrics that enable different program architectures to be compared using a set of straightforward dimensions. Size = n + a where n is the number of nodes and a is the number of arcs. For the architecture shown in Figure 19.5. Size = 17 + 18 = 35 Depth = the longest path from the root to a leaf node. Example in Figure 19.5, depth = 4. Width = maximum number of nodes at any one level of the architecture. Example in Figure 19.5, width = 6.

15. Jerry Gao Ph.D.9/2001 Metrics for Source Code Topic: Software Metrics II - Technical Metrics for Software Halstead’s theory of software science is one of the best known software metrics for software source code. It proposed the first analytical “laws” for software. Software science assigns quantitative laws to the development of computer software using a set of primitive measures.  1 = the number of distinct operator that appear in a program  2 = the number of distinct operators that appear in a program N 1 = the total number of operators occurrences N 2 = the total number of operand occurrences Halstead uses these primitives to develop expressions for - the overall program length - the potential minimum volume (for an algorithm) - the actual volume (in bits) - the program level ( a measure of software complexity) - the language level (a constant for a given language) - others, such as development effort and time

16. Jerry Gao Ph.D.9/2001 Metrics for Source Code Topic: Software Metrics II - Technical Metrics for Software Halstead shows that the program length N can be estimated N = n 1 log 2  1 + n 2 log 2  2 and program volume may be defined V = N log 2 (  1 +  2 ) = (N 1 + N 2 ) log 2 (  1 +  2 ) where N = N 1 + N 2 V will vary with programming language and represents the volume information (in bits) required to specify a program. Program level L and difficulty D can be computed L = V * / VD = 1/L Where V and V* are two different implementations based on the same set of the requirements

17. In Software Science a metric was proposed expressing effort (E) to implement the software. It is defined as E = V / LE = V / L* Where L* is the estimate of the program level. Inserting the previous;y obtained expression we derive E = V / V* = (N log 2  ) 2 / V* Topic: Software Metrics II - Technical Metrics for Software Jerry Gao Ph.D.9/2001 Metrics for Source Code

18. Jerry Gao Ph.D.9/2001 Metrics for Testing Topic: Software Metrics II - Technical Metrics for Software

19. Jerry Gao Ph.D.9/2001 Metrics for Maintenance Topic: Software Metrics II - Technical Metrics for Software There are some metrics developed explicitly for maintenance activities. IEEE Std. 982.1-1988 suggests a software maturity index (SMI) that provides an indication of the stability of software product based on changes that occur for each release of the product. M T = the number of modules in the current release F C = the number of modules in the current release that have been changed F a = the number of modules in the current release that have been added F d = the number of modules from the proceeding release that were deleted in the current release The software maturity index is computed as follows: SMI = [ M T - (F a + F C + F d ) ] / M T As SMI --> 1.0, the product begins to stabilize.