Table of Content

1 SCOPE......................................................................................................................................................................2

2 ROLES & RESPONSIBILITIES ...................................................................................................................................2

3 GLOSSARY OF TERMS...............................................................................................................................................2

4 PROCESS..................................................................................................................................................................3
4.1 ENTRY CRITERIA........................................................................................................................................................4
4.2 PROCEDURE.............................................................................................................................................................4
4.2.1 Plan for Reviews...........................................................................................................................................4
4.2.2 Prepare for Reviews......................................................................................................................................7
4.2.3 Conduct Reviews...........................................................................................................................................8
4.2.4 Resolving Defects and Open Issues.................................................................................................................8
4.2.5 Review Feedback and Defect Details................................................................................................................8
4.2.6 Rework Phase...............................................................................................................................................9
4.2.7 Follow-up and Closure phase.........................................................................................................................9
4.2.8 Conduct Causal Analysis................................................................................................................................9
4.2.9 Identify corrective and preventive action and implement process improvement.....................................................9
4.3 EXIT CRITERIA.........................................................................................................................................................9
5 MEASUREMENTS....................................................................................................................................................9

6 VERIFICATIONS....................................................................................................................................................9

7 TAILORING & WAIVERS.........................................................................................................................................9

8 RESOURCES USED................................................................................................................................................10
8.1 REFERENCES..........................................................................................................................................................10
8.2 DOCUMENTS & TEMPLATES............................................................................................................................................10
 Review Process

1 Scope
Review is a process by which a part or whole of a software item or product under development
and the associated documents are examined by an individual or a group of people for any
possible defects / problems.
The purpose of this artifact is to define the process of planning, organizing, conducting and
recording and analyzing the activities related to review of an item or product and the
associated documents to be reviewed.

2 Roles & Responsibilities

Activity Responsibilit Accountability Consult Inform
y
Plan for reviews (SQA, PL / PM PL/PM PC UH / PC
Peer etc.) at the Project
Management Planning
stage as per the project
schedule finalized.
Prepare for reviews PL / PM / TM Author / PC UH
Facilitator
Conduct reviews as per PM / Facilitator Facilitator PM/PL UH
the Plan
Log Review feedback and PM / Facilitator Facilitator PM/PL UH
defect details in the form
of Review Report/ Review
Log
Identify corrective & Facilitator Facilitator PM UH /QH
Preventive Actions & take
approval from PM/PL
Correct defects PL / TL Author PM UH /QH
Track defects to closure PL / TL PL / TL PM /PL / TM UH / QH
Conduct Causal Analysis PM PM /PL PC UH / QH
Implement PM / PC PC QH UH
Identify and log Process
Improvements

3 Glossary of Terms
Abbreviation/Acronyms Definitions
CC Configuration Controller
MR Management Review
PC Process Consultant
 Review Process

PEG Process Engineering Group

PM Project Manager
PMP Project Management Plan
PR Peer Review
QAR Quality Assurance Review
QH Quality Head
SCMP Software Configuration Management Plan
SME Subject Matter Expert
SQA Software Quality Assurance
SRS Software Requirement Specification
TM Team Member
UH Unit Head

4 Process
The purpose of review process is to:
• Detects and eliminates defects before it reaches the formal testing process.
• Helps double check the quality documents before they are baselined.
• Increases probability of delivering/maintaining the right product.

The different types of reviews are:

Management Reviews
Management reviews are conducted for management purposes: considering current project
status and the future commitment of resource ("Go / No-Go decisions"). Management
reviews are done at fixed intervals. Management reviews are carried out by, or on behalf of,
the management personnel having direct responsibility for the system. Management reviews
identify consistency with and deviations from plans, or adequacies and inadequacies of
management procedures.
Senior Management Technical Review
Technical Review at senior management level will be done by DH / GDD for the purpose of
checking the correctness of the deliverable from the technical requirements point of view e.g.
the GDD will check that the graphics are as per the concept, the animation are running
correctly, there is appropriate synch between the sound and the animations etc.
Peer Review
Peer review is a process used for checking the work performed by one's equals (peers) to
ensure it meets specific criteria. Peer review is used in working groups for many professional
occupations because it is thought that peers can identify each other's errors quickly and
easily, speeding up the time that it takes for mistakes to be identified and corrected. In
software development, peer review is sometimes used in code development where a team of
coders will have a meeting and go through code line by line (even read it aloud possibly) to
look for errors. Generally, the goal of all peer review processes is to verify whether the work
 Review Process

