First thing. Why do we need to review? - to remove defects from software work products early and efficiently.
- reviews improve schedule performance.
- reviews reduce rework.
- rework accounts for 44% of development cost!
req. (1%), design (12%), coding (12%), testing (19%)
- reviews are pro-active tests.
find errors not possible through testing.
. Next question arises is how do we do peer review? out of these.... - severity - a
- 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.
- severity -b
- 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.
- severity - c
- this severity class denotes an alternative approach. The decision regarding incorporation of the suggestion lies with the author/moderator.
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 - - 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.
intangible benefits - a formal definition of peer review can be written as - 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 ) 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.
walkthrough (done by single peer person other than the author) walkthroughs are used to review small documents and products related to routine activities.
some of the tools used for peer review - - 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
if you require further information, feel free to let me know like skills required for peer review, how is it actually performed, etc.
Posting Permissions
Reply With Quote