Level 4 - Software Quality Management

Software Quality Management

a key process area for level 4: Managed


The purpose of Software Quality Management is to develop a quantitative understanding of the quality of the project's software products and achieve specific quality goals.

Software Quality Management involves defining quality goals for the software products, establishing plans to achieve these goals, and monitoring and adjusting the software plans, software work products, activities, and quality goals to satisfy the needs and desires of the customer and end user for high quality products.

The practices of Software Quality Management build on the practices of the Integrated Software Management and Software Product Engineering key process areas, which establish and implement the project's defined software process, and the Quantitative Process Management key process area, which establishes a quantitative understanding of the ability of the project's defined software process to achieve the desired results.

Quantitative goals are established for the software products based on the needs of the organization, the customer, and the end users. So that these goals may be achieved, the organization establishes strategies and plans, and the project specifically adjusts its defined software process, to accomplish the quality goals.

Goals

Goal 1

The project's software quality management activities are planned.

Goal 2

Measurable goals for software product quality and their priorities are defined.

Goal 3

Actual progress toward achieving the quality goals for the software products is quantified and managed.

Commitment to perform

Commitment 1 -- The project follows a written organizational policy for managing software quality.

This policy typically specifies that:
  1. The project's software quality management activities support the organization's commitment to improve the quality of the software products.
    Improvements to the process that increase software product quality are a top priority of the organization.

    Each new software product release should be measurably better than its predecessor or leading competitor.


  2. The project defines and collects the measurements used for software quality management based on the project's defined software process.
  3. The project defines the quality goals for the software products and monitors its progress towards them.
  4. Responsibilities for software quality management are defined and assigned to the software engineering group and other software-related groups.
    Examples of software-related groups include:
    • software quality assurance,
    • software configuration management, and
    • documentation support.

  5. Criteria are established to enable the groups to determine their success in achieving the quality goals for the software products.

Ability to perform

Ability 1 -- Adequate resources and funding are provided for managing the quality of the software products.

  1. Specialty engineers in areas such as safety and reliability are available to help set the software quality goals and review progress towards the goals.
  2. Tools to support predicting, measuring, tracking, and analyzing software quality are made available.
    Examples of support tools include:
    • data collection tools,
    • database systems,
    • spreadsheet programs,
    • software life-cycle simulators,
    • quantitative analysis tools, and
    • code audit tools.

Ability 2 -- The individuals implementing and supporting software quality management receive required training to perform their activities.


Examples of training include:
  • planning quality commitments and goals for the product,
  • measuring product and process quality, and
  • controlling product quality using the defined software process.


Refer to the Training Program key process area.


Ability 3 -- The members of the software engineering group and other software-related groups receive required training in software quality management.


Examples of training include:
  • understanding the goals and benefits of quantitatively managing product quality,
  • collecting measurement data,
  • understanding the quality measurements for the software process and product, and
  • planning and controlling the quality of the software product.


Refer to the Training Program key process area.


Activities performed

Activity 1 -- The project's software quality plan is developed and maintained according to a documented procedure.

This procedure typically specifies that:
  1. An understanding of the software quality needs of the organization, customer, and end users is developed as appropriate.
    The end users referred to in these practices are the customer-designated end users or representatives of the end users.



    Examples of ways to measure the customer's and end users' software quality needs include:
    • surveys,
    • focus groups, and
    • product evaluations by users.

  2. The software quality needs and priorities of the organization, customer, and end user are traceable to the system requirements allocated to software and the software quality goals.
    An example of a method to trace these needs and priorities is Quality Function Deployment (QFD).

    An example of tracing needs and priorities to the software quality goals for the product is establishing targets for the number of post-delivery defects and performing predictive exercises as the product matures to assess the likelihood of meeting those goals.



    The system requirements allocated to the software are referred to as "allocated requirements" in these practices.

    Refer to the Requirements Management key process area for practices covering the system requirements allocated to software.


  3. The capability of the project's defined software process to satisfy the software quality goals is assessed and documented.
    Techniques such as Quality Function Deployment and Taguchi's method for robust design can be used to relate the quality goals of a product to the process capability.
  4. The software quality plan satisfies the quality plans of the organization, as appropriate.
  5. The software quality plan is based on plans for previous or current projects in the organization, as appropriate.
  6. The software quality plan is updated at the start of the project, at major project milestones, and whenever the allocated requirements change significantly.
  7. The software quality plan undergoes peer review.
    Refer to the Peer Reviews key process area.


  8. The software quality plan is reviewed by affected groups and individuals.
    Examples of affected groups and individuals include:
    • the customer,
    • the end user,
    • software engineering (including all subgroups, such as software design),
    • software estimating,
    • system engineering,
    • system test,
    • software quality assurance,
    • software configuration management,
    • contract management, and
    • documentation support.

  9. Senior management reviews the software quality plans.
  10. The software quality 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 formality 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.


  11. The software quality plan is available to all affected groups and individuals.

Activity 2 -- The project's software quality plan is the basis for the project's activities for software quality management.

