1. Programming Techniques Lecture 13 Product Metrics Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman Software Engineering Fall 2005

2. Programming Techniques Overview Software engineers use product metrics to help them assess the quality of the design and construction of the software product being built. 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 work products arising from analysis, design, coding, or testing.

3. Programming Techniques 1. Software Quality Software quality is conformance to: - explicitly stated functional and performance requirements; - explicitly documented development standards; - implicit characteristics that are expected of all professionally developed software.

4. Programming Techniques Software Quality Principles Conformance to software requirements is the foundation from which quality is measured. Specified standards define a set of development criteria that guide the manner in which software is engineered. Software quality is a suspect when a software product conforms to its explicitly stated requirements and fails to conform to the customer's implicit requirements (e.g., ease of use).

5. Programming Techniques 1.1. McCall's Quality Factors Focus on three software quality factors: –The software’s operational characteristics. –The ability to change the software. –The adaptability of the software to new environments. Admittedly, some of the measures are only arrived at subjectively.

6. Programming Techniques McCall’s Triangle of Quality Maintainability Maintainability Flexibility Flexibility Testability Testability Portability Portability Reusability Reusability Interoperability Interoperability Correctness Correctness Reliability Reliability Efficiency Efficiency Integrity Integrity Usability Usability PRODUCT TRANSITION PRODUCT TRANSITION PRODUCT REVISION PRODUCT REVISION PRODUCT OPERATION PRODUCT OPERATION

7. Programming Techniques McCall's Quality Factors I Correctness: The extent to which a program satisfies its specification and fulfills the customer’s mission objectives. Reliability: The extent to which a program can be expected to perform its intended function with required precision. Efficiency: The amount of computing resources and code required by a program to perform its function. Integrity: The extent to which access to software or data by unauthorized persons can be controlled. Usability: The effort required to learn, operate, prepare input for, and interpret output of a program.

8. Programming Techniques McCall's Quality Factors II Maintainability: The effort required to locate and fix an error in a program. Flexibility: The effort required to modify and operational program. Testability: The effort required to test a program to ensure that it performs its intended function. Portability: The effort required to transfer the program from one hardware and/or software environment to another. Reusability: The extent to which a program (or parts) can be reused in other applications. Interoperability: The effort required to couple one system to another.

9. Programming Techniques A Comment McCall’s quality factors were proposed in the early 1970s. They are as valid today as they were in that time. It’s likely that software built to conform to these factors will exhibit high quality well into the 21st century, even if there are dramatic changes in technology.

10. Programming Techniques 1.2. ISO 9126 Quality Factors International organization for standardization (ISO) adopted ISO9126 as the standard for software quality (ISO, 1991). It was developed in an attempt to identify quality attributes for computer software.

11. Programming Techniques ISO 9126 Quality Factors ISO 9126 is the software product evaluation standard from the International Organisation for Standardisation. This international standard defines six characteristics that describe, with minimal overlap, software quality. ISO 9126 FunctionalityReliabilityUsabilityEfficiencyMaintainabilityPortability

12. Programming Techniques ISO 9126 Quality Attributes I Functionality. The degree to which the software satisfies stated needs as indicated by: suitability, accuracy, interoperability, compliance and security. Reliability. The amount of time that the software is available for use as indicated by: fault tolerance, recoverability, maturity. Usability. The degree to which the software is easy to use as indicated by: learnability, operability, understandability.

13. Programming Techniques ISO 9126 Quality Attributes II Efficiency. The degree to which the software makes optimal use of system resources as indicated by: time & resource bahaviour. Maintainability. The ease with which repair may be made to the software as indicated by: changeability, stability, testability, analyzability. Portability. The ease with which the software can be transposed from one environment to another as indicated by: adaptability, installability, conformance, replaceability.

14. Programming Techniques Quality Issues in Software Systems The ISO’s ISO 9126 standard is now widely adopted Other industry standards such as IEEE have adjusted their standards to comply with the ISO standards

15. Programming Techniques 2. Framework for Product Metrics Benefits of product metrics Assist in the evaluation of the analysis and evaluation model Provide indication of procedural design complexity and source code complexity Facilitate design of more effective testing

