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