Peer reviews goals are to detect and remove defects from work products early in the development cycle. Peer reviews involve a methodical examination of work products by the author’s peers to identify defects and areas where changes are needed. The specific products that will undergo a peer review are identified and selected in the project's plan.
This set of goals that will be satisfied by performing this process.
· Goal 1: Peer reviews are planned, scheduled and monitored.
· Goal 2: Defects are identified, reworked and removed in the peer reviews.
This is the set of polices that guide this process.
· Plan all peer reviews and document these plans
· Identify and remove defects in the work products.
· Perform peer reviews according to a documented procedure.
The major objectives of peer reviews are to find defects, omissions, and contradictions. Its aim is to improve the product; consider alternative implementations and exchange new techniques and style variations to the participants.
The planning phase enables the identification of the work products to be reviewed, the method to be used to perform the review and the requirements to be satisfied by each selected work product is identified.
The execution of peer review involves scheduling, preparing, and executing peer review meetings.
The reworking procedure will give the author the opportunity to rework the work product and resolve all raised issues in the review meeting. This procedure is optional.
In the follow-up procedure, corrections of all defects planned for rework are verified. The performers confirm that all open issues have been resolved, and all redline errors have been corrected, and closing out the review.
This is a list of assumptions that will be used during performing this process.
· Peer review planning, quality assurance and configuration management activities follow the related processes and procedures.
· The peer review plan is an integral part of the software project management plan.
· Peer review could be applied for software project on both technical work products (such as requirements, design, code, test cases, etc.) and non-technical work products (such as plans, estimations, reports, etc.).
This is a set of risks which may impact the implementation of the process.
· Participants do not understand the review process.
· The review process is not followed.
· The right people do not participate.
· Review meetings drift into problem solving.
· The Project Management Process will plan, monitor, control and measure all activities in the Peer Review Process.
· The Configuration Management Process will provide the infrastructure for performing all the activities. In addition, it will provide a consistent change management cycle for all changes.
· The Quality Assurance Process will audit all critical process’s activities and work products.
· Peer reviews are an important as a proven mechanism for effective defect removal. The peer review and testing processes areas may appear to be similar, but they address different issues. Testing, as a part of the product development process, demonstrates that the product, as provided (or as it will be provided), will fulfill its intended use, whereas peer review addresses whether the work product properly reflects the specified requirements. In other words, peer review ensures that ‘you built it right’, whereas testing ensures that ‘you built the right thing’.
· Selection of the peer review methods typically begins with involvement in the definition of product and product component requirements, as a part of the Product Development Process, to ensure that these requirements are verifiable. Re-verification should be addressed by the peer review methods to ensure that rework performed on work products does not cause unintended defects.