《软件工程-实践者的研究方法》_评审技术ppt课件

1、第十二章n评审技术评审技术Slide Set to accompanySoftware Engineering: A Practitioners Approach, 7/e by Roger S. PressmanSlides copyright 1996, 2001, 2005, 2021 by Roger S. PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunction with Softw

2、are 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.评审 什么是评审?n由技术人员指点，并面向技术人员的一个会议n在软件工程过程中，对一个任务产品的技术评价n一种软件质量保证

3、机制n一个培训园地 评审不是n工程总结和进度评价 n一个信息发布会议 n对人员的评价 What 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 v

4、ery different economic, business, psychological, and human impactnHowever, the temporal distinction made between errors and defects in this book is not mainstream thinking软件缺陷对本钱的影响v在软件过程的环境中，术语缺陷(defect)和缺点(fault)是同义词，两者都是指在软件发布给最终用户(或软件过程内其他框架活动)后发现的质量问题。v术语错误(error)来描画在在软件发布给最终用户(或软件过程内其他框架活动)之前软

5、件工程师(或其他人)发现的质量问题。v正式技术评审的主要目的是在软件过程中发现错误，以使它们不会在软件交付之后变成缺陷(fault) 正式技术评审最明显的优点就是可以早些发现错误，以防止将错误传送到软件过程的后续阶段。缺陷放大和消除n可以用“缺陷放大模型来阐明在软件工程过程的设计和编码活动中错误的产生和检测。该模型如以下图所示：Errors passed throughAmplified errors 1:xNewly generated errorsDevelopment stepErrors fromPrevious stepErrors passed To next stepDefect

6、sDetectionPercentEfficiencyDefect 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 stepErro

7、rs fromPrevious stepErrors passed To next stepDefectsDetectionPercentEfficiencyDefect AmplificationnIn the example provided in SEPA, Section 15.2, na software process that does NOT include reviews,nyields 94 errors at the beginning of testing andnReleases 12 latent defects to the fieldna software pr

8、ocess that does include reviews,nyields 24 errors at the beginning of testing andnreleases 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 ac

9、count评审度量及其运用v软件工程组织要定义一套可以用来评价其任务效率的度量来了解每项活动的有效性。v可以为所进展的每项评审搜集以下评审度量数据：v预备任务量Ep在实践评审会议之前评审一个任务产品所需的任务量单位：人时。v评价任务量Ea实践评审任务中所破费的任务量(单位：人时)。v返工任务量Er修正评审期间发现的错误所用的任务量(单位：人时)。v任务产品规模WPS被评审的任务产品规模的衡量(例如UML模型的数量、文档的页数或代码行数)。v发现的次要错误Errminor发现的可以归为次要错误的数量要求少于预定的改错任务量。v发现的主要错误Errmajor发现的可以归为主要错误的数量要求多于预定

10、的改错任务量。v经过将所评审的任务产品类型与所搜集的度量数据相关联，这些度量数据可以进一步细化。MetricsnPreparation 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 (

11、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

12、, 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)An ExampleInIf past hist

13、ory 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 errors during the review of the document. nIf you find only 6 errors, youve done an

14、 extremely good job in developing the requirements model or your review approach was not thorough enough.An ExampleIInThe effort required to correct a minor model error (immediately after the review) was found to require 4 person-hours. nThe effort required for a major requirement error was found to

15、 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 error during review is about 6 person-hours. nRequirements related error

16、s 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 the review of the requirements model, a saving of about 660 person-hours

17、of testing effort would be achieved. And thats just for requirements-related errors.评审的本钱效益n有评审和没有评审时破费的任务量with reviews参考模型非正式评审n非正式评审包括:n与同事就软件工程产品进展的简单桌面检查n以评审一个任务产品为目的的暂时会议n结对编程评审n两人一同任务和分享思想共同处理复杂的软件开发。他们不断进展检查彼此的产品，从而以最有效的方式尽早去除缺陷。n假设作为结对编程的结果消费出的任务产品的质量明显优于单个人的任务，在质量方面的节约，足以弥补结对编程带来的“冗余。Inform

18、al ReviewsnInformal reviews include:na simple desk check of a software engineering work product with a colleaguena casual meeting (involving more than 2 people) for the purpose of reviewing a work product, or nthe review-oriented aspects of pair programmingnpair programming encourages continuous rev

19、iew as a work product (design or code) is created. nThe benefit is immediate discovery of errors and better work product quality as a consequence.正式技术评审n正式技术评审FTR是一种由软件工程师(以及其他人)进展的软件质量控制活动。FTR的目的是：n发现软件的任何一种表示方式中的功能、逻辑或实现上的错误；n验证评审中的软件能否满足其需求；n保证软件的表示符合预先指定的规范；n获得以一致的方式开发的软件；n使工程更易于管理。nFTR实践上是一类评审方

20、式，包括走查(walkthrough)和审查(inspection)。每次FTR都是以会议方式进展的，只需经过适当的方案、控制和参与，FTR才干获得胜利。Formal Technical ReviewsnThe objectives of an FTR are: nto uncover errors in function, logic, or implementation for any representation of the softwarento verify that the software under review meets its requirementsnto ensur

21、e that the software has been represented according to predefined standardsnto achieve software that is developed in a uniform mannernto make projects more manageablenThe FTR is actually a class of reviews that includes walkthroughs and inspections.评审会议n评审会通常应该由3-5人参与n应该提早进展预备，但是占用每人的任务时间应该不超越2小时n评审会

22、的时间应该少于2小时nFTR应该关注的是整个软件中的某个特定部分例如：只走查各个构建或者一小部分构建，不要试图评审整个设计The Review MeetingnBetween three and five people (typically) should be involved in the review.nAdvance preparation should occur but should require no more than two hours of work for each person.nThe duration of the review meeting should be

23、 less than two hours.nFocus is on a work product (e.g., a portion of a requirements model, a detailed component design, source code for a component)参与人员The PlayersnProducerthe individual who has developed the work productninforms the project leader that the work product is complete and that a review

24、 is requirednReview leaderevaluates the product for readiness, generates copies of product materials, and distributes them to two or three reviewers for advance preparation.nReviewer(s)expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar wi

25、th the work.nRecorderreviewer who records (in writing) all important issues raised during the review. 评审会议参与人员n评审会议由评审会主席、一切评审员和开发人员参与。其中一位评审员还充任记录员的角色，担任记录在评审过程中发现的一切重要问题。FTR普通从引见会议日程并由开发人员做简单的引见开场。然后由开发人员“走查该任务产品，并对资料做出解释，而评审员那么根据预先的预备提出问题。当发现了明确的问题或错误时，记录员逐一加以记录。评审指点原那么n评审任务产品，而不是评审开发人员。n制定并遵守日程表。n限制争论和辩驳。n要阐明问题，但是不要试图处理一切记录的问题。n做笔记。n限制参与者人数。n为每个将要评审的任务产品建立