satisfies the specifications, identify any deviations from the standards, and provide
suggestions for improvements. There are two types of Peer review.
a) Inspection
An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a
moderator, reader, and a recorder to take notes. The subject of the inspection is typically a
document such as a requirements spec or a test plan, and the purpose is to find problems
and see what's missing, not to fix anything. Attendees should prepare for this type of
meeting by reading thru the document; most problems will be found during this preparation.
The result of the inspection meeting should be a written report/Log.
b) Walkthrough
A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no
preparation is usually required. The software walkthrough also caters to the needs of the
author; it is the author who initiates the session. Consequently there may be several
walkthroughs in each life cycle activity.
Quality Assurance Review
The purpose of the Software Quality Assurance Review is to verify that the software products
and activities conform to the established procedures and standards, and to provide the
project and appropriate managers with the result of this review.

4.1 Entry Criteria

The readiness of work products (artifacts/code/deliverables/planning documents) for review.

4.2 Procedure

4.2.1 Plan for Reviews

At the time of planning for the project, the following will be identified in the Project
Management Plan of the project / business unit:-
• Work products that need to be reviewed.
• Inputs received for development activities from customer or any other external source
• Types of reviews appropriate for work products.
• Any training required by the team on conducting reviews will also be planned in PMP.
• A code review checklist needs to be prepared, if required, before conducting a
review.
Projects will plan for required reviews during a project life cycle from following sample list.
 Review Process

The following is a guideline/reference for people to use and follow.

Phase Review Participants Scope Artifact Nature
type
Planning PR, QAR, PL To review the PMP, Schedule, All Planning Items
MR planning and SCMP, Contract, shall be CI.
provide Proposal, Project
suggestion for Initiation Note,
improvement Estimation Sheet
QAR PC To conduct PMP, Schedule ,
planning SCMP, Estimation
review Sheet
(Availability &
Adequacy of
PMP Sections)
Requirements PR - Team To review the SRS , Notes made SRS shall be
Inspectio Member / methodology for requirement configurable
n SME adopted for collection , item. Test
reviewer/ collecting System and Cases shall be
SQA Review requirements Acceptance Test configurable
and its Case item.
documentation
in Scope
Matrix and
review System
and
Acceptance
Test cases
Baseline CC To audit the SRS, System &
Audit SRS from Acceptance Test
process Cases,
perspective
and check the
Configuration
Management
 Review Process

Delivery To conduct SRS, Peer Review

Audit Delivery Audit Report/Review
( if SRS & also to Log and Baseline
is review Metrics, audit report,
customer Planning while Delivery Note,
deliverab conducting the Contract
le ) PC/PM facilitation
+Facilita
tion

Design Peer, Team To review the SDD , SRS , Unit SDD, Unit Test
Walkthro Member methodology Test Cases, Cases,
ugh adopted for Integration Test Integration
designing and Cases Test Cases
its shall be
documentation configurable
in SDD. Also item.
check if all
requirements
are covered.
Check the Unit
Test Cases and
Integration
Test Cases
Baseline CC To audit the SDD, Peer review
Audit SDD from report, Baseline
process Audit checklist
perspective
and check the
Configuration
Management
Delivery To conduct SDD, Review
Audit ( if Delivery Audit report of
SDD is Peer/Review Log
customer and Baseline
deliverab review report ,
le) PC and PM Delivery Note ,
Contract
+Facilita
tion
Coding and Peer, Coding Team To review the Code To check if the
Testing Walkthro coding and requirements
ugh check if coding have been
standards and met.
guidelines are
followed
 Review Process

Baseline PC To audit and Code Code shall be

Audit check the baselined.
Configuration
Management
User Manual Delivery PC and PM, To review the User Manual, User
Audit+ Technical deliverable to Technical Manual, Documentation
facilitatio Writer customer Online help etc shall be
n +User configurable
To review User
Manual items
Documentation
Review
Team Review Project PM ,Team To review Weekly Progress Managed and
Progress and UH project report Controlled
Review progress
Project Project PM, UH and To review Monthly Progress Managed and
Review Progress Quality Head project Report Controlled
Review progress

