Source: http://www2.umassd.edu/SWPI/sei/tr25f/tr25_l3g.html, the words “training”
and “trained” are highlighted
Peer Reviews
a key process area for
level 3: Defined
The purpose
of Peer Reviews is to remove defects from the software work products early and
efficiently. An important corollary effect is to develop a better understanding
of the software work products and of defects that might be prevented.
Peer Reviews involve a
methodical examination of software work products by the producers' peers to
identify defects and areas where changes are needed. The specific products that
will undergo a peer review are identified in the project's defined software
process and scheduled as part of the software project planning activities, as
described in Integrated Software Management.
This key process area
covers the practices for performing peer reviews. The practices identifying the
specific software work products that undergo peer review are contained in the
key process areas that describe the development and maintenance of each
software work product.
Goals
Goal 1
Peer review
activities are planned.
Goal 2
Defects in
the software work products are identified and removed.
Commitment to perform
Commitment 1 -- The
project follows a written organizational policy for performing peer reviews.
This policy
typically specifies that:
- The organization identifies a standard set
of software work products that will undergo peer review.
- Each project identifies the software work
products that will undergo peer review.
Refer to
Activity 1 of the Integrated Software Management key process area and Activity
2 of the Organization Process Definition key process area for practices
covering the identification of software products that undergo peer review.
Examples
of software work products include:
- operational software and support
software,
- deliverable and nondeliverable software
work products,
- software (e.g., source code) and
nonsoftware work products (e.g., documents), and
- process descriptions.
- Peer reviews are led by trained peer review
leaders.
- Peer reviews focus on the software work product
being reviewed and not on the producer.
- Results of the peer reviews are not used
by management to evaluate the performance of individuals.
Ability to perform
Ability 1 -- Adequate
resources and funding are provided for performing peer reviews on each software
work product to be reviewed.
Resources
and funding are provided to:
- Prepare and distribute the peer review
materials.
- Lead the peer review.
- Review the materials.
- Participate in the peer review and any
follow-up reviews required based on the defects identified in the peer
review.
- Monitor the rework of the software work
product based on the defects identified in the peer review.
- Collect and report the data resulting from
the peer reviews.
Ability 2 -- Peer review
leaders receive required training
in how to lead peer reviews.
Examples of
training include:
- the objectives, principles, and methods of
peer reviews;
- planning and organizing a peer review;
- evaluating readiness and completion
criteria for a peer review;
- conducting and facilitating a peer review;
- reporting the results of a peer review;
- tracking and confirming rework to address
the actions identified in a peer review; and
- collecting and reporting the data required
for the peer reviews.
Refer to
the Training Program key process area.
Ability 3 -- Reviewers who
participate in peer reviews receive required training in the objectives, principles, and
methods of peer reviews.
Examples of
training include:
- types of peer reviews (e.g., reviews of
software requirements, software design, code, and software test
procedures);
- the objectives, principles, and methods of
peer reviews;
- roles of reviewers; and
- estimating the effort for preparing and
participating in peer reviews.
Refer to
the Training Program key process area.
Activities performed
Activity 1 -- Peer reviews
are planned, and the plans are documented.
These
plans:
- Identify the software work products that
will undergo peer review.
- The software work products selected
include the set identified in the organization's standard software
process.
Refer to
Activity 2 of the Organization Process Definition key process area for
practices covering the organization's standard software process.
- Specify the schedule of peer reviews.
For peer reviews
that are scheduled to occur in the near future, the trained peer review leaders and the other
reviewers for each peer review are identified.
Activity 2 -- Peer reviews
are performed according to a documented procedure.
This
procedure typically specifies that:
- Peer reviews are planned and led by trained peer review
leaders.
- Review materials are distributed to the
reviewers in advance so they can adequately prepare for the peer review.
The review
materials should include the relevant inputs to the development of the software
work product undergoing peer review.
Examples of relevant input
include:
- the objectives of the software work
product,
- the applicable standards,
- the relevant requirements for a design
module, or
- the relevant detailed design for a code
module.
· Reviewers have assigned roles in peer
reviews.
· Readiness and completion criteria for the
peer reviews are specified and enforced.
- Issues in satisfying these criteria are
reported to the appropriate managers.
· Checklists are used to identify criteria for
the review of the software work products in a consistent manner.
- The checklists are tailored to the
specific type of work product and peer review.
Examples of
items addressed by tailoring the checklist include:
- compliance with standards and procedures,
- completeness,
- correctness,
- rules of construction, and
- maintainability.
· The checklists are reviewed by the checklist
developers' peers and potential users.
· Actions identified in the peer reviews are
tracked until they are resolved.
· The successful completion of peer reviews,
including the rework to address the items identified in the peer reviews, is
used as a completion criterion for the associated task.
Activity 3 -- Data on the
conduct and results of the peer reviews are recorded.
Examples of
data include:
- identification of the software work
product reviewed,
- size of the software work product,
- size and composition of the review team,
- preparation time per reviewer,
- length of the review meeting,
- types and number of defects found and
fixed, and
- rework effort.
Measurement and analysis
Measurement 1 --
Measurements are made and used determine the status of the peer review
activities.
Examples of
measurements include:
- number of peer reviews performed compared
to the plan,
- overall effort expended on peer reviews
compared to the plan, and
- number of work products reviewed compared
to the plan.
Verifying implementation
Verification 1 -- The
software quality assurance group reviews and/or audits the activities and work
products for peer reviews and reports the results.
Refer to
the Software Quality Assurance key process area.
At a
minimum, the reviews and/or audits verify that:
- The planned peer reviews are conducted.
- The peer review leaders are adequately trained for their
roles.
- The reviewers are properly trained or
experienced in their roles.
- The process for preparing for the peer
reviews, conducting the peer reviews, and performing the follow-up actions
are followed.
- Reporting of peer review data is complete,
accurate, and timely.
![[^^]](CMM%20Key%20Practices%20for%20Level%203%20-%20Peer%20Reviews-Dateien\up.gif){kind=small}
![[->]](CMM%20Key%20Practices%20for%20Level%203%20-%20Peer%20Reviews-Dateien\back.gif){kind=small}