16. Programming Techniques Terminology Measure: Quantitative indication of the extent, amount, dimension, or size of some attribute of a product or process. Metrics: The degree to which a system, component, or process possesses a given attribute. Relates several measures (e.g. average number of errors found per person hour). Indicators: A combination of metrics that provides insight into the software process, project or product. Direct Metrics: Immediately measurable attributes (e.g. line of code, execution speed, defects reported). Indirect Metrics: Aspects that are not immediately quantifiable (e.g. functionality, quantity, reliability). Faults: –Errors: Faults found by the practitioners during software development. –Defects: Faults found by the customers after release.

17. Programming Techniques Product Metrics Focus on the quality of deliverables Product metrics are combined across several projects to produce process metrics Metrics for the product: –Measures of the Analysis Model –Complexity of the Design Model 1. Internal algorithmic complexity 2. Architectural complexity 3. Data flow complexity –Code metrics

18. Programming Techniques Metrics Guidelines Use common sense and organizational sensitivity when interpreting metrics data Provide regular feedback to the individuals and teams who have worked to collect measures and metrics. Don’t use metrics to appraise individuals Work with practitioners and teams to set clear goals and metrics that will be used to achieve them Never use metrics to threaten individuals or teams Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement Don’t obsess on a single metric to the exclusion of other important metrics

19. Programming Techniques Normalization for Metrics How does an organization combine metrics that come from different individuals or projects? Depend on the size and complexity of the project Normalization: compensate for complexity aspects particular to a product Normalization approaches: –Size oriented (lines of code approach) –Function oriented (function point approach)

20. Programming Techniques Why Opt for FP Measures? Independent of programming language. Some programming languages are more compact, e.g. C++ vs. Assembler Use readily countable characteristics of the “information domain” of the problem Does not “penalize” inventive implementations that require fewer LOC than others Makes it easier to accommodate reuse and object- oriented approaches Original FP approach good for typical Information Systems applications (interaction complexity) Variants (Extended FP and 3D FP) more suitable for real- time and scientific software (algorithm and state transition complexity)

21. Programming Techniques Measurement Principles The objectives of measurement should be established before data collection begins; Each technical metric should be defined in an unambiguous manner; Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable); Metrics should be tailored to best accommodate specific products and processes

22. Programming Techniques Measurement Process Formulation. The derivation of software measures and metrics appropriate for the representation of the software that is being considered. 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. Recommendations derived from the interpretation of product metrics transmitted to the software team.

23. Programming Techniques Metrics Characterization and Validation Principles A 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. Each metric should be validated empirically in several contexts before it is used to make decisions.

24. Programming Techniques Measurement Collection and Analysis Principles Automate data collection and analysis whenever possible Use valid statistical techniques to establish relationships between internal product attributes and external quality characteristics Establish interpretive guidelines and recommendations for each metric

25. Programming Techniques Goal-Oriented Software Measurement The Goal/Question/Metric (GQM) paradigm emphasizes the need to: –(1) establish an explicit measurement goal that is specific to the process activity or product characteristic that is to be assessed; –(2) define a set of questions that must be answered in order to achieve the goal; and –(3) identify well-formulated metrics that help to answer these questions.

26. Programming Techniques Attributes of Effective Software Metrics Simple and computable. It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time. Empirically and intuitively persuasive. The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration. consistent and objective. The metric should always yield results that are unambiguous. Consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of unit. Programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself. An effective mechanism for quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher quality end product

27. Programming Techniques Metrics for the Analysis Model Function-based metrics: use the function point as a normalizing factor or as a measure of the “size” of the specification. System size: measures of the overall size of the system defined in terms of information available as part of the analysis model. Specification metrics: used as an indication of quality by measuring number of requirements by type.

28. Programming Techniques Metrics for the Design Model Architecture metrics Component-level metrics Specialized OO Design Metrics

29. Programming Techniques Source Code Metrics Halstead metrics Complexity metrics Length metrics

30. Programming Techniques Testing Metrics Statement and branch coverage metrics Defect-related metrics Testing effectiveness In-process metrics

31. Programming Techniques 3. Metrics for the Analysis Model Function-pint (FP) metrics (Albrecht) Specification quality metrics (Davis)

32. Programming Techniques Function-Point Metric A function point (FP) is a synthetic metric that is comprised of the weighted totals of the inputs, outputs, inquiries, logical files, and interfaces belonging to an application. The function point measure can be computed without forcing the specification to conform to a particular specification model or technique.

