Object-Oriented Analysis and Design Lecture 11 Maintenance (from Schach, “O-O and Classical Software Engineering”)

Why Maintenance? Correct faults in specification, design, coding, documentation This is corrective maintenance, maybe 20% of the job (according to one study) Perfective maintenance (60%) is adding functionality or improving operability Adaptive maintenance (20%) is reaction to changes in the operating environment Altogether, often 2/3 of the cost of software

Maintenance is Hard Yet organizations usually give it to newbies and incompetents Maintenance requires knowledge of all the skills in software development Maintenance requires knowledge of the complete program

Responding to a Fault Report User submits fault report: product doesn’t work like the manual says Is the user wrong? Is the manual wrong? Is it the code? What code? Can I fix the code without regression faults? Is there documentation (requirements, design, code, testing)?

Perfective Maintenance The programmer has to be expert in specs, design, coding, testing & documentation Less experienced programmers don’t belong here

The “Rewards” Thankless task; you only deal with unhappy users Someone else caused the problem, you have to fix it The code may be badly written Definitely not a high-status position But if you do a poor job, the client goes elsewhere (maybe you do too)

Temperate Fruit Committee The problem - no room for expansion - was caused by the developer, not the maintainer Clients don’t understand that maintenance can be difficult or impossible Development must consider future expansion

Maintenance Management Fault reports Keep a prioritized list of backlogged reports Try to find a workaround immediately Analyze, and add info (documentation, listings, etc.) to the fault report Circulate fault report with workaround to all users Sometimes cheaper & easier to fix several faults at once

Maintenance Management Know which modules need changing Use version control to ensure two modules aren’t simultaneously changed Ensure continued maintainability Beware the moving target

Maintenance of O-O Software Encapsulation is supposed to make some maintenance problems disappear But it can add new difficulties It may be hard to see all the methods of a class in a deep hierarchy. Solution: use tools Polymorphism may make it time consuming to check the effect of a change Changes to a class interior to a hierarchy are propagated to the leaf classes

Other Issues Reverse engineering may be necessary Case tools can help for O-O software Metrics can alert to especially fragile or sensitive classes Are changes being made to reused components? If so, should the reuse library be updated?