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.
The 4 goals of this KPA are:
activities are planed.
to applicable standards, procedures, and requirements is verified objectively.
groups are informed of SQA activities.
issues that cannot be resolved at the project level are escalated to senior
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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 3rd 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.