Software Quality Assurance

The purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and of the products being built and designed. The primary purpose of this document is to standardize the policies and procedures with respect to Software Quality Assurance. This document will establish a formal written policy for handling Software Quality Assurance.

Additionally, the purpose is to provide quality software. Quality should be measured via a set of the following attributes:

• Portability: the ability of the software to be transferred easily from one computer to another.
• Efficiency: the ability of the software to perform with minimum use of computer resources.
• Usability: the ability of the software to be easily understood and used by human users.
• Testability: the ability of the software to be easily verified by execution.
• Understandability: the ability of the software to be read by a software maintained.
• Modifiability: the ability of the software to be revised by a software maintained.

Goals

• Ensuring customer satisfaction through involvement of all employees in learning how to reliably produce and deliver quality software.
• The Software Quality Assurance Group (SQAG) should provide a structured environment for all team members to work together to improve the quality of the software and promote communication and teamwork.
• All Software Quality Assurance activities are planned in advance by one member from the team.
• Adherence of the software products and activities to the standards, procedures, and requirements is verified objectively by individuals that are not associated with the particular project. The adherence is documented by reviews.
• Affected groups and individuals are informed of software quality assurance activities and results. These reports will also be made available to include each project member, and the project leader. This notification will be done formally through the project review form.
• Noncompliance issues that can't be resolved within the software project are addressed by senior management, along with the group's project leader. Communication to the project leader can be done by several methods. If there is an actual non-compliance issue, the Non-Compliance Form can be generated with the appropriate information and sent to the proper personnel. If there is a possible upcoming problem detected, then just a communiquè to the project leader can be generated.

Commitment to Perform

Team Members

Each Team Member is responsible for learning what quality in the Software Life Cycle is and how to produce quality work throughout. Quality evolves from correct requirements, design, coding and then comprehensive testing.

Oranizational Policy

Each project must follow the established written organizational policy. Reviews will be performed biweekly to ensure that all SQA functions are in place and being utilized by Projects.

Ability to Perform

Responsibility

Responsibility for Software Quality Assurance will be one member of the team.

Documentation

All documentation for the Software Quality Assurance groups will be maintained and archived for future reference. The format of the individual reports will depend on the circumstance and the situation at hand, but the reports in appendix four will be used and archived. Documentation of noncompliance issues will be provided to all project members upon completion of the audits and copies will be sent to all senior management.

Training

Team members will be made aware of their duties and responsibilities. This is one of the actions of SQA. The primary training that needs to be performed is to inform the SQA members of the policies and procedures for SQA throughout the Software Life Cycle. All objectives and activities will also be explained to the members of the SQA group. Training on the use of the tools that are to be used will be performed on an as-needed basis.

Activities Performed

The Software Quality Assurance group will work with the project during its early stages and through the quarter to establish plans, standards, and procedures that will add value to the software project and satisfy the constraints of the project and the organization's policies. By participating in establishing the plans, standards, and procedures, the Software Quality Assurance group helps ensure they fit the projects needs and verifies that these plans will be usable for performing reviews and audits throughout the software project life cycle to ensure quality.

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.

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.

Measurement and Analysis

SQA Measures

Measuring the quality of the software should consist of measuring the attributes that make up quality.

• Understandability and Modifiability:
  • Naming conventions should be chosen for data items and logic structures that reflect and reinforce the meaning of what they do.
  • Make the code simple, structured and modular.
  • Use indentations and white space to clarify logic organization and make it visually appealing.
  • Organize the code logic to make it easier to read and reference.
  • Use a consistent and easy to understand style.
  • Comments at the beginning of each module, at each subfunction, complex section of code, interface, collection of data items, and individual data items.
  • Provide appropriate overall historic information such as a record of changes with dates and names of programmers.
  • To accomplish Understandability and Modifiability, the above coding standards must be followed. A review and or audit must take place to ensure that these standards are being followed.

• Testability:
  • To accomplish testability, each requirements should be traceable to a test case

• Usability:
  • Reviews must take place to verify that the systems contains the usability characteristics required for the intended user audience.

• Efficiency:
  • Efficiency must be quantified in Functional Requirements. During testing, efficiency must be evaluated and comply with the Requirements.

• Portability:
  • If portability is specified in the Requirements, then software should be able to run on other types of specified types of environments.

The SQA group will maintain records related to completion of various milestones as defined in each project's SQA plan. The records will consist of separate Milestone reports.

The SQA group will establish standards for projects to maintain and record results of meetings.

Verifying Implementation

Periodic reviews by management will be performed on at least a quarterly basis. These reviews will be conducted to ensure that the SQA group is performing all of its assigned tasks properly.

SQA Functions and Activities

• Assignment and Initialization of the SQA group
• Develop individual SQA plan for the project
• Review the project plan
• Verify Milestone Completion
• Project Audit
• Project Review
• Product Evaluation / Audit

During the first week of the semester, the SQA member will be identified. The project leader is not allowed to be a member of the SQA . Once the SQA group is formed, one member will be selected and will function as the SQA group leader. The selection of the leader will be done by senior management.

The first actions of SQA will be to review project documentation and become familiar with the project.

Develop individual SQA plan

After reviewing project documentation, the SQA group will review the project SQA plan that was developed by each project team and ensure that it adheres to established SQA policies and guidelines.

This SQA plan must be approved by the team. If there are changes that need to be made, the SQA group will generate a "communiqué to the project leader" informing the leader of the necessary changes that are required before the plan is approved.

Review of the project plan

The SQA group will review each project plan to ensure that it meets all established policies. The SQA group must pay particular attention to the establishment of milestones and ensure that the milestones can be verified. If there are any problems, they must be addressed before the project plan can be accepted. The SQA group will use the "communiqué to the project leader" form to inform the project team of the needed changes or acceptance of the project plan. (Any changes to the project plan after acceptance of the project plan must be accompanied by a "Project plan change form". The SQA group must be informed of these changes to ensure that it is able to verify adherence of the project to the plan as well as established policies.

Verify Milestone Completion

The SQA group will verify that each milestone is completed when the appropriate deliverable is produce (i.e. design document). The SQA group is responsible for verifying that the milestone was indeed completed The SQA group is also responsible for verifying that the milestone was completed following established policy. (i.e. The SQA group will note any obvious deviations from established policy; such as the design document was not placed under configuration management.) (The SQA group member(s) that perform this verification must fill out a "Milestone Report" as provided in appendix four.)

Project Audit

The SQA group is permitted to perform an audit of the project at any time. Audits are expected to normally be the result of a poor review of a project during one of the scheduled biweekly reviews.

Project Review

The SQA group will schedule biweekly reviews with each project team to evaluate the project's status and address SQA issues. These reviews are intended to be informal sit-downs with the project team. If significant problems arise (especially if they are repeated problems), the SQA group is expected to perform an audit of the project. The SQA group will file a "Biweekly Review of Project". A copy of this review will be provided to the project team. The SQA group will pay special attention to process aspects (such as use of configuration management). The SQA group is responsible for verifying that the project follows all procedures and guidelines as specified in the project's SQA plan.

Product Audit/Evaluation

The SQA group is also responsible for the quality of the software that is delivered. As a result the SQA group must evaluate all software before it is released. The SQA group is not expected to debug the program, but rather evaluate it for meeting requirements as well as for software defects. A form is provided in appendix four to be filled out during an evaluation (multiple copies of the form can be used if the number of defects warrants it). A copy of the product evaluation will be given to the project leader after which the project team is expected to work in fixing the problems prior to re-submitting the project to the SQA group for evaluation.