Lecture 12 Maintenance CSCI – 3350 Software Engineering II Fall 2014 Bill Pine

CSCI 3350Lecture Overview Why worry about maintenance? Issues for maintenance programmers Maintenance skills vs. development skills Reverse engineering Testing issues during maintenance Summary

CSCI 3350Lecture Why Worry about Maintenance? What is maintenance? – Any change to a product that has passed acceptance testing Why worry? –Maintenance is the largest percentage of total system cost - 2X to 3X development cost –Cost to find and fix a fault in maintenance is by far the greatest of all workflows Main challenge for maintenance team –How to maintain, without destroying the product

Horror Story City of Toronto lost nearly $700,000 in pet fees when nearly one-half of pet owners were not billed –Early 2000, layoffs in the city’s computer support staff resulted in the dismissal of the only maintenance programmers experienced in the application –A major crash left the city with no one who could quickly restore operations CSCI 3350Lecture

CSCI 3350Lecture Four Categories of Maintenance Corrective –Find and fix any remaining faults Perfective –Business environment is constantly changing Additional functionality Adaptive New platform - e.g. Move to new version of OS; Non business change - tax code, ZIP + 4

Categories of Maintenance (cont) Preventative –Activities designed to increase the maintainability of the system – refactoring, updating documentation (external and internal) The first three categories increase the complexity of the product; the fourth attempts to reduce complexity CSCI 3350Lecture

CSCI 3350Lecture Constraints on Maintenance Despite –Fraction of total product cost, resulting in maintenance being a major revenue source –The difficulty of maintenance Incorporates all the other workflows Historically (still true today) maintenance is –The home of “newbie” –Elephant burial ground Less competent programmers

Recall Error, Failure Fault Error - A discrepancy between an actual value and a expected value Failure - Inability for the system to perform according to specifications Fault - A condition that causes the system to fail If an error is observed, then a failure must have occurred If a failure has occurred, then there must be a fault in the system CSCI 3350Lecture

CSCI 3350Lecture A Typical Maintenance Scenario Maintenance programmer (MP) is given a defect report –Defect = “Sumthin ain’t right” How does the MP proceed? –MP needs to reproduce the error –Determine wherein the problem lies Documentation - requirements, design, user manual, reference manual, … Code Maybe no problem at all

CSCI 3350Lecture Scenario (cont) What “resources” does the MP have? –The defect report Often incomplete or inaccurate –Test suite Probably no existing tests to pinpoint the problem –Will have to write some tests to reproduce the defect –Documentation Out of date, incomplete, inaccurate –The source code Structurally “mutilated”

CSCI 3350Lecture Scenario (cont) To find the fault –The MP must be a superb diagnostician Fault could be anywhere –Requirements -> implementation –How likely, given the talent pool?

CSCI 3350Lecture Scenario (cont) Eventually our MP finds the fault A huge problem remains –How to fix the fault, without breaking something else If the documentation were “good” –Consult it prior to generating a “fix” But it won’t be –The MP has only the source code upon which to rely

CSCI 3350Lecture Scenario (cont) So, with great trepidation, our MP –Reads and tries to understand the code –Makes some changes to the source code Tests with the tests that he used to reproduce the error –Hopefully, the defect is gone Reruns the entire regression test suite –You know that there will be problems

CSCI 3350Lecture Scenario (cont) Add the additional tests to the test suite Documents all changes –Changes to the requirements documents –Changes to the design documents –Adds comments to the source code Before moving on to the next, and always more critical defect report –Yeah, right - I have some prime ocean-side property in Kansas for you

CSCI 3350Lecture Scenario (cont) To achieve this, our MP must –Be a Dr. House class diagnostician –Be a coder extraordinaire –Have excellent testing skills –Have great documentation skills Dare I mention the talent pool again? What lifecycle model does this process most closely resemble?

Summary of Process The MP must devise a test to induce the failure in the system, which reproduces the fault Uncover the fault which lead to the failure Repair the fault Rerun complete regression test suite CSCI 3350Lecture

CSCI 3350Lecture Change Orders Similar process must occur when the maintenance programmer gets a change order for –Adaptive maintenance –Perfective maintenance When the product was developed, specialists produced –Specification –Design –Implementation

CSCI 3350Lecture Change Orders (cont) However, our MP –Must do all of the above Plus –Testing SQA representative may (should) be involved –Documentation Is maintenance a good place for the “newbies” and the less competent?

CSCI 3350Lecture Where Have All the Flowers Gone? The MP’s life is not a joyous one –MP deals with unhappy users –Problems (initially) traceable to developers not MP –The code may be poorly written (or have been degraded) –High stress Poor maintenance -> no repeat business –Most developers hate maintenance

CSCI 3350Lecture Flowers (cont) In brief, –Maintenance is the hardest and least rewarding aspect of software engineering

CSCI 3350Lecture Product Quality The more changes there are –The more the product deviates from its original design –The more difficult further changes become –Documentation becomes even less reliable –A major rework of some portion may be needed –Regression testing files may not be current But should strive to keep code maintainability high for the future

CSCI 3350Lecture The Odious Customer The customer / user will generate lots of –Defect reports –Change requests Change is more difficult to handle than during the requirements workflow The required response time is always short Remember the customer is paying “big bucks” for maintenance –Customer expects service –Customer is the 1200 pound gorilla

CSCI 3350Lecture Reverse Engineering If you have only the source code, or the documentation is hopelessly out of date Reverse engineering the design (or requirements) is the only solution –Start with the source code –Recreate the design No terribly difficult, but time consuming –Recreate the specifications Extremely difficult Only have the executable?

CSCI 3350Lecture Testing During Maintenance Regression testing is mandatory –Complete test suite in electronic form Tests Expected results –Test suite must be maintained

A Maintenance Process SCRUM – an agile process An iterative method applied to each change Four phases –Planning – define change, estimate cost, schedule –Architecture – adapt the design to accommodate the changes –Development sprints – implement the changes –Closure – plan for release of iteration CSCI 3350Lecture

CSCI 3350Lecture Summary Maintenance is at least as demanding as development –But probably harder since MP must have all the skills of the “experts” used during development But, developers are –More highly respected –Better paid