NSI Development Process 1.0
Conformance Statement

1. Submitter Information

Enter the name of the author of this Conformance Statement

Organization: Scientific Games International

Author: Abi Salimi

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: 1500 Bluegrass Lakes Pkwy, Alpharetta, GA 30004

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: Rich Newman

Title: Director, Systems Development

Quality Manager:

Name: Rich Newman

Title: Director, Systems Development

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.

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.

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:

Other methods used by SG are: (1) Integration testing, (2) Extensive reviews of requirements to make sure the requirements are correct and that the customer understands what to expect, and (3) Two separate testing cycles after development (i.e., QC and then OPS) before the software is turned over to the Lottery for UAT.

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:

Because of the variety of programming languages we use in the SG applications, some of the codes follow coding standards.

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:

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

An RFA (Request for Action) is created for each identified defect. The RFA gets analyzed by developers and other appropriate individuals to determine the cause. The defects would then be addressed appropriately.

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:

Yes, if requested to do so by a lottery. In that case, we hold meetings with the lottery to review open issues and turn over tested product (by going through each issue that remains, if any.) We also provide access to a view of the problem reporting tool to the lotteries which ask for it.

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.