SYSTEM PROMOTION STRATEGY PROJECT NAME

[Project Name]

System Promotion Strategy

Document Overview
Prepared By:
Prepared For:
Date Created:
Last Updated:
RASCI Alignment
(R)esponsible / Technical Lead
(A)uthority / Technical Manager
(S)upport: / ITPD Team
(C)onsult: / ITPD Management
(I)nform: / Project Manager

Revision Log

Revision / Date / Initials / Description of Revision
1.0 / 10/10/2008 / Initial Draft
1.1 / 10/16/2009 / AL / Updated Draft
1.2 / 10/20/2009 / AL / Updated Draft
1.3 / 11/09/2009 / AL / Updated Draft
1.4 / 11/10/2009 / AL / Updated Draft
1.5 / 12/04/2009 / AK / Updated Draft, minor changes
1.6 / 12/04/2009 / AL / Accepted changes, minor updates

Table of Contents

1) Overview: 4

1.1) Objective 4

1.2) Strategy 4

1.3) Assumptions 4

1.4) Logical Diagram and Process Flow 4

2) Transports/Migration 5

2.1) What? 5

2.2) When? 5

2.3) How? 5

3) Tools 5

3.1) Script 5

3.2) Technical tools 6

3.3) Testing tools 6

4) Standard Defect Management Process 6

5) Approval Process 7

5.1) Business Approvals 7

5.2) Technical Approvals 7

6) Execution 7

6.1) Resources involved in effort 7

6.2) Timeframes 7

6.3) Notifications 7

6.4) Reasons/Objectives 7

6.5) Environments involved 7

7) Verification 7

7.1) Manual testing 7

7.2) Automated Testing 7

7.3) Sign Off 8

8) Terms and Definitions 8

9) Document Signoff 9

1) Overview:

1.1) Objective

The purpose of this document is to diagram and document the process for management of code

transport and promotion of code to the various environments used for the project.

Instructions for areas in question or requiring more details are provided at the beginning of each section where appropriate and are colored in blue and should be deleted after completing the document. This includes this particular paragraph. Remember, areas can always be flagged as N/A, but be prepared to defend that decision.

1.2) Strategy

The purpose of this section is to provide a high level description of the promotion strategy.

<This section should include things such as versioning, naming conventions, logic for movement from one environment to the next. It should also include high level steps for logical progression of the environments towards production>

1.3) Assumptions

Use a table such this one below to identify the assumptions regarding promotion activities. It also defines who is accountable those activities, such as a vendor or an internal organization.

Please change the table accordingly with your requirements.

Activity/Assumption / Internal/External / Organization

1.4) Logical Diagram and Process Flow

<The Logical and Physical environment diagrams should be included or referenced here. The number of environments created for each project will obviously need to be referenced in your promotion flow, so no environment is left without a code build, unless that is by design (in the case of some cold spare setups.). >

Examples of the environments are:

The Quality Assurance environment provides a controlled environment to perform testing. This environment is specifically used as a final validation point for acceptance into production. No changes are permitted in this system. The QA system will be updated via approved transports/ migration from the development system.

Explanations for all other environments represented in the logical diagram for that specific project should be included too.

2) Transports/Migration

The process of moving configuration and development object code from one environment to another follows a controlled process.

Questions to be answered may include:

2.1) What?

a)  What is included in a release ( e.g: database code, database stored procedures, code fixes, , etc.)?

b)  What constitutes a major/minor, patch release?

2.2) When?

a.  When a release a scheduled?

b.  How often a release is deployed?

2.3) How?

a)  What are the steps necessarily to implement a release?

b)  Identify the differences (if there are) when you migrate from one environment to the other

3) Tools

3.1) Script

List scripts or pseudocode used to migrate environments from one to another

3.2) Technical tools

<List all tools that are in use during a system promotion/code push>

a)  Developer tools: Visual Studio, Eclipse, SQL Server Management Studio

b)  Migration/Deployment tools: SSH, Site Server, DTS

3.3) Testing tools

