Assignment Kit for

Design and Code Review Checklists

________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________

PSP Fundamentals

The Software Engineering Institute (SEI)

is a federally funded research and development center
sponsored by the U.S. Department of Defense and
operated by Carnegie Mellon University.

This material is approved for public release.

Distribution limited by the Software Engineering Institute to attendees.

Review Checklists

June 2012

2012 by Carnegie Mellon University

PSP Fundamentals
Assignment Kit for Design and Code Review Checklists
Overview
Topics

This assignment kit covers the following topics.

Section

Prerequisites

Review Checklists

See Page

Prerequisites
Design review and code review checklist requirements

Using review checklists

Review script examples

Building review checklists

Checklist examples

Evaluation criteria

11

Design review checklist template

12

Code review checklist template

13

Grading Checklist - Design and Code Review Checklists

14

Reading
Chapter 9

June 2012

2012 by Carnegie Mellon University

Design review and code review checklist requirements

Design and code
review checklist
requirements

Produce, document, and submit design review and code review checklists.
Submit your defect logs for programs 1-2.
Review material for submission as you complete and submit the Grading
Checklist Design and Code Review Checklists.
The checklists should be tailored for the
design notation and programming language that you use
types of defects that you inject (for this assignment, correlate checklist item
with defect number(s))
NOTE: You may include items in your checklist that you feel are important,
even if they are not found in your defect log.

Review Checklists

June 2012

2012 by Carnegie Mellon University

Using review checklists

The goal of
PSP reviews

The goal of PSP reviews is consistently high yield.

Review yield is the percentage of defects in the product at review time found
by the review.
Process yield is the percentage of defects found of the defects injected before
the first compile or test if there is no compile phase in your process.
With practice, experienced engineers can achieve consistently high process and
review yields of about 70% to 80%.

How checklists
are used

Checklists are used to

guide the review process
establish a consistent set of criteria for judging that the design or code is
correct and complete
promote early defect removal
tailor the review process to support personal defect-injection issues

Conducting
effective
reviews

To conduct effective PSP personal reviews

follow the processalways
use a personal checklist that is designed to find the defects that you make
devise a review strategy and use it
review one product component at a time
check for one topic at a time
treat each check as a personal certification that the product is free of this
defect

Review Checklists

June 2012

2012 by Carnegie Mellon University

PSP code review script

A PSP code review process is described in the following script.

The code
review process

Your checklists should be designed to support your review process.

Code Review Script

Purpose

To guide you in reviewing programs

Entry Criteria

- A completed and reviewed program design

- Source program listing
- Code Review checklist
- Coding standard
- Defect Type standard
- Time and Defect Recording logs

General

Do the code review with a source-code listing; do not review on the screen!

Step

Activities

Description

Review

- Follow the Code Review checklist.

- Review the entire program for each checklist category; do not try to
review for more than one category at a time!
- Check off each item as it is completed.
- For multiple procedures or programs, complete a separate checklist for
each.

Correct

- Correct all defects.

- If the correction cannot be completed, abort the review and return to the
prior process phase.
- To facilitate defect analysis, record all of the data specified in the Defect
Recording log instructions for every defect.

Check

- Check each defect fix for correctness.

- Re-review all design changes.
- Record any fix defects as new defects and, where you know the number of
the defect with the incorrect fix, enter it in the fix defect space.

Exit Criteria

- A fully reviewed source program

- One or more Code Review checklists for every program reviewed
- All identified defects fixed
- Completed Time and Defect Recording logs

Review Checklists

June 2012

2012 by Carnegie Mellon University

PSP design review script

A PSP design review process is described in the following script.

The design
review
process

Your checklists should be designed to support your review process.

PSP2 Design Review Script

Purpose

To guide you in reviewing detailed designs

Entry Criteria

- Completed program design

- Design Review checklist
- Design standard
- Defect Type standard
- Time and Defect Recording logs

General

Where the design was previously verified, check that the analyses
- covered all of the design
- were updated for all design changes
- are correct
- are clear and complete

Step

Activities

Description

Preparation

Examine the program and checklist and decide on a review strategy.

Review

- Follow the Design Review checklist.

- Review the entire program for each checklist category; do not try to
review for more than one category at a time!
- Check off each item as you complete it.
- Complete a separate checklist for each product or product segment
reviewed.

Fix Check

