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 • McCabe’s 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 [1*4 + 0] = 4 interfaces - for k = 2, then [2*3 + 1] = 7 interfaces - for k = 4, then [4*1 + 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 Traditionally, 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 • by customer • by support personnel