软件工程-实践者的研究方法chapter12cn评审技术

1、These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,1,第十二章,评审技术,Slide Set to accompanySoftware Engineering: A Practitioners Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009

2、by Roger S. Pressman For non-profit educational use only May 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.

3、 All 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, 2

4、001, 2005,2,. 没有特别的原因说明为什么你的朋友 和同事不能成为你最严格的批评人,Jerry Weinberg,什么是评审?,由技术人员领导，并面向技术人员的一个会议 在软件工程过程中，对一个工作产品的技术评估 一种软件质量保证机制 一个培训园地,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 & Asso

5、ciates, Inc., copyright 1996, 2001, 2005,3,评审不是,项目总结和进度评估 一个信息发布会议 对人员的评估,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, 2005,4,What Do We Lo

6、ok For?,Errors and defects Errora quality problem found before the software is released to end users Defecta quality problem found only after the software has been released to end-users We make this distinction because errors and defects have very different economic, business, psychological, and hum

7、an impact However, the temporal distinction made between errors and defects in this book is not mainstream thinking,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,5,软件缺陷对成本的影响,在软件过程的环境中，术语缺陷(defe

8、ct)和故障(fault)是同义词，两者都是指在软件发布给最终用户(或软件过程内其他框架活动)后发现的质量问题。 术语错误(error)来描绘在在软件发布给最终用户(或软件过程内其他框架活动)之前软件工程师(或其他人)发现的质量问题。 正式技术评审的主要目标是在软件过程中发现错误，以使它们不会在软件交付之后变成缺陷(fault) 正式技术评审最明显的优点就是可以早些发现错误，以防止将错误传递到软件过程的后续阶段。,缺陷放大和消除,可以用“缺陷放大模型”来说明在软件工程过程的设计和编码活动中错误的产生和检测。该模型如下图所示：,These slides are designed to accom

9、pany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,7,Errors passed through,Amplified errors 1:x,Newly generated errors,Development step,Errors from Previous step,Errors passed To next step,Defects,Detection,Percent Efficiency,Defect

10、Amplification,A 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.,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

11、 copyright 2009 by Roger Pressman.,8,Errors passed through,Amplified errors 1:x,Newly generated errors,Development step,Errors from Previous step,Errors passed To next step,Defects,Detection,Percent Efficiency,Defect Amplification,In the example provided in SEPA, Section 15.2, a software process tha

12、t does NOT include reviews, yields 94 errors at the beginning of testing and Releases 12 latent defects to the field a software process that does include reviews, yields 24 errors at the beginning of testing and releases 3 latent defects to the field A cost analysis indicates that the process with N

13、O reviews costs approximately 3 times more than the process with reviews, taking the cost of correcting the latent defects into account,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,9,评审度量及其应用,软

14、件工程组织要定义一套可以用来评估其工作效率的度量来理解每项活动的有效性。 可以为所进行的每项评审收集以下评审度量数据： 准备工作量Ep在实际评审会议之前评审一个工作产品所需的工作量（单位：人时）。 评估工作量Ea实际评审工作中所花费的工作量(单位：人时)。 返工工作量Er修改评审期间发现的错误所用的工作量(单位：人时)。 工作产品规模WPS被评审的工作产品规模的衡量(例如UML模型的数量、文档的页数或代码行数)。 发现的次要错误Errminor发现的可以归为次要错误的数量（要求少于预定的改错工作量）。 发现的主要错误Errmajor发现的可以归为主要错误的数量（要求多于预定的改错工作量）。 通

15、过将所评审的工作产品类型与所收集的度量数据相关联，这些度量数据可以进一步细化。,Metrics,Preparation effort, Epthe effort (in person-hours) required to review a work product prior to the actual review meeting Assessment effort, Ea the effort (in person-hours) that is expending during the actual review Rework effort, Er the effort (in perso

16、n-hours) that is dedicated to the correction of those errors uncovered during the review Work 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) Minor errors found, Errmin

17、orthe number of errors found that can be categorized as minor (requiring less than some pre-specified effort to correct) Major 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 ac

18、company Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,11,An ExampleI,If past history indicates that the average defect density for a requirements model is 0.6 errors per page, and a new requirement model is 32 pages long, a rough est

19、imate suggests that your software team will find about 19 or 20 errors during the review of the document. If you find only 6 errors, youve done an extremely good job in developing the requirements model or your review approach was not thorough enough.,These slides are designed to accompany Software

20、Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,12,An ExampleII,The effort required to correct a minor model error (immediately after the review) was found to require 4 person-hours. The effort required for a major requirement error was found t

21、o be 18 person-hours. Examining 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 error during review is about 6 person-hours. Requirements related errors

22、 uncovered during testing require an average of 45 person-hours to find and correct. Using the averages noted, we get: Effort saved per error = Etesting Ereviews 45 6 = 30 person-hours/error Since 22 errors were found during the review of the requirements model, a saving of about 660 person-hours of

