This document serves as a guideline for the practices for performing peer reviews , the types of peer reviews, the procedures and operational guidelines
The objectives of peer review process is to remove defects from the software work products early and efficiently. Peer reviews can be classified based on their degree of formality or their relative levels of discipline and flexibility. All peer reviews involve some combination of planning, indivdual examination of the work product, review meeting, correction of the errors and correction verification.
Figure 1 Peer Review formality spectrum
3.0 Peer Review types
Two type of peer review will be discussed in this document:
Walkthroughs are the least formal of peer reviews. At a minimum, the product author and one peer are required to conduct a Walkthrough . Additional peers may be assigned depending on the size of the product being reviewed. A peer is defined as someone, besides the principal work product author, who is trained, experienced, and knowledgeable of the work product being reviewed
The objectives of walkthroughs are to:
· Find defects, omissions, and contradictions
· Improve the software product
· Consider alternative implementations
· Create a forum for learning and exchange of techniques
· May be used to evaluate conformance to standards and specifications
4.1 Special Responsibilities
· Author (mandatory): responsible for the product requiring a walkthrough, and selects the peers to participate in the review and presents the product.
· Reviewer(s) (may be one person, mandatory): performs the reviewer role within the scope and to satisfy the goals of the walkthrough.
· Recorder (may be the reviewer, mandatory): the author may request or assign a team member to perform the duties of a recorder. If assigned, records all comments made during the walkthrough that pertain to errors found, questions of style, omissions, contradictions, and suggestions for improvement or alternate approaches. If not assigned, the author should take the role of recorder.
5.0 Formal Inspection
Formal Inspection (FI) is a structured formal peer review. The purpose of an FI is to identify and classify product defects. The product author’s peers conduct FIs. An FI team typically has three to six members. A moderator leads the process. Defect resolution is mandatory, and rework may be formally verified by re-inspection or informally reviewed. Defect data is systematically collected and stored in a peer review database.
The objectives of the Formal Inspection are to:
· Verify that the software work product satisfies its specifications.
· Verify that the software work product conforms to the applicable standards.
· Detect and identify defects and deviation from specification and applicable standards.
· Verify resolution.
5.1 Special Responsibilities
· Inspector(s): Identify and describe the defects and anomalies in the software work product from different viewpoints according to the specified objectives. The inspector(s) in a FI are responsible for following the guidance provided in the inspector's checklist.. The items in the inspector's checklist can be tailored to individual project needs and the type of work product to be inspected.
· Moderator: The moderator leads, manages, and coordinates the FI by providing guidance to the inspection participants and enforces a positive attitude. The moderator also identifies team members and assigns roles to match and develop team member skills. He or she follows guidance outlined in the moderator's checklist. The items in the moderator's checklist can be tailored to individual project needs and the type of work product to be inspected. Finally, the Moderator facilitates the inspection meeting by effective prior planning including starting the meeting on time, focusing on the identification and classification of defects and open issues within the two-hour inspection period.
· Author: The author prepares the work product to be inspected by meeting the inspection entry criteria. The author participates in all phases of the inspection and follows the guidance outlined in the author's checklist. The author replies to any raised questions in any phase, and negotiates the raised defects with the inspector(s). The authro then performs rework and removes all identified defects. The author must not take any other role in the inspection process.
· Presenter / Reader: The primary responsibility of the presenter is to focus the attention of the inspection participants on details of the work product by paraphrasing and summarizing sections as appropriate. Along with that primary role, the presenter acts as a regular inspector by participating in all functions required of other inspectors. The presenter follows the guidance outlined in the presenter's checklist. Items in this checklist may be tailored to individual project needs and the type of work product to be inspected.
· Recorder (could be moderator): The recorder is responsible for accurate and complete documentation of defects reported by the inspection team members, defect classification, open issues, assigned action items, and inspection feedback/lessons learned.
6.0 Procedures for reviews
The following table provides more detailes that will help in conducting each procedure of the peer review processs according to the selected review type.
1. Authorized person sends Walkthrough request.
2. Plan or approve the Walkthrough plan.
3. Author sends his/her commitment to the plan.
4. Reviewer(s) send their commitment to perform their tasks in the plan
1. The project manager assign proposed participants to specific roles.
2. Determine the size of the work product to be inspected.
3. Establish requirement for overview meeting.
4. Schedule the overview and the inspection activities and meetings.
5. Prepare and distribute FI packages “work products, templates, check lists etc.” to par ticipants.
6. Record measurements data in the Planning phase for measurements
1. Conduct overview meeting to educate participants on the work product to be inspected, and Review the FI procedures applicable to the work product and inspection team and address any raised questions and concerns (optional).
2. Inspectors review the work product.
3. Classify and record all defects.
4. Return completed defects by the due date.
5. Confirm defects have been documented correctly.
6. Ensure all participants are adequately prepared for the inspection.
7. Confirm readiness of the work product for inspection.
8. Merge and distribute the Peer Review defects.
9. Record Preparation phase metrics.
1. The author walks through the work product.
2. The reviewer(s) ask questions for clarifications and the author replies their questions.
3. The reviewer(s) raise their issues and describe them according to the standards speci fied, such as type, category, severity, priority, …etc.
4. The author negotiates the raised issues with the reviewers.
5. The author takes decisions for the reviewers’ issues.
6. The author and reviewer(s) conduct root cause brainstorming meeting.
7. The author takes decision for conducting re-review meeting.
8. The author (or recorder), records all negotiated issues and decisions taken for each.
1. Determine if there are enough participants to conduct the inspection.
2. Review roles, focus areas and guidelines for conducting the inspection.
3. Call for global defects or issues affecting the entire work product.
4. Call for specific defects and issues to be reviewed and recorded.
5. Determine if additional time is required to complete the inspection.
6. Use a third hour to complete remaining inspection activities (optional).
7. Assign open issues.
8. Decide if the work product should be re-inspected.
9. Solicit feedback from participants regarding the inspection.
10. Conduct optional root cause brainstorming meeting.
11. Record Inspection Phase metrics.
12. Complete Inspection portion of the participant’s checklists
1. The author notifies the project manger of the size of rework.
2. The project manager plans and schedules the rework.
3. The author performs the rework according to the planned task and the issues in the log file.
4. The author may ask the project manager for a re-review meeting.
1. Estimate due dates for resolution of open issues.
2. Correct all defects identified in the work product.
3. Resolve all open issues for the work product.
4. Correct all "redline" errors identified in the work product.
5. Record Rework Phase metrics.
6. Complete Rework portion of the participant’s checklists
1. Moderator schedules the follow-up meeting with the author of the work product.
2. Moderator verifies that all defects planned for rework have been corrected.
3. Moderator verifies that all open issues planned for resolution have been resolved.
4. Moderator verifies that all "redline" errors have been corrected during rework.
5. Log remaining open issues or defects into project tracking system.
6. Complete the follow-up portion of the participant’s checklists.
7. Complete and distribute the FI documentation