《《软件工程-实践者的研究方法》chapter-12-cn-评审技术》由会员分享，可在线阅读，更多相关《《软件工程-实践者的研究方法》chapter-12-cn-评审技术（30页珍藏版）》请在金锄头文库上搜索。
1、These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1第十二章n评审评审技术技术Slide Set to accompanySoftware Engineering: A Practitioners Approach, 7/e by Roger S. PressmanSlides copyright 1996, 2001, 2005, 2009
2、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.Al
3、l copyright information MUST appear if these slides are posted on a website for student use.评审 These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,
4、 20052. . 没有特别的原因说明为什么你的朋友没有特别的原因说明为什么你的朋友没有特别的原因说明为什么你的朋友没有特别的原因说明为什么你的朋友和同事不能成为你最严格的批评人和同事不能成为你最严格的批评人和同事不能成为你最严格的批评人和同事不能成为你最严格的批评人Jerry WeinbergJerry Weinberg什么是评审?n由技术人员领导，并面向技术人员的一个会议n在软件工程过程中，对一个工作产品的技术评估n一种软件质量保证机制n一个培训园地 These courseware materials are to be used in conjunction with Software
5、 Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 20053评审不是n项目总结和进度评估 n一个信息发布会议 n对人员的评估 These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are prov
6、ided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 20054What 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 dis
7、tinction 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,
8、7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.5软件缺陷对成本的影响v在软件过程的环境中，术语缺陷(defect)和故障(fault)是同义词，两者都是指在软件发布给最终用户(或软件过程内其他框架活动)后发现的质量问题。v术语错误(error)来描绘在在软件发布给最终用户(或软件过程内其他框架活动)之前软件工程师(或其他人)发现的质量问题。v正式技术评审的主要目标是在软件过程中发现错误，以使它们不会在软件交付之后变成缺陷(fault) 正式技术评审最明显的优点就是可以早些发现错误，以防止将错误传递到软件过程的后续
9、阶段。缺陷放大和消除n可以用“缺陷放大模型”来说明在软件工程过程的设计和编码活动中错误的产生和检测。该模型如下图所示：These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.7Errors passed throughAmplified errors 1:xNewly generated errorsDevelopment stepErrors fro
10、mPrevious stepErrors passed To next stepDefectsDetectionPercentEfficiencyDefect 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 andReleases 12 latent defects to the fieldna software process th
11、at does include reviews,yields 24 errors at the beginning of testing andreleases 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
12、 slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.9评审度量及其应用v软件工程组织要定义一套可以用来评估其工作效率的度量来理解每项活动的有效性。v可以为所进行的每项评审收集以下评审度量数据：v准备工作量Ep在实际评审会议之前评审一个工作产品所需的工作量（单位：人时）。v评估工作量Ea实际评审工作中所花费的工作量(单位：人时)。v返工工作量Er修改评审期间发
13、现的错误所用的工作量(单位：人时)。v工作产品规模WPS被评审的工作产品规模的衡量(例如UML模型的数量、文档的页数或代码行数)。v发现的次要错误Errminor发现的可以归为次要错误的数量（要求少于预定的改错工作量）。v发现的主要错误Errmajor发现的可以归为主要错误的数量（要求多于预定的改错工作量）。v通过将所评审的工作产品类型与所收集的度量数据相关联，这些度量数据可以进一步细化。An ExampleInIf past history indicates thatnthe average defect density for a requirements model is 0.6 er
14、rors 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 errors during the review of the document. nIf you find only 6 errors, youve done an extremely good job in developing the requirements model or your review approach
15、 was not thorough enough.These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.12An ExampleIInThe effort required to correct a minor model error (immediately after the review) was found to require 4 pers
16、on-hours. nThe effort required for a major requirement error was found to be 18 person-hours. nExamining the review data collected, you find that minor errors occur about 6 times more frequently than major errors. Therefore, you can estimate that the average effort to find and correct a requirements
17、 error during review is about 6 person-hours. nRequirements related errors uncovered during testing require an average of 45 person-hours to find and correct. Using the averages noted, we get:nEffort saved per error = Etesting Ereviews n45 6 = 30 person-hours/errornSince 22 errors were found during
18、the review of the requirements model, a saving of about 660 person-hours of testing effort would be achieved. And thats just for requirements-related errors.These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger P
19、ressman.13评审的成本效益n有评审和没有评审时花费的工作量These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.14with reviews参考模型These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw
20、-Hill 2009). Slides copyright 2009 by Roger Pressman.15非正式评审n非正式评审包括:n与同事就软件工程产品进行的简单桌面检查n以评审一个工作产品为目的的临时会议n结对编程评审n两人一起工作和分享思想共同解决复杂的软件开发。他们不断进行检查彼此的产品，从而以最有效的形式尽早去除缺陷。n如果作为结对编程的结果生产出的工作产品的质量明显优于单个人的工作，在质量方面的节约，足以弥补结对编程带来的“冗余”。These slides are designed to accompany Software Engineering: A Practition
21、ers Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.16正式技术评审n正式技术评审（FTR）是一种由软件工程师(以及其他人)进行的软件质量控制活动。FTR的目标是：n发现软件的任何一种表示形式中的功能、逻辑或实现上的错误；n验证评审中的软件是否满足其需求；n保证软件的表示符合预先指定的标准；n获得以统一的方式开发的软件；n使项目更易于管理。nFTR实际上是一类评审方式，包括走查(walkthrough)和审查(inspection)。每次FTR都是以会议形式进行的，只有经过适当的计划、控制和
22、参与，FTR才能获得成功。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.18评审会议n评审会（通常）应该由3-5人参加n应该提前进行准备，但是占用每人的工作时间应该不超过2小时n评审会的时间应该少于2小时nFTR应该关注的是整个软件中的某个特定部分（例如：只走查各个构建或者一小部分构建，不要试图评审整个设计）These slides are
23、designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.20参与人员These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Press
24、man & Associates, Inc., copyright 1996, 2001, 200522评审会主席评审会主席评审会主席评审会主席生产者生产者生产者生产者记录员记录员记录员记录员复审者复审者复审者复审者(SQA)(SQA)维护人员维护人员维护人员维护人员用户代表用户代表用户代表用户代表评审会议参与人员n评审会议由评审会主席、所有评审员和开发人员参加。其中一位评审员还充当记录员的角色，负责记录在评审过程中发现的所有重要问题。FTR一般从介绍会议日程并由开发人员做简单的介绍开始。然后由开发人员“走查”该工作产品，并对材料做出解释，而评审员则根据预先的准备提出问题。当发现了明确的问题或
25、错误时，记录员逐一加以记录。These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 200524评审指导原则n评审工作产品，而不是评审开发人员。n制定并遵守日程表。n限制争论和辩驳。n要阐明问题，但是不要试图解决所有记录的问题。n做笔记。n限制
26、参与者人数。n为每个将要评审的工作产品建立检查清单。n为FTR分配资源和时间。n对所有评审员进行有意义的培训。n评审以前所做的评审。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.25指导评审These courseware materials are to be used in conjunction with Software Engine
27、ering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 200527准备好准备好准备好准备好在评审之前评估这个产品在评审之前评估这个产品在评审之前评估这个产品在评审之前评估这个产品 评审产品，而不是生产者评审产品，而不是生产者评审产品，而不是生产者评审产品，而不是生产者 语音轻柔，问问题而不是指责语音轻柔，问问题而不是指责语音轻柔，问问题而不是指责语音轻柔，问问题而不是指责 坚守评审日程坚守评审
28、日程坚守评审日程坚守评审日程提出问题，而不是解决他们提出问题，而不是解决他们提出问题，而不是解决他们提出问题，而不是解决他们 避免讨论其他问题避免讨论其他问题避免讨论其他问题避免讨论其他问题坚持技术正确性坚持技术正确性坚持技术正确性坚持技术正确性有计划的评审有计划的评审有计划的评审有计划的评审记录以及上报所有评审结果记录以及上报所有评审结果记录以及上报所有评审结果记录以及上报所有评审结果1.1.2.2.3.3.4.4.5.5.6.6.7.7.8.8.评审选项矩阵These courseware materials are to be used in conjunction with Softw
29、are Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 200528trained leadertrained leaderagenda establishedagenda establishedreviewers prepare in advancereviewers prepare in advanceproducer presents productproducer p
30、resents product“reader” presents product“reader” presents productrecorder takes notesrecorder takes noteschecklists used to find errorschecklists used to find errorserrors categorized as founderrors categorized as foundissues list createdissues list createdteam must sign-off on resultteam must sign-
31、off on resultIPRinformal peer review WTWalkthroughIPRinformal peer review WTWalkthroughINInspection RRRround robin reviewINInspection RRRround robin reviewIPRIPRWTWTININRRRRRRnonomaybemaybemaybemaybemaybemaybenonomaybemaybenonononononononoyesyesyesyesyesyesyesyesnonoyesyesnonononoyesyesyesyesyesyesy
32、esyesyesyesnonoyesyesyesyesyesyesyesyesyesyesyesyesyesyesyesyesyesyesnonononoyesyesnonononoyesyesmaybemaybe* *基于样本的复审 (SDRs)nSDRs主要是找到最需要复审的工作产品为完成这件事 n审查每个软件工作产品i的一小部分，记做ai，记录在ai中发现的错误数目。n用fi 除以ai可以得到在工作产品i中缺陷数量的粗略估算值n按照缺陷数量粗略估算值的递减次序排列这些工作产品n将现有的评审资源集中到那些具有最高缺陷数量估算值的产品上These courseware materials a
33、re to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 200529从评审获得的度量These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 200530每页文档的评审时间 每个KLOC 或 FP的评审时间每个评审者/小时找到的错误 每个准备小时发现的错误每个软件工程任务(e.g., design)发现的错误小错误的数目 准备过程中发现的错误大错误的数目 (e.g., 与需求不兼容.) 每个KLOC 或 FP的评审工作量
