1. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 15 Review Techniques Software Engineering: A Practitioner’s Approach, 6/e Chapter 15 Review Techniques copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

2. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 Reviews & Inspections... there is no particular reason why your friend and colleague cannot also be your sternest critic. Jerry Weinberg

3. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 What Are Reviews? a meeting conducted by technical people for technical people a meeting conducted by technical people for technical people a technical assessment of a work product created during the software engineering process a technical assessment of a work product created during the software engineering process a software quality assurance mechanism a software quality assurance mechanism a training ground a training ground

4. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 What Reviews Are Not A project summary or progress assessment A project summary or progress assessment A meeting intended solely to impart information A meeting intended solely to impart information A mechanism for political or personal reprisal! A mechanism for political or personal reprisal!

5. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5 Rationale for Software Technical Reviews Software development is error-prone process (later errors detected, higher the cost for repair) Software development is error-prone process (later errors detected, higher the cost for repair) Not possible to test all software Not possible to test all software Cannot do exhaustive testing; Cannot do exhaustive testing; Cannot test specification or high level design Cannot test specification or high level design Reviews are a form of validation Reviews are a form of validation Aid in tracking project Aid in tracking project Provide feedback Provide feedback Educational aspect – better understanding of software; learn additional technical skills Educational aspect – better understanding of software; learn additional technical skills Impact on morale – provides visibility of work; some see as intrusion Impact on morale – provides visibility of work; some see as intrusion Impact on maintainability – force incremental documentation Impact on maintainability – force incremental documentation

6. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6 The Players review leader producer recorder reviewer standards bearer (SQA) maintenanceoracle user rep

7. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7 Planning for the Review Select participants Schedule review Develop agenda 1. 2. 3.

8. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8 Conducting the Review be prepared—evaluate product before the review review the product, not the producer keep your tone mild, ask questions instead of making accusations stick to the review agenda raise issues, don't resolve them avoid discussions of style—stick to technical correctness schedule reviews as project tasks record and report all review results 1. 2. 3. 4. 5. 6. 7. 8.

9. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Review Options Matrix trained leader agenda established reviewers prepare in advance producer presents product “reader” presents product recorder takes notes checklists used to find errors errors categorized as found issues list created team must sign-off on result IPR—informal peer review WT—Walkthrough IN—Inspection RRR—round robin review (no face to face meeting) IPRWTIN RRR nomaybemaybemaybenomaybenonononoyesyesyesyesnoyesnonoyesyes yesyesyesnoyesyesyesyesyesyesyesyesyesnonoyesnonoyesmaybe * *

10. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10 Sample-Driven Reviews (SDRs) SDRs attempt to quantify those work products that are primary targets for full FTRs. SDRs attempt to quantify those work products that are primary targets for full FTRs. To accomplish this … Inspect a fraction a i of each software work product, i. Record the number of faults, f i found within a i. Inspect a fraction a i of each software work product, i. Record the number of faults, f i found within a i. Develop a gross estimate of the number of faults within work product i by multiplying f i by 1/a i. Develop a gross estimate of the number of faults within work product i by multiplying f i by 1/a i. Sort the work products in descending order according to the gross estimate of the number of faults in each. Sort the work products in descending order according to the gross estimate of the number of faults in each. Focus available review resources on those work products that have the highest estimated number of faults. Focus available review resources on those work products that have the highest estimated number of faults.

11. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11 Metrics Derived from Reviews inspection time per page of documentation inspection time per KLOC or FP errors uncovered per reviewer hour errors uncovered per preparation hour errors uncovered per SE task (e.g., design) number of minor errors (e.g., typos) number of errors found during preparation number of major errors (e.g., nonconformance to req.) (e.g., nonconformance to req.) inspection effort per KLOC or FP

12. Inspection checks

13. Inspection rate 500 statements/hour during overview 500 statements/hour during overview 125 source statement/hour during individual preparation 125 source statement/hour during individual preparation 90-125 statements/hour can be inspected 90-125 statements/hour can be inspected Inspection is therefore an expensive process Inspection is therefore an expensive process Inspecting 500 lines costs about 40 man/hours effort = $5600 Inspecting 500 lines costs about 40 man/hours effort = $5600