Lecture 12 Maintenance

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

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

3. 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 CSCI 3350

4. 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 3350

5. 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 CSCI 3350

6. 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 3350

7. 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 CSCI 3350

8. 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 3350

9. 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 3350

10. 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 3350

11. 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 3350

12. 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 3350

13. 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 3350

14. 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 3350

15. 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? CSCI 3350

16. 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 3350

17. 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 3350

18. 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 3350

19. 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 3350

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

21. 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 3350

22. 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 3350

23. 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 3350

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

25. 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 3350

26. 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 CSCI 3350