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

软件工程

第十二章评审技术评审技术技术评审是在软件过程早期查错最有效的机制。如果在软件过程的早期发现错误，修改的成本就较少。另外，随着软件过程的推进，错误会随之放大，因此，过程早期留下的没有处理的小错误，可能在项目后期放大成一组严重的错误。最后，通过减少项目后期所需的返工，评审节省了时间。评审技术评审一般分为6个步骤：计划、准备、组织会议、记录错误、进行修改（评审之后做）、验证是否恰当地进行了修改。评审的输出是发现问题和（或）错误的清单。另外，还标示出工作产品的技术状态。评审技术软件评审是软件过程中的“过滤器”。也就是说，在软件工程过程的不同阶段进行软件评审，可以起到发现错误和缺陷，进而消除它们的作用。软件评审还能够“净化”需求模型、设计模型、源代码和测试数据等软件工程工作产品。评审技术评审（任何评审）是使用人群之间的差异达到以下目的：

1.指出个人或团队的产品中需要改进的地方；

2.确认产品中不期望或不需要改进的部分；

3.与没有评审相比，得到质量更统一或至少更可预测的技术工作，以使技术工作更加可管理。软件缺陷对成本的影响在软件过程的环境中，术语缺陷(defect)和故障(fault)是同义词，两者都是指在软件发布给最终用户(或软件过程内其他框架活动)后发现的质量问题。术语错误(error)来描绘在在软件发布给最终用户(或软件过程内其他框架活动)之前软件工程师(或其他人)发现的质量问题。软件缺陷对成本的影响正式技术评审的主要目标是在软件过程中发现错误，以使它们不会在软件交付之后变成缺陷。正式技术评审最明显的优点就是可以早些发现错误，以防止将错误传递到软件过程的后续阶段。产业界的大量研究表明：设计活动引入的错误占软件过程中出现的所有错误(和最终的所有缺陷)数量的50%~65%。已经证明，评审技术在发现设计缺陷方面高达75%有效。通过检测和消除大量设计错误，评审过程将极大降低软件过程后续活动的成本。缺陷放大和消除可以用“缺陷放大模型”来说明在软件工程过程的设计和编码活动中错误的产生和检测。该模型如图12-1所示，其中方框表示软件工程活动。在该活动中，可能由于疏忽产生错误，评审可能没有发现新产生的错误以及来自前面步骤的错误，从而导致一定数量的错误通过了当前步骤。在某些情况下，从前面步骤传过来的错误在当前步骤中会被放大（放大倍数为x）。将开发步骤方框进一步细分可以说明这些特点及错误检测的有效性百分比，错误检测的有效性百分比是评审完善性的函数。缺陷放大模型图12-1缺陷放大模型实例：缺陷放大——无评审图12-2缺陷放大——无评审实例：缺陷放大——有评审图12-3缺陷放大——有评审评审度量及其应用软件工程组织要定义一套可以用来评估其工作效率的度量来理解每项活动的有效性。可以为所进行的每项评审收集以下评审度量数据：准备工作量Ep——在实际评审会议之前评审一个工作产品所需的工作量（单位：人时）。评估工作量Ea——实际评审工作中所花费的工作量(单位：人时)。返工工作量Er——修改评审期间发现的错误所用的工作量(单位：人时)。工作产品规模WPS——被评审的工作产品规模的衡量(例如UML模型的数量、文档的页数或代码行数)。发现的次要错误Errminor——发现的可以归为次要错误的数量（要求少于预定的改错工作量）。发现的主要错误Errmajor——发现的可以归为主要错误的数量（要求多于预定的改错工作量）。通过将所评审的工作产品类型与所收集的度量数据相关联，这些度量数据可以进一步细化。分析度量数据总评审工作量Ereview和发现的错误总数Errtot定义为:

Ereview=Ep+Ea+Er

Errtot=Errminor+Errmajor错误密度表示评审的每单位工作产品发现的错误数。

错误密度=Errtot/WPS分析度量数据如果是对一些不同类型的工作产品（如需求模型、设计模型、代码、测试用例）进行评审，可以通过所有评审所发现的错误总数来计算每次评审发现的错误百分比。此外，也可以计算每个工作产品的错误密度。在为多个项目收集到许多评审数据后便可利用其错误密度的平均值估计一个新的项目中将发现的错误数。在进行了测试之后，有可能收集到另外一些错误数据，包括在测试期间发现和纠正错误所需要的工作量，以及软件的错误密度。可以将测试期间发现和纠正错误的相关成本与评审期间的相比较。评审的成本效益若要实时地测量任何技术评审的成本效益都是困难的。只有在评审工作已经完成，已收集了评审数据，计算了平均数据，并测量了软件的下游质量（通过测试）之后，软件工程组织才能够对评审的有效性和成本效益进行评估。课本实例评审的成本效益[Wie02]在他的有关同行评审的书中讨论了从大公司得到的传闻数据，这些大公司已经使用审查（一种比较正式的技术评审）作为软件质量控制活动的一部分。HP称审查有10:1的投资回报率，并指出实际产品交付时间平均提前了1.8月。AT&T公司表示，审查使软件错误总成本降低到原来的十分之一，质量提高了一个数量级，而且生产率提高了14%。技术评审(为设计和其他技术活动)提供了明显的成本效益，并且确实节省了时间。对软件评审行业数据的收集已有20多年，如图12-4所示。评审的成本效益图12-4有评审和没有评审时花费的工作量评审：正式程度应该以某种正式程度应用技术评审，该正式程度应该适合所生产的产品、项目的时间线和做评审工作的人。图12-5描述了技术评审的参考模型，该模型中的4个特性有助于决定进行评审的形式。参考模型的每个特性有助于确定评审的正式程度。评审的正式度提高需当：(1)明确界定每位评审人员的不同职责(2)为评审进行充分的计划和准备，(3)为评审定义了清晰的结构（包括任务和内部工作产品），以及(4)评审人员对所做修改的后续跟踪。技术评审参考模型图12-5技术评审参考模型非正式评审非正式评审包括与同事就软件工程产品进行的简单桌面检查，以评审一个工作产品为目的的临时会议，或结对编程评审。与同事进行的简单桌面检查或临时会议是一种评审。但是，因为没有事先规划或筹备工作，没有会议的议程或结构，没有对发现的错误进行后续的跟踪处理，这种评审的有效性大大低于更为正式的方法。非正式评审提高桌面检查评审效能的一种方法是为软件团队的每个主要的工作产品制定一组简单评审检查单。检查单中提出的问题都是常见问题，但有助于指导评审人员检查工作产品。评审人员指出的任何错误和问题由设计人员记录下来以在稍后的时间进行解决。桌面检查可以以一个特别的方式安排，或者也可以授权作为良好的软件工程实践的一部分。一般来说，桌面检查评审材料的数量相对较少，总体上花费时间大致在一两个小时。非正式评审结对编程是一种强大的技术，可以有效创造高品质的软件产品。两人一起工作和分享思想共同解决复杂的软件开发。他们不断进行检查彼此的产品，从而以最有效的形式尽早去除缺陷。此外，他们彼此一心一意专注于手头的任务。如果作为结对编程的结果生产出的工作产品的质量明显优于单个人的工作，在质量方面的节约，足以弥补结对编程带来的“冗余”。正式技术评审正式技术评审（FTR）是一种由软件工程师(以及其他人)进行的软件质量控制活动。FTR的目标是:(1)发现软件的任何一种表示形式中的功能、逻辑或实现上的错误；(2)