23、 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 Pressman.,13,评审的成本效益,有评审和没有评审时花费的工作量,These slides are designed to accompany

24、 Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,14,with reviews,参考模型,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,15,非正式评审,非正式评

25、审包括: 与同事就软件工程产品进行的简单桌面检查 以评审一个工作产品为目的的临时会议 结对编程评审 两人一起工作和分享思想共同解决复杂的软件开发。他们不断进行检查彼此的产品，从而以最有效的形式尽早去除缺陷。 如果作为结对编程的结果生产出的工作产品的质量明显优于单个人的工作，在质量方面的节约，足以弥补结对编程带来的“冗余”。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by R

26、oger Pressman.,16,Informal Reviews,Informal reviews include: a simple desk check of a software engineering work product with a colleague a casual meeting (involving more than 2 people) for the purpose of reviewing a work product, or the review-oriented aspects of pair programming pair programming en

27、courages continuous review as a work product (design or code) is created. The benefit is immediate discovery of errors and better work product quality as a consequence.,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 200

28、9 by Roger Pressman.,17,正式技术评审,正式技术评审（FTR）是一种由软件工程师(以及其他人)进行的软件质量控制活动。FTR的目标是： 发现软件的任何一种表示形式中的功能、逻辑或实现上的错误； 验证评审中的软件是否满足其需求； 保证软件的表示符合预先指定的标准； 获得以统一的方式开发的软件； 使项目更易于管理。 FTR实际上是一类评审方式，包括走查(walkthrough)和审查(inspection)。每次FTR都是以会议形式进行的，只有经过适当的计划、控制和参与，FTR才能获得成功。,These slides are designed to accompany Sof

29、tware Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,18,Formal Technical Reviews,The objectives of an FTR are: to uncover errors in function, logic, or implementation for any representation of the software to verify that the software under rev

30、iew meets its requirements to ensure that the software has been represented according to predefined standards to achieve software that is developed in a uniform manner to make projects more manageable The FTR is actually a class of reviews that includes walkthroughs and inspections.,These slides are

31、 designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,19,评审会议,评审会（通常）应该由3-5人参加 应该提前进行准备，但是占用每人的工作时间应该不超过2小时 评审会的时间应该少于2小时 FTR应该关注的是整个软件中的某个特定部分（例如：只走查各个构建或者一小部分构建，不要试图评审整个设计）,These slides are designed to accompany Soft

32、ware Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,20,The Review Meeting,Between three and five people (typically) should be involved in the review. Advance preparation should occur but should require no more than two hours of work for each p

33、erson. The duration of the review meeting should be less than two hours. Focus is on a work product (e.g., a portion of a requirements model, a detailed component design, source code for a component),These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-H

34、ill 2009). Slides copyright 2009 by Roger Pressman.,21,参与人员,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, 2005,22,评审会主席,生产者,记录员,复审者,(SQA),维护

35、人员,用户代表,The Players,Producerthe individual who has developed the work product informs the project leader that the work product is complete and that a review is required Review leaderevaluates the product for readiness, generates copies of product materials, and distributes them to two or three revie

36、wers for advance preparation. Reviewer(s)expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar with the work. Recorderreviewer who records (in writing) all important issues raised during the review.,These slides are designed to accompany Sof

37、tware Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,23,评审会议参与人员,评审会议由评审会主席、所有评审员和开发人员参加。其中一位评审员还充当记录员的角色，负责记录在评审过程中发现的所有重要问题。FTR一般从介绍会议日程并由开发人员做简单的介绍开始。然后由开发人员“走查”该工作产品，并对材料做出解释，而评审员则根据预先的准备提出问题。当发现了明确的问题或错误时，记录员逐一加以记录。,These courseware mater

38、ials 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, 2005,24,评审指导原则,评审工作产品，而不是评审开发人员。 制定并遵守日程表。 限制争论和辩驳。 要阐明问题，但是不要试图解决所有记录的问题。 做笔记。 限制参与者人数。 为每个将要评审的工作产品建立检查清单。 为FTR分配资

39、源和时间。 对所有评审员进行有意义的培训。 评审以前所做的评审。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,25,Conducting the Review,Review the product, not the producer. Set an agenda and maintain it. Limit debate and rebu

40、ttal. Enunciate problem areas, but dont attempt to solve every problem noted. Take written notes. Limit the number of participants and insist upon advance preparation. Develop a checklist for each product that is likely to be reviewed. Allocate resources and schedule time for FTRs. Conduct meaningfu

41、l training for all reviewers. Review your early reviews.,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,26,指导评审,These courseware materials are to be used in conjunction with Software Engineering:

42、 A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005,27,准备好在评审之前评估这个产品,评审产品，而不是生产者,语音轻柔，问问题而不是指责,坚守评审日程,提出问题，而不是解决他们,避免讨论其他问题坚持技术正确性,有计划的评审,记录以及上报所有评审结果,1.,2.,3.,4.,5.,6.,7.,8.,评审选项矩阵,These courseware materials are to be used in