EDW Release Management Process Guide-FINAL

7/29/2019 EDW Release Management Process Guide-FINAL

http://slidepdf.com/reader/full/edw-release-management-process-guide-final 1/26

BIDS Release Management Process Guide

BIDS EDW Release Management Process Guide

Version No. 7.2

Copyright © 2009-2013 Ford Motor Company(U.S. and international notice, and original material were added in each indicated year)

Originator: BIDS Software Configuration Management Working Group of 26 Date Issued: 01/08/2013

BIDS EDW Release Management Process Guide Revised: 2013-03-27

Record Type: Official Retention Period: C+3, T



BIDS Release Management Process GuideRecord of Revisions

The following table provides a record of revisions to the project/application SCM Plan:

Revision Number Description Revision Date

1.0 Original Created by: Brouillette, Alan (A.J.); Patel, Dave (D.);Hastie, Gordon (G.D.); Metla, Janardhanarao (J.); Duraku, Bajo(B.D.); Becker, Ron (R.); D'Amico, Mark (M.); Dannana, Venkat(V.)

9/5/2009

1.1 1. Modified Chapter 4.1 (Total Rewrite)

2. Modified Chapter 4.2 to include new inputs (Data QualitySLA)

3. Modified Chapter 4.3 to include new inputs (ExceptionEvidence)

4. Modified Chapter 4.6 to show that the BOV is updatedonce each project is launched

5. References to "Data Models" were changes to "tabledefinitions and table views" throughout the document

6. Updated Chapter 4.0 to include the Manage EDWReleases BIM

11/24/2009

1.2 Modified Appendix #7 to clarify the SCM AddendumRequirements -Patel, Dave (D.)

11/29/2009

2.0 Added EDW Release Management Meeting attendanceguidelines to the process -Patel, Dave (D.)

1/29/2010

2.1 Added a new required artefact to appendix #7 2/6/2010

3.0 Fixed hyperlinks and removed EDW SLA References 2/28/2010

4.0 Undated Appendix #7 to include justification for each artifact andinclude compensating controls that might be used in lieu of providing the artifact -Patel, Dave (D.)

3/5/2011

5.0 Updated Appendix #7 to reflect new required artifacts--D.Naranjo

10/17/2012

5.1 Enhanced Appendix #7 to better describe the required artifacts--D.Naranjo

10/18/2012

6.0 Major revision. Chapter 4 was re-written to reflect current stateof the release Management Process --D.Naranjo

12/20/2012

7.0 Major revision. Updated entire document to reflect current stateof the EDW Release Management Process. Deleted allappendices --D.Naranjo

1/07/2013

7.2 Updated all field codes, figures; revised Separation of Duties toreflect updated roles and responsibilities --D.Naranjo

1/08/2013







1 INTRODUCTION

The purpose of this document is to describe the BIDS EDW release management process. This documentwill serve to outline the processes and procedures associated with. Release management is a critical

process, in that it provides an effective and efficient path for all application changes to be made within acontrolled process.

1.1 Scope of this Document

The BIDS EDW application has many consuming applications (otherwise known as EDW Product

Lines). An EDW Product Line is an application that uses the EDW as a source system. Generally, the

EDW loads data into the EDW and the Product Lines consume EDW data. Note: Some EDW Prodcut

Lines will physically pull data out of the EDW while other EDW Product Lines have data pushed to

them from the EDW. The EDW application owns the code that loads the EDW and the code that

pushes data to the Product Line’s front end application. The EDW Product Line owns the code that

pulls the data out of the EDW. Figure 1.1 describes what code is included and excluded within the

EDW.

Bids Release Management Process Guide Figure 1.1






BIDS Release Management Process GuideThis document only covers the release management procedures associated with the management of

code that the EDW owns. Interaction, coordination and risk management need to exist between the

EDW and the EDW Product Lines. The Release Manager verifies the following:

• EDW Product Lines follow the processes outlined in this process guide

• EDW Product Lines follow Classic or Unified Systems Development Methodology Processes

(SDM or USDM) procedures,

• Product Lines obtain appropriate approvals prior promoting code

Notes:

• Some EDW Product Lines actually perform the work of loading data into the EDW as well as

creating the front end application or presentation layer. These EDW Product Lines are

required to manage their projects as follows:

