28/06/2015Dr Andy Brooks1 MSc Software Maintenance MS Viðhald hugbúnaðar Fyrirlestur 42 Maintainability Index Revisited.

18/04/23 Dr Andy Brooks 1

MSc Software MaintenanceMS Viðhald hugbúnaðar

Fyrirlestur 42Maintainability Index Revisited


Case StudyDæmisaga

ReferenceMaintainability Index Revisited – position paper -, Tobias

Kuipers and Joost Visser. CSRM2007/SQM2007http://www.cs.vu.nl/csmr2007/workshops/SQM07_paper3.pdf

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.”


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.


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.


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”.


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


171 5.2 ( ) 0.23 ( ) 16.2 ln( ) 50sin( 2.4 )MI ln avgV avgV g avgLOC avgPerCM

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.


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.”


Software Improvement Group

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


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?

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?

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?

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”



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?


Case StudyDæmisaga

ReferenceThe 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

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.”



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


Figure 1: The Twelve Days of Christmas

Andy says: we agree this code is maintainable...

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,”


28/06/2015Dr Andy Brooks1 MSc Software Maintenance MS Viðhald hugbúnaðar Fyrirlestur 42 Maintainability Index Revisited.

Documents