软件工程实践者的研究方法chapter12.ppt
These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.1Chapter 12nReview TechniquesSlide Set to accompanySoftware Engineering:A Practitioners Approach,7/e by Roger S.PressmanSlides copyright 1996,2001,2005,2009 by Roger S.PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering:A Practitioners Approach,7/e.Any other reproduction or use is prohibited without the express written permission of the author.All copyright information MUST appear if these slides are posted on a website for student use.These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.2ReviewsThese slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.3What Are Reviews?na meeting conducted by technical people for technical peoplena technical assessment of a work product created during the software engineering processna software quality assurance mechanismna training groundThese slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.4What Reviews Are NotnA project summary or progress assessmentnA meeting intended solely to impart informationnA mechanism for political or personal reprisal!These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.5What Do We Look For?nErrors and defectsnErrora quality problem found before the software is released to end usersnDefecta quality problem found only after the software has been released to end-usersnWe make this distinction because errors and defects have very different economic,business,psychological,and human impactnHowever,the temporal distinction made between errors and defects in this book is not mainstream thinkingThese slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.6Defect AmplificationnA defect amplification model IBM81 can be used to illustrate the generation and detection of errors during the design and code generation actions of a software process.Errors passed throughAmplified errors 1:xNewly generated errorsDevelopment stepErrors fromPrevious stepErrors passed To next stepDefectsDetectionPercentEfficiencyThese slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.7Defect AmplificationnIn the example provided in SEPA,Section 15.2,na software process that does NOT include reviews,yields 94 errors at the beginning of testing and Releases 12 latent defects to the fieldna software process that does include reviews,yields 24 errors at the beginning of testing and releases 3 latent defects to the fieldnA cost analysis indicates that the process with NO reviews costs approximately 3 times more than the process with reviews,taking the cost of correcting the latent defects into accountThese slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.8MetricsnThe total review effort and the total number of errors discovered are defined as:Ereview=Ep+Ea+Er Errtot=Errminor+ErrmajornDefect density represents the errors found per unit of work product reviewed.Defect density=Errtot/WPSnwhere These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.9MetricsnPreparation effort,Epthe effort(in person-hours)required to review a work product prior to the actual review meetingnAssessment effort,Ea the effort(in person-hours)that is expending during the actual reviewnRework effort,Er the effort(in person-hours)that is dedicated to the correction of those errors uncovered during the reviewnWork product size,WPSa measure of the size of the work product that has been reviewed(e.g.,the number of UML models,or the number of document pages,or the number of lines of code)nMinor errors found,Errminorthe number of errors found that can be categorized as minor(requiring less than some pre-specified effort to correct)nMajor errors found,Errmajor the number of errors found that can be categorized as major(requiring more than some pre-specified effort to correct)These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.10An ExampleInIf past history indicates thatnthe average defect density for a requirements model is 0.6 errors per page,and a new requirement model is 32 pages long,na rough estimate suggests that your software team will find about 19 or 20 er
