What is peer review document process, that document contains what?

Replies to This Discussion

Permalink Reply by Deepak Kumar on September 24, 2011 at 7:57am

peer review document process is done by team members those are involved in that project.

• ▶ Reply

Permalink Reply by rameshk on September 24, 2011 at 1:25pm

Hi Shanavas,

 

It nothing for if u are writing testcase in excel hope u might have seen ur excel might contain versioning and review colums.

 

so once if completed ur task u need send it for reviews to whether u have missed/covered the requremts

 

Regards,

ramesh

• ▶ Reply

Permalink Reply by Shanavas on September 24, 2011 at 3:35pm

Thanks Ramesh,

 

    i understand the process of the peer review.

 

Thanks,

Shanavas

• ▶ Reply

Permalink Reply by Don Mills on September 25, 2011 at 2:24am

Big topic, Shanavas.  Let's see:

• Review (for current purposes) -- "Evaluation by one or more people of the status of a project, process, or work product".
• Peer - "Person of similar hierarchichal OR technical status."

Probably you're interested in peer reviews of technical documents, where "technical" means "created by a specialist in some discipline for use by one or more specialists in the same or other disciplines."  Examples include: Project plans, schedules, and budgets; requirements specifications; design specifications; source code; user documentation; and test documentation (plans, designs, scripts ...).

 

"Peer review" refers generally to hierarchical peers of the author.  In general, if the author is a manager (plans, budgets, schedules ...), the reviewers should be managers; if the author is "staff" (specifications, code, test documentation ...), the reviewers should be "staff".  Including managers in a "staff" peer review severely damages its effectiveness.  On the other hand, thoroughgoing peer reviews of project plans, schedules, and budgets are probably the most valuable to do: If such documents are wrong, the whole project will go wrong.

 

Conduct of the review will depend on the purpose -- broadly:

• To evaluate compliance to process standards, etc: Audit by external specialists;
• To evaluate project status and make control decisions: Management review by managers;
• To transfer information to a group of people, with feedback: Walkthroough;
• To gain consensus on technical solutions among a group of technical experts: Technical review;
• To find as many defects as possible, and to learn how not to make them in future: Inspection.

The Inspection process goes:

• Checking entry criteria by the Inspection Leader (e.g., did author use correct template, and apply spell-check and grammar check?)
• Planning review objectives by Inspection Leader, and selecting review type, reviewers (including the author), and tools (e.g., checklists; recording forms) to meet objectives, and booking meeting dates, times, and locations
• Kickoff meeting led by Inspection Leader to explain objectives, plan, etc., to participants, and deal with questions
• Individual preparation (at a slow rate, < 1000 words per hour) to record "issues" identified as "inconsistencies" within the target document, or between that document and any applicable standards and sources the author used or should have used, or between the target document and the checklist(s), or between the target document and the reviewers' own knowledge, beliefs, or requirements
• Inspection Meeting, moderated by the Inspection Leader, NOT to discuss issues (there'll be too many) or solutions (too much disagreement), but to consolidate individual findings into an Author Action List, using a second (group) pass through the target document to find additional issues
• Edit of the target document by the author, in response to the Author Action List
• Followup by the Inspection Leader to verify that all logged issues have been dealt with
• Checking exit criteria by the Inspection Leader to evaluate whether the process has been conducted completely and correctly, whether the objectives have been met, and whether the target document is of adequate quality for release for downstream use.

Besides the author, reviewers should include intended users of the target document (people who will need to use it to achieve downstream work) -- e.g., for a Software Requirement Specification, users might include a software architect, a technical writer, a system tester, and a customer representative (representative of customer/user management who will have to sign off the document).  The author of the main source used by the author of the target document (e.g., for a Software Requirements Specifiocation, the author of the Business Requirements Specification) should also be included.  Reviewers of (e.g.) a Project Management Plan prepared by a Project Manager might include (e.g.) a Development Manager, a Test Manager, a Release Manager, and a senior customer representative.

 

These reviewers will all be checking the same page(s) in parallel, but from different expert perspectives.  Optimum size for an Inspection team: 4 to 6 people (adding more adds to the cost without finding enough additional issues to justify the added cost).

 

It's a very common mistake, to allow an author to write pages of poor-quality material with no assistance.  Technical authors (managers, analysts, designers, coders, etc.) shouldn't write more than about a page at a time without its being reviewed immediately, until (after between five and ten pages) the author has learned so much about his/her own error patterns that their defect injection rate has fallen to such a low level that continued review is no longer required.  Ongoing quality can then be measured via reviews of occasional sample pages (e.g., every 10th page or so).

 

The types of review I've mentioned are all more-or-less "formal", meaning structured by written rules that help ensure that the reviewers understand what they're required to achieve, and how to achieve it.  In general, informal reviews are likely to be only around 10% effective at finding defects, walkthroughs perhaps 20%, technical reviews perhaps 50%, and inspections (by experienced inspectors) up to 85%.  To put some perspective on that, an Inspection by experienced reviewers is likely to find between 80 and 100 major defects per page of a typical requirements specification.  Each major defect missed by the other, "cheaper", methods is likely to cost 10 times as much downstream (in development and testing) than finding it at the requirements stage would have cost.  This accounts for a lot of what's wrong in the IT industry.

 

There's a lot more to it than the above, but I hope that helps, Shanavas.

 

-- Don

• ▶ Reply