Perot Systems TSI

Change Management

CHANGE MANAGEMENT

Version No. Released On Authored by Reviewed by Approved by

1.0 5-08-2004 Neeru Goel

Anil-Vijay Malhotra

Perot Systems TSI Plot #3, Sector 125, NOIDA-201301, Uttar Pradesh, India www.pstsi.com Security Classification: PSTSI Confidential This is a controlled document. Unauthorized access, copying and replication are prohibited. This document must not be copied in whole or part by any means, without the written authorization of PSTSI Project Manager.

Version 0.5
1

Company Confidential

Page

Perot Systems TSI

Change Management

CONTENTS Anil-Vijay Malhotra...........................................................................1 1. Change Management.....................................................................3 2. Classification.................................................................................3 2.1 Problem/ Requirement Identification...............................................3 2.2 Analysis......................................................................................4 2.3 Design........................................................................................4 2.4 Construction................................................................................4 2.5 Regression/System Testing...........................................................5 2.6 Acceptance Testing......................................................................5 2.7 Delivery......................................................................................5 3. Minor Change Management............................................................5 4. Major Change Management ...........................................................6 5. Emergency Defect Management.....................................................6 6. Normal Defect Management...........................................................7

Version 0.5
2

Company Confidential

Page

Perot Systems TSI

Change Management

1.

Change Management

Changes are basically enhancements to existing applications for adding new functionality or including new business logic or making changes with respect to system performance. Change management describes procedures that ensure that all proposed changes are subjected to an authorization process, including assessment. for impact and resource requirement. 2. Classification

Changes are mainly classified as minor and major changes. Changes, which do not have any serious impact on existing system, are classified as minor and the changes, which have major impact on the existing systems, are classified as Major. Regression testing will be an additional activity carried out for major changes. All change requests are logged into Issue Log application. From where a unique control-Id is issued to all Issues and change requests, which help in tracking, all the issues/change requests till they are closed. All minor changes are carried out in the earliest possible timeframe say within 24 hours. But the time frame for all major changes gets decided only after analyzing the issue. All changes whether minor or major will be logged in issue log application. Issue log will also have testing and deployment mails for all CRs. The process to provide change request service is a repetitive cycle of monitoring, acting and reporting. In general the lifecycle comprises of the following: Problem / Requirement Identification Analysis Design Construction Regression/System Testing Acceptance Testing Delivery

2.1 Problem/ Requirement Identification The main activities comprising this step are:
3

Classify the type of change request as adaptive, corrective, perfective, or emergency. Analyse to determine whether to accept, reject, or further evaluate the request. Make a preliminary estimate of the effort involved. Company Confidential Page

Version 0.5

Perot Systems TSI

Change Management

Priorities the request on the basis of Classification and complexity Assign the request to a planned release

2.2 Analysis Analysis is an iterative process having at least two components: Feasibility Analysis- Determines the impact of the modification in terms of safety and security factors, short-term and long-term costs, and the human factors. Alternate solutions (including prototyping), and the value of the benefit of making the modification are also identified. Detailed Analysis- Defines the firm requirements for the modification, identifies the elements to be modified, identifies the safety and security issues, generates a test strategy and an implementation plan. At the end of the analysis phase, a risk analysis is performed. The output of the analysis phase is used to revise the resource estimates and a decision on whether to proceed to the design phase or not is taken jointly by the client and MIS. 2.3 Design Design activity comprises the following: Identifying affected software modules. Modifying software module documentation (e.g. data and control flow diagrams, schematics, SRS etc.) Creating test cases for the new design, including safety and security issues. Identifying/creating regression tests.

2.4 Construction
Construction of the design comprises the following sub-processes, which may be repeated in an incremental, iterative approach:

