MSc Software Maintenance MS Viðhald hugbúnaðar

1. MSc Software MaintenanceMS Viðhald hugbúnaðar Fyrirlestur 42Maintainability Index Revisited Dr Andy Brooks

2. Case StudyDæmisaga Reference Maintainability Index Revisited – position paper -, Tobias Kuipers and Joost Visser. CSRM2007/SQM2007http://www.cs.vu.nl/csmr2007/workshops/SQM07_paper3.pdf Dr Andy Brooks

3. Problems with the Maintainability Index • “We have used the Maintainability Index in our consultancy practice over the last four years and found a number of problems with it.” • “Although we see a clear use for determining the maintainability of the source code in one (or a few) simple to understand metrics, we have a hard time using the Maintainability Index to the desired effect.” Dr Andy Brooks

4. Root cause analysis • Because MI is a composite metric it is very difficult to know what a value for means. • When the MI has a low value, it is not immediately clear what should be done to increase it. Dr Andy Brooks

5. Average complexity • The complexity metric is flawed. • Because of all the getters and setters in Java which have a complexity of 1, the average complexity is low. • a class with 9 getters and setters and 1 method with a complexity of 10 will have an average complexity of 1.9 • Anecdotal evidence suggests maintainance problems occur in a few outliers that have a complexity of over 100. Dr Andy Brooks

6. Computability • There is no formal definition of what constitutes an operator or operand for Java or C#. • The Halstead Volume metric “is not widely accepted within the software engineering community”. Dr Andy Brooks

7. Comments • “... we find that counting the number of lines... in general, has no relation with maintainability whatsoever.” • Source code which has been “commented out” gets counted. • Comments sometimes are not kept up-to-date and refer to a previous version. • The comments part of the MI is optional. • it is possible drop the term containing PerCM Dr Andy Brooks

8. Understandability • Developers feel they have a lack of control over the value of the MI and this “makes them dismissive of the MI for quality assessment purposes”. • The developers´ attitude directly influences management´s acceptance of the value. Dr Andy Brooks

9. Software Improvement Group The SIG Maintainability Model • The model is under development • Five easy-to-calculate metrics • Metrics are not composed into one unifying metric like MI • “From discussions with developers of dozens of industrial systems we learn that the metrics are well accepted, or acceptable.” Dr Andy Brooks

10. Five easy-to-calculate metrics 1. Total Size • Source lines of code (SLOC). • excluding comments and blank lines • A larger system requires a larger effort to maintain. So a smaller system is better. • a simple, intuitive idea that everyone understands • No correction is applied for the expressiveness of a programming language. • a 1000-line Java program is considered to be more easily maintained than the functionally equivalent 1200-line C program Dr Andy Brooks

11. Five easy-to-calculate metrics 2. Number of Modules • The ratio between the number of modules and the total lines of code is “a measure of how well a system is decomposed”. • “as an initial estimate it turns out to be rather useful” • A module in Java or C# is a class. Andy asks: What is a reasonable ratio? Dr Andy Brooks

12. Five easy-to-calculate metrics 3. Number of units • A module is decomposed into units. • In Java or C#, a unit is a method. • A unit is the smallest piece of code that can be executed (tested) individually. Andy asks: What is a reasonable number of units per module? Dr Andy Brooks

13. Five easy-to-calculate metrics 4. Cyclomatic Complexity above X • Calculate complexity of units. • Do not calculate average values. • Complexity is expressed as the percentage of lines of code of the system that are in units which have a higher complexity than some threshold X. • X is currently taken to be 20 though McCabe suggests that X should be 10 Andy asks: What is a reasonable % for complexity? Dr Andy Brooks

14. Five easy-to-calculate metrics 5. Duplication • “... measuring code duplication gives a fairly simple estimate of how much larger a system is than it needs to be.” • Exact string matching duplication. • Duplication is measured as the percentage of all code that occurs more than once in equal code blocks of at least X lines. • “we take X to be 6” • “we see a duplication percentage of around 3% for well managed systems” Dr Andy Brooks

15. Discussion and Conclusions • The SIG Maintainability Model is easily explained to technical personnel and managers. • How the source code influences the five metrics is clear. • “We are currently putting this model to work in our consultancy practice.” Andy asks: what about use of OO language features such as inheritance? keep DOI < 5? Dr Andy Brooks

16. Case StudyDæmisaga Reference The Software Maintainability Index Revisited Kurt D. Welker. CROSSTALK The Journal of Defense Software Engineering, August 2001, pp18-21 http://www.stsc.hill.af.mil/crosstalk/2001/08/welker.html Dr Andy Brooks

17. Comments in code • Comments that are out-of-date can actually hinder maintenance. • Sometimes identifier names are used instead of comments. • distanceMetres • distance //measured in metres • “A man in the maintainability assessment loop is essential both in how to measure comments in the source code (which MI equation) and then in determining the meaning of the results.” Dr Andy Brooks

18. Andy says: we agree this code is not very maintainable... Dr Andy Brooks

19. Figure 1: The Twelve Days of Christmas Andy says: we agree this code is maintainable... Dr Andy Brooks

20. Figure 2: The Twelve Days of Christmas - Metrics • The 3 metric MI (without comments) suggests Example 1 is more maintainable. • The 4 metric MI (with comments) suggests Example 2 is more maintainable. • “... but did the comments really make the difference? No,” Dr Andy Brooks