33. Programming Techniques Function-Point Metric Usage The FP can be used to: - estimate the cost or effort required to design, code, and test the software; - predict the number of errors that will be encountered during testing; and - forecast the number of components and/or the number of projected source lines in the implemented system.

34. Programming Techniques Using FP Errors per FP Defects per FP Cost per FP Pages of documentation per FP FP per person month

35. Programming Techniques Function Point: Information Domain Values Number of external inputs (EIs): those items provided by the user to the program (such as file names and menu selections). Inputs should be distinguished from inquiries, which are counted separately. Number of external outputs (EIs): those items provided to the user by the program (such are reports, screens, error messages, etc.). Individual data items within a report are not counted separately. Number of external inquiries(EQs): interactive inputs requiring a response. Each distinct enquiry is counted. Number of internal logical files (ILFs): logical master files (i.e. a logical grouping of data that may be part of a large database or a separate file) in the system. Number of external interface files (EIFs): logical grouping of data that resides external to the application but provides data that may be of use to the application.

36. Programming Techniques Function Point Once the information domain values are collected, the table in the next Figure is completed Complexity value is associated with each count and is subjective to the experience and expertise of the engineer conducting the metrics. Each item identified is assigned a subjective "complexity" rating on a three-point ordinal scale: "simple," "average," or "complex." Then, a weight is assigned to the item, based on a FP complexity weights table. The function point count total is computed by multiplying each raw count by the weight and summing all values

37. Programming Techniques Function Points Information Domain ValueCountsimple average complex Weighting factor External Inputs (EIs) External Outputs (EOs) External Inquiries (EQs) Internal Logical Files (ILFs) External Interface Files (EIFs) 346 457 346 71015 5710 = = = = = Count total x x x x x

38. Programming Techniques Value (Complexity) Adjustment Factors (VAF) Rated on a scale of 0 (not important) to 5 (very important): 1.Does the system require reliable backup and recovery? 2.Are data communications required? 3.Are there distributed processing functions? 4.Is performance critical? 5.System to be run in an existing, heavily utilized environment? 6.Does the system require on-line data entry? 7.On-line entry requires input over multiple screens or operations? 8.Are the master files updated on-line? 9.Are the inputs, outputs, files, or inquiries complex? 10.Is the internal processing complex? 11.Is the code designed to be reusable? 12.Are conversion and instillation included in the design? 13.Multiple installations in different organizations? 14.Is the application designed to facilitate change and ease-of-use?

39. Programming Techniques Computing Function Points FP =  (count x weight) x C or FP = count total X C where, C - complexity multiplier C = 0.65 +(0.01 x  (Fi))

40. Programming Techniques Computing Function Points (Summary) Establish count for input domain and system interfaces Analyze information domain of the application and develop counts Weight each count by assessing complexity Assign level of complexity (simple, average, complex) or weight to each count Grade significance of external factors (value adjustment factors), Fi, such as reuse, concurrency, OS,... Assess the influence of global factors that affect the application Compute function points FP =  (count x weight) x C where complexity multiplier C = (0.65+0.01 x N) degree of influence N =  (Fi)

41. Programming Techniques Function Point Advantages and Disadvantages The FP measure has the advantage that it is a technology-independent measure of software size that can be applied early in the requirements and design phase to provide useful information, which can be effectively used for measuring a variety of aspects related to the economic productivity of software. However, there are also several problems with the function-points measure. There is the problem of subjectivity in the technology factor, problems with double counting internal complexity, problems with counter-intuitive values for the complexity rating of "average," problems with accuracy, inappropriateness for early life cycle use because it requires a full software system specification, changing requirements, technology dependence, application domain, subjective weighting, and measurement theory. A major disadvantage of function points is the potentially wide variation in function point calculations that may be generated by inexperienced practitioners and/or in response to unique programming applications.

42. Programming Techniques Function Point Many enhancements and modification have been made to the original Function Point Metric since its first publication in October 1979. –In 1986 Software Productivity Research (SPR) developed a new enhanced function point called feature point, that includes a new parameter, algorithm, in addition in addition to the five standard function point parameters. –There is an International Function Point User’s Group (IFPUG), several books, and recent publications that are dedicated to the study and application of Function Point related measures.