• The work performed getting data into the EDW and pushing data out of the EDW is considered

EDW work. All EDW work performed must comply with the procedures presented in this

document.

• The EDW Product Line Single Point of Contact (SPOC) is required to interact and follow the

processes outlined in this document in order to migrate code

• The EDW Release Manager is an EDW Role that can only be fulfilled by an EDW employee.

This role can not be assigned to a person that is a member of the any of the EDW Product

Line team (see chapter 3 for detailed roles and responsibilities)

• The word code refers to any object that is incorporated into the EDW including, but, not limited

to the following:

• ETL code (data in and data out)

• Table definitions (DDL), table views

• User defined functions and stored procedures

• Unix scripts, cron and/or autosys jobs

• JCL, fastload, multiload, BTEQ, etc…







1.2 Who should use this

document?

The primary users of this document are as follows:

• EDW Release Manager as this is their guide to releasing changes into the EDW.

• All EDW Product Line SPOCS







2 BIDS EDW RELEASE MANAGEMENT PROCESS OVERVIEW

2.1 Scope for the BIDS EDW

Software Release Management Process Design

Release management is involved in the planning, design, build, configuration, and testing of hardware

and software to create a set of release components for a live (production) environment. Activities also

cover the planning, preparation and scheduling of a release to many customers.

From a software configuration management (SCM) perspective, five main components are included in

the overall release management process. These five main components are version control, build

management, deployment management, process metrics and workflow management as shown in the

figure below.

Figure 2:1: Five Components of Software Configuration Management

2.2 EDW Release Management

Process Description

The EDW Release Management Process takes a holistic view of change to an IT service and ensuresthat both technical and non-technical aspects are considered. It aims to work across platforms and

internal boundaries, and uses formal procedures and checks to protect the live environment.

Many service providers and suppliers may be involved in the release of hardware and software in a

distributed environment. Good resource planning and management are essential to package and

distribute a release successfully to the Business Customer.







2.3 EDW Release Definition

An EDW Release is a collection of authorized changes to the EDW. It is defined by the requests for

change (RfCs) that the EDW implements. An EDW Release will typically consist of a number of

problem fixes and enhancements to the service. A release consists of the new or changed software

required.

EDW releases are composed of EDW projects. EDW projects can be new development projects,

enhancement projects, system maintenance projects, Incidents and Emergency Changes. All EDW

projects contained in each individual EDW release are managed by the Product Line SPOC(s). Each

EDW Release can contain multiple projects from various EDW Product Lines

The EDW Release Manager makes sure that all required project deliverables are completed correctly

before allowing code to be migrated from one environment another. It is the responsibility of each

SPOC to create the deliverables and save evidence of Business Customer and IT authorizations. The

Release Manager simply verifies that the deliverables and authorizations are in place before code is

migrated.

2.4 Release ManagementObjectives

The objectives of release management are:

• To plan and oversee the successful rollout of EDW Code. Each unique collection of changes to

the EDW that are launched as a release at the same time will receive a unique EDW release

number

• To design and implement efficient procedures for the distribution and installation of changes to

the EDW

• To ensure software being changed is traceable and secure, and that only correct, authorized

and tested versions are installed

• To communicate and manage expectations, as far as project status, issues risks and

deliverable timing, of the customer during the planning and rollout of new releases.

• To agree to the exact content and rollout plan for the release, through liaison with change

management

• To implement new software releases into the operational environment using the controlling

processes of change management. Note: change management processes control the physical

release while release management processes controls the coordination, collection and

preparation of required project artifacts and approvals

2.5 Release Management and

Solution Design Methodology (SDM) Relationship

All EDW projects are required to follow either the classic or unified systems development methodology(SDM or USDM) as appropriate to assist with tasks relative to documentation, procedures, gate reviews,testing, and approvals, etc...). This includes emergency projects.







3 BIDS EDW RELEASE MANAGEMENT PROCESS

Release management process tasks include release planning, coordination validation, testing, andmigrating software. These tasks define the responsibilities of a specific process or development phase.

The responsibilities are then assigned to roles associated with the person(s) in the development and/or management process (roles are not titles or job descriptions). Roles are important to a successful processin that they define what individuals do as part of the overall team. Roles are assigned to one or moreindividuals and in many cases one person performs several roles. i.e. This is not a one to one relationship.Several people could be assigned the same role, or one person could be assigned to different roles.

