3. CONFIDENTIAL PAGE II OF II
2.5.4 Step 3.1 – Review the Work Product ...........................................................................7
2.5.5 Step 3.2 – Submit Defect Logs....................................................................................8
2.5.6 Step 3.3 – Consolidate Defect Logs ............................................................................8
2.5.7 Step 3.4 – Determine whether Review Meeting is required ...........................................8
2.5.8 Step 4.1 – Conduct Peer Review meeting....................................................................8
2.5.9 Step 5.1 – Defect correction........................................................................................9
2.5.10 Step 6.1 – Review Defect Logs ...................................................................................9
2.5.11 Step 6.2 – Resolve Open Issues .................................................................................9
2.5.12 Step 6.3 – Perform Causal Analysis ............................................................................9
2.6 Output ...........................................................................................................................9
2.7 Exit Criteria....................................................................................................................9
Appendix A Swim Lane Diagram..............................................................................................i
Appendix B Process Forms.....................................................................................................ii
Appendix C Work Products .....................................................................................................v
Appendix D Checklists and Standards ..................................................................................vii
Table of Figures
Figure 2-1 - Peer Review process overview .....................................................................................4
4. CONFIDENTIAL PAGE 1 OF 9
1 Introduction
1.1 Purpose
The purpose of this document is to provide the Codify Projects team with a process for planning and
executing a peer review of selected work products generated during various stages of project
execution.
Peer reviews form an essential part of the software development process as identified by the CMMI.
Reviews are used to identify defects, address misunderstandings, and reduce the cost of failure. By
identifying problems or potential problems early on we can reduce rework costs in a project, or
maintenance, substantially.
The purpose of reviews is to improve the quality of the work product output. This is a team
responsibility and should not be viewed as criticism of the author. Authors therefore need to be open
to issues raised and reviewers need to focus on defects that will cause problems rather than style or
personal preferences.
1.2 Background
Peer reviews have been used in the software industry since the early 1990s as an effective means of
addressing quality issues. Michael Fagan pioneered the concept of a software inspection in 1986 with
the introduction of the Fagan inspection (Fagan, 1976)1
. He formalised the concept of a structured
review of project work products to address quality issues early on to reduce the overall cost of non-
quality. Another advantage is the development of a better understanding of the work product by all the
reviewers.
Peer reviews form an essential part of the VER (Verification) process area in the CMMI (Capability
Maturity Model Integrated). In the CMMI, peer reviews are included as a specific goal in the VER
process area.
1.3 Acknowledgements
The author would like to acknowledge the inspiration obtained from the SSC San Diego Process Asset
Library2.
1.4 Document Overview
The document is structured into the following manner:
Section 1 – Provides an overview of the Peer Review process and its relation to CMMI
1
http://en.wikipedia.org/wiki/Fagan_inspection
2
http://sepo.spawar.navy.mil/
5. CONFIDENTIAL PAGE 2 OF 9
Section 2 – Describes the Peer Review process in detail including a description of the
process actors and external standards and checklists.
Appendix A – A detailed swim lane diagram.
Appendix B – List of all process forms including completion instructions.
Appendix C – Provides a list of all the work products that are subject to a peer review and
documents who is responsible for reviewing each product
Appendix D – A list of all checklists and standards used during the peer review process.
1.5 Definitions
The following definitions are used through the document:
1 Peer Review – A Peer Review is a structured review of a project work product with the goal of
identifying defects and other changes. The list of work products that will undergo a review are
defined during the project planning phase of the project. The reviews are planned for an
included in the project plan.
2 Walkthrough – An informal review of a work product with the goal of locating quality issues.
3 Work Product – A deliverable that is produced during the execution of a project such as a
functional specification, design document(s), source code, test plans, support manuals, etc.
4 Peer – A peer is an individual who is tasked with conducting a review of a work product in
accordance with the Peer Review process. A peer is also commonly known as an inspector or
reviewer.
5 Author – The author is the individual responsible for creating the work product that is subject
to a peer review.
6 Entry Criteria – Requisite elements and conditions which must be in place before initiation of
the process.
7 Input – Data which the process operates on.
8 Output – Data which the process operates on.
9 Exit Criteria – Requisite elements and conditions which must be in place to complete a
process.
10 Major Defect – A significant error or defect in a work product that would (likely) result in a
serious problem or malfunction. A major defect is considered the most serious type of defect
and must be rectified before advancing the project.
11 Minor Defect – A small error or omission that does not significantly impact the overall quality of
the work product.
12 Open Issue – Any issue that cannot be categorised as a major/minor defect or a redline error
that warrants discussion or debate during the Review Meeting.
6. CONFIDENTIAL PAGE 3 OF 9
13 Redline Error – A spelling, grammar or punctuation problem. These issues are not considered
defects.
1.6 Abbreviations and Acronyms
CMMI Capability Maturity Model Integrated
VER Verification
PAS Process Asset Library
1.7 References
This process document makes reference to numerous external documents which are all available in
the Process Asset Library3
. The following is a list of all referenced documents:
1 Peer Review Announcement Form
2 Defect Log Form
1.8 Conventions
1.8.1 Document Conventions
Italicised angle brackets are often contained within a process step description to indicate an action
such as create a document or refer to a checklist. The example below indicates that the individual
executing a process step should refer to the “Process Checklist” document.
[Refer to Process Checklist]
1.8.2 Process Conventions
The following conventions are used in the process diagrams.
ELEMENT DESCRIPTION
Represents an individual activity that is
undertaken by a process actor.
Represents an external process normally
composed of multiple activities that is defined in
another process document. A process identifier
will be included when referencing external
processes.
3
http://intranet/SiteDirectory/CMMI
Process
External
Process
7. CONFIDENTIAL PAGE 4 OF 9
Represents a decision element which redirects
the position in the workflow based on the
outcome of the decision.
Represents either the beginning or the end of the
entire process.
2 Process Description
2.1 Process Overview
Figure 2-1 is an overview of the 6 parts which constitute the Peer Review process. Please note that
the peer review process is work product agnostic since the general framework applies to the
verification of any work product.
Peer Review
2. Overview
(optional)
3. Review
4. Meeting
(optional)
1. Planning
5. Rework
6. Review & Audit
Figure 2-1 - Peer Review process overview
The structure of a peer review is based on the Fagan inspection model proposed by Michael Fagan.
Each individual phase is summarised below:
1 Planning – The Planning phase involves announcing the pending peer review, assigning roles
and responsibilities to members of the project team and discussing and agreeing entrance
criteria.
Decision
Terminator
8. CONFIDENTIAL PAGE 5 OF 9
2 Overview (optional) – The Overview phases provide the author with the opportunity to
educate the project team about the work product. This step is not always required since peers
are normally already familiar with the type of product to review.
3 Review – The Review involves each reviewer conducting an independent review of the work
product and submitting a Defect Log to the Author and Project Manager. This is the most
important part of the process and cannot be missed.
4 Meeting (optional) – The purpose of the Meeting phase is to discuss any contentious issues
that require further debate and discussion. The Author must interrogate the reviewers to fully
understand the defects so they can be rectified in the Rework phase. Self-explanatory defects
will be rectified immediately and do not warrant discussion at peer review meeting.
5 Rework – The Rework phase involves the Author correcting all open defects. Depending on
the number of defects, another Review and Meeting may be required.
6 Review & Audit – The Project Manager checks the revised work product to ensure that all
open defects have been corrected. The Project Manager and Author can optionally conduct
rudimentary causal analysis4
to better understand the source of defects.
2.2 Roles and Responsibilities
The following section describes the responsibilities of each process actor. Each individual involved in
a peer review must clearly understand their roles and responsibilities to ensure the review is effective.
2.2.1 Project Manager
The Project Manager must ensure that peer reviews of project work products are planned for and
carried out according to the project plan. In addition the Project Manager has the following
responsibilities:
Approve the Peer Review process.
Liaise with the Operations Director to review and improve the Peer Review process using
implementation feedback.
Provide the necessary resources of time, budget and facilities to enable the planning and
execution of peer reviews.
2.2.2 Project Staff
Project Staff (such as Software Developers, Business Analysts, etc) are responsible for implementing
the Peer Review process.
4
Causal analysis is included in the CAR (Casual Analysis and Resolution) process areas in the CMMI.
9. CONFIDENTIAL PAGE 6 OF 9
2.2.3 Reviewer
A Reviewer is an individual who is tasked with reviewing a work product. This individual should be
trained in the Peer Review process and posses relevant knowledge to effectively review the work
product.
2.2.4 Author
The Author is the individual responsible for presenting the work product to be reviewed.
2.3 Entry Criteria
The entry criteria for the process are listed below:
1 The product is ready for a Peer Review.
2 A series of checklists, standards and support documentation applicable to the product being
reviewed are available.
2.4 Input
The inputs to this process are listed below:
1 The work product being reviewed.
2 Applicable checklists and standards.
3 Supporting documentation that would assist an individual undertake a review.
2.5 Process Steps
Please refer to the swim lane diagram in Appendix A for a pictorial representation of the entire
process. The following sections describe each numbered activity in greater detail.
2.5.1 Step 1.1 – Build Team and Assign Responsibilities
The Project Manager is responsible for building a team that has the requisite knowledge and
experience to review the work product. Each team member must be assigned a role which will be
documented in the Peer Review Announcement form. Please refer to section 2.2 for a complete list of
all the roles.
The exact composition of the peer review team is left to the discretion of the Project Manager given
the varied nature of projects. However, the peer review team should not be restricted solely to the
author’s peer. Each work product should also be reviewed by its consumer, i.e. the team or individual
who will use the work product in the next stage of the project. For example, a functional specification
should be reviewed by a senior developer in addition to the analyst’s peer.
2.5.2 Step 1.2 – Announce Peer Review
[Create Peer Review Announcement form]
10. CONFIDENTIAL PAGE 7 OF 9
The Project Manager should now announce the Peer Review by completing the Peer Review
Announcement form and distributing it to the team.
The Peer Review Announcement form should include the following information:
A reference to the work product being reviewed.
References to all applicable standards, checklists and supporting documentation that will
assist the reviewers.
The project code and name the work product pertains to.
A deadline date for the submission of all defect logs.
A proposed date for the peer review meeting.
Proposed dates for an overview and review meeting.
Time recording details for all members of the peer review team. The Project Manager should
pre-create all the requisite project tasks.
2.5.3 Step 2.1 – Conduct Work Product Overview
The purpose of the Work Product Overview is to provide the peer review team with a better
understanding of the product under review. This step is optional and is only required if the product is
sufficiently complicated to warrant an overview. Unfortunately, there aren’t any hard and fast rules
that govern the inclusion of an overview step in the overall process. The Project Manager should take
into account the experience and knowledge of each reviewer and the Author should consider the
complexity of the product. Together, both individuals should have a clear idea about whether to
conduct an overview or not.
The meeting should be organised by the Project Manager and chaired by the Author. Attendance by
the Project Manager is optional. The Author should supply the team with any relevant documentation
prior to the meeting. The meeting itself could be a walkthrough of document supported by an
overhead projector, a product demonstration, etc.
2.5.4 Step 3.1 – Review the Work Product
[Create a Defect Log]
Each Reviewer identified in the Peer Review Announcement form should independently review the
work product and complete a Defect Log. The purpose of the defect log is to provide the Author and
Project Manager with a list of omissions, defects and issues that potentially affect the work product
quality. The Project Manager must ensure that all defect logs are submitted on or before the deadline
submission date otherwise the whole process will stall.
Specifically, the following tasks should be undertaken by each reviewer:
Verify that the work product complies with the original requirements.
11. CONFIDENTIAL PAGE 8 OF 9
Utilise all relevant checklists, standards and supporting documentation to ensure the product
adheres to Codify’s internal quality expectations.
Document all defects and issues.
2.5.5 Step 3.2 – Submit Defect Logs
Each reviewer should submit their Defect Log via email to the Author and Project Manager.
2.5.6 Step 3.3 – Consolidate Defect Logs
A Peer Review will produce multiple defect logs. These individual defect logs must now be merged
into a single consolidated log. To avoid unnecessary administrative overhead there is no requirement
to remove duplicates.
The consolidated defect log should be subject to configuration management at this point to prevent
concurrent access. At the time of writing, we have yet to develop the Configuration Management (CM)
support process. Ultimately, we envisage that all work products will be stored in our SharePoint
server which has excellent document management features including check in and check out and
automatic document versioning.
2.5.7 Step 3.4 – Determine whether Review Meeting is required
The Defect Log form includes a field entitled “Meeting Required” which is populated by each reviewer.
This field enables a reviewer to request a meeting if they believe a sufficient number of contentious
issues are present to warrant a discussion. The Project Manager and Author should utilise their
judgement to determine whether a meeting is actually required.
2.5.8 Step 4.1 – Conduct Peer Review meeting
During the peer review meeting, the team discuss and debate all of the contentious issues identified
during step 1.3.
The date of the Peer Review meeting will be included in the Peer Review Announcement form
irrespective of whether or not a meeting is required. It is always good to assume that a review
meeting will be required.
The meeting itself must be well managed and not deviate from discussing the outstanding defects.
The Author should chair the meeting and run through each defect, eliciting feedback from the
reviewers to better understand the problem and generate debate.
Each defect can be categorised like so:
No action – Everyone is satisfied that the defect warrants no either incorrect.
Corrective action required – The team has decided the reported defect is legitimate and
changes are required to improve the work product.
12. CONFIDENTIAL PAGE 9 OF 9
2.5.9 Step 5.1 – Defect correction
The Project Manager should instruct the Author to address all the reported defects. Any defects that
cannot be rectified should be reported to the Project Manager.
The Author should flag each defect as corrected in the consolidated Defect Log for tracking purposes.
2.5.10 Step 6.1 – Review Defect Logs
The Project Manager and Author meet to check that all reported defects have been corrected to the
satisfaction of the Project Manager. Based on the volume of defects and the success of the peer
review meeting, the Project Manager should decide whether an additional round of peer review is
required to verify the work product. Unfortunately, there is no applicable rule of thumb to automate the
decision to submit the product for further review. The Project Manager should utilise their professional
judgement in each situation.
2.5.11 Step 6.2 – Resolve Open Issues
All defects in the consolidated Defect Log should be flagged as approved. The Project Manager
should also sign-off the entire Defect Log.
2.5.12 Step 6.3 – Perform Causal Analysis
Optionally, the review team can perform casual analysis of each of the logged defects to better
understand the source of the error. This process can be instrumental in obtaining a better
understanding of defect origin to prevent future reoccurrences.
All findings should be logged against the individual defect in the consolidated Defect Log.
2.6 Output
The outputs of this process are listed below:
1 The completed Peer Review Announcement form.
2 A consolidated Defect Log signed-off by the Project Manager.
3 The revised work product.
2.7 Exit Criteria
The exit criteria for the process are listed below:
1 All defects identified during the peer review have been addressed to the satisfaction of the
Project Manager.
2 The work product has been modified as necessary.
13. CDY/000/PR/02
CONFIDENTIAL PAGE I
Appendix A Swim Lane Diagram
Peer Review Process
PlanningOverviewReviewMeetingReworkReview&Audit
Project Manager ReviewerAuthor
Start
End
1.1
Build Team and
Assign
Responsibilities
2.1
Conduct Work
Product Overview
3.1
Review the Work
Product
3.3
Consolidate
Defect Logs
5.1
Defect correction
6.1
Review Defect
Logs
Overview
required?
Yes
No
1.2
Announce Peer
Review
3.2
Submit Defect Log
Meeting
required?
4.1
Conduct Peer
Review meeting
Yes
No
6.2
Resolve Open
Issues
6.3
Perform Causal
Analysis
Additional
Review
required?
No
Yes
3.4
Determine
whether Review
Meeting required
14. CDY/000/PR/02
CONFIDENTIAL PAGE II
Appendix B Process Forms
This appendix describes each of the reference process forms and provides end-users with completion
instructions.
Both the Peer Review Announcement and Defect Log forms can be obtained from the Codify Process
Asset Library located at the following URL: http://intranet/SiteDirectory/CMMI.
Peer Review Announcement
The Peer Review Announcement form is used by the Project Manager to announce the peer review of
a work product and list all the participants of the review. The Project Manager is responsible for
completing all sections of the form.
The form is split into two sections as detailed below:
1) Header Information: Information identifying the work product under review and the project it is
related to.
a) Project Code: The unique project code obtained from C2, e.g. PG-053
b) Project Name: The project description.
c) Work Product Name: The name of the work product being reviewed.
d) Work Product Type: The type of work product being reviewed. The value of this field is
restricted to the list present in the dropdown control
e) Announcement Date: The date the peer review was announced.
f) Overview Meeting Date: The proposed date for an overview meeting to educate reviewers
about the work product.
g) Defect Log Submission Date: The date by which all defect logs must be submitted to the
Project Manager and Author.
h) Review Meeting Date: The proposed date for peer review meeting to discuss contentious
issues with the team.
i) Time Recording: Time recording particulars to assist the peer review team log their time
against the correct project and tasks.
2) Peer Review Participants: A list of everyone who is participating in the peer review.
a) Role: Restricted to Author and Reviewer
b) Name: The name of the participant
c) Notes: Any additional information the Project Manager wants to communicate to the
individual or team
Defect Log
15. CDY/000/PR/02
CONFIDENTIAL PAGE III
A Defect Log is completed by individual reviewers to record the list of defects and issues discovered
during the review.
The form is split into three separate sections as described below:
1) Header Information: Information identifying the work product under review and the project it
is related to.
a) Project Code: The unique project code obtained from C2.
b) Project Name: The project description.
c) Reviewer Name: The name of the individual who composed the defect log.
d) Work Product: The name of the work product being reviewed.
e) Date Submitted: The date the defect log was submitted to the Project Manager and
Author.
f) Meeting Required: Indicates whether the review believes a meeting is required to discuss
contentious issues.
g) Approved By: The name of the Project Manager who has checked that all defects and
issues have been addressed.
h) Approved Date: The date the defect log was approved by the Project Manager.
2) Statistics: Automatically generated statistics based on the defects logged by the reviewer.
Please note that all of these statistics are automatically calculated. Do not override the
spreadsheet formulas.
a) Major Defects: The total number of defects categorised as Major.
b) Minor Defects: The total number of defects categorised as Minor.
c) Open Defects: The total number of defects categorised as Open.
d) Total Defects: A summation of the above three statistics.
3) Defects: A list of all defects discovered by the reviewer during the review. Additionally, there
is provision for recording the results of casual analysis.
a) #: Automatically generated unique identifier for the defect.
b) Init: The initials of the individual recording the defect/issue. Although the reviewer’s name
is recorded in the Header Information section, consolidating the defect logs will result in
multiple logs being merged into one, therefore it is imperative that the source of each
defect is clearly labelled.
c) Description: A detailed description of the defect/issue. The description should not include
a proposed solution.
d) Location: The area within the work product (e.g. line number, paragraph, etc) containing
16. CDY/000/PR/02
CONFIDENTIAL PAGE IV
e) Defect Type: The defect category (Major, Minor or Open).
f) Cause: The results of causal analysis. Populating this column is the responsibility of the
Project Manager with the author’s assistance. Conducting casual analysis is an optional
activity but can be extremely beneficial in understanding the source of defects to reduce
the likelihood of reoccurrence in the future.
g) Rework Done: A Yes/No field that the Author populates after a defect is corrected. Any
defects that cannot be correct should be reported to the Project Manager.
h) Approved: A Yes/No field populate by the Project Manager after the defect correction has
been verified.
17. CDY/000/PR/02
CONFIDENTIAL PAGE V
Appendix C Work Products
The purpose of this appendix is to itemise all of the work products that are subject to a peer review
and identify who should be involved in a review of each product.
WORK PRODUCT DESCRIPTION
Proposal (P) A document generally produced by the Sales department
outlining the scope of work and indicative costs.
Project Plan (PP) A formal document created and maintained by a Project
Manager that is used to guide the execution and control of a
project.
Requirements Specification (RS) A document developed by a Business Analyst designed to
capture the functional and non-functional requirements of a
system.
Functional Specification (FS) A Functional Specification documents how a proposed system
will work from a user’s perspective.
Quotation (Q) A Quotation is a client document that details the total costs
associated with building a system.
Source Code (SC) Produced by a Developer, source code is composed of a
sequence of statement and declarations written in a human-
readable programming language.
Database Schema (DS) Represents the structure of a database system which includes
tables, fields and the relationships amongst individual tables and
fields.
Training Material (TM) Any material produced by the Software Trainer designed to
educate end-users of a system in its operation.
Test Plan (TP) Contains a series of acceptance tests that confirm whether a
system meets the original functional and non-functional
requirements.
Technical Data Package (TDP) Also know as a Design document, a Technical Data Package
contains all the necessary information to build a system.
The following table defines which disciplines should be involved in reviewing each type of work
product. The Primary Reviewer column lists the disciplines that are essential to the peer review
process. Their attendance in the review is mandatory. The Optional Reviewer column – as the name
suggests – lists all the optional attendees of the peer review. The Project Manager should use their
professional judgement regarding whether to utilise these optional disciplines.
WORK PRODUCT PRIMARY REVIEWER OPTIONAL REVIEWER
Proposal Sales Senior Software Developer
18. CDY/000/PR/02
CONFIDENTIAL PAGE VI
Project Manager
Project Plan Project Manager
Business Analyst
Senior Software Developer
Project Team
Requirements Specification Business Analyst
Project Manager
-
Functional Specification Business Analyst
Project Manager
Senior Software Developer /
Domain Expert
-
Quotation Project Manager
Senior Software Developer
Software Tester
Source Code Software Developer -
Database Schema Software Developer -
Training Material Software Trainer
Project Manager
Business Analyst
Test Plan Software Tester
Business Analyst
Project Manager
Technical Data Package Senior Software Developer -
19. CDY/000/PR/02
CONFIDENTIAL PAGE VII
Appendix D Checklists and Standards
The following table list all the applicable checklists and standards associated with each work product.
Each document is available from our CMMI Process Asset Library available from the following URL:
http://intranet/SiteDirectory/CMMI.
Each entry in the Checklists & Standards column is prefixed with a three-letter code to identify the
entry as either a Checklist (CHK) or Standard (STD).
WORK PRODUCT CHECKLISTS & STANDARDS
Proposal CHK: Proposal Checklist
Project Plan CHK: Project Planning Checklist
Requirements Specification CHK: Software Requirements Specification (SRS)
Checklist
Functional Specification CHK: Functional Requirements Checklist
Quotation CHK: Quotation Checklist
Source Code STD: C# Coding Conventions
Database Schema STD: Database Schema Conventions
Training material CHK: User Documentation Checklist
Test Plan CHK: Test Plan Checklist
CHK: Test Case Checklist
Technical Data Package CHK: Preliminary Design Checklist
CHK: Detailed Design Checklist