- Check each defect fix for correctness.

- Re-review all changes.
- Record any fix defects as new defects and, where you know the defective
defect number, enter it in the fix defect space.

Exit Criteria

- A fully reviewed detailed design

- One or more Design Review checklists for every design reviewed
- All identified defects fixed and all fixes checked
- Completed Time and Defect Recording logs

Review Checklists

June 2012

2012 by Carnegie Mellon University

Building review checklists

Overview

When constructing review checklists, your objective is to identify and devise checks
for the specific defect types that you make.
To build and improve your review checklists, you will need
a documented review process
detailed defect data on the errors that you make

data on the review process

These data can be derived from PSP defect logs and project plan summaries.

The steps in constructing a review checklist are as follows:

1. Analyze defect data to identify opportunities and priorities.
2. Devise checks for the defects that you make.
3. Organize checks to support the review process.

Analyzing defect
data

To ensure that your reviews provide the most benefit, your checklists should focus on
defects that

give you the most trouble

provide the most leverage
A Pareto distribution will help you to establish priorities. Create distributions for
defect frequency by category
defect cost by category
Figure 9.8, page 179, shows an example Pareto distribution.
As you gather more data on defects, it may be necessary to create defect subcategories.
An example subcategorization is shown in Table 9.5 on page 178 in the text.
Due to the limited amount of data you have to work with at this time, you may include
items in your checklist that you feel are important, even if they are not found in your
defect log.
Defects injected - In what phase do I inject the most defects?
and removed by - In what phase are they removed?
phase
- Could they be removed earlier?
Defect types
- What defect types will the compiler or static analysis tool
found by the
find?
compiler or other
- How effective is the compiler or static analysis tool at finding
static analysis
defects?
tool

- What defect types does the compiler or static analysis tool

miss?
Defect fix time
analysis
Defect removal
rates for reviews
Review yield

Review Checklists

June 2012

What does it cost to fix a defect?

What could be saved by removing defects earlier?
How efficient are my review processes?
How do they compare?
How effective are my review processes?

2012 by Carnegie Mellon University

Building review checklists, Continued

Devising checks

The next step in building checklists is to devise checks for the highest priority
defect types.
Examine your defect logs to identify the specific defects that you make and
devise checks to find them.
Checks should be devised to specifically address the defects that you make. For
example, if you often forget to include semicolons at the end of a statement,
devise a checklist item for that defect:

All statements end with a semicolon

While too much detail can be overwhelming, reviews are generally more efficient
when each checklist item has a small, easily tested scope that can be quickly and
accurately checked.
Organizing
checklist items

The final step in building checklists is to organize your checklist items into
categories.
When selecting categories consider the following.
Merge similar items into one category.
Order categories to support your review strategy and process.
The example design review and code review checklists illustrate one possible
organization that you might use.
The design review checklist organization is explained in the following table.

Review Checklists

Category

Includes checks to ensure that

Complete

The design is complete with respect to requirements, etc.

Logic

The program logic is correct.

Special Cases

Special and extreme cases are properly handled.

Functional use

Functional aspects and interfaces of the design are correct.

Names

Names, variables, parameters, objects, and so on are properly

used and scoped.

Standards

The design conforms to design standards.

June 2012

2012 by Carnegie Mellon University

Checklist examples
The following design and code review checklists can be used as a starting point
for designing your own checklists.
PSP2 Design Review Checklist

Design and code

review checklists
Purpose

To guide you in conducting an effective design review

- Review the entire program for each checklist category; do not attempt to review
for more than one category at a time!
- As you complete each review step, check off that item in the box at the right.
- Complete the checklist for one program or program unit before reviewing the
next.

General

Complete

External Limits

Logic

Internal Limits
Special Cases

Functional Use

System
Considerations

Names

Standards

Verify that the design covers all of the applicable requirements.