43. Programming Techniques Example: SafeHome Functionality User SafeHome System Sensors User Monitor and Response System System Config Data Password Zone Inquiry Sensor Inquiry Panic Button (De)activate Messages Zone Setting Sensor Status (De)activate Alarm Alert Password, Sensors, etc. Test Sensor

44. Programming Techniques Example: SafeHome FP Calculations 3 EIs: password, panic button, activate/deactivate; 2 EOs: messages and sensor status; 2. EQs: zone inquiry and sensor inquiry; 1 ILF: system configuration file; 4 EIFs: test sensor, zone setting, activate/deactivate and alarm alert. These data, along with the appropriate complexity are entered into the next Figure. For this example we assume that  (Fi) = 46 (a moderatly complex product).

45. Programming Techniques Example: SafeHome FP Calculation complexity multiplier function points number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces measurement parameter 3 4 3 7 5 count weighting factor simple avg. complex 4 5 4 10 7 6 7 6 15 10 = = = = = count-total X X X X X 3 2 2 1 4 9 8 6 7 20 56 50 1.11

46. Programming Techniques Example I: How to use FP values Based on the FP value, the project team can estimate the overall implemented size of the SafeHome user interaction function. Assume that past data indicates: - that one FP translates into 60 lines of codes; - 12 FPs are produced for each person-month of effort. The project manager can plan the project then based on the analysis model rather than preliminary estimates.

47. Programming Techniques Example II: How to use FP values Assume that past project have found an average of 3 errors per function point during analysis and design reviews and 4 errors per function point during unit and integration testing. These data can help software engineers asses the completeness of their review and testing activities.

48. Programming Techniques 4. Representative Design Metrics Design metrics for software are available, but the vast majority of software engineers continue to be unaware of their existence.

49. Programming Techniques 4.1. Architectural Design Metrics Focus on characteristics of the program architectural structure and the effectiveness of modules or components within the architecture. They are ‘black box’ in the sense that they do not require any knowledge of the inner workings of a particular software components.

50. Programming Techniques Architectural Design Metrics Card and Glass define three software design complexity measures: - Structural complexity (based on module fan- out); - Data complexity (based on module interface inputs and outputs); - System complexity (sum of structural and data complexity).

51. Programming Techniques Architectural Design Metrics Representatives Morphology (i.e. shape) metrics - number of nodes and arcs in program graph. Design structure quality index (DSQI)

52. Programming Techniques 4.2.Metrics for OO Design-I Whitmire describes nine distinct and measurable characteristics of an OO design: –Size - defined in terms of four views: population, volume, length, and functionality. –Complexity - how classes of an OO design are interrelated to one another. –Coupling - the physical connections between elements of the OO design –Sufficiency - “the degree to which an abstraction possesses the features required of it, or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.”

53. Programming Techniques Metrics for OO Design-II –Completeness - an indirect implication about the degree to which the abstraction or design component can be reused. –Cohesion - the degree to which all operations working together to achieve a single, well-defined purpose. –Primitiveness - applied to both operations and classes, the degree to which an operation is atomic. –Similarity - the degree to which two or more classes are similar in terms of their structure, function, behaviour, or purpose. –Volatility - measures the likelihood that a change will occur.

54. Programming Techniques 4.3. Class-Oriented Metrics What the role of class-oriented metrics in assessing the quality of an OO system? - The class is the fundamental unit of an OO system. Therefore, measures and metrics for an individual class, the class hierarchy, and class collaborations will be invaluable to software engineer who must assess design quality. - The number of methods and their complexity are directly related to the effort required to test a class. - The depth of the inheritance tree can be used to estimate the complexity of the class hierarchy. - It is important to strive to have low coupling between classes and high cohesion within each class. - If large class sizes are detected during OOA review, the classes should be partitioned to improve the modularity of the system and make it easier to maintain.

55. Programming Techniques Class-Oriented Metrics – The CK Metrics Suite Proposed by Chidamber and Kemerer (CK) Weighted metrics per class (WMC)Weighted metrics per class (WMC) Depth of inheritance tree (DIT)Depth of inheritance tree (DIT) Number of children (NOC)Number of children (NOC) Coupling between object classes (CBO)Coupling between object classes (CBO) Response for a class (RFC)Response for a class (RFC) Lack of cohesion in methods (LCOM)Lack of cohesion in methods (LCOM)

