Software Quality Assurance Plan

Design and Coding Standards: A set of design and coding standards need to be established. Each team member must follow these standards.

Structured Life Cycle: A Structured Life Cycle needs to be chosen and documented according to the project at hand.

Reviews: The following reviews must take place throughout the Software Life Cycle.

• Requirements Reviews
• Design Reviews
• Peer Coding Reviews
• Test Reviews

Audits: Through normal reviews, an anomaly may be spotted. In this event, an audit team is established and presented with a task and desired finding, and given resources to complete its assignment.

Review and Audit Guidelines

Reviews

• qualified and available team members
• resources to enable the team members to perform
• predefined agenda (agenda must be established)
• a clear picture of the goals of the review

Audit

• qualified and available team members
• resources to enable the team members to perform
• a clear picture of the goals of the audit
• a commitment from the developers that they will not obstruct the audit teams' search
• a clout to enable the use of the finding of the audit

Documentation Standards: Documentation standards must be established and documented here.

Testing Standards: Testing standards must be established and documented here.

Verification and Validation: Verification and Validation criteria must be established and documented here.

Tools, Techniques and Methodologies: Any tools, techniques and methodologies must be stated here.

Documentation Reference: Any reference to other documentation must be stated here.

Adapted from material at Real-World Lab, Georgia Tech.

A SQA plan will be prepared for each project according to the following guidelines.

The SQA plan is developed in the early part of the project. In most cases this will be in the beginning of a quarter. It is recommended that the plan be developed in the beginning of a quarter so that it can be followed for the duration of a developer's (student's) time spent on the project. The SQA plan is to be developed along with the overall project plan. A copy of the project plan will be given and stored by the SCM group.

The SQA plan developed for the project is reviewed by senior management (the professor), the project leader, the SQA group, the customer (if possible) and other software process groups, such as the SCM group.

The SQA plan developed is placed under the control of the SCM group. The SQA plan is revised using established polices (according to configuration management) and modifications to the SQA plan must be reviewed and approved by the SQA group and senior management. Only an approved SQA plan will be used.

The SQA plan for the project will follow this format. (A description for these plans is included in appendix four).

• Design and Coding Standards
• Structured Life Cycle
• Reviews
• Audits
• Review and Audit Guidelines
• Documentation Standards
• Configuration Management
• Testing Standards
• Verification and Validation
• Tools, Techniques and Methodologies
• Documentation Reference

The SQA plan, once approved is handed to the SCM group to be placed under configuration management.

SQA Group Activities

The SQA group is established to execute SQA activities.

The SQA group is responsible for making sure that each project follows a previously defined SQA plan (mentioned earlier). The SQA group performs random audits of each project. In order to avoid conflicts of interest, only the members of the SQA group who are not involved with the project perform the audit. Results of the audit are discussed with the full SQA group and the members of the project. Any problems that are found can be discussed and resolved at this time. If a resolution cannot be reached senior management is brought in to arbitrate.

The SQA group is responsible for providing management with information concerning adherence to the established software process. The SQA group is also responsible for providing management with information concerning defects in software products.

The SQA group is responsible for verification and validation of the software and maintaining statistics and other information regarding defects in the code.

The SQA group is expected to require at least the following resources: 1) a computer with database, spreadsheet, and word-processing software, 2) access to all documentation pertaining to the software process, 3) access to senior-management (the professor), 4) access to any revision control databases, 5) access to all requirements, design documents, and project plans.

The SQA group will need to be present (or at least represented) in all meetings regarding development plans for each project. (This will be the case since one member of each project team is a member of the SQA group.)

The SQA group will produce (through audits and questionnaires), evaluations of each project team with respect to adherence to software development policy, as well as evaluations of the quality of the software being developed.

The SQA group will monitor deviations from established policies after a solution has been implemented to verify compliance. Follow up audits may be required to verify that the problems have been solved. (This information as with all information concerning problems will be recorded in a database.) Milestone reports will be generated at each documented milestone according to the project plan.

The SQA group will be required to verify that software products meet customer requirements prior to delivery. In addition the SQA group will verify that the product meets standards. These standards are derived from the functional requirements. Any deviations will be resolved prior to release to the customer.

SQA group will provide reports on the project. These reports will be made available to all members of the team for review and comment. When appropriate, the customer should also be provided with these reports, as well as senior management.