lecture 12 maintenance csci – 3350 software engineering ii fall 2014 bill pine
TRANSCRIPT
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