CMMI and Quality

CMM/CMMI emphasize the importance and independence of the Software Quality Assurance (SQA) group that is responsible for implementing organizational quality policies, standards, and processes, while the PMBOK emphasizes the importance of the integration of quality activities into the overall project plan. The PMBOK assigns responsibility for project quality issues to the project manager and treats organizational policies, standards, and processes as an input to the planning process. The 2 approaches are not necessarily in conflict but form 2 different views of the issue, taken from 2 different perspectives. This article focuses on aligning the project management best practices described in the PMBOK with the criteria for Level 2 CMM/CMMI certification. Certification will be impossible without an SQA group that meets the criteria set by CMM/CMMI.

Another key difference between CMM/CMMI and the PMBOK is the scope of their respective approaches: CMM/CMMI only addresses quality assurance practices for software development projects while the PMBOK attempts to define the best quality practices for any project. As with the other KPAs, Software Quality Assurance is organized into goals, commitments, abilities, activities, measurements, and verifications.

Goals

The 4 goals of this KPA are:

1. SQA activities are planed.
2. Adherence to applicable standards, procedures, and requirements is verified objectively.
3. Affected groups are informed of SQA activities.
4. Non-compliance issues that cannot be resolved at the project level are escalated to senior management.

Commitment to Perform

The project commits to follow a written organizational policy for implementing SQA that is applied to all projects and that the group has a reporting channel to senior management that is independent of the project. Most software development organizations will have an SQA group which will provide testing services to the project. The policies, standards, and procedures used by the group should be independent of the project and this group should be responsible to senior management for the correct implementation and usage of the organization’s quality standards. SQA policies, standards, and procedures are inputs to the Quality Management processes.

Ability to Perform

The ability to perform revolves around the SQA group. Such a group must be in place, be adequately funded and trained, and train the members of the software project in their role and responsibilities.

Activities

1. An SQA plan is prepared for the software project according to a documented procedure and the plan is reviewed with the rest of the project plan, is managed, and controlled. Organizational policies, standards, and procedures (Organizational Assets) are all inputs to the Plan Quality process. Management and control are achieved through the Perform Quality Assurance and Perform Quality Control processes. Quality Assurance ensures that the product meets the quality goals and objectives established in the plan while Quality Control ensures that the project adheres to the organizational policy (basically that the project is following the plan), that standards are met, and procedures implemented.
2. SQA activities are performed according to the SQA plan. This activity addresses evaluations, audits, and reviews to be performed by the SQA group. This activity also requires the implementation of a trouble reporting system.
3. The SQA group participates in the preparation and review of the project’s development plan and has input to the standards and procedures adopted for the project. To meet this criterion, identify SQA Subject Matter Experts (SMEs) and have them contribute to planning the developer testing plans, including design reviews, code walk-throughs, etc. They will also be responsible for identifying SQA testing activities to you as you plan the project. Standards and procedures are Organizational Assets and are identified as inputs to the Quality Planning process.
4. The SQA group reviews software engineering activities to verify compliance. The software engineering activities referred to here are the testing activities performed by the developers. SQA SMEs should be part of the team that reviews designs and code.
5. The SQA group audits designated software products to verify compliance. Responsibilities here include reporting bugs and verifying bug fixes. This should be the core competency of the SQA group. Your job as project manager will be to ensure that the SQA group not only tests according to the organizational policies, standards, and procedures, but that these tests meet the needs of the project.
6. The SQA reports results to the software engineering group periodically. This activity should be automated by your bug reporting system. The reports on quality should be specified in your Communications Management plan.
7. Deviations in software activities and software work products are documented and handled according to a documented process. The process for bug reporting and tracking should be described in the Quality Management plan and communicated to the SQA group and the developers. This process should support an escalation procedure that deals with deviations that are not corrected by the software developers.
8. The SQA group conducts periodic reviews of its activities and findings with the customer’s SQA personnel. These may come through special meetings scheduled for the purpose or regular Gate Review meetings. The Gate Review meeting that marks the transition from build to deployment will usually be dominated by SQA findings.

Measurement and Analysis

Performance to budget and schedule for SQA activities is measured. These measurements will be part of the overall project plan to measure project progress in other areas.

Verifying Implementation

The first 2 verifications are duplications of the other KPAs: that SQA activities are reviewed with senior management and the project manager periodically. The proper venue for these reviews will be Steering Committee meetings and/or Gate Review meetings. The 3^rd verification calls for an independent group of experts to review SQA activities and work products of the project’s SQA group. This is an organizational call outside the scope of your software project, however User Acceptance Testing (UAT) is one means of verifying the SQA group's work.