UNDER CONSTRUCTION

1. Introduction

Typically starts with a quote from the NPR that helps define the activity. Additional descriptive material is meant to help define the activity but not be so detailed that it pulls in all of the guidance from the SWEs in the activity.

Software peer reviews and inspections are the in-process technical examination of work products by peers to find and eliminate defects early in the life cycle. Software peer reviews and inspections are performed following defined procedures covering the preparation for the review, the review itself is conducted, results are recorded, results are reported, and completion criteria is certified. When planning the composition of a software peer review or inspection team, consider including software testing, system testing, software assurance, software safety, software cybersecurity, and software IV&V personnel.

Examples of Some Documents Going Through Peer Review

Site Resources > Activity - Software Peer Reviews and Inspections > Peer Review.png

1.1 Inputs

List of some of the inputs from other activities that are necessary for the activity to begin.

Planning - Peer Reviews are planned activities. They appear in the plans and schedules for the project
Requirements - These are the things that are Peer Reviewed
Architecture Items - These are the things that are Peer Reviewed
Design items - These are the things that are Peer Reviewed
Test Plans and Procedures - These are the things that are Peer Reviewed

1.2 Predecessor Activities

List of some of the other activities that must be started (not necessarily completed) this activity to begin.

Predecessor Activities are performed before Peer Reviews. These activities produce the work products that will be reviewed.

Life Cycle Planning - Peer Reviews are planned activities. They are also used to review and improve all types of plans.

1.3 Outputs

List of some of the outputs or work products of the activity. These are typically used as inputs by the downstream activity. In some cases there is a supporting SWE associated with the work product.

In the case of Peer Reviews, outputs cycle back to the activity that provided the inputs so that improvements to the work products can be made. The activities that initiated the Peer Review, receive the findings from Peer Reviews, Those activities then use those findings to to fix defects and implement improvements uncovered in the reviews. The improved work products are then used by downstream activities as the project proceeds.

Output Work Product	Used by Downstream Activity
Peer Review Findings	Life Cycle Planning Software Architecture Software Design Software Testing Configuration Management Coding

1.4 Successor Activities

Links to Activities which might be started or supported by this activity.

Life Cycle Planning
Software Architecture
Software Design
Software Testing
Configuration Management
Coding

1.5 Repetition

Describe what conditions determine if the activity needs to be repeated.

How much of the activity needs to be repeated
Frequency of repetition

Peer Reviews are planned activities and may be repeated as needed throughout the life cycle. Certainly as Requirements, budgets, schedules, and technology changes are factored into the project, additional Peer Reviews may be desirable.

2. Defining the Activity

This tab contains the links to pages in the SWEHB that are at the heart of the activity.

2.1 SWEs

This section contains the links to SWE pages that form the heart of the activity.

2.2 Topics and other Supporting Materials

This section is for SWEHB pages, other than SWEs, that directly support the activity. This section contains Topics, document content pages, PATs, and other pages.

7.10 - Peer Review and Inspections Including Checklists

2.3 Other Associated SWEs, Topics, etc.

Includes other SWEHB pages that are indirectly associated with the activity. May include SWEs, Topics, document definition pages, PATs, etc. They may have been mentioned in the guidance of another page.