Lecture 12Maintenance

CSCI – 3350 Software Engineering II

Fall 2014

Bill Pine

CSCI 3350 Lecture 12 - 2

Overview

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

CSCI 3350 Lecture 12 - 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

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 Lecture 12 - 4

CSCI 3350 Lecture 12 - 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

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 Lecture 12 - 6

CSCI 3350 Lecture 12 - 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

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 Lecture 12 - 8

CSCI 3350 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 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?

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 Lecture 12 - 16

CSCI 3350 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 20

Flowers (cont)

• In brief,– Maintenance is the hardest and least rewarding

aspect of software engineering

CSCI 3350 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 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 Lecture 12 - 24

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 3350 Lecture 12 - 25

CSCI 3350 Lecture 12 - 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