Application Management and Product Support

Reengineering and Migration

Gausa is capable of executing large reengineering and migration projects involving database and language changes and data conversion, from one platform to another - Unisys to IBM, CDC to IBM and Mainframes to Client Server environments. Gausa’s reengineering process includes:

• Analysis of existing applications.
• Identification of suitable technology and platforms.
• Replacement of obsolete applications through fresh development or integration of established products.
• Migration of applications to the new platform
• Design, development and integration of the new environment.

Priorities on Application Maintenance Process

In Gausa’s opinion, the following areas need to be accorded top priority during the maintenance of applications:

• Effective management of in-house knowledge
• Collection of appropriate metrics
• Effective monitoring of service levels

Effective Management of In-house Knowledge

The main issue in a typical maintenance scenario is the dissemination of application knowledge. With the constituents of a maintenance team being dynamically changed on a continuous basis, unless the application knowledge available with the team is captured and stored in an electronic repository facility, it will be very difficult to keep the knowledge ‘recycled’. Especially for ‘mission’ critical applications where the learning curve is likely to be a significant bottleneck in providing effective maintenance services. It is absolutely essential to find out means of storing the domain application knowledge so that spreading the same by way of training is made relatively simpler.

Collection of Appropriate Metrics

Metrics form a vital part of any maintenance project. Appropriate metrics can provide indications to the adherence to the service levels being provided, very early in the process. The type of metrics to be collected during maintenance services must be finalized up front. Gausa has the ability to capture and use many different types of metrics associated with software maintenance activities.

Effective Monitoring of Services Levels

Once the service levels have been agreed upon and frozen, the adherence to the same must be monitored on a continuous basis. Gausa strongly believes that a formal process for doing so is a requirement and delivers such for every feasible project. The initial tailoring of the service levels to suit the changing environment in Client would begin with existing service level with an intent to improve upon these whenever possible, as fast as possible.

Gausa has a large pool of resources, which are involved in Legacy application support.

The main objective of Gausa is to continuously improve its software process. This will benefit Client by Gausa providing:

• Deliveries on time
• Deliveries with measurable quality objectives and targets
• Deliveries with minimum cost
• Deliveries on budget
• Deliveries with lower residual defects
• A clear understanding of Client requirements and priorities

Risks

Some of the risks that could impact cost and schedule and the methods to mitigate them are given below

Peak Load - Too many problems reported all at once

The overloads will be handled by extending the normal working hours. In the unlikely event of Gausa not being able to address the peak load of errors, the matter will be escalated to Client for further action. This will be discussed in good faith with Client and suitable action plan will be arrived at, which includes prioritizing the workload or treating some of the workload as change requests for enhancements.

Communication Link Failure between Offshore and Onsite

Based on the previous experience with other large projects, the communication link is very stable. Even in case of sudden failure due to unforeseen circumstances Gausa has the knowledge and expertise to bring the communication link back into usage in a very short down time. The onsite team will handle the daily production support during such periods.

New Releases of Software, Application Systems

Whenever a new release of software is put into use, Gausa would evaluate the impact on the application systems, operating environment and identify potential issues and prepare a corrective plan and software re-hosting plan. This will reduce occurrence of errors in the new release environment. Whenever Client is releasing a new version for production purpose, the Gausa team should be educated about the salient features addressed in this release. Gausa and Client can mutually agree on the procedures during the Transition Phase. A comprehensive system test plan and data is very essential before the release of any new version of the application system. Gausa will assist Client in preparing such a test environment and Gausa feels that having and using such an environment will greatly reduce the error occurrence after the system is released for production.

Discontinuity of Staff

In case a member discontinues, smooth induction of a new member into the project is ensured by the Maintenance Manual and Training programs that will be prepared. The project team will do a periodic review of risk tracking and containment. Apart from tracking the already identified risks, new potential risks, if any, will be identified and the mitigation plans for them will be discussed with Client.

Project Security

Gausa gives utmost importance to the security aspects. These are handled at various levels as explained below.

All Gausa buildings are controlled by security guards, who provide 24-hour service. Entry to any Gausa premise is controlled through Identity cards. Visitors’ entries are restricted through visitor cards and are also recorded.

Every project member shall sign the confidentiality agreement with the clients to abide by their security guidelines. Gausa has signed such agreements with some clients, where, even the name of the client cannot be disclosed for security reasons.

Gausa is willing to provide all security restrictions to the client as it is currently provided at onsite. The Gausa offices have frequently been audited for security by professional groups on various clients’ request and the security system has proven to be matching the international standards.

Reverse Knowledge Transfer

Whenever required by Client, Gausa is committed to transfer the application, environment and maintenance knowledge to Client. Gausa would maintain and deliver the following documents during the Application Maintenance life cycle:

• Maintenance Manual
• Problem log and the resolution details
• Functional specifications for major code changes or new code development
• Metrics
• Causal Analysis document

