Teams are expected to conduct peer reviews throughout this course. Reviews will likely cover the spectrum from informal desk checks, pair-programming, and pass-arounds, to walkthroughs, team reviews, and formal inspections. Team reviews or formal inspections will be conducted on occasion. The following describes what a typical review might look like.

Typical Review

Prior to Review with Customer:

• Select artifacts for review
• Ensure artifacts meet entry criteria
• Source documents have been inspected and baselined (e.g. requirements are reviewed and approved prior to architecture review)
• Artifact conforms to standards
• Artifact is in repository and has unique identifier (version number)
• Moderator detected no flagrant problems in brief examination
• Code may have additional criteria such as clean compile with specific compiler settings, corresponding automated unit tests with prescribed test coverage, and/or all errors resolved from prescribed static analysis tools
• Post artifacts on the team website
• Identify reviewer roles: Author, Moderator, Recorder, Reader, Inspectors
• Communicate all of above to all participants

Conduct Review

• Moderator facilitates meeting (see Moderator Checklist)
• Reader reads/describes artifact
• Inspectors detect defects, make suggestions
• Author mostly stays quiet except to answer clarifying questions
• Recorder logs artifacts reviewed and defects identified

Post-Review

• Author fixes defects, communicates results through bug-tracking system