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
