1. Product released!
Software
Released!
Now what?

2. 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

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

4. Problem Arrival Curve 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.
Problems
discovered & reported
Time (after software release)
Problem Arrival Curve

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

6. Software support is not free Software support is not forever
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

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

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

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

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

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

12. Sample Problem Priority Levels
Problem Category
Fix Response
Time 1
Severe functional
problem with no
work-around
As soon as possible 2
Severe functional problem but has
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
Sample Problem Priority Levels

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

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

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

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

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

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

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