This includes development roles, testing roles and specialist roles. However, resource constraints andproject size determines how roles are assigned to individuals. The assignment of people to roles isdocumented in the SCM plan addendum for each individual project.

3.1 BIDS EDW Release

Management Process Roles and Responsibilities

All roles defined here are EDW project team roles. All roles can be performed by either an EDW teammember or a EDW Product Line team member except for the Release Manager role.

Note: EDW Product Line application resources can be used to fill any of the roles listed here except for theRelease Manager role. If an EDW Product Line resource is used fill any of these roles, the work thatresource produces is governed by the EDW SCM processes.

3.1.1 System Design Analyst (SDA)

Guides and oversees development of application software components. Validates readiness for migrationof ETL programs to next environment by participating (and approving) in a technical inspection of each ETLprogram and it's associated program specification; responsible for ensuring all changes are included for the

application to function in a test or production environment.

3.1.2 Developer

Performs the following tasks under the supervision of the System Design Analyst (SDA)

• Participates in design activity

• Constructs, tests and documents ETL programs

• Participates in tech reviews for other developers

• Checks code into SCM tool and applies bundle name label

3.1.3 EDW Product Line’s Single Point of Contact (SPOC)

Identifies the development project goals, objectives and provides the planning and scheduling for development and QC activities.






BIDS Release Management Process Guide3.1.4 Environment Team

Creates and maintains all packaging and build scripts necessary to build an application for use. Thisincludes the following:

• Extracts code from SCM tool based on labelling

• Deploys code or prepares deployment request for the Component Administrator

• Adds production and development bundle labels in SCM tool

• Promotes code based on SCM processes

• Maintains the configuration definition (using bundle names) for controlled environments

3.1.5 EDW Component Administrator (DBA, ETL Administrator,

etc…)

Deploys code and data to the component they administer

3.1.6 Quality Control (QC) Test SpecialistCollect and verify unit test results, and provides and executes test scripts for integration and functionaltesting.

3.1.7 Business Customer

Owner of application that must approve changes to production, verifies production changes, createschange requests and is responsible for testing changes that they originated. Also participates in the CCCB.

3.1.8 EDW S3 Support Manager

Owner of all EDW incidents. Manages the bug fix, enhancement and testing activities

3.1.9 Data Architect

Translate business information requirements into a flexible, scalable, efficient design which captures therequirements of the processes, ensures integrity, integrates into the overall enterprise architecture, andclearly reflects the blueprint of corporate data usage, business rules and relationships.

3.1.10 Release Manager

Coordinates, oversees and approves QA and Production migration request. The Release Manager is alsoresponsible for working with the Product Line SPOC(s) to ensure the development process is understoodand followed. The Release Manager will mentor SPOC(s) throughout the process.

3.1.11 Enterprise Architecture (EA)The EA is responsible for the Information Architecture Strategy, Tools, and Models (EDM and EPM) andensures alignment to them by consulting with various projects worldwide.







3.2 Separation of Duties

This section documents how the project team will achieve the separation of duties as required in theadministrative controls section of the Information Technology Policy Manual (ITPM).

Note: The method of reading this chart is to take a role in the left column and going across that row ask whether that role can also playan additional role in the life cycle of a change request. For example, a Developer (DEV) may also be the Lead Developer (LD) for that

particular change request. However, a Developer cannot also be the Release Manager (RM).

Role Played During Process Dev SPOC PM ET CA DA RM QC Bus EA

Developer (Dev) No No No No No No No No

System Design Analyst (SDA) No No No No No No No No

PL Single Point of Contact (SPOC) No No No No No No No

Environment Team (ET) No No No No No No

Component Administrator (CA) No No No No No No No No

Data Architect (DA) No No No No No No No No No

Release Manager (RM)No No No No No No

QC Test Specialist (QC) No No No No No No No No No

Business Customer (CB) No No No No No No No No No

EA - Enterprise Architecture No No No No No No No No No







BIDS EDW RELEASE MANAGEMENT PROCESS

The following diagram decomposes the EDW Release Management swimlane document located in Appendix C of the EDW Service Level Agreement (EDWSLA). The swimlane diagrams depicted in Appendix C illustrates the high level sub-processes performed in the enterprise software release managementprocess and the sequence in which they are executed.

