INTEGRATED SOLUTIONS

Software Support process

Prepared By:
Lead Author, Integrated Solutions	Date
Approved by & Effective on Date of Signature below:
Yufen Chang Yu, Integrated Solutions	Date

THIS DOCUMENT IS TO BE REGARDED AS THE OFFICIAL EMPLOYEE TRAINING GUIDE WITHIN INTEGRATED SOLUTIONS. IT IS TO BE MAINTAINED UNDER CHANGE CONTROL BY THE DOCUMENT CONTROL COORDINATOR.

CHANGE SHEET
TITLE: Integrated Solutions Software Support Process
DESCRIPTION OF CHANGE
ISSUE	DATE	SECTION	DESCRIPTION
1.0	7/29/97	All	Original Issue

1.0 Purpose

This process is to be used by Integrated Solutions (IS) if not specified in the contract or required by the customer to use a different process.

2.0 Description

This process defines the procedures to be used for the support and maintenance of released software products developed at Integrated Solutions or supplied to by third parties when the supplier does not provide maintenance and support. The process describes the procedures for providing product support, the procedures for implementing problem fixes and feature changes, and the procedures for planning and executing a maintenance release.

3.0 Overview

All generally released products are maintained and supported by clearly identified resources within the IS. It is the responsibility of the appropriate maintenance owner’s team to provide support when a problem has been isolated to a failing subsystem and/or module by the field support personnel. A maintenance owner (usually a team leader) monitors incoming problem reports and feature changes and prioritizes them by analyzing the reported priority level, the impact to the customer, and the amount of time required to make the fix or change. The maintenance owner ‘s team will package all implemented problem fixes and feature changes into a generally available maintenance release as required in the contract.

4.0 Problem and Change Tracking

The maintenance owner’s team will document activity on all incoming problem reports and feature change requests through the IS ticket systems or per the contract. The team may also use localized tracking mechanisms during testing periods, at the conclusion of the testing period all unresolved problems are then transferred into the required system. The local ticket system allows for the tracking of problem reports, progress of analysis, implementing a defect correction (if necessary), and final resolution.

5.0 Support Activities

Initiation - Normally, assistance is provided after the Field Support Team has obtained all pertinent information and completed an initial investigation to determine that a problem has been encountered and created a problem report via the corporate problem tracking mechanism.

Management Directive - Occasionally, the software maintenance support team is directed by management to provide a support function in emergency situations prior to the existence or transfer of a problem report via the corporate problem reporting mechanism. When this emergency situation occurs field support team creates a formal problem report as soon as possible after engineering’s participation in the problem investigation.

Consultation (Phone, E-mail, Direct verbal Contact) - Consultation with product users or with field support analysts prior to the existence or transfer of a problem report may be an anticipated support function. This should be an exceptional situation. A support analyst should create a problem report as soon as possible. The results of the consultation should be recorded by the software maintenance support team member in the problem report in the problem tracking system that was created.

Internally Detected Problem - When a problem is detected in a pre-release software product, an internally originated Ticket should be created to track the problem.

6.0 Implementing Problem Fixes and Feature Changes

PROCEDURE DEFINITION

Incoming problems and feature changes - This procedure begins when a problem report or (Ticket, technical action request) is created and:

1) is transferred to the maintenance owner responsible for the support of the product from the field support owner with a state of “under investigation” and a reason code of “under investigation by development”

or

2) is already assigned to the maintenance owner when it was opened (as when created by another engineering organization).

Task 1 - Input Verification

Incoming problem reports and feature changes are given a preliminary analysis to determine if there is sufficient information to proceed. Typical information gathered includes:

o Problem symptom, detail description. Justification for transfer to software maintenance.

o Impact on customer/ problem priority/ political sensitivity. Is there a temporary work around?

o Description of any recent changes (e.g., is this a new installation?) to hardware or software (including applications), or procedures.

o Indicate if problem is reproducible & how reproduced. If not, what was going on when problem occurred? When did it occur (i.e.: time of day)? What is the frequency of occurrence?

o Environment- both hardware and software. Hardware description should include network configuration and characteristics, client and server descriptions/models (including memory sizes) and if bridges / routes are utilized. Software information should include version numbers of resident products including applications, drivers and the Operating System for both clients and servers. User application functional descriptions may also be necessary.

o Reproducible problems should include supporting documentation such as product configuration files, product component logs, core files, product component error logs, etc. Non-reproducible problems should include as much supporting documentation as available.

o Other given information should always include contact name, phone number, location, and best contact time.

If there is not enough information and if the problem report is customer generated, the Ticket may be placed into the “suspended” state with a reason code of “awaiting documentation” and responsibility transferred back to the originating NGSC support team leader. This should be done with consideration given to the nature of the Ticket, e.g., priority, customer sensitivity or political aspects.

If there is not enough information and if the problem report has been generated by someone else, then the originator of the problem report is contacted and more information is requested. The Ticket is modified to a “suspended” state with a reason code of “awaiting documentation”. If this request is not satisfied within a maximum of 30 days, then the Ticket may be modified to a “return” state with a reason code of “insufficient docs” and returned to the responsibility of the field support owner.

Task 2 - Problem Report Classification

Once sufficient information has been obtained, and if the software product that the problem report has been determined to be against is a third party vendor supplied product with which the IS has a support agreement, then the product specific document (may be a contractual agreement) for the specific third party vendor product will govern the support activities.

If the software product involved is not covered by a support agreement with a third party supplier, proceed to the next task.

