Software Quality Assurance

a key process area for level 2: Repeatable

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.

Software Quality Assurance involves reviewing and auditing the software
products and activities to verify that they comply with the applicable
procedures and standards and providing the software project and other
appropriate managers with the results of these reviews and audits.

The software quality assurance group works with the software project during its
early stages 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 project’s needs and verifies that they will be usable for
performing reviews and audits throughout the software life cycle. The software
quality assurance group reviews project activities and audits software work
products throughout the life cycle and provides management with visibility as
to whether the software project is adhering to its established plans,
standards, and procedures.

Compliance issues are first addressed within the software project and resolved
there if possible. For issues not resolvable within the software project, the
software quality assurance group escalates the issue to an appropriate level of
management for resolution.

This key process area covers the practices for the group performing the
software quality assurance function. The practices identifying the specific
activities and work products that the software quality assurance group reviews
and/or audits are generally contained in the Verifying Implementation common
feature of the other key process areas.

Goals

Goal 1

Software quality assurance activities are planned.

Goal 2

Adherence of software products and activities to the applicable standards,
procedures, and requirements is verified objectively.

Goal 3

Affected groups and individuals are informed of software quality assurance
activities and results.

Goal 4

Noncompliance issues that cannot be resolved within the software project are
addressed by senior management.

Commitment to perform

Commitment 1 — The project follows a written organizational policy for
implementing software quality assurance (SQA).

This policy typically specifies that:

1. The SQA function is in place on all software projects.
2. The SQA group has a reporting channel to senior management that is
   independent of:
   • the project manager,
   • the project’s software engineering group, and
   • the other software-related groups.

     Examples of other software-related groups include:

     • software configuration management, and
     • documentation support.

   Organizations must determine the organizational structure that will support
   activities that require independence, such as SQA, in the context of their
   strategic business goals and business environment.

   • Independence should:
   • provide the individuals performing the SQA role with the organizational
     freedom to be the “eyes and ears” of senior management on the software project;
   • protect the individuals performing the SQA role from performance appraisal
     by the management of the software project they are reviewing; and
   • provide senior management with confidence that objective information on
     the process and products of the software project is being
     reported.
3. Senior management periodically reviews the SQA activities and results.

Ability to perform

Ability 1 — A group that is responsible for coordinating and implementing
SQA for the project (i.e., the SQA group) exists.

A group is the collection of departments, managers, and individuals who have
responsibility for a set of tasks or activities. A group could vary from a
single individual assigned part time, to several part-time individuals assigned
from different departments, to several individuals dedicated full time.
Considerations when implementing a group include assigned tasks or activities,
the size of the project, the organizational structure, and the organizational
culture. Some groups, such as the software quality assurance group, are
focused on project activities, and others, such as the software engineering
process group, are focused on organization-wide activities.

Ability 2 — Adequate resources and funding are provided for performing
the SQA activities.

1. A manager is assigned specific responsibilities for the project’s SQA
   activities.
2. A senior manager, who is knowledgeable in the SQA role and has the
   authority to take appropriate oversight actions, is designated to receive and
   act on software noncompliance items.
   • All managers in the SQA reporting chain to the senior manager are
     knowledgeable in the SQA role, responsibilities, and authority.
3. Tools to support the SQA activities are made available.

   Examples of support tools include:

   • workstations,
   • database programs,
   • spreadsheet programs, and
   • auditing tools.

Ability 3 — Members of the SQA group are trained to perform their SQA
activities.

Examples of training include:

• software engineering skills and practices;
• roles and responsibilities of the software engineering group and other
  software-related groups;
• standards, procedures, and methods for the software project;
• application domain of the software project;
• SQA objectives, procedures, and methods;
• involvement of the SQA group in the software activities;
• effective use of SQA methods and tools; and
• interpersonal communications.

Ability 4 — The members of the software project receive orientation on
the role, responsibilities, authority, and value of the SQA group.

Activities performed

Activity 1 — A SQA plan is prepared for the software project according to
a documented procedure.

This procedure typically specifies that:

1. The SQA plan is developed in the early stages of, and in parallel with,
   the overall project planning.
2. The SQA plan is reviewed by the affected groups and
   individuals.

   Examples of affected groups and individuals include:

   • the project software manager;
   • other software managers;
   • the project manager;
   • customer SQA representative;
   • the senior manager to whom the SQA group reports noncompliance issues; and
   • the software engineering group (including all subgroups, such as software
     design as well as the software task leaders).
