qa_dp_releaseprocess

8/7/2019 qa_dp_releaseprocess

1/15

Release Process Draft Template

Best Practice for Quality Assurance of Product Development inthe Lottery Industry: Development Process

Version 1.0, October 2007


2/15

Copyright 2007, The Open Group

All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or byany means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of thecopyright owner.

The Open Group is a registered trademark of The Open Group in the United States and other countries.

Release Process Draft Template

Best Practice for Quality Assurance of Product Development in the Lottery Industry:Development Process

Version 1.0, October 2007

Published by The Open Group, October 2007.

Comments relating to the material contained in this document may be submitted to:

[email protected]

ii Release Process Draft Template (2007)
mailto:[email protected]:[email protected]


3/15


4/15


5/15

1 Introduction

This template contains all the best practice requirements contained in the Best Practice forQuality Assurance of Product Development in the Lottery Industry: Development Process:Release Process.

1.1 General Requirements

It is the intent of this Release Process document to serve as a dynamic guide and ongoingreference for all project stakeholders involved in the execution of this review and to be used inaddition to the lottery and vendor Project Management Plan.

This project will be implemented and maintained in compliance with the NSI Best Practice for

Quality Assurance of Product Development in the Lottery Industry: Development Process (Doc.No. BP0402).

1.2 Change History

This section records changes to the Release Process document the version number, the date of update/change, the author responsible, and a brief description of the context of the revision to theRelease Process document.

Version Date Auth Desc angesor(s) ription of Ch

1.3 Project Information

t associated with this Release Process document.This section lists details for the projec

Project Name:

Project Description:

Project Start Date:

Quality Assurance of Project Development in the Lottery Industry: Development Process 1


6/15

2 Documented Release Plan

2.1 Vendor Creates the Plan

The Release Process is the process by which the internally accepted system and its associateddocumentation deliverables are prepared for delivery to the lottery for its acceptance. Oncedelivered, the new or updated product will need to be installed and integrated into an existinglottery environment.

The Release Process covers both the preparatory steps performed on the vendor side, and thedocumentation necessary to facilitate the installation and integration performed on the lotteryside. The Release Process addresses installation plans, start-up strategies and plans, and

conversion requirements. The Release Process could also include training of operations staff, thelottery, and retailers.

Representatives from the vendor must create the plans for the release of the system or systemcomponents. The plans must be documented.

Vendor Representatives

Name Role Signature

2.2 Requirements for the Plan

This section should include the documentation created by the vendor, as listed in the followingsections.

2.2.1 Means of Delivery

This section should include the means of delivery.

2.2.2 Delivery Medium

This section should include the delivery medium.

2.2.3 Lotterys Acceptance Process

This section should include the lotterys acceptance process and acceptance test period.

2 Release Process Draft Template (2007)


7/15

2.2.4 Knowledge Transfer

This section should include a plan for knowledge transfer from the vender to the lotteryregarding the use and operation of the system.

2.2.5 Problem Reporting

This section should include a problem reporting mechanism to be used after the delivery of thesystem. There should be a documented process of how to handle problem reporting duringacceptance testing and through to post-installation/integration.

2.2.6 Release Notes

The vendor should address release notes by including the following at a minimum.

2.2.6.1 Formal Build Description

This section should include a formal build description for the software portion of the release,which must include:

The system version

The version of all component modules

The version of all deliverable documents

System Description Version

Component Description Version

Deliverable Document Description Version

2.2.6.2 Known Problems

clude a list of any known problems in the release and the plans for

Resolution Plans Status

This section should inresolving them.

Problem Description



8/15

Problem Description Resolution Plans Status

2.2.6.3 Limitations in the Scope

This section should include any limitations in the scope of the system, or any requirements thatifications but were deferred or eliminated and will not be implementedwere included in the specas a part of this release.

Limitation Description Reason Status

2.2.6.4 Additional Functionality

This section should include a definition of any additional functionality that is being delivered butwas not defined in the Requirements Specification (i.e., enhancements); this must include a

nality is documented.reference to where the functio

Functionality Description Reason Reference

2.2.6.5 rables

This section should include a list of all deliverables, which must include:

A description of and identifying serial and part numbers for all hardware comp ents

ponents and associated software modules

2.2.6.6 T t R

T v a test report that summarizes the test results of internal testing.

Intern Test Results Status

List of Delive

on

Software com Documents

Tools

es eport

he endor should create

al Test

2.2.6.7 Usability traints

This section should include any known usability constraints (for example, performancelimitations).

Cons



9/15

2.2.6.8 Portability Constraints

This section should include any known portability constraints.

2.2.6.9 Interoperability Constraints

any known interoperability constraints.This section should include



10/15

3 Integration Plan

The lottery and vendor must work together to produce an Integration Plan. The Integration Planshould be created during the Requirements Definition.

The Integration Plan must be performed in accordance with the agreed plan. It may be refinedduring Acceptance Testing.

The Integration Plan must be approved by both the vendor and the lottery.

See Appendix A for the creation signature page.

See Appendix B for the approval signature page.

3.1 Plan Contents

This section should include the information described below.

3.1.1 Business Functions

Both the lottery and vendor must work together to produce the information.

3.1.1.1 Processes Impacted

This section includes a review of the business processes impacted by the changes.

Business Processes Description of Impact

3.1.1.2 Changes are Known

This section includes ensuring that people responsible for the affected business functions knowof the changes.

Name Function Date Informed

3.1.1.3 People are Notified in Advance

This section includes ensuring that the people responsible for the affected business functions arenotified in advance of what business process changes need to be made (if any).



11/15

Name Concur that Notification was in Advance

3.1.1.4 Non-Software Issues

This section ensures that non-software issues are resolved in time to support the installation of the new software or hardware.

Resolution StatusNon-Software Issue

3.1.2 ut the Comple nment

Both the lottery and vendor must work together to produce this information.

The Integration Plan must include information that covers the complete environment into which

3.1.3

ation.

ystem,cribed below.

3.1.3.1

3.1.3.2 Data Conversion

Information abo te Enviro

the product will be integrated and deployed.

This section must include a complete description of the environment.

Impact of the Product Release

Both the lottery and vendor must work together to produce this inform

This section must identify the impact of the product release on the overall lottery sincluding but not limited to the areas des

Security Changes This section must include any security changes that are required. The security changes must beidentified in the Integration Plan together with assigned actions for the responsible parties fromeither the vendor or the lottery.

This section must include any data conversion that is necessary. The vendor must provide detailsand assigned actions for execution of the data conversion.

3.1.3.3 Platform Variations

This section must include the identification of platform variations that may occur at differentlottery or retail sites and document assigned actions to address them.

3.1.3.4 Deployment Variations

This section must include the identification of deployment variations that may occur at differentlottery or retail sites and document assigned actions to address them.



12/15


13/15

A Integration Plan Creation Signature Page

Signatures indicate that the Integration Plan associated with the project below has been createdby both the lottery and the vendor.

Project Name:


Project Start Date:

Lottery Authorization

Role Signature DateApproved by

Vendor Authorization

Approved by Role Signature Date



14/15

B Integration Plan Approval Signature Page

Signatures indicate that the Integration Plan associated with the project below has been approvedby both the lottery and the vendor.

Project Name:


Project Start Date:

Lottery Authorization

Role Signature DateApproved by

Vendor Authorization

Approved by Role Signature Date



15/15

C Terms, Definitions, Acronyms

This appendix defines the terms and acronyms used in the Release Process document.
