wiki:DC3/SoftwareQualityAssurancePlan
Last modified 10 years ago Last modified on 01/23/2009 01:27:44 PM

from Baseline Software Management Plans

DRAFT last revised 23 January 2009

DC3 Software Quality Assurance Plan

1. Introduction



Caveat
Data Challenge 3 introduces the formal specification of Baseline Project Plans.
Not every requirement stated in LSST DM Software Development Process has been implemented.
Those procedures not possible or required for DC3 will be noted in the following text.



This Software Quality Assurance Plan realizes the policies and procedures defined in the LSST Software Quality Assurance Guidelines for the Data Challenge 3 (DC3) baseline.

Any section below containing the phrase "No change" indicates that section did not deviate from the LSST Software Development Plan guidelines.

1.1 Purpose of Document

In particular, the DC3 Software Quality Assurance Plan moves from generalities to the concrete specification of the SQA verification procedures.

1.2 Scope

DC3 software quality assurance will occur based on the DC3 objectives specified in the DC3 Software Release Project Plan.

1.3 Definitions, Acronyms, Abbreviations

No change.

1.4 Support Tools

No change.

2. Documentation

The exceptions to the LSST Software Development Plan guidelines include:

  • DC3 will not generate separate Acceptance Test, Systems Test, or Unit Test Plans;
  • The defined DC3 Baseline goals are derived from the LSST Science Requirements Document (SRD) and the Functional Requirements Specification (FRS). Subset SRD and FRS documents will not be generated.

3. Standards, Practices, Conventions and Metrics

3.1 Documentation Standards

No change.

3.2 Design Standards

No change.

3.3 Coding Standards

No change.

3.4 Commentary Standards

No change.

3.5 Testing Standards and Practices

Unit Tests and their successful completion will be required prior to Integration Testing.

Since DC3 is defined entirely within the Data Management domain (i.e. no external interfaces), the highest level Integration Tests will satisfy Systems and Acceptance Testing.

3.6 Selected SQA Metrics

No change.

3.7 Compliance Monitoring

No change.

4. Verification

4.1 Reviews

The exception to the LSST Software Development Plan does not require every anomaly report be solved prior to baseline release. Anomaly reports which are non-critical to DC3 successful completion, as decided by the DM SA, need not be closed prior to release.

4.2 Testing

4.2.1 Unit Test Verification

All DM code modules are required to have associated Unit Testers.

  • When a code development Ticket progresses into the inStandardsReview state, the SQA reviewer should ensure that the associated Unit Tester exists and has been executed.

The current DC3 build process can, optionally, include unit testing of all packages.

  • The Integration Test Manager should check the build log for the Release Products' compilation and loading to ensure that Unit Testing occurred and that no Unit Test failed.

4.2.2 Integration Test Verification

The complete suite of Integration Tests and the order in which to execute them are defined in the DC3 Integration Test Plan. The Integration Test Manager should ensure the Integration Tests were successfully built. The Integration Test Manager should record the Test Identifier, the Test date, and Test status (succeed/fail) when the Integration Tests are executed. The SQA Reviewer will review the validation table to verify the Integration Testing has occurred and the results were as expected.

4.3 Problem Reporting and Corrective Action

No change.

4.4 Code and Document Control

During DC3, a member of the SQA team will review code for general conformance to the LSST Coding and Documentation Standards at the completion of each code development Ticket in the inTicketWork Workflow state.

4.5 Management

Refer to the DC3 Software Release Project Plan for overall DC3 management roles and responsibilities.

4.6 Archival Control

No change.

4.7 Records collection, maintenance and retention

Unit, Systems, and Acceptance Testing results will not be collected as per the reason mentioned above in Section 3.5 "Testing Standards and Practices".

5. Training

No change.

6. Risk Management

No change.

7. References

None