NSI Development Process 1.0
Conformance Statement


Note to submitter: This form contains a series of questions that need to be answered. Please complete ALL the fields in the questionnaire below to produce a conformance statement for your Development Process. Your completed form should be submitted to the Certification and Verification Authority when you register for certification or verification. Please ensure that you use the current version of the questionnaire (available on the certification/verification web site) for your submission. See the Guide to the NSI Certification and Verification Program and Guide Supplements for more information. Please note that all information in this conformance statement will appear on the public Register of certified/verified practices, except for the names of the individual Business Practice Managers. Revision History showing the changes in this Conformance Statement from prior versions is contained at the end of this document.

1. Submitter Information

Enter the name of the author of this Conformance Statement

Organization: GTECH Corporation

Author: Kenneth Perry


2. Business Practice Information

Business Practice Location

This is the Business Practice Location in which product development is carried out under the leadership of the Business Practice Management, and in which the documented processes and procedures for the development process are accessible. The Business Practice Location is where the on-site assessments are performed.

Business Practice Location: GTECH Global Technology Solutions - Service Delivery, West Greenwich, Rhode Island, USA

Business Practice Management

These are the lead technical and quality persons within your organization who have overall responsibility for managing the technical and quality aspects of the product development process on a day-to-day basis and ensuring that it is carried out in accordance with the documented processes and procedures. The specified Technical and Quality Managers may be the same person.

Technical Manager:

Name: Dave Caron

Title: Technology Director, Americas Technology Solutions Group

Quality Manager:

Name: Kenneth Perry

Title: Technology Director, Technology Process Group


3. Best Practice Implementation

Your Organization is required to implement all of the "Should" requirements in which the Practitioner is identified as "Vendor" in Appendix A of the Development Process Best Practice, or provide rationale for why the recommendation is not implemented. If there are any "Should" requirements that your Business Practice does not support at all or does not support as a normal course of business for each product you produce, please select each such requirement and supply your rationale for why your organization believes the requirement is not applicable or required.

Requirement 21: The release notes should include at a minimum: - 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 ...
Rationale
The candidate batches are software only deliveries so there is no evidence of the delivery of hardware components.
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale
Requirement
Rationale

Your Organization is also required to implement all of the "Should" requirements in which the Practitioner is identified as "Vendor" in Appendix A of the Acceptance Testing Best Practice, or provide rationale for why the recommendation is not implemented. If there are any "Should" requirements that your Business Practice does not support at all or does not support as a normal course of business for each product you produce, please select each such requirement and supply your rationale for why your organization believes the requirement is not applicable or required.

Requirement
Rationale

4. Characterization of the Vendor's Development Process

This section identifies the optional requirements associated with the Development Process. Your Organization is not required to provide support for these optional requirements, but you are required to indicate which ones you support and in what capacity. Please answer each question below and provide supporting text, as appropriate.

Implementation

Question 1: Which software development practices does your organization employ?

Response:

Please select all that apply.

Utilize documented coding standards for all software coding

Perform code walkthroughs, inspections, or reviews

Utilize formal methods to establish correctness of the implementation of each requirement

Utilize other specified methods to ensure the correctness of the implementation

If "utilize other specified methods" is selected, please identify those other methods:

GTECH has been appraised and found to be compliant with CMMI level 4 and as such utilizes the CMMI Validation and Verification process areas to ensure the correctness of implementation

If any of the selected practices are only used on some lottery product development projects, please indicate the situations in which they would be used:

GTECH maintains a defined organizational Standard Project Process (SPP) that is compliant with CMMI level 4. It is mandatory for all projects to use the SPP. A procedure exists that allows projects to tailor the SPP to the specific needs of the customer delivery but any such tailoring requires the review and approval of GTECH's Technology Process Group (TPG) to ensure that key processes are not being removed

Rationale:

An organization should implement one or more of the software development practices identified above.

Reference:

Quality Assurance of Product Development in the Lottery Industry: Development Process, April 2004 - Section 4.3.2.1, Best Practice Requirements for Implementation.

Internal Testing

Question 2: Does your defined testing process utilize root cause analysis?

Response:

Yes, always

Yes, sometimes

No

If you selected "Yes, sometimes", please explain the situations in which your organization might utilize root cause analysis:

Root cause analysis takes place dependent upon severity and impact. High severity defects that have the potential to impact multiple system components or whose origination is believed to be within the core product are analyzed to identify a root cause. A Global Request for Software Service (RFSS) procedure exists and is managed by a central corporate team to address defects that have the potential to affect multiple customer systems.

If you selected "Yes, always" or "Yes, sometimes", please explain which root cause analysis techniques your organization utilizes (e.g., Ishikawa diagrams):

Rationale:

Utilizing root cause analysis as part of the internal testing process is optional.

Reference:

Quality Assurance of Product Development in the Lottery Industry: Development Process, April 2004 - Section 4.3.3.1, Best Practice Requirements for Internal Testing.

Problem Reporting Process

Question 3: Does your organization invite the lottery's quality assurance team to participate in the team that performs the reviews of problem reports?

Response:

Yes, always

Yes, sometimes

Yes, if requested to do so by a lottery

No

If you selected "Yes, sometimes", please explain the situations in which your organization would invite the lottery's quality assurance team to participate in the review group:

Rationale:

Problem report reviews should be performed by a team of representatives from each key party. Inclusion of the lottery's quality assurance team in this review group is optional.

Reference:

Quality Assurance of Product Development in the Lottery Industry: Development Process, April 2004 - Section 4.3.7.1, Best Practice Requirements for Problem Reporting.


Copyright © 2004-2008 The Open Group, All Rights Reserved
Issue 1.0.3 - May 2008