【正文】 include verification time from the followup stage duration of the inspection meeting in hours , total number of major and minor defects found by the inspection team。 checking traceability to, and Moderator and Author Peer Review Process Description anization Page 6 consistency with, predecessor specifications。Organization Peer Review Process Description Version draft1 date author Table of Contents 1. Overview..................................................................................................................................1 2. Work Aids ................................................................................................................................1 3. Risk Assessment Guidance .....................................................................................................1 4. Participants ..............................................................................................................................2 5. Inspection Procedure...............................................................................................................4 6. Walkthrough Procedure ..........................................................................................................9 7. Passaround Procedure...........................................................................................................10 8. Measurements .......................................................................................................................11 9. Process Maintenance ............................................................................................................12 10. Revision History...................................................................................................................12 Peer Review Process Description anization Page 1 1. Overview In a peer review, coworkers of a person who created a software work product examine that product to identify defects and correct shortings. A review: ? verifies whether the work product correctly satisfies the specifications found in any predecessor work product, such as requirements or design documents ? identifies any deviation from standards, including issues that may affect maintainability of the software ? suggests improvement opportunities to the author ? promotes the exchange of techniques and education of the participants. All interim and final development work products are candidates for review, including: ? requirements specifications ? user interface specifications and designs ? architecture, highlevel design, and detailed designs and models ? source code ? test plans, designs, cases, and procedures ? software development plans, including project management plan, configuration management plan, and quality assurance plan This document defines an overall peer review process. It includes procedures for conducting inspections and two types of informal peer review, a walkthrough and a passaround, as well as guidance for selecting the appropriate approach for each review. 2. Work Aids The following peer review work aids are available from location: ? Inspection Summary Report ? Issue Log ? Typo List ? Inspection Moderator’s Checklist ? Inspection Lessons Learned Questionnaire ? defect checklists for several types of software work products 3. Risk Assessment Guidance To judge which software ponents (or portions of ponents) to review and what type of review method to use, consider the following risk criteria: ? ponents that use new technology, techniques, or tools ? key architectural ponents ? plex logic or algorithms that are difficult to understand but must be accurate and optimized Peer Review Process Description anization Page 2 ? mission, security, or safetycritical ponents with dangerous failure modes ? ponents having many exception conditions or failure modes ? exception handling code that cannot easily be tested ? ponents that are intended to be reused ? ponents that will serve as models or templates for other ponents ? ponents that affect multiple portions of the product ? plex user interfaces ? ponents created by less experienced developers ? code modules having high cyclomatic plexity ? modules having a history of many defects or changes Work products that fit in one or more of these categories are considered high risk. A product is considered low risk if an undetected error will not significant affect the project’s ability to meet its schedule, quality, cost, and feature objectives. Use inspections for highrisk work products, or the highrisk portions of large products, and for major work products that are about to be baselined. Less formal reviews are acceptable for other work products 4. Participants