Project Identification
Project Name / Project Number
Program Manager / Project Manager
Date Submitted / Submitted By
I. PURPOSE
During a Software Code Peer Review, software code, supporting documentation, Unit Test plans and test results are examined to identify defects as early as possible and to verify the work product meets requirement and design specifications and conforms to approved policies, standards, and procedures.
Selected peers of the software work product developer perform the Software Code Peer Review following Unit Testing.
If anomalies are discovered, the work product fails the review and is returned to the developer to make modifications.
This procedure is an informal, yet structured approach to perform a Software Code Peer Review.
II. SCOPE
This procedure applies to all Software Code Peer Reviews.
III. REQUIREMENTS
A. Prerequisites
1. Software Code Peer Reviews are project tasks and should be identified and specified in project planning documents, including the Project Plan, Project Schedule, and Project Budget, and in the project Software Quality Assurance Plan (SQAP).
2. A Software Code Peer Review should be conducted when a software work product is completed and from the developer’s perspective is ready to be promoted to another environment or to the next phase in the software development life cycle.
3. Regulations, guidelines, policies, standards, and documented procedures necessary should be available.
4. Reviewers are expected to be familiar with the objectives of a Software Code Peer Review and evaluate the software product in advance.
5. Individual preparation time for all Software Code Peer Review sessions is recorded and tracked. (Records are maintained to determine the Total Cost of Quality.)
B. Expected Performance and/or Process
Project Manager
1. Include Software Code Peer Reviews in planning documents, including Project Plan, Project Schedule, Project Budget, and Project Software Quality Assurance Plan. Allow for time and resources required to perform Software Code Peer Reviews.
Development Lead
2. Determine the need for a Software Code Peer Review and select the Reviewer.
3. Make arrangements for the Software Code Peer Review, including announcing the session, selecting and notifying the Reviewer, and verifying the Reviewer is prepared. If, at the scheduled time of the review, the Reviewer is not prepared, reschedule the review session.
Development Lead / Reviewer / Author
4. Track individual preparation times and record the total. Provide to the Project Manager.
Author
5. Assemble the Software Code Peer Review materials for the Reviewer. Materials include the code, any supporting documentation, Unit Test plans and results, and if available, a comparison of the old verses new code, applicable requirements, policies, standards, and procedures. Place the items under Software Configuration Management (SCM) control.
6. Present an overview of the software product to the Reviewer. The overview introduces the Reviewer to the software product.
Reviewer
7. Tailor a checklist to be used during the Software Code Peer Review and review input materials provided, including code, any supporting documentation, Unit Test plans and results, and if available, a comparison of the old verses new code, applicable requirements, policies, standards, and procedures.
8. Examine the software product and other inputs prior to the Software Code Peer Review.
9. Report and forward anomalies detected during the advance examination to the Author for disposition.
10. Classify anomalies to ensure that the Software Code Peer Review meeting time is used effectively.
Author
11. Specify the order in which the software product will be presented during the Software Code Peer Review (sequential, hierarchical, data flow, control flow, bottom up, or top down).
12. Conduct the Software Code Peer Review with the Reviewer.
13. Answer specific questions and contribute to anomaly detection based on a special understanding of the software product. If there is disagreement about an anomaly, log the potential anomaly and mark it for resolution at the end of the Software Code Peer Review.
Reviewer
14. Examine the software product objectively and thoroughly. Focus on detection of anomalies and not resolution. Comment only on the software product.
15. Evaluate the software product and determine if it is complete and conforms to requirements, design specifications, regulations, policies, standards, procedures, guidelines, and plans applicable to the project.
16. Use the tailored Software Code Peer Review checklist.
17. Ask questions and make comments about the work product to the Author.
18. List and classify anomalies by preparing a Software Code Peer Review report. List each anomaly, location, description, and classification on an anomaly list.
Reviewer / Author
19. Review the Software Code Peer Review report to ensure it is complete and accurate. Discuss every anomaly where disagreement occurred. Do not allow the discussion to focus on resolving the anomaly but on clarifying what constitutes the anomaly.
Development Lead
20. Determine if the software product is complete and accurate. Decide on the software product disposition: Accept with no or minor rework, Accept with rework verification, or Re-inspect and schedule another Software Code Peer Review to verify rework.
21. If decision is to Accept with no or minor rework, change the status to indicate the software work product is complete and may be promoted. Notify the Author. Go to step 24.
22. If decision is to rework, change the status to place the software work product back in Development. Notify the Author. When rework is complete, go to step 3.
23. A Software Code Peer Review is complete when the decision on the exit criteria listed above has been accomplished.
24. Place all artifacts produced during the Software Code Peer Review under CM control. This may include modified code, revised test plans or results, updated documentation, and the Software Code Peer Review report.
Software Code Peer Reviews Procedure
Software Code Peer Review ProcedureSoftware Code Peer Reviews Procedure