1. Chapter 12 Software Support and Maintenance

2. Product released! Software Released! Now what?

3. Customer/User Support Post software product-release support –Non-defect support Usage questions-answers General help (install, recovery, etc.) Additional and supplemental functions (future releases) –Defect support Report and track failure and defect Recovery from failure Work around Fixes releases

4. Defect Support While both non-defect and defect support are important, defect support requires some sophistication: –Project the # of problems and problem arrival rate –Estimate and plan the needed support resources –Educate and build the defect support team –Defect reporting and tracking –Defect identification, fix, and release

5. Problem Arrival Curve Time (after software release) Problems discovered & reported -During the period right after release, many problems are discovered and reported. -The amount of problems discovered eventually decreases; at the same time the nature of the problem discovered becomes more difficult to diagnose.

6. Problem Discovery Curve Traditionally follow a Raleigh Curve: –A special case of Weibull distribution : f(t) = (m/t) (t/c) m e (-t/c)m [ note : m is a superscript to (-t/c) ] when m = 2, we have Rayleigh curve f(t) = (2/t) (t/c) 2 e (-t/c)2

7. Customer Support Software support is not free –Most charge an annual fee (e.g. 18% of product) Software support is not forever –Most product goes through a number of releases –Each product release is only supported for a limited number of years –Customers/users are moved from back-level software to the current release as soon as possible Usually support no more than 2 back-levels of a software

8. Product Support Life cycle Plan & Prepare for Support/Maintenance Product Release Non-Defect support Defect support Announcement of new release or replacement software Reduced Defect support (only severe defects) User/customer migration Product withdrawal

9. Product “Sun-setting” Stop any product’s additional feature and enhancement Fix only the high severity problems Announce new replacement product Encourage new and existing customers to move to new product Notify all old users on the old product of the planned termination date Provide names of other vendors who are willing to support the old product to the customers who chooses to stay Terminate the customer product and withdraw the product from market

10. Tiered Customer Support Organize the support group into tiers: –A direct customer contact tier to accept problems, prioritize the problems, record problem, solve the “easy” problems, and manage the problem- resolution cycle. –A higher tier pf specialized resource that sometimes talk to customers to resolve more difficult problems with work arounds –A tier of experts that can fix and rebuild the code May be One tier

11. A Sample Service and Support Organization Customer Service/ Support Reps. Customers/ users Customers/ users........ Telephone Call On-line Direct Customer Support Technical Problem / Fix Analysts Problem Fixes & Delivery Problem/ Fix information FAQ On- line Support (one tier)(another tier)

12. Problem Fixes A key parameter in keeping the customers satisfied is to turn the problem fixes around within some reasonable time-frame. This requires an understanding and a “contract” of service terms. The contract on fix response time is in turn dependent on the types of problem based on some “prioritization” scheme

13. Sample Problem Priority Levels Priority LevelProblem CategoryFix Response Time 1 Severe functional problem with no work-around As soon as possible 2 Severe functional problem but has work-around 1 – 2 weeks 3 Functional problem that has a work- around 3 – 4 weeks 4 Nice to have or to change Next product release or earlier

14. Installing Fixes Customers do not always install a fix release provided by the software support group. –Choose and pick the fixes they want –Modified code and can not apply the generic fix release –Stay on some past release because it “finally” works Need to explain the potential serious problem –Fix Release related to other fix releases that customer care about in product fix situation. (see next slide) –A released fix may have reworked over a previous “emergency’ fix code area (see a later slide)

15. Multiple-Product Fix Releases that must be applied together to keep all the functions and data in synch Base Manufacturing Application Update/Fix maintenance Release 1 Update/Fix maintenance Release 2 Update/Fix maintenance Release 3 Related Financial Application Related Distribution Application Update/Fix maintenance Release 1 Update/Fix maintenance Release 2 Update/Fix maintenance Release 4 Update/Fix maintenance Release 1 Update/Fix maintenance Release 3 6 months12 months18 months24 months

16. Fix Overlay Problem Statement 1 Statement 2 Statement 3 Statement 4 Statement 5 Statement 6 Statement 7 Statement 8 Statement 9. Fix Release n. Statement 3’ Statement 4’ Statement 5’ Statement 6’. Fix 1. Statement 2’ Statement 3” (del) Statement 5’’ Statement 6’’’. Statement 3’’ Statement 4’’ Statement 6’’. Statement 11’. Fix 2 Fix 3 Fix release (n+1), containing 3 accumulated fixes (re-tooled) emergency fix

17. Fix Install Users and customers should be encouraged to install the latest fix release and install the fix releases in sequence. Sometimes they need a better explanation than “it is our policy”

18. Change Control in Support & Maintenance All problems reported need to be tracked through successful problem-resolution with the customers. A part of this control is to ensure that all changes, for fixes and for enhancements, are not arbitrary and capricious. Change Control is the mechanism used, just as in software development prior to release, to ensure that all changes are managed through –Change control process –Documented changes (change control form as an aid) –Change control committee

19. Change Control Process and Committee Manages the changes via a work flow: –Origination of change request –Approval of change request –Monitoring the changes being made –Closing the completed change Needs resource to ensure the control process: –Change control board or committee –Automated workflow tool (using a change control form)

20. Sample Maintenance Change Request Form Change Request # :_____________Request Date:_____________ Requestor Name:_______________ Request Accepted-Date:_______________ Status: Rejected-Date:_______________ Processing Start-Date :________ Completion-Date:_____________ Brief Change Request Description:__________________________________ ________________________________________________________________ Areas Impacted by the Change Request :______________________________ _________________________________________________________________ Estimated Effort: ___________Inclusion in Maintenance Rel.#: ___________ Requestor Priority: High, Medium, Low