While scheduling a review decide following

• Type of review
• Reviewers (role & responsibilities)
• Quality records of reviews
All work products (Documents, Code, and Deliverables) in a project will be reviewed as per
Review plan in the Project Management Plan. PM/PL/Peers/PC assigned to the project, conducts
reviews.
Effort required for reviews will be estimated and documented in the Peer Review
Report/Review Log.

4.2.2 Prepare for Reviews

• A meeting request will be sent for review with roles and agenda identified.
• The Author or the owner of document is referred as facilitator for Peer Review
session.
• Plans/ documents to be reviewed will be sent with meeting request to help
reviewers
come prepared with the review feedback.
• All other reference material will be provided in advance.
• Review checklist will be refereed while reviews are conducted.
• The reviewer will review the document / software item or product before review
meeting
and will prepare their comments/defects, recommendations and questions on the
 Review Process

document / software item or product to be discussed at the review meeting.

• For conducting the code review, team will prepare project specific code review
checklist,
which will cover standards, documentation and coding practice related checkpoints.

4.2.3 Conduct Reviews

• Reviews shall be conducted as per the review plan defined in the project’s Project
Management Plan. A reviewer is expected to spend sufficient time preparing and
identifying issues and concerns about the software product.
• All review meeting will follow meeting facilitation (ISHIR_MeetingFacilitation.ppt)
• Any issues related to review activities that cannot be closed within a defined
timeframe will be escalated to the PM / UH.
• To send review feedback from client site, reviewer will fill in the Peer review
report/Review Log and send it to the meeting facilitator.
• All work products/ documents shall be baseline after reviews.

4.2.4 Resolving Defects and Open Issues

• The author and the review team will resolve defects identified during the review.
These points would be checked against peer review guidelines.
• The author will discuss the open issues with the reviewer and resolve them.

4.2.5 Review Feedback and Defect Details

• Review Defects shall be documented in Review Report/Review log. Attributes of
defects shall be captured as part of review – type, severity, priority, and origin.
• The defects in the document reviewed shall be classified in terms of severity as
follows:
Severity Type for System
High: - May lead to system collapse, Defect identified at later stage
Medium: - Inadequate, Incomplete
Low: - Cosmetic Changes
Severity Type for Documents
High: - Deviation from process defined in QMS, Non availability,
Medium: - Inadequate, Incomplete
Low: - Formatting Related
If customer specifies a different method for classifying defects then it shall be identified and
mapped to the above-mentioned classification for the purpose of consolidation.
The priority of defects shall be defined in the Quality Plan of the projects. It may vary
depending upon the project duration.
Origin of defect shall be identified during review. For example, a defect identified in LLD, may
have originated from HLD or Requirements.
 Review Process

4.2.6 Rework Phase

The author will work on the defects as recorded in the review form.

4.2.7 Follow-up and Closure phase

The author or an authorized individual of the work product will identify corrective & preventive
action needed to close/correct the defect found during reviews. The work product/ document
may be subjected to re -review, after incorporating the feedback, depending on the nature
and number of defects. The PC shall monitor the closure of review defects. Depending on the
nature of review, Effort spent on rework shall be tracked separately.

4.2.8 Conduct Causal Analysis

The review results shall be analyzed by PEG according to the SQMP for projects and Causal
Analysis sheet shall be updated accordingly.

4.2.9 Identify corrective and preventive action and implement process improvement
After conducting the causal analysis, the identified corrective and preventive actions would be
implemented and they would trigger process improvements wherever necessary.

4.3 Exit Criteria

Review Report/Review Log
Closure of All Review Comments
Updated Document / Software item or work product

5 Measurements
Estimated and Actual Effort of the review product
Type and number of defects found and fixed
Rework effort

6 Verifications
Verification of defects by RM
UH Review as per communication plan in the PMP
PM/TL Review as per communication plan in the PMP
Internal Audit, SQA Reviews as per Audit/SQA plan
Senior Management Review as defined in the PMP

7 Tailoring & Waivers

Projects/Units can use either Peer review report or Review log or both to record review findings
and other review details
 Review Process

8 Resources Used

8.1 References

8.2 Documents & Templates