Task 3 - Prioritization

Unless specified in the contract or per the customer requirements, the current problem resolution time guidelines are linked to the priority of a Ticket. These are currently:

· Priority 1 - 48 hours

· Priority 2 - 10 days

· Priority 3 - 21 days

· Priority 4 - next maintenance release

The problem report is reviewed by the team to determine if and when it will be scheduled for resolution, and who will be responsible for the implementation. If a customer requires a fix for a problem prior to the next maintenance release, the priority is raised if necessary to reflect the urgency and a team member is assigned to resolve the problem and deliver a fix to the customer. If an incoming Ticket is of a higher priority, than a Ticket planned for the next release, but does not require delivery to a customer prior to the next maintenance release, the team may substitute the incoming Ticket in its maintenance release schedule. The team also has the option to request additional resources from their coach if all problems are considered to be high priority.

Task 4 Diagnose Problem

The problem is diagnosed by the assigned team member to determine if the Ticket is a software defect which has been assigned to the correct product name, product version and responsible person . If not, the call may be reclassified and/or redirected as necessary, or returned with the appropriate reason.

The Ticket is considered to be a defect if the product fails to conform with documented operation (e.g., Functional Specifications, Technical Publications, Release Package, etc.). If the call is a latent software defect, the developer attempts to identify the problem. Critical points to be considered are :

o Problem symptoms

o Problem stimulus

o Changes in the environment

o New features introduced (both hardware and software)

o Frequency of occurrence

o Time of day/age of system

The diagnosis continues until the problem has been identified. Not only identified as a problem but where the problem was introduced into the product. The maintenance analyst must identify the root cause and classify it into one of the following categories:

Requirements - The error was introduced due to lack of clarity in the product requirements at end of Definition Phase.

Design - The error was introduced due to incomplete or incorrect design.

Implementation - The error was introduced during implementation, but is not a coding error.

Coding - A simple coding error or mistake.

Documentation - The user documentation contains a mistake.

Packaging (SCM activity) - An error in the production of the distribution package.

Supplier - An error in the product as received from a supplier.

This information is then entered into the appropriate system.

Once the problem has been identified, the maintenance analyst must decide if a software fix is necessary. If a software fix is not required, the Ticket may be reclassified and/or redirected as necessary, or returned with the appropriate reason code. Otherwise continue.

Task 5 Design and Implementation

When a Ticket has been defined, the Ticket is required to contain the following:

o Description of fix

o Modules changed (and their new version if applicable)

o IS release in which fix is included

o Test information

In the design activity, the developer determines a solution for the problem. If the change is major, the developer should review the design with other team members for feedback.

Once the design has been agreed upon, the source code is checked out from the repository where stored and copied to a development area. The source changes are applied to the subject modules, compiled, and optionally the code is reviewed by the same team that reviewed the design. If a code review is held, any changes agreed upon are applied to source code and modules are recompiled.

Note: Unit testing is mandatory. Integration/Acceptance testing is mandatory only prior to the maintenance release. A test description should be included in the Ticket fix description, formal documentation although optional is recommended.

Task 6 - Build / Deliver Software Change / Customer Test

The decision to deliver a software change depends on the willingness of the customer to wait for the next maintenance release. If the problem is severe (Ticket priority 1) or if the customer needs the fix prior to the availability of the next maintenance release, then a delivery of a fix to the customer is necessary. The team member may create a patch package with an appropriate name and should inform Software Configuration Management (SCM) of the patch delivery.

When a customer originated problem is delivered, the associated Ticket is modified, changing its state to “suspend“ with the reason code of “awaiting customer verification” and is assigned to the responsible team leader in the field support who ensures that the fix meets the customer’s expectations. The software change will be delivered by an field support analyst to the originating customer for installation and testing. Once the results of the software change installation are determined, the field support analyst responsible for delivering the ‘patch’ modifies the Ticket by changing its state from suspended to “interim solution” with a reason code of “fix accepted” and transfers responsibility back to the maintenance owner.

Task 7 - Source Control

Upon successful completion of testing and/or customer verification, the modified source code is checked in so that the software change can be incorporated in the next generally available software feature or maintenance release. The Ticket must be modified by changing its state to “permanent solution“ with a reason code of “solution acceptable”, when a release containing the fix has been sent to the distribution centers.

Task 8 - Update Testbed

Updating the engineering support testbed may be necessary prior to completion of a Maintenance Release, a Special Test Requirement or following successful customer verification of product corrections. This may include updating any relevant product Integration or Acceptance Test Plans and/or specifications (i.e. updating Revision B to Revision C).

3 - Planning and Executing a Maintenance Release

A maintenance release is defined as a minor software 'point' release intended mainly to consolidate verified problem fixes into a single general release for replacement of a previously released, but flawed, general release version.

Maintenance Releases are scheduled per each contract or customer requirement. It is recommended that the responsible team have a coordinator (usually a team leader) who oversees the planning of the release, maintain a project micro schedule and a project notebook to assist in managing the delivery of the maintenance release and other related support activities.

When planning a release, all unresolved problems should be reviewed and prioritized. The team decides which problems, based on priority, will be implemented in each release. As previously stated, incoming calls can alter the original plan. The team determines the release date and then calculates the date that the software needs to go to SCM and from there the date that I/A testing needs to begin. It then figures out the number of development weeks available. This estimate is used to determine how many open calls will get implemented in the next release. The team should also take additional support activities, planned vacations, and training into account when determining maintenance schedules.