3. The SQA plan is managed and controlled.

   “Managed and controlled” implies that the version of the work product in use at
   a given time (past or present) is known (i.e., version control), and changes
   are incorporated in a controlled manner (i.e., change control).

   If a greater degree of control than is implied by “managed and controlled” is
   desired, the work product can be placed under the full discipline of
   configuration management, as is described in the Software Configuration
   Management key process area.

Activity 2 — The SQA group’s activities are performed in accordance with
the SQA plan.

The plan covers:

1. Responsibilities and authority of the SQA group.
2. Resource requirements for the SQA group (including staff, tools, and
   facilities).
3. Schedule and funding of the project’s SQA group
   activities.
4. The SQA group’s participation in establishing the software development
   plan, standards, and procedures for the project.
5. Evaluations to be performed by the SQA group.

   Examples of products and activities to be evaluated include:

   • operational software and support software,
   • deliverable and nondeliverable products,
   • software and nonsoftware products (e.g., documents),
   • product development and product verification activities (e.g., executing
     test cases), and
   • the activities followed in creating the product.
6. Audits and reviews to be conducted by the SQA group.
7. Project standards and procedures to be used as the basis for the SQA
   group’s reviews and audits.
8. Procedures for documenting and tracking noncompliance issues to
   closure.

   These procedures may be included as part of the plan or may be included via
   reference to other documents where they are contained.

9. Documentation that the SQA group is required to produce.
10. Method and frequency of providing feedback to the software engineering
    group and other software-related groups on SQA activities.

Activity 3 — The SQA group participates in the preparation and review of
the project’s software development plan, standards, and procedures.

1. The SQA group provides consultation and review of the plans,
   standards, and procedures with regard to:
   • compliance to organizational policy,
   • compliance to externally imposed standards and requirements (e.g.,
     standards required by the statement of work),
   • standards that are appropriate for use by the project,
   • topics that should be addressed in the software development plan, and
   • other areas as assigned by the project.
2. The SQA group verifies that plans, standards, and procedures are in place
   and can be used to review and audit the software project.

Activity 4 — The SQA group reviews the software engineering activities to
verify compliance.

1. The activities are evaluated against the software development plan and the
   designated software standards and procedures.

   Refer to the Verifying Implementation common feature in the other key process
   areas for practices covering the specific reviews and audits performed by the
   SQA group.

2. Deviations are identified, documented, and tracked to closure.
3. Corrections are verified.

Activity 5 — The SQA group audits designated software work products to
verify compliance.

1. The deliverable software products are evaluated before they are delivered
   to the customer.
2. The software work products are evaluated against the designated software
   standards, procedures, and contractual requirements.
3. Deviations are identified, documented, and tracked to closure.
4. Corrections are verified.

Activity 6 — The SQA group periodically reports the results of its
activities to the software engineering group.

Activity 7 — Deviations identified in the software activities and
software work products are documented and handled according to a documented
procedure.

This procedure typically specifies that:

1. Deviations from the software development plan and the designated project
   standards and procedures are documented and resolved with the appropriate
   software task leaders, software managers, or project manager, where possible.
2. Deviations from the software development plan and the designated project
   standards and procedures not resolvable with the software task leaders,
   software managers, or project manager are documented and presented to the
   senior manager designated to receive noncompliance items.
3. Noncompliance items presented to the senior manager are periodically
   reviewed until they are resolved.
4. The documentation of noncompliance items is managed and
   controlled.

Activity 8 — The SQA group conducts periodic reviews of its activities
and findings with the customer’s SQA personnel, as appropriate.

Measurement and analysis

Measurement 1 — Measurements are made and used to determine the cost
and schedule status of the SQA activities.

Examples of measurements include:

• completions of milestones for the SQA activities compared to the plan;
• work completed, effort expended, and funds expended in the SQA activities
  compared to the plan; and
• numbers of product audits and activity reviews compared to the
  plan.

Verifying implementation

Verification 1 — The SQA activities are reviewed with senior management
on a periodic basis.

The primary purpose of periodic reviews by senior management is to provide
awareness of and insight into software process activities at an appropriate
level of abstraction and in a timely manner. The time between reviews should
meet the needs of the organization and may be lengthy, as long as adequate
mechanisms for exception reporting are available.

Refer to Verification 1 of the Software Project Tracking and Oversight key
process area for practices covering the typical content of senior management
oversight reviews.

Verification 2 — The SQA activities are reviewed with the project
manager on both a periodic and event-driven basis.

Refer to Verification 2 of the Software Project Tracking and Oversight key
process area for practices covering the typical content of project management
oversight reviews.

Verification 3 — Experts independent of the SQA group periodically review the activities and
software work products of the project’s SQA group.

Table of contents
Back one chapter
Forward one chapter