软件工程讲义第十二章 评审技术知识

1、单击此处编辑母版标题样式单击此处编辑母版文本样式第二级第三级第四级第五级*单击此处编辑母版标题样式单击此处编辑母版文本样式第二级第三级第四级第五级*软件工程 第十二章 评审技术评审技术技术评审是在软件过程早期查错最有效的机制。如果在软件过程的早期发现错误，修改的成本就较少。另外，随着软件过程的推进，错误会随之放大，因此，过程早期留下的没有处理的小错误，可能在项目后期放大成一组严重的错误。最后，通过减少项目后期所需的返工，评审节省了时间。评审技术评审一般分为6个步骤：计划、准备、组织会议、记录错误、进行修改（评审之后做）、验证是否恰当地进行了修改。评审的输出是发现问题和（或）错误的清单。另外，还

2、标示出工作产品的技术状态。评审技术 软件评审是软件过程中的“过滤器”。也就是说，在软件工程过程的不同阶段进行软件评审，可以起到发现错误和缺陷，进而消除它们的作用。软件评审还能够“净化”需求模型、设计模型、源代码和测试数据等软件工程工作产品。评审技术评审（任何评审）是使用人群之间的差异达到以下目的： 1.指出个人或团队的产品中需要改进的地方； 2.确认产品中不期望或不需要改进的部分； 3.与没有评审相比，得到质量更统一或至少更可预测的技术工作，以使技术工作更加可管理。软件缺陷对成本的影响在软件过程的环境中，术语缺陷(defect)和故障(fault)是同义词，两者都是指在软件发布给最终用户(或软

3、件过程内其他框架活动)后发现的质量问题。术语错误(error)来描绘在在软件发布给最终用户(或软件过程内其他框架活动)之前软件工程师(或其他人)发现的质量问题。缺陷放大模型图12-1 缺陷放大模型实例：缺陷放大无评审图12-2 缺陷放大无评审实例：缺陷放大有评审图12-3 缺陷放大有评审评审度量及其应用软件工程组织要定义一套可以用来评估其工作效率的度量来理解每项活动的有效性。可以为所进行的每项评审收集以下评审度量数据：准备工作量Ep在实际评审会议之前评审一个工作产品所需的工作量（单位：人时）。评估工作量Ea实际评审工作中所花费的工作量(单位：人时)。返工工作量Er修改评审期间发现的错误所用的工

4、作量(单位：人时)。工作产品规模WPS被评审的工作产品规模的衡量(例如UML模型的数量、文档的页数或代码行数)。发现的次要错误Errminor发现的可以归为次要错误的数量（要求少于预定的改错工作量）。发现的主要错误Errmajor发现的可以归为主要错误的数量（要求多于预定的改错工作量）。通过将所评审的工作产品类型与所收集的度量数据相关联，这些度量数据可以进一步细化。分析度量数据总评审工作量Ereview和发现的错误总数Errtot定义为: Ereview=Ep+Ea+Er Errtot=Errminor+Errmajor错误密度表示评审的每单位工作产品发现的错误数。 错误密度=Errtot/W

5、PS分析度量数据如果是对一些不同类型的工作产品（如需求模型、设计模型、代码、测试用例）进行评审，可以通过所有评审所发现的错误总数来计算每次评审发现的错误百分比。此外，也可以计算每个工作产品的错误密度。在为多个项目收集到许多评审数据后便可利用其错误密度的平均值估计一个新的项目中将发现的错误数。在进行了测试之后，有可能收集到另外一些错误数据，包括在测试期间发现和纠正错误所需要的工作量，以及软件的错误密度。可以将测试期间发现和纠正错误的相关成本与评审期间的相比较。评审的成本效益若要实时地测量任何技术评审的成本效益都是困难的。只有在评审工作已经完成，已收集了评审数据，计算了平均数据，并测量了软件的下游

6、质量（通过测试）之后，软件工程组织才能够对评审的有效性和成本效益进行评估。课本实例评审的成本效益Wie02在他的有关同行评审的书中讨论了从大公司得到的传闻数据，这些大公司已经使用审查（一种比较正式的技术评审）作为软件质量控制活动的一部分。HP称审查有10:1的投资回报率，并指出实际产品交付时间平均提前了月。AT&T公司表示，审查使软件错误总成本降低到原来的十分之一，质量提高了一个数量级，而且生产率提高了14%。技术评审(为设计和其他技术活动)提供了明显的成本效益，并且确实节省了时间。对软件评审行业数据的收集已有20多年，如图12-4所示。评审的成本效益图12-4 有评审和没有评审时花费的工作量

7、评审：正式程度应该以某种正式程度应用技术评审，该正式程度应该适合所生产的产品、项目的时间线和做评审工作的人。图12-5描述了技术评审的参考模型，该模型中的4个特性有助于决定进行评审的形式。参考模型的每个特性有助于确定评审的正式程度。评审的正式度提高需当：(1)明确界定每位评审人员的不同职责(2)为评审进行充分的计划和准备，(3)为评审定义了清晰的结构（包括任务和内部工作产品），以及(4)评审人员对所做修改的后续跟踪。技术评审参考模型图12-5 技术评审参考模型非正式评审非正式评审包括与同事就软件工程产品进行的简单桌面检查，以评审一个工作产品为目的的临时会议，或结对编程评审。与同事进行的简单桌面

