Managing Maintenance

1
Managing Maintenance

• Many issues in managing the maintenance phase
• Maintenance activities themselves are hard
• People and Morale
• Maintenance Process and Artifacts
• Maintenance cost
• Support metrics

2
Maintenance Activities

• The basic activities of maintenance is not that
  different from development - - - but
• New requirements existing requirements
• New design existing design
• New code existing code
• New test existing test
• New integration existing files
• New documentation existing documentations

- Developing a new release has all the risks of
the first release the need to understand the
existing materials. - If the existing
materials are well updated and available, there
may be some advantage - - - assuming the first
release developed kept maintenance in mind.
3
Importance of Regression Test

• Whenever a new release is built upon a previous
  release, we are concerned that no existing
  functions are destroyed.
• Integration and Regression tests are important -
  - - is it a must ?
• Do we rerun all the previous test cases
  (especially with OO inheritances) along with the
  new test cases?
• If we run only part of the previous test cases,
  then which parts?
• Parts that have interfaces to the new parts?
• Parts that showed error proneness?
• Randomly pick test cases from previous regression
  bucket?

4
Existing Material Complexity

• Many existing material are good and provide a
  basis for further development
• Maintenance people need to be giving time to
  digest all the existing material this takes time
• Some original developers should be made available
  to the maintenance personnel
• Tools should be provided to help understand and
  track the various pieces and parts
• Configuration management process
• Configuration management tool
• Version control
• Build and integration

5
Some Complexity Measure for Maintenance

• McCabes Cyclomatic Number on a control flow
  graph
• Complexity edges nodes 2 or
• Complexity of binary decisions 1
• of Fan-in and of Fan-out for the effect of
  coupling on maintenance
• Gerlich Denskat (of m components and k needs
  changes) then
• k(m-k) k(k-1)/2 interfaces need to be
  checked

Note the increase in interfaces as k increases
(for example let m 5 ) - for k 1, then
14 0 4 interfaces - for k 2, then
23 1 7 interfaces - for k 4, then
41 6 10 interfaces
One of the most difficult task of modifying an
existing code or design is to understand all the
relationships and interfaces among the parts
(modules) and components (applications)
6
Some Interesting Experiencesbased on Porter and
Selby

• Using Classification Tree Analysis to predict
  interface errors likely to be encountered during
  maintenance found the following to be most
  error-prone
• Components that encounter between 4 to 8 design
  revisions with 15 data bindings
• Components whose primary function is to manage
  files where there have been 9 revisions or more
• Classification Tree is technique of defining a
  particular attribute of interest, classifying the
  attribute with some metric, and placing the
  different categories as defined by the metric
  into a tree structure which may be used for
  analysis

7
People and Morale

• Management Priority needs to be properly set
• Is fixing a problem properly more important than
  fixing it quickly and getting the backlog
  numbers down more important? (both is not a
  good answer! - - - you should know which is
  higher priority)
• Fixing defects (especially high priority ones)
  must be separate from the planned maintenance
  release
• Maintenance releases, within themselves, may have
  different priorities
• (e.g.) is perfective more important than
  corrective?
• (e.g.) is revenue more important than user
  perception of quality?
• Support, Service, and Maintenance personnel needs
  to be treated differently
• Deal with a lot of negatives
• Feel unappreciated
• Sometimes paid less

8
Maintenance Process and Artifacts

• Should the maintenance process be different from
  regular development process?
• User call management clearly is different
• Should there be emphasis on
• Refactoring
• Regression test
• Documentation
• Integration and build
• The artifacts that the maintenance teams get more
  than the normal developers receive are the
  constant user and customer problems (both defect
  and non-defect) reports - - - lots of
  requirements
• If measurements are kept, the maintenance team
  also have a better view of where the previous
  error prone areas were.

9
Support Maintenance Release Process
Users customers
Problem Reports
Release Content Planning
External entities
Industry Reports
Recommendations
Change Control Board
Based on - Impact analysis - Priority analysis -
Cost analysis - Resource analysis
Refactoring other
Next Release Content
Maint. Engrs.
Release Development
Business Competition Reports
Next Release
Sales others
(pretty much same as development)
10
Maintenance Cost

• Pure defect (corrective maintenance) releases are
  just an expense that is balanced by continuing
  support fees charged to customers. If the total
  cost is less than the total fees, then we are in
  good shape.
• Other maintenance releases (e.g. perfective
  maintenance with major new functions) can be
  priced and charged to customers. Thus the cost of
  developing these releases are important.

Note that if we support multiple releases, the
cost of corrective maintenance will go up
- more number of release versions to keep track
of - some problems are already fixed in
the later releases and can be evaded Traditionall
y, software companies would want to support no
more than 2 back level versions.
11
Problem Arrival Curves for Multiple
ReleasesThat are Too Close to Each Other
Accumulative problems arrival from
multiple releases that are too close
Problems discovered reported
Rel. 1
Rel. 2
Rel. 3
Time (after software release)
12
Problem Arrival Curves for Multiple
ReleasesThat are Spread Out a Bit
Accumulative problems arrival from
multiple releases that are spread out a bit
Problems discovered reported
Rel. 2
Rel. 1
Time (after software release)
13
Some Estimations of Maintenance Cost

• Effort Estimate by Belady and Lehman
• M p K(c-d) where
• M maintenance effort
• P complete production effort
• K some empirical constant
• c complexity caused by lack of good design and
  docs
• d degree to which maintenance team is familiar
  with the software

This a good estimation of the relationships
between cost and other items. - But do you think
this is an equation?! - How do you even use this
when the constant K is empirical and depends on
each environment? - How does one measure c? -
How does one measure d?
14
Some Estimations of Maintenance Cost

• Maintenance Estimate from COCOMO II (Boehm)
• Size ASLOC (AA SU .4DM .3CM .3IM) / 100
  where
• ASLOC estimated loc to be adapted
• AA assessment and assimilation effort (range
  from 0 8)
• SU rating scale of needed amount of software
  understanding based on complexity of the software
  (range from 10 to 50)
• DM percentage of design to be modified
• CM percentage of code to be modified
• IM percentage of externally integrated code

The most difficult part of this estimation is
coming up with ASLOC and all the other
parameters. Again, the relationship makes sense
- - - but an estimation formula?
15
Some Support Metrics

• Number of backlogs of unresolved problems
• by problem severity level
• by month
• accumulative total
• Time spent on resolving problems
• by problem severity level
• by month
• by person
• Number of erroneous problem fixes
• by severity level of original problem and by the
  erroneous fix
• by person
• by month
• accumulative total
• Number of LOC or FP delivered with each release
• Number of components impacted
• by release
• by fixes per month
• Accumulative
• Number of minutes spent on customer calls