2) Coordinate

and ValidateRelease

3) Package Code

and Migrate

Release to QA

4) Coordinateand QA Test

Release

Approval to

Proceed?

5) Migrate toProduction

6) Close Release

Yes

2) Coordinate

and ValidateRelease

3) Package Code

and Migrate

Release to QA


Release

Approval to

Proceed?


6) Close Release

Yes

2) Coordinate

and ValidateRelease

3) Package Code

and Migrate

Release to QA


Release

Approval to

Proceed?


6) Close Release

Yes

1) Manage and Plan all EDW Releases

EDW Release 2 EDW Release 3EDW Release 1

No No No

Originator: BIDS Software Conf iguration Management Working Group of 26 Date Issued: 01/08/2013



https://www.tc2.ford.com/ts/ADSsdBIDS/RelMgt/Shared%20Documents/EDW%20Workspace/67_Service_Level_Agreement_EDW.doc








BIDS Release Management Process GuideFigure 4.0.1 contains the Manage EDW Release Business Integration Model:

Originator: BIDS Software Conf iguration Management Working Group of 26 Date Issued: 01/08/2013






3.3 Manage and Plan all EDW

Releases

Process Goal:

Release planning involves the review of all EDW projects; New Development, Enhancements,System Maintenance, Incidents and Emergency Change. Through this process, the planning andexecution of each individual EDW release occurs. This process determines which projects areincluded in each individual EDW release.

Definitions:

• EDW Product Line: A funding source for a collection of related EDW projects. Each EDWconsuming application is considered an EDW Product Line.

• EDW Project: A temporary process, which has a clearly defined start and end time, a set of tasks, and a budget, that is developed to solve a well defined goal or objective. The projectterminates once the project scope is achieved and project approval is given by theBusiness Customer.

Notes:• The work associated with either putting data into or pushing data out of the EDW is

considered to be part of an EDW project. Therefore, any work associated with creating thefront end or presentation layer associated with an EDW project is out of scope and ismanaged outside the processes defined in this document.

• The EDW itself is considered an EDW consuming application. Therefore, some projectswill be funded by the EDW. For example: Some system maintenance projects and/or corporate mandated changes (legal and regulatory changes) will be funded by the EDWand will be managed as EDW Projects.

Actors:

• Release Manager

•Product Line SPOC(s)

Process Inputs (Actor responsible):

• EDW Change Control Register Report (Release Manager)

• Project status for all active EDW Projects (Product Line SPOC)

Process Outputs:

• Updated EDW Change Control Register entriesProcess/Artifacts:

This process is managed by the Release Manager in a biweekly release management meeting withall the actors (listed above). These meetings review the following items:

• Active Project Status

• Release Management process changes

Notes:

• All EDW projects are required to follow either the classic or unified systems developmentmethodology (SDM). This includes emergency projects and releases.

• All projects are required to use follow the processes outlined in the BIDS Change ControlProcess Guide to request work and store project artifacts and approvals.




http://root/convert/apache-tomcat-6.0.20/EDW%20Change%20Control%20Process/BIDS%20EDW%20Change%20Control%20Process%20Guide.doc








3.4 Coordinate and Validate

Release

Process Goal:

To verify/validate that all projects in the current EDW release have all required releasemanagement artifacts in place.

Actors:

• Release Manager

• Project ManagersProcess Inputs:

• Business requirements (with sign-off)Process Outputs:

• Approval (Release Manager)

• Code (documented, unit tested, reviewed and identified in the sourcecontrol library)

Process/Artifacts:

This process is managed by the Release Manager. The Release Manager holds one or moremeetings that occur before projects are allowed to migrated to the QA environment. The ReleaseManager verifies the projects business requirements are signed-off and placed the that projectsevidence folder. Please refer to the list of EDW Required Artifacts each individual EDW projectmust have.




https://www.tc2.ford.com/ts/ADSsdBIDS/RelMgt/EDW%20Required%20Artifacts/Home.aspx






3.5 Migrate to QA

Process Goal:

Standardize the way code and test data are packaged and migrated to the QA environment.Validate the migration once QA is populated

Actors:

• Release Manager

• Project Manager

• Environment Team

• EDW Component Administrator

