MSc Software Maintenance MS Vi

1
MSc Software MaintenanceMS Viðhald hugbúnaðar

• Fyrirlestur 42Maintainability Index Revisited

2
Case StudyDæmisaga
Reference Maintainability Index Revisited
position paper -, Tobias Kuipers and Joost
Visser. CSRM2007/SQM2007http//www.cs.vu.nl/csmr2
007/workshops/SQM07_paper3.pdf
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.

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.

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.

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.

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

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
  managements acceptance of the value.

9
The SIG Maintainability Model
Software Improvement Group

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

10
1. Total Size
Five easy-to-calculate metrics

• 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

11
2. Number of Modules
Five easy-to-calculate metrics

• 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?
12
3. Number of units
Five easy-to-calculate metrics

• 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?
13
4. Cyclomatic Complexity above X
Five easy-to-calculate metrics

• 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?
14
5. Duplication
Five easy-to-calculate metrics

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

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 lt 5?
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
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.

18
Andy says we agree this code is not very
maintainable...
19
Figure 1 The Twelve Days of Christmas
Andy says we agree this code is maintainable...
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,