The plan covers:
  1. The points in the process where software quality is measured.
  2. The high-leverage quality goals for the software products.
    High-leverage quality goals for the software products are those that provide the greatest customer satisfaction at the least cost, or the "must haves" from the customer or end user.


  3. The actions that the software project will implement to improve on past quality performance.
  4. The activities to measure software product quality.
    Examples of software activities to measure software product quality include:
    • peer reviews,
    • prototype development,
    • product simulation, and
    • testing.

  5. Quality goals for software work products, as appropriate.
    Examples of quality goals for software products that are appropriate to document in the project's software quality plan include:
    • the characteristics that are planned to be met; and
    • the critical characteristics that, if not met, would make the product undesirable or not needed by the customers or end users.

  6. The actions that will be taken when the software product quality is projected not to meet the quality goals.

Activity 3 -- The project's quantitative quality goals for the software products are defined, monitored, and revised throughout the software life cycle.

  1. Characteristics of product quality that describe how well the software product will perform or how well it can be developed and maintained are identified.
    Examples of software product quality characteristics include:
    • functionality,
    • reliability,
    • maintainability, and
    • usability.

  2. The measurements used to quantify the characteristics of software product quality are identified.
    Examples of activities to identify measurements for software product quality include:
    • reviewing prior performance data and customer requirements,
    • developing prototypes,
    • expressing intermediate software products in formal representations,
    • using formal software engineering methods, and
    • conducting tests.

  3. For each characteristic of software product quality, measurable, numeric values, based on the required and desired values, are selected as quality goals for the product.
    Examples of possible quality goals for the software product 's reliability include:
    • the mean time between failure as specified in the requirements,
    • the mean time between failure that must be achieved (as determined by analysis and experimentation), and
    • the mean time between failure that is planned to be achieved.

  4. Quality goals for the software products are documented in the project's software quality plan.
    Examples of quality goals for software products that are appropriate to document in the project's software quality plan include:
    • the characteristics that are planned to be met; and
    • the critical characteristics that, if not met, would make the product undesirable or not needed by the customers or end users.
    • Quality goals for each software life-cycle stage are defined and documented.
      Examples of software life-cycle stages include:
      • software requirements,
      • software design,
      • coding, and
      • software test.


      Examples of quality goals related to software life-cycle stages include:
      • product defects related to each software life-cycle stage will be reduced from the previous product release by some predetermined percentage, and
      • a predetermined percentage of predicted defects will be found by the end of the test cycle.

    • Quality goals for the software products and software life-cycle stages are revised as understanding of the products and understanding of the organization's, customer's, and end users' needs evolve.

Activity 4 -- The quality of the project's software products is measured, analyzed, and compared to the products' quantitative quality goals on an event-driven basis.


Refer to the Quantitative Process Management key process area for practices covering use of measurement data.


  1. The software tasks are planned and performed to address the project's software quality goals. At the beginning of a software task, the team performing the task:
    • reviews the quality goals for the software product,
    • determines the quality goals applicable to the software task,
    • identifies its plans to achieve the software quality goals, and
    • reviews changes made to the process to meet the software quality goals.

    An example of a change is revising a peer review checklist to address defects that have been found to escape peer reviews.


  2. The quality of the software work products of each software life-cycle stage are measured.
    Examples of methods to measure the quality of work products include:
    • peer reviews,
    • simulation, and
    • testing.

  3. The quality measurements are analyzed and compared to the software quality goals to determine whether the quality goals are satisfied.
  4. Appropriate actions, consistent with the software quality plan, are taken to bring the quality measures of the products in line with the software quality goals.
  5. When it is determined that the software quality goals conflict (that is, one goal cannot be achieved without compromising another goal), actions are taken to resolve the conflict.
  6. The cost for achieving the software quality goals is analyzed.
  7. Alternative software quality goals are considered in light of long-term business strategies as well as short-term priorities.
  8. The customer and end users participate in quality tradeoff decisions, as appropriate.
  9. The software work products and plans are revised, as appropriate, to reflect the results of the tradeoffs.

Activity 5 -- The software project's quantitative quality goals for the products are allocated appropriately to the subcontractors delivering software products to the project.


Refer to Activity 1 of the Software Subcontract Management key process area.


Measurement and analysis

Measurement 1 -- Measurements are made and used to determine the status of the software quality management activities.


Examples of measurements include:
  • the cost of poor quality (based on the known quality measurements to whatever degree of accuracy they can be collected), and
  • the costs for achieving the quality goals.

Verifying implementation

Verification 1 -- The activities for software quality management are reviewed with senior management on a periodic basis.


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 activities for software quality management 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 -- The software quality assurance group reviews and/or audits the activities and work products for software quality management and reports the results.


Refer to the Software Quality Assurance key process area.


At a minimum, the reviews and/or audits verify:
  1. The preparation of the project's software quality plan.
  2. The process for establishing and tracking the software quality goals.

[^^]Table of contents [->]Back 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