Process Inputs:

• Code (Development: documented, unit tested, reviewed and identified in the source controllibrary)

Process Outputs:

• Code (QA)

Process s/Artifacts:

The package code and migrate to QA process is described flowchart 4.3.







B1) Identify Code

associated to theRelease in Source

Control Library

A2) ApproveRequest

R e l e a

s e

M a n a g e r

E D W

C o m p o n e n t

A d m i n i s t r a t o r

B2) RequestMigration

B3) ApproveMigration Request

P r o j e c t

M a n g e r

E n v i r o n m e n t

T e a m

B5) Assign Technology Administrator to physically migrate

Change Package

A3) Load QA DataB6) Migrate

Change Package

to QA

A4) NotifyRequestor that

Load Complete

B7) Notify Approver

when MigrationComplete

Yes

B8) Was Change Package

Migrated Correctly?

No

B4) Verify that

Request and SourceControl Library

match

Yes

No

Migrate Code, and Data to QA

A1) Request Prodto QA Data

Migration

A5) Was Change

Package Migrated

Correctly?

No

Stop

Yes

The above diagram depicts two separate processes:

• Loading data to QA

• Migration of code to QA







3.5.1 Load Data to QA:

A1. The Project Manager requests Data Migration from Production to QA A2. The Release Manager Approves or rejects the request, If approved assigns the request to

the Component Administrator A3. The Component Administrator actions the request A4. The Component Administrator notifies the Project Manager that the QA data refresh is

complete A5. The Project Manager verifies that the QA data refresh is correct

3.5.2 Migration of Code to QA:

B1. The Project Manager identifies the code to be migrated to QA that is associated with thecurrent EDW Release in the source control library.

B2. The Project Manger requests QA code

B3. The Release Manager approves or rejects the request.

B4. The Environment Team receives the request and compares the migration code list to thecode identified in the source control library. If the migration code list and the codeidentified in the source control then Environment Team assigns the request to the

appropriate Component Administrator for physical migration to QA. Otherwise the requestis rejected and the process will start over at step B1.

B5. Environment Team assigns the request to the appropriate Component Administrator for physical migration to QA

B6. Component Administrator migrates code to QA

B7. Component Administrator notifies the requestor (Developer or Lead Developer) themigration is complete

B8. The Project Manger verifies that all code modules were migrated to QA correctly. If problems exist (i.e. something was not migrated correctly) the process will start over atstep #B1







3.6 Coordinate and QA Test

Release

Process Goal:

Test all code and table definitions (DDL), table views associated with the release within the QAenvironment

Actors:

• Release Manager

• Project Manager

• ETL CoE

• EDW S3 Manager

• EDW Architect

• Business Customers

Process Inputs:

•ETL Coe Approval

• EDW S3 Approval

• EDW Architecture Approval

• Business Customer Approved Test Cases and Results

• Code (QA)

Process Outputs:

• Business Customer Approval of Test Cases and Results

• Business Customer Approval to launch

• ETL CoE Approval to Launch

• EDW S3 Approval to Launch

• EDW Architecture Approval to Launch

Process/Artifacts:

Each Project Manager will be required to execute their project test plans which include user acceptance tests. See Appendix A of this document for details on the process outputs describedabove







3.7 Migrate to Production

Process Goal:

Standardize the way code, table definitions, and table views are packaged and migrated from the QA

Environment to the Production Environment

Actors:

• Release Manager

• Project Manager

• Environment Team

• Lead Developer

• Developer

• Component Administrator

Process Inputs:

• Code (documented, unit tested, UAT tested, reviewed and identified in the source controllibrary)

• Approval (Business Customer: for each project)

Process Outputs:

• Code rolled to production

Process s/Artifacts:

The Package Code and Migrate to Production Process is described in flowchart, figure 4.5.







1) Identify Code

associated to the

Release in

Source Control

Library

Stop

R e l e a s e

M a n a g e r

E D W

C o m p o n e n t

A d m i n i s t r a t o r

2) RequestMigration

4) Approve

Migration

Request

P r o j e c t

T e a m

E n v i r o n m e n t

T e a m

5) Assign Technology

Administrator to physically

migrate Change Package

6) Migrate

ChangePackage to

Production

7) Notify

Approver whenMigration

Complete