<There are a variety of tools that may be used to support testing. Tools can be used for various elements of the testing process as described below.

Test Scenarios Definition: The Test Scenarios will be defined by the QA team in the following documents:

a)  QUAL026_PROJ Unit Test Script_20090309_v1.0_1.0.xls

b)  QUAL027_PROJ String_Scenario Test Script_20090309_v1.0_1.0.xls

c)  QUAL028_PROJ Integration Test Script_20090309_v1.0_1.0.xls

d)  QUAL029_PROJ Performance Test Script_20090309_v1.0_1.0.xls

e)  QUAL030_PROJ Stress Test Script_20090309_v1.0_1.0.xls

f)  QUAL031_PROJ Disaster Recovery Test Script_20090309_v1.0_1.0.xls

g)  QUAL032_PROJ Regression Test Script_20090309_v1.0_1.0.xls

Test Scenarios Definition: The Test Scenarios will be defined in the String/Scenario Test Scripts. Template is available as part of the Project Methodology Deliverables.

Test Data Generation: Data will be loaded manually or using <tool used>.

Test Script Execution

Test Scripts will be executed manually or using <tool used>.

Defect Tracking

Defects will be tracked using <tool used>.

Volume/Stress Testing

Tools are required to support stress and volume testing in order to simulate the loads associated with production peak volumes. <Tool used> will be used for this purpose.

4) Standard Defect Management Process

The goal of a defect management process is to minimize the resolution time for problems by logging, tracking, and expediting problems as they occur, keeping stakeholders current as to resolution status, exploring all factors that can lower mean time to resolution (MTTR) and maintain a high level of overall customer satisfaction.

Refer to QUALXXX_PROJ Defect Management Process_20091013_v1.0_1.1 for further detail.(the document wasn’t created yet) If you don’t refer to an external document, list in here the necessary defect management process which goes into needing to push code.

5) Approval Process

The approval should be done before the promotion.

5.1) Business Approvals

The business area that is participating in the project should approve the contents of the promotion.

5.2) Technical Approvals

The technical team that is participating in the project should approve the contents of the promotion.

6) Execution

6.1) Resources involved in effort

·  A list of the technical resources and contacts involved in the migration and test effort should be included in this section.

·  A list of application components that will be involved in the migration task

·  A list of data components that will be involved in the migration task

6.2) Timeframes

·  The timeframe for the migration, including detailed steps as identified in the Transport/Migration paragraph.

6.3) Notifications

·  The method for notifying the team and users of the planned migration, and the completion of the environment migration should be provided.

6.4) Reasons/Objectives

·  The main reasons and objectives to be recognized by migrating an environment should be identified. (functional upgrade, hardware upgrade, code upgrade)>

6.5) Environments involved

·  A list of the specific environments included in the migration should be identified..

7) Verification

7.1) Manual testing

·  By whom

7.2) Automated Testing

·  By whom

·  Scripts and tools used

7.3) Sign Off

·  Business Approvals

The business area that is participating in the project should sign off the contents of the promotion.

·  Technical Team Approvals

The technical team that is participating in the project should signoff the contents of the promotion.

8) Terms and Definitions

Terms and definitions related to the environments and promotion strategy for each project should be included in this section. There must be at least 2 environments included in every project, one for testing and one for production.

Examples could be:

Release

Major release

Minor release

Patch

9) Document Signoff

Phase: Design

The (Deliverable Name) document has been reviewed and found to be consistent with the specifications and/or documented project requirements. The signature below documents acceptance of this document and/or work product by the signing authority

Organization: University of Chicago______Contractor______
Approved by:
Signature: ______
Name: ______
Title:
Date:
Organization: University of Chicago______Contractor______
Approved by:
Signature: ______
Name: ______
Title:
Date:
Organization: University of Chicago______Contractor______
Approved by:
Signature: ______
Name: ______
Title:
Date:

File Name: QUAL040_PROJ System Promotion Strategy_20091204_v1.0_1.6.docx Page 2 of 2

Last Saved: 12/4/2009