56. Programming Techniques Weighted Metrics Per Class (WMC) Assume that n methods of complexity C1, C2, …, Cn are defined for a class C. The specific complexity metrics that is chosen (e.g. cyclomatic complexity) should be normalized so that nominal complexity for a method takes on a value of 1.0. WMC = ∑Ci (for i =1 to n)

57. Programming Techniques WMC II The number of methods and their complexity are reasonable indicators of the amount of effort required to implement and test class. Larger the number of methods, the more complex is the inheritance tree. As the number of methods grows for a given class, it is likely to become more and more application specific, thereby limiting potential reuse. For all these reasons, WMC should be kept as low as is reasonable.

58. Programming Techniques Depth of Inheritance Tree (DIT) This metric is the ‘maximum length from the node to the root of the tree’. As DIT grows, it is likely that lower-level classes will inherit many methods. This leads to potential difficulties when attempting to predict behaviour of a class. A deep class hierarchy (DIT is large) also leads to greater design complexity. Positively, large DIT values imply that many methods may be reused. Example: Referring to the next Figure, the value of DIT for the class-hierarchy shown is 3.

59. Programming Techniques Figure: A Class Hierarchy Plane CargoPlaneFighterPlane Passenger Plane B747B757AirbA320

60. Programming Techniques Number of Children (NOC) The subclasses that are immediately subordinate to a class in the class hierarchy are termed its children. Total number of children for each class. Large NOC may dilute abstraction and increase testing Example: Referring to the previous Figure, class PassengerPlane has 3 children– subclasses: B747, B757 and AirbA320. (i.e. NOC = 3)

61. Programming Techniques Coupling Between Object Classes (CBO) Total number of collaborations listed for each class in CRC cards. As CBO increases, it is likely that the reusability of a class will decrease. Keep CBO low because high values complicate modification and testing. This is consistent with the general guideline to reduce coupling in conventional software.

62. Programming Techniques Response For a Class (RFC) Set of methods potentially executed in response to a message received by a class. High RFC implies test and design complexity increasing the testing effort. As RFC increases, the overall design complexity of the class increases.

63. Programming Techniques Lack of Cohesion in Methods (LCOM) Number of methods in a class that access one or more of the same attributes. If no methods access the same attributes, then LCOM = 0. High LCOM means tightly coupled methods.

64. Programming Techniques MOOD Metrics Suite 4.4. Class-Oriented Metrics – The MOOD Metrics Suite Proposed by Harrison, Counsel, and Nithi. Method inheritance factor – the degree to which the class architecture of an OO system makes use of inheritance. Coupling factor – an indication of the connections between elements of the OO design.

65. Programming Techniques Method Inheritance Factor (MIF) MIF = ∑Mi(Ci)/∑Ma(Ci) Where the summation occurs over i=1 to Tc. Tc is defined as the total number of classes in the architecture; Ci is a class within the architecture; and Ma(Ci) = Md(Ci) + Mi(Ci) where Ma(Ci) is the number of methods that can be invoked with C i Md(Ci) is the number of methods declared in C i Mi(Ci) is the number of methods inherited and not overridden in C i

66. Programming Techniques Coupling Factor (CF) CF=. where the summation occur over i=1 to TC and j=1 to TC (TC is the total number of classes in the architecture); is_client(x,y) = 1 if a relationship exists between the client class and the server class. 0 otherwise. (TC 2 -TC) is the total number of relationships possible (Total Classes 2 – diagonal) CF is [0,1] with 1 meaning high coupling

67. Programming Techniques 4.5. OO Metrics Proposed by Lorenz and Kidd Class size (CS)Class size (CS) Number of operations added by a subclass (NOA)Number of operations added by a subclass (NOA)

68. Programming Techniques Class Size (CS) The overall size of a class can be determined with: - total number of operations (inherited, private, public) that are encapsulated within the class; - number of attributes (inherited, private, public) that are encapsulated within the class. May be an indication of too much responsibility for a class.