8) Was ChangePackage Migrated

Correctly? Yes

No

3) Verify that

Request and SourceControl Library

match

YesNo

Migrate Code to Production

B u s i n e

s s

C u s t o m

e r

9) Notify

Release

Manager of production

Migration

10) Notify

Business

Customer o

production

Migration

11) Business Post

Launch Testing

Successful?

Yes

No

1. The Project Manager requests production migration (via the EDW change control register). Note: 1)Included in the request is a migration code list (A list of code modules that require migration). 2)This procedure is documented in the EDW change control process guide

2. The Environment Team receives the request and compares the migration code list to the codeidentified in the source control library. If the migration code list and the code identified in thesource control library and then Environment Team assigns the request to the appropriate EDW

Component Administrator for physical migration to production. Otherwise the request is rejectedand the process will start over at step #1.

3. The Release Manager approves or rejects the request

4. Environment Team assigns the request to the appropriate Component Administrator for physicalmigration to production

5. Component Administrator migrates code to production






BIDS Release Management Process Guide6. Component Administrator notifies the requestor (Developer or Lead Developer) the migration is

complete

7. The Project Manager, Lead Developer and/or Developer verify that all code modules were migratedto production correctly. if problems exist (ie something was not migrated correctly) the process willstart over at step #1

8. The Project Manager notifies the Release Manager that the code migrated to production

9. The Release Manager notifies the Business Customer that the code migrated to production

10. The Business Customer performs post launch production testing. If successful, the process stopsotherwise it starts over at the beginning of the process.







3.8 Close Release

Process Goal:

Standardize the way each Release is closed

Actors:• Release Manager

• Project Manager

• Business Customer

• EDW S3

Process Inputs:

• Release Plan

• BOV

• Launch Notification

Process Outputs:

• EDW Change Control Register Issue (Closed)

• Updated BOV Reconciliation Spreadsheet

Process/Artifacts:

This process is initiated once the Business Customer provides post launch business approval for the projects they own. This process is managed by the Release Manager. Each release needs tobe properly closed by performing the following tasks:

1. The Project Manager for each project contained within the Release will obtain post launchbusiness approval.

2. Release Manager will verify each unique project within the release receives post launch

business approval3. The Project Manager will close the related issue within the BIDS Change Control Register 4. The Release Manager will update the EDW BOV Appendix A and remove the "Date

needed" for each entity that was launched into production for each project.







4 GLOSSARY

Term Definition

Active project: A project that has successfully completed the BOV reconciliation process and is

assigned to an EDW Release and is being developed

Build The process by which an application is compiled, linked and made ready for execution.This will include makes, linking or just packaging files for delivery.

Customer Change Control Board(CCCB)

A group of people who can give expert advice to Change Management on theimplementation of changes. This Board is likely to be made up of representatives fromall areas within IT and representatives from business units.

Change The addition, modification or removal of approved, supported or baseline hardware,network, software, application, environment, system, desktop build or associateddocumentation.

Change Management Process of controll ing changes to the infrastructure or any aspect of services, in acontrolled manner, enabling approved changes with minimum disruption.

Change Request (CR) A change request (CR) record is created from the Request for Change record type.The CR typically denotes changes which are to be made by an application group.

Code Refers to any object that is incorporated into the EDW including,but, not limited to the following:

ETL Code (Data In and Data Out)

Table Definitions (DDL), Table Views

User Defined Functions and Stored Procedures

Unix Scripts, CRON and/or Autosys Jobs

JCL, Fastload, Multiload, BTEQ, etc…

Configuration Item (CI) A configuration item (CI) is a component of or directly related to the IT-infrastructure.CI’s are: hardware, software, documentation, processes and procedures. includes:

Technical Refreshes, Hardware and Infrastructure Upgrades, Corporate MandatedChanges (legal and regulatory changes) and Production Support Incidents

Configuration Management The process of identifying and defining Configuration Items in a system, recording andreporting the status of Configuration Items and Requests for Change, and verifying thecompleteness and correctness of Configuration Items.

Developer A person responsible for creating, modifying and unit testing CIs, and identifying theresulting components.

Development Life Cycle The entire process for how software is created beginning with a request and endingwith a completed application in the production environment.

