What is peer review?

First thing. Why do we need to review? [list][*]to remove defects from software work products early and efficiently.[*]reviews improve schedule performance.[*]reviews reduce rework.[*]rework accounts for 44% of development cost![*][indent]req. (1%), design (12%), coding (12%), testing (19%)[/indent][*]reviews are pro-active tests.[*][indent]find errors not possible through testing.[/indent][/list][list][*]reviews provides:[*][indent]defect information to the author.[*]information on work product and development to peers.[*]fault likelihood data to testers.[*]product status to management[/indent][/list]. Next question arises is how do we do peer review? [list][*]the activity starts after the input documents are approved. For eg. Sdqp, test plans, updated moms, sqa reports etc.[*]the frequency is decided to carry out reviews.[*]peer review is conducted and the defects are logged in rtdf.[*]it is done over both executable and non-executable software work products to identify defects in creation / modification stages.[*]peer reviews are of two types -[*][indent]single person review applicable for walkthrough.[*]group review applicable for inspection[/indent][*]the defects identified in peer review are classified as a,b,c[/list]out of these.... [list][*]severity - a [indent][*]defects that would result in failure of the software element's or an observable departure from standards. These errors degrade the performance and does not have any known workaround solution.[*]for eg. Test cases are missing and not complete as per requirements. Some major functionalities missing.[/indent][*]severity -b [indent][*]defects that would effect only the non-functional aspects of the document / software element. This severity class shall include defects with observable departure from the guidelines. These errors degrade the performance and have a known workaround solution.[*]eg. Some test cases are missing for a functionality.[/indent][*]severity - c [indent][*]this severity class denotes an alternative approach. The decision regarding incorporation of the suggestion lies with the author/moderator.[/indent][/list]the purpose of peer reviews is to remove defects from the software work products early and efficiently. Peer review activities are planned. Tangible benefits of peer review - [list][*]reviews can find 60-100% of all defects.[*]reviews are technical, not management.[*]reviews reduce total project cost, but have non-trivial cost (~15%)[*]upstream defect removal is 10-100 times cheaper.[*]reviews disseminate domain knowledge, development skills.[/list]intangible benefits - [list][*]to prevent defects.[*]to develop better understanding of product.[*]they disseminate corporate culture.[*]review data can assess/improve quality of: [indent][*]work product[*]software development process[*]review process[/indent][/list][u]a formal definition of peer review can be written as - [/u]peer review is a process to inspect / walk through software work products generated at different phases of software development life cycle or modified during maintenance, conversion and migration. There are two types of reviews inspection (done by peer team ) [indent]inspections are used to review large or critical documents/products having direct impact on functionality or external commitments where review by a single individual can not uncover all the defects.[/indent]walkthrough (done by single peer person other than the author) [indent]walkthroughs are used to review small documents and products related to routine activities.[/indent]some of the tools used for peer review - [list][*]code review checklist[*]test plan and test case review checklist[*]user & software requirement checklist[*]proposal and contract review checklist[*]project plan review checklist[*]design review checklist[*]review/test defect form[*]feedback form[*]peer review tracker[*]sqa tracker[/list]if you require further information, feel free to let me know like skills required for peer review, how is it actually performed, etc.