软件工程讲义第十二章评审技术摘要.ppt

样本驱动评审 在理想情况下，每个软件工程工作产品都要经过正式技术评审。但在实际的软件项目中，由于资源有限和时间不足，评审常常被省略。 [The01]提出了样本驱动评审过程，在这个过程中，要对所有软件工程工作产品的样本进行审查，以决定哪些工作产品是最有错误倾向的，然后集中全部FTR资源，（根据抽样过程中收集的数据）只分配给那些可能具有错误倾向的工作产品。 样本驱动评审 为了提高效率，样本驱动评审过程必须对作为整个FTR的主要目标的那些工作产品进行量化。量化时一般采用以下步骤： 1.审查每个软件工作产品i的若干分之一，记做ai，记录在其中发现的缺陷数量fi。 2.用fi除以ai可得到在工作产品i中缺陷数量的粗略估算值。 3.按照缺陷数量粗略估算值的递减次序排列这些工作产品。 4.将现有的评审资源集中到那些具有最高缺陷数量估算值的工作产品上。 小结 作业 P236 3,4,5,10 软件工程 第十二章 评审技术 评审技术 技术评审是在软件过程早期查错最有效的机制。 如果在软件过程的早期发现错误，修改的成本就较少。另外，随着软件过程的推进，错误会随之放大，因此，过程早期留下的没有处理的小错误，可能在项目后期放大成一组严重的错误。最后，通过减少项目后期所需的返工，评审节省了时间。 评审技术 评审一般分为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+Er