Emergency Change Al l emergency change requests must either be associated with an existing Incident, or be necessary to continue the business. Emergency changes must be entered beforethe implementation can begin, but will be Filtered in an expedited manner in order toallow the RFC’s development and implementation to take place as soon as possible.

An Emergency Change is subject to the same approvals as a Normal change exceptthat this will occur after the change has been implemented.

Emergency Release Emergency software and hardware changes, normally containing the corrections to asmall number of known problems.

Goals The term used to denote the objectives of a defined process.

Incident Any event that is not part of the standard operation of a service and which causes, or may cause, an interruption to or a reduction in the quality of that service.

Incident Management The process of managing the l ife cycle of an incident and restoring service as quickly






BIDS Release Management Process Guideas possible with minimum disruption to the business.

Inputs The information that is required by any activity or task in a process to execute the stepsof a process.

Master Test Plan A list of each all the test plans for all projects being implemented in the release. TheMaster Test Plan will also contain a QA Data Refresh Plan for the release.

Pending project: A project that has not completed the BOV reconciliation process and has not beenassigned to an EDW release

Problem A problem is the unknown underlying cause of one or more incidents. It will become aKnown Error when the root cause is known and a temporary workaround or permanentalternative has been identified.

Procedure An established series of steps to accomplish a specified task(s).

Process A defined relationship among the systems management activities and/or tasks requiredaccomplishing an enterprise functional objective. A process is a series of definable,repeatable and measurable activities and tasks.

Project Project: A temporary process, which has a clearly defined start and end time, a set of tasks, and a budget, that is developed to solve a well defined goal or objective. Theproject terminates once the project scope is achieved and project approval is given bythe Business Customer

Release One or more applications or projects bundled together for concurrent availability to theend user. A specific collection of software components that once associated will create

a distinct and unique application.

Release Management The process of managing a Release, a collection of new and/or changed Cis which aretested and introduced into the live environment together, and to ensure all technicaland non-technical aspects of a release are dealt with in a coordinated manner.

Request for Change (RFC) A Request for Change (RFC) is a request initiated either by a customer, IncidentManagement or by Problem Management aimed to change the status of one or moreconfiguration items (CI’s).

Revision An instance of a single file or archive (see archive).

Role A set of responsibilities, activities and authorizations.

SCM Plan Describes how the integrity of the software work products (Configuration Items) will bemaintained for a project. This will include identification of project resources,descriptions of development environment, list of baselines, list of project developmenttools, and identification of development, test and production environments.

SDM Solution Development Methodology

Service Level Management The process of defining, agreeing, documenting, and managing the levels of Customer IT service, that are required and cost justified.

Solution Delivery Methodology (SDM) Ford’s integrated framework of well-connected processes, tools, metrics, andmanagement disciplines that deliver high quality solutions. Gates are defined for eachof the 6 SDM stages to ensure the project is ready to move the next stage or lists thoseitems that must be accomplished before the project can move to the next stage.

Software Configuration Management(SCM)

The art of identifying, organizing and controlling modifications to the software beingbuilt by an application team.

SCM Plan Describes how the integrity of the software work products (Configuration Items) will bemaintained for a project. This will include identification of project resources, escriptionsof development environment, list of baselines, list of project development tools, andidentification of development, test and production environments.

Source Code A uniquely named program, DLL, bind file, command file, make file, data file, text or document file, BEFORE it is stored as an archive.

Source Control Library Library management software used to produce audit trails of program changes and tomaintain program version numbers, creation-date information and copies of previousversions. Organizes, manages, and protects software assets in the EDW.






BIDS Release Management Process GuideSub-process Sub-processes are performed within a process. One or more people within the

process may be doing different parts of the sub-process. Sub-processes are made upof activities.

Tasks Tasks are individual elements and/or subsets of an activity. Normally, tasks relate tohow a specific activity is performed.

UAT User Acceptance Testing

Uncontrolled Environment No or minimal risk, highly productive environment for software development. Some

separation of duties exist under application code control workflow and polices, but notfor deployment or propagation to the environment for build.

User Ford employee or vendor who uses the managed elements as defined in the scope

Version An instance of a system or subsystem at a certain point in time (see baseline). Oftenin software, a version is also called a release or a baseline.


EDW Release Management Process Guide-FINAL

Documents

Transcript of EDW Release Management Process Guide-FINAL