- All specified outputs are produced.
- All needed inputs are furnished.
- All required includes are stated.
Where the design assumes or relies upon external limits, determine
if behavior is correct at nominal values, at limits, and beyond
limits.
- Verify that program sequencing is proper.
Stacks, lists, and so on are in the proper order.
Recursion unwinds properly.
- Verify that all loops are properly initiated, incremented, and
terminated.
- Examine each conditional statement and verify all cases.
Where the design assumes or relies upon internal limits, determine if
behavior is correct at nominal values, at limits, and beyond limits.
- Check all special cases.
- Ensure proper operation with empty, full, minimum, maximum,
negative, and zero values for all variables.
- Protect against out-of-limits, overflow, and underflow conditions.
- Ensure impossible conditions are absolutely impossible.
- Handle all possible incorrect or error conditions.
- Verify that all functions, procedures, or methods are fully
understood and properly used.
- Verify that all externally referenced abstractions are precisely
defined.
- Verify that the program does not cause system limits to be
exceeded.
- Verify that all security-sensitive data are from trusted sources.
- Verify that all safety conditions conform to the safety
specifications.
Verify that
- all special names are clear, defined, and authenticated
- the scopes of all variables and parameters are self-evident or
defined
- all named items are used within their declared scopes
Ensure that the design conforms to all applicable design standards.
Continued on next page

Review Checklists

June 2012

2012 by Carnegie Mellon University

Checklist examples, Continued

C++ Code Review Checklist
Purpose

To guide you in conducting an effective code review

- Review the entire program for each checklist category; do not attempt to review
for more than one category at a time!
- As you complete each review step, check off that item in the box at the right.
- Complete the checklist for one program or program unit before reviewing the
next.

General

Complete
Includes
Initialization

Calls

Names

Strings

Pointers

Output Format

() Pairs
Logic Operators
Line-by-line check

Standards
File Open and Close

Review Checklists

June 2012

Verify that the code covers all of the design.

Verify that the includes are complete.
Check variable and parameter initialization.
- at program initiation
- at start of every loop
- at class/function/procedure entry
Check function call formats.
- pointers
- parameters
- use of &
Check name spelling and use.
- Is it consistent?
- Is it within the declared scope?
- Do all structures and classes use . reference?
Check that all strings are
- identified by pointers
- terminated by NULL
Check that all
- pointers are initialized NULL
- pointers are deleted only after new
- new pointers are always deleted after use
Check the output format.
- Line stepping is proper.
- Spacing is proper.
Ensure that () are proper and matched.
- Verify the proper use of ==, =, ||, and so on.
- Check every logic function for ().
Check every line of code for
- instruction syntax
- proper punctuation
Ensure that the code conforms to the coding standards.
Verify that all files are
- properly declared
- opened
- closed

10

2012 by Carnegie Mellon University

Evaluation criteria
Reviewing your
assignment

Use the attached grading checklist to check your assignment. Ensure that your
assignment is correct before you submit it.

Evaluation
criteria

Keep your checklists simple and short.

Your checklists must be
complete
legible
tailored to the design method and notation that you use
tailored to the programming language that you use
designed to address the defects that you inject (for this assignment, correlate
items in checklist with defects found in defect log)

Review Checklists

June 2012

11

2012 by Carnegie Mellon University

Design Review Checklist Template

Student
Program
Instructor

Date
Program #
Language

Purpose

To guide you in conducting an effective design review

General

- Review the entire program for each checklist category; do not attempt to review
for more than one category at a time!
- As you complete each review step, check off that item in the box at the right.
- Complete the checklist for one program or program unit before reviewing the
next.

Defec
t Log
#

Review Checklists

June 2012

12

2012 by Carnegie Mellon University

Code Review Checklist Template

Student
Program
Instructor

Date
Program #
Language

Purpose

To guide you in conducting an effective code review

General

- Review the entire program for each checklist category; do not attempt to review
for more than one category at a time!
- As you complete each review step, check off that item in the box at the right.
- Complete the checklist for one program or program unit before reviewing the
next.

Defec
t Log
#

Review Checklists

June 2012

13

2012 by Carnegie Mellon University

Grading Checklist - Design and Code Review Checklists

Student
Instructor

Accepted or Resubmit

Comments

Accepted

Resubmit

Legend

- O.K.

X - resubmit

Design Review Checklist Contents

Comments

The checklist is complete.

The checklist is tailored to the design method and
notation used.
The checklist is based on defect frequency.
It covers the highest priority defects.
Its contents demonstrate an understanding of the data.

Code Review Checklist Contents

Comments

The checklist is complete.

The checklist is tailored to the programming language
used.
The checklist is based on defect frequency.
It covers the highest priority defects.
Its contents demonstrate an understanding of the data.

General Comments

Review Checklists Grading Checklist

June 2012 14

2012 by Carnegie Mellon University