8、检查或临时会议是一种评审。但是，因为没有事先规划或筹备工作，没有会议的议程或结构，没有对发现的错误进行后续的跟踪处理，这种评审的有效性大大低于更为正式的方法。非正式评审提高桌面检查评审效能的一种方法是为软件团队的每个主要的工作产品制定一组简单评审检查单。检查单中提出的问题都是常见问题，但有助于指导评审人员检查工作产品。评审人员指出的任何错误和问题由设计人员记录下来以在稍后的时间进行解决。桌面检查可以以一个特别的方式安排，或者也可以授权作为良好的软件工程实践的一部分。一般来说，桌面检查评审材料的数量相对较少，总体上花费时间大致在一两个小时。非正式评审结对编程是一种强大的技术，可以有效创造高品质的

9、软件产品。两人一起工作和分享思想共同解决复杂的软件开发。他们不断进行检查彼此的产品，从而以最有效的形式尽早去除缺陷。此外，他们彼此一心一意专注于手头的任务。如果作为结对编程的结果生产出的工作产品的质量明显优于单个人的工作，在质量方面的节约，足以弥补结对编程带来的“冗余”。正式技术评审正式技术评审（FTR）是一种由软件工程师(以及其他人)进行的软件质量控制活动。FTR的目标是:(1)发现软件的任何一种表示形式中的功能、逻辑或实现上的错误；(2)验证评审中的软件是否满足其需求；(3)保证软件的表示符合预先指定的标准；(4)获得以统一的方式开发的软件；(5)使项目更易于管理。FTR实际上是一类评审方

10、式，包括走查(walkthrough)和审查(inspection)。每次FTR都是以会议形式进行的，只有经过适当的计划、控制和参与，FTR才能获得成功。评审会议FTR关注的是某个工作产品。开发这个工作产品的个人(生产者)通知项目负责人“该工作产品已经完成，需要进行评审”。项目负责人与评审主席取得联系，由评审主席负责评估该工作产品是否准备就绪，制作产品材料副本，并将这些副本分发给2到3位评审员以便事先做准备。每位评审员应该用1到2个小时来评审该工作产品，通过做笔记或者其他方法熟悉该工作产品。同时，评审会主席也应该评审该工作产品，并制定评审会议的日程表，通常会安排在第二天开会。评审会议评审会议由

11、评审会主席、所有评审员和开发人员参加。其中一位评审员还充当记录员的角色，负责记录在评审过程中发现的所有重要问题。FTR一般从介绍会议日程并由开发人员做简单的介绍开始。然后由开发人员“走查”该工作产品，并对材料做出解释，而评审员则根据预先的准备提出问题。当发现了明确的问题或错误时，记录员逐一加以记录。评审会议在评审结束时，所有FTR与会者必须做出以下决定中的一个：(1)可以不经修改而接受该工作产品；(2)由于严重错误而否决该工作产品(错误改正后必须再次进行评审)；(3)暂时接受该工作产品(发现了一些必须改正的小错误，但是不再需要进行评审)。做出决定之后，所有FTR与会者都需要签名，以表示他们参加

12、了此次FTR，并且同意评审小组所做的决定。评审报告和记录保存在评审会议结束时，要生成一份“评审问题清单”。此外，还要完成一份“正式技术评审总结报告”。评审总结报告中要回答以下3个问题： 1.评审的产品是什么？ 2.谁参与了评审？ 3.发现的问题和结论是什么?评审总结报告通常只是一页纸的形式。它是项目历史记录的一部分，有可能将其分发给项目负责人和其他感兴趣的参与方。评审报告和记录保存评审问题清单有两个作用：(1)标识产品中存在问题的区域；(2)作为行动条目检查单以指导开发人员进行改正。通常将评审问题清单附在总结报告的后面。为了保证评审问题清单中的每一条都得到适当的改正，建立跟踪规程非常重要。只有

13、做到这一点，才能保证提出的问题真正得到“解决”。方法之一就是将跟踪的责任指派给评审会主席。评审指导原则评审工作产品，而不是评审开发人员。制定并遵守日程表。限制争论和辩驳。要阐明问题，但是不要试图解决所有记录的问题。做笔记。限制参与者人数。为每个将要评审的工作产品建立检查清单。为FTR分配资源和时间。对所有评审员进行有意义的培训。评审以前所做的评审。样本驱动评审在理想情况下，每个软件工程工作产品都要经过正式技术评审。但在实际的软件项目中，由于资源有限和时间不足，评审常常被省略。The01提出了样本驱动评审过程，在这个过程中，要对所有软件工程工作产品的样本进行审查，以决定哪些工作产品是最有错误倾向的，然后集中全部FTR资源，（根据抽样过程中收集的数据）只分配给那些可能具有错误倾向的工作产品。样本驱动