Level 2 - Software Quality Assurance

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

page d'accueil

contact

 

menu precedent
Acknowledgements
SEI CMM Key Practices - Overview
Introduction
CMM Overview
Using the Key Practice Pages
Interpreting the CMM
Level 2 - Requirements Management
Level 2 - Software Project Planning
Level 2 - Software Project Tracking and Oversight
Level 2 - Software Subcontract Management
Level 2 - Software Quality Assurance
Level 2 - Software Configuration Management
Level 3 - Organization Process Focus
Level 3 - Organization Process Definition
Level 3 - Training Program
Level 3 - Integrated Software Management
Level 3 - Software Product Engineering
Level 3 - Intergroup Coordination
Level 3 - Peer Reviews
Level 4 - Quantitative Process Management
Level 4 - Software Quality Management
Level 5 - Defect Prevention
Level 5 - Technology Change Management
Level 5 - Process Change Management
Appendix A: References
Appendix B: Glossary
Appendix C: Abridged Key Practices
Appendix D: Change History

 

 

contact

<-- precedent ] page d'accueil ] menu precedent ] suite --> ]

FREE, la liberté n'a pas de prix !  antoine@apple2.com 29-04-2000