Coding and Unit Testing- Implement the change into the code in development environment and perform unit testing in testing environment. Integration- After the modifications are coded and unit tested, or at appropriate intervals during coding, the modified software is integrated with the system and the integration and regression tests are refined and performed. All effects (e.g. performance, functional, usability, safety) of the modification on the existing system are assessed and any defects are resolved. Risk Analysis- In the implementation phase, risk analysis and review is performed periodically during the phase rather than at its end, as in the design and analysis phase. Test-readiness review- To assess preparedness for system test Version 0.5
4

Company Confidential

Page

Perot Systems TSI

Change Management

2.5 Regression/System Testing System test is performed on the coded and unit tested software. Regression testing is a part of system testing and is performed to validate that the modified code does not introduce faults that did not exist prior to the maintenance activity. 2.6 Acceptance Testing
Acceptance testing is performed by the client organization and comprises the following process steps:

Perform acceptance tests at the functional level Perform interoperability tests Perform regression testing

2.7 Delivery Delivery of a modified product comprises the following: 3. Conduct a physical configuration audit Notify the user community Develop an archival version of the system for backup Perform installation and training, if required, at the customer facility Minor Change Management
DEFECT RAISING, CLASSIFYING, APPROVAL, AND DEFECT RAISING, CLASSIFYING, APPROVAL, AND ASSIGNING ASSIGNING
ANALYSIS, CHECKOUT BASELINE CODES ANALYSIS, CHECKOUT BASELINE CODES

MAKE CHANGES MAKE CHANGES

TESTING TESTING

UAT UAT

RELEASE TO PRODUCTION RELEASE TO PRODUCTION AND CLOSING AND CLOSING

Version 0.5
5

Company Confidential

Page

Perot Systems TSI

Change Management

4.

Major Change Management

Change Initiation Change Initiation

Analysis and Estimation Analysis and Estimation

Approval and Approval and assigning assigning

Making changes Making changes

QA Testing QA Testing Regression Regression Testing Testing

(If applicable) (If applicable)

UAT UAT

Implementation and close Implementation and close CR CR

5.

Emergency Defect Management

In case of a problem when Production is stopped from functioning, and after following all escalation procedures, a fix is derived at and the production team checks out code remotely. MIS first line support team applies the fix and after testing hands over the code to intranet admin who then promotes the code to EFIX (or Emergency Fix), which is one, level higher to Production. These kinds of defects are resolved at higher priority and team tries to resolve them within 24 hours.

Version 0.5
6

Company Confidential

Page

Perot Systems TSI

Change Management

DEFECT INITIATION, DEFECT INITIATION, CLASSIFICATION AND CLASSIFICATION AND ASSIGNMENT ASSIGNMENT

PRODUCTION CHECKOUT, PRODUCTION CHECKOUT, DEFECT FIXING AND TESTING DEFECT FIXING AND TESTING RELEASE TO RELEASE TO PRODUCTION PRODUCTION RETROFIT RETROFIT CHANGES CHANGES CHECKOUT BASELINED CHECKOUT BASELINED CODES CODES MAKE MAKE CHANGES CHANGES

TESTING TESTING

UAT UAT RELEASE TO PRODUCTION RELEASE TO PRODUCTION AND CLOSING AND CLOSING

6.

Normal Defect Management

All Problems, that are not resolved at first level helpdesk, are eventually converted as Defects and are tracked through the Defect Tracking Mechanism. These kinds of defects are basically day-to-day issues and are resolved immediately.

Version 0.5
7

Company Confidential

Page

Perot Systems TSI

Change Management

DEFECT RAISING, CLASSIFYING, APPROVAL, AND ASSIGNING DEFECT RAISING, CLASSIFYING, APPROVAL, AND ASSIGNING

ANALYSIS, CHECKOUT BASELINE CODES ANALYSIS, CHECKOUT BASELINE CODES

MAKE CHANGES MAKE CHANGES

TESTING TESTING

UAT UAT

RELEASE TO PRODUCTION RELEASE TO PRODUCTION AND CLOSING AND CLOSING

Version 0.5
8

Company Confidential

Page