CSC 395 – Software Engineering Lecture 34: Post-delivery Maintenance -or- What’s Worse than Being a Code Monkey?

Postdelivery Maintenance Includes all changes after acceptance testing Hotfixes to remove bugs Patches to improve performance Modify documentation so “onomatopoeia” spelled correctly But software engineering about maintenance Finding & fixing all errors as soon as possible Making modifying or adding code clean & easy Do not want to mess this up post-delivery

Why Is This Step Needed? Corrective maintenance Find and fix residual faults Perfective maintenance Handle client requests to improve effectiveness Adaptive maintenance Adjust to changes in product’s environment

Real-World Maintenance At least 67% of the product cost in postdelivery maintenance Also a really nice source of income Most difficult part of any program Involves tasks from all previous workflows Requires understanding all previous decisions And yet… Maintenance often not well regarded Nobody enjoys handling customer complaints Often staffed by people below “code monkey”

Programming After Delivery Defect report handed to maintenance programmer Often provided by user who just wants it fixed Rarely well researched or clearly presented May not be anything wrong with program Problem not located between keyboard & CPU User manual may be wrong and not the code Often, however, code contains a fault

Programming After Delivery Maintenance programmer must be excellent debugger Faults could lie anywhere within the program Specification & design documents may be lost Once (if) source of fault is found, must fix it Easy given excellent documentation & notes Rarely occurs in the real-world, however If fixed, update all analysis & design documents Also record how bug found & fixed

Software Engineering the Fix After updating code, check that fix works Fix should not introduce regression fault Re-run the project on previous test cases… … which are unable to expose the bug Design new test case(s) to test for this bug Keep the test case as simple as possible Make sure test cases fail when run on old version Double-check that they pass on the new version Add new tests & document why they are needed

Adaptive & Perfective Maintenance Maintenance programmer goes through Requirements Specifications Design Implementation and integration Slight benefit over original project Uses existing product as starting point HUGE downside versus original project Same team (person) performs all of the workflows

Rewards of Maintenance Work

Defect Reports Mechanism to record defects and their fixes Includes tool for client to report defects Clients uninterested helping lousy $&$%# who cost them a days work… Must get enough info to recreate problem May let client see what progress is being made

Handling New Defect Report First step is to consult defect report file Check if someone else is working on fix See if error already fixed or dismissed Reply with any known workarounds Otherwise, try finding cause of defect Once found, record defect’s cause in report Also write down any workaround discovered Finally, document fix & all changes involved Mark defect as “closed” Send out alert of bug & fix to all effected Document other client requests

Authorizing Changes Changes for corrective maintenance Assign programmer to find & fix the defect Perform the regression testing Update documentation to reflect the change(s) Include comments in the code to reflect What was changed Why it was changed Who made & authorized the change When the change was made

Who Performs the Testing? Before delivery all testing done by SQA group Testing is difficult and time consuming Developers should never test code they wrote SQA group has people, training, & resources After delivery all testing done by SQA group Testing is difficult and time consuming Developers should never test code they wrote SQA group has people, training, & resources

Moving Target Problem Development teams dislike moving targets Much harder to code something in flux Makes documenting what is happening nearly impossible Creates a product that differs from the design Results in complex code with lots of special cases Problem exacerbated during maintenance Maintenance team rarely has stationary target Over time, maintenance becomes impossible Eventually requires total rewrite to move forward

Maintaining OO Software OO promotes maintenance in four ways: Uses independent units as program bases Conceptual independence (encapsulation) Physical independence (information hiding) Communication via message-passing (methods) Reality is not so kind, however…

Inheritance Hierarchy Size To discover what a class does, may need to scan over complete tree Not at all like the “independent units” theorized When inheritance tree is too deep, ask: Is the inheritance really being used? Can we regroup concepts to reduce tree? Could functionality be encapsulated into other classes? Can design be simplified by grouping ideas together?

Conclusion Theory & practice miles apart during maintenance Hardest workflow offering biggest challenges Also largest workflow in terms of time & money Worst place to leave: Unsupervised beginner Lesser-skilled computer professional Anyone else not at top of their game But maintenance used as dumping ground Location of people looking up to code monkeys

For Next Lecture Will not be here on Friday Schedule altered slightly to reflect this fact Most of department’s faculty also gone So no lecture on Friday Will end up losing day from ethics section Use the extra time working in your groups Be prepare to defend ethics of your actions