69. Programming Techniques Number of Operations added by a Subclass (NOA) Subclasses are specialised by adding operations and attributes. As the value for NOA increases, the subclass drifts away from the abstraction implied by the superclass. As the DIT increases, the value for NOA at lower levels in the hierarchy should go down.

70. Programming Techniques 4.6. Component-Level Design Metrics Cohesion metrics: a function of data objects and the focus of their definition. Coupling metrics: a function of input and output parameters, global variables, and modules called. Complexity metrics: hundreds have been proposed (e.g., cyclomatic complexity). Can be used to predict critical information about reliability and maintainability of software systems from automatic analysis of source code.

71. Programming Techniques 4.7. Operation-Oriented Metrics Average operation size (OSavg) – the number of messages sent by the operation (an alternative for operation size). As the number of messages sent by a single operation increases, it is likely that responsibilities have not been well-allocated within a class. Operation complexity (OC) – strive to keep OC as low as possible. Average number of parameters per operation (NPavg) – t he larger the number of operation parameters, the more complex the collaboration between objects. NPavg should be kept as low as possible.

72. Programming Techniques 4.8. User Interface Design Metrics Layout appropriateness: a function of layout entities, the geographic position and the “cost” of making transitions among entities.

73. Programming Techniques 5. Source Code Metrics Overall program length Potential minimum algorithm volume Actual algorithm volume (number of bits used to specify program) Program level (software complexity) Language level (constant for given language)

74. Programming Techniques Source Code Metrics Halstead’s Software Science: a comprehensive collection of metrics all predicated on the number (count and occurrence) of operators and operands within a component or program –It should be noted that Halstead’s “laws” have generated substantial controversy, and many believe that the underlying theory has flaws. However, experimental verification for selected programming languages has been performed.

75. Programming Techniques Halstead’s Metrics Halstead’s Software Science (entropy measures) –n 1 - number of distinct operators –n 2 - number of distinct operands –N 1 - total number of operators –N 2 - total number of operands

76. Programming Techniques Example if (k < 2) { if (k > 3) x = x*k; } Distinct operators: if ( ) { } > < = * ; Distinct operands: k 2 3 x n 1 = 10 n 2 = 4 N 1 = 13 N 2 = 7

77. Programming Techniques Halstead’s Metrics Overall program length: N = N 1 + N 2 Vocabulary: n = n 1 + n 2 Estimated length: N = n 1 log 2 n 1 + n 2 log 2 n 2 –Close estimate of length for well structured programs Volume (number of bits required to specify a program) Volume V = N log 2 n –Number of bits to provide a unique designator for each of the n items in the program vocabulary.

78. Programming Techniques 6. Testing Metrics Testing metrics fall into two major categories: - metrics that focus on test coverage, and - metrics that focus on the duration of the testing process.

79. Programming Techniques Testing Metrics Metrics that focus on test coverage for a given component: –Cyclomatic complexity (lies at the core of basis path testing). Metrics that predict the likely number of tests required during various testing phases: –Function-based metrics (e.g., function points). –Architectural design metrics. –Cyclomatic complexity can target modules that are candidates for extensive unit testing. –Halstead effort.

80. Programming Techniques 7. Maintenance Metrics - Software Maturity Index (SMI) Software Maturity Index (IEEE Standard 982.1- 1988) Provides an indication of the stability of a software product (based on changes that occur for each release of the product). SMI approaches 1.0 as product begins to stabilize

81. Programming Techniques How to Compute Software Maturity Index Mt – the number of modules in the current release Fc – the number of modules in the current release that have been changed Fa – the number of modules in the current release that have been added. Fd – the number of modules from the preceding release that were deleted in the current release The software maturity index is computed in the following manner: SMI = [Mt – (Fa + Fc + Fd)] / Mt

82. Programming Techniques Software Maturity Index SMI may also be used as a metric for planning software maintenance activities. The mean time to produce a release of a software product can be correlated with SMI and empirical models for maintenance effort can be developed.

83. Programming Techniques Summary Software engineers use product metrics to help them assess the quality of the design and construction of the software product being built. Product metrics provide software engineers with a basis to conduct analysis, design, coding, and testing more objectively. 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 work products arising from analysis, design, coding, or testing.

84. Programming Techniques 2005F Instructor John D Lin - johndlin@hotlinemail.com Lectures Tues & Thurs 10:00-11:30 RM. 100, Lower Block