Gausa will also prepare any additional documents as required by Client.

Maintenance Model

The maintenance activities will be carried out through a set of well-defined phases, based on proven SEI, CMM and ISO certified methodology. The location of the maintenance team forms a key factor in determining the success of the outsourcing initiative and various models are available in this regard. Gausa can execute this project for Client using any of the following models:

Onsite :: Offsite :: Offshore approach

In this approach, part of the Gausa maintenance team will be located at Client. The other part of the team will be located at Gausa, New Delhi, India.

Gausa Onsite team acts as the front-end for Client. Gausa will allocate a Business Relationship manager and he will be the single point of contact for Client. The Gausa onsite team will interact directly with the Client’s ITM staff and users for better understanding of problems and minor enhancements. Production calls will be handled at onsite, offsite or offshore depending on the time of the day with problems being reported directly to support team at either locations.

There will be a set of 'steady state' activities that the offshore team would work on, for example, error analysis of critical systems and enhancing documentation. Maintenance support activities would be taken up on a priority basis as and when they arise.

Gausa will setup a communication link to offsite and offshore locations to have access to Client’s mainframe and other servers.

As a supplement to this approach, Gausa can also replicate the Client environment on to its own computing facilities at Offshore and work on some of the service requests. This can reduce the load on the Client computing resources. This approach will be suitable for those requests that have the following characteristics:

On-site :: Off-site Model

If Client prefers, Gausa can consider the option of locating an Off-site team at a Gausa location within the United States instead of locating them in India. The rest of the approach is the same as the previous model, except that the Off-site team substitutes the Offshore team, which has impact on the cost.

On-site Model

In this model, the entire team from Gausa will be located at Client location.

Service Level Methodologies

A service level agreement (SLA) is a contract between a provider and consumer of a service. The purpose of the SLA is to establish agreed to targets of performance while satisfying the expectations of the customer. The objective is to achieve a level of performance acceptable to the customer of the service and realistic to the provider.

It is essential to setup and document the appropriate service level expectations in the form of a Service Level Agreement. This section provides guidelines to arrive at such a Service Level Agreement. It specifies the duration for providing temporary fix and permanent solution for the service request at each severity level.

A detailed definition for each of the severity levels will be discussed with Client to adopt these to their requirements.

Gausa and Client will discuss and mutually arrive at a service level matrix stipulating the service levels expected.

Measuring Service Levels

Gausa focuses on the following Metrics for measuring the legacy application systems services :

Responsiveness: To measure the turn-around time in production problems. The formula for calculating responsiveness is Responsiveness = Time taken to respond to a production problem / Time committed as per the service level agreement Responsiveness is measured monthly

Backlog Management Index: To measure and compare the number of problems yet to be taken up with respect to the current workload The formula for calculating BMI is BMI = (Number of closed problems + Number of open problems) / Number of closed problems BMI is measured monthly

Schedule Adherence: To measure the accuracy of the schedule estimation, adherence to the schedule and the quality of the process. Schedule Adherence = (Actual Service Request duration – Estimated Service Request duration) / Estimated Service Request duration Schedule Adherence is measured monthly

Defect Density: This will be used to measure the number of defects residing in the System / service request based on the effort consumed for the service request Defect density = ( Number of defects in peer review + Number of defects in Unit test ) / Person days of effort for that service request Defect density is measured monthly

Fix Quality: The number of defects fixed improperly in a maintenance project is a measure of effectiveness of the maintenance. This coupled with causal analysis of the defects will identify the factors responsible for the bad fixes and help initiate corrective actions Fix quality = Number of Defective Fixes Reported Fix quality is measured monthly

Transition Methodology

Gausa would evaluate the following transition methodologies and adopt a suitable one for transitioning the application maintenance services:

Crash Transition

This approach means taking up the application support, maintenance, enhancement or development, completely from the incumbent Gausa within the shortest possible period of time. This will mean a multi-dimensional approach towards Familiarization, Audit and Planning; Knowledge Transition; Transition of service; Service and Stabilization, and Process Improvement. This approach will mean staffing the project fully from the very beginning, conducting crash courses and putting in place a strong project management team to handle the multitude of issues.

This approach carries significant risks and it will be very likely that the current service levels will get affected adversely. The current context does not justify taking such high risks. It is advisable to take up the phased transition route.

However, in case the situation demands such a transition, Gausa has the necessary expertise, experience and willingness to do so.

Phased Transition

Phased transition means following a step-by-step approach to transition the application knowledge over a period of time. In this scenario, Gausa will start with the knowledge acquisition phase to build up the critical mass. Gausa will conduct an extensive study during the planning phase to prepare a detailed route map for the complete transition program in a phased manner. The driver for such a plan will be ‘business-as-usual’ for Client at lower cost and minimal risks.