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

1、软件工程 第十二章 评审技术评审技术v技术评审是在软件过程早期查错最有效的技术评审是在软件过程早期查错最有效的机制。机制。v如果在软件过程的早期发现错误，修改的如果在软件过程的早期发现错误，修改的成本就较少。另外，随着软件过程的推进，成本就较少。另外，随着软件过程的推进，错误会随之放大，因此，过程早期留下的错误会随之放大，因此，过程早期留下的没有处理的小错误，可能在项目后期放大没有处理的小错误，可能在项目后期放大成一组严重的错误。最后，通过减少项目成一组严重的错误。最后，通过减少项目后期所需的返工，评审节省了时间。后期所需的返工，评审节省了时间。评审技术v评审一般分为评审一般分为6个步骤：计划

2、、准备、组个步骤：计划、准备、组织会议、记录错误、进行修改（评审之后织会议、记录错误、进行修改（评审之后做）、验证是否恰当地进行了修改。做）、验证是否恰当地进行了修改。v评审的输出是发现问题和（或）错误的清评审的输出是发现问题和（或）错误的清单。另外，还标示出工作产品的技术状态。单。另外，还标示出工作产品的技术状态。评审技术v 软件评审是软件过程中的软件评审是软件过程中的“过滤器过滤器”。也就是说，在软件工程过程的不同阶段进也就是说，在软件工程过程的不同阶段进行软件评审，可以起到发现错误和缺陷，行软件评审，可以起到发现错误和缺陷，进而消除它们的作用。软件评审还能够进而消除它们的作用。软件评审还

3、能够“净化净化”需求模型、设计模型、源代码和需求模型、设计模型、源代码和测试数据等软件工程工作产品。测试数据等软件工程工作产品。评审技术v评审（任何评审）是使用人群之间的差异评审（任何评审）是使用人群之间的差异达到以下目的：达到以下目的： 1.指出个人或团队的产品中需要改进的地指出个人或团队的产品中需要改进的地方；方； 2.确认产品中不期望或不需要改进的部分；确认产品中不期望或不需要改进的部分； 3.与没有评审相比，得到质量更统一或至与没有评审相比，得到质量更统一或至少更可预测的技术工作，以使技术工作更少更可预测的技术工作，以使技术工作更加可管理。加可管理。软件缺陷对成本的影响v在软件过程的环

4、境中，术语缺陷在软件过程的环境中，术语缺陷(defect)和故障和故障(fault)是同义词，两者都是指在软是同义词，两者都是指在软件发布给最终用户件发布给最终用户(或软件过程内其他框或软件过程内其他框架活动架活动)后发现的质量问题。术语错误后发现的质量问题。术语错误(error)来描绘在在软件发布给最终用户来描绘在在软件发布给最终用户(或软件过程内其他框架活动或软件过程内其他框架活动)之前软件工之前软件工程师程师(或其他人或其他人)发现的质量问题。发现的质量问题。软件缺陷对成本的影响v正式技术评审的主要目标是在软件过程中发现错正式技术评审的主要目标是在软件过程中发现错误，以使它们不会在软件交

5、付之后变成缺陷。正误，以使它们不会在软件交付之后变成缺陷。正式技术评审最明显的优点就是可以早些发现错误，式技术评审最明显的优点就是可以早些发现错误，以防止将错误传递到软件过程的后续阶段。以防止将错误传递到软件过程的后续阶段。v产业界的大量研究表明：设计活动引入的错误占产业界的大量研究表明：设计活动引入的错误占软件过程中出现的所有错误软件过程中出现的所有错误(和最终的所有缺陷和最终的所有缺陷)数数量的量的50%65%。已经证明，评审技术在发现设。已经证明，评审技术在发现设计缺陷方面高达计缺陷方面高达75%有效。通过检测和消除大量有效。通过检测和消除大量设计错误，评审过程将极大降低软件过程后续活设

6、计错误，评审过程将极大降低软件过程后续活动的成本。动的成本。缺陷放大和消除v可以用可以用“缺陷放大模型缺陷放大模型”来说明在软件工程过来说明在软件工程过程的设计和编码活动中错误的产生和检测。该程的设计和编码活动中错误的产生和检测。该模型如图模型如图12-1所示，其中方框表示软件工程活所示，其中方框表示软件工程活动。在该活动中，可能由于疏忽产生错误，评动。在该活动中，可能由于疏忽产生错误，评审可能没有发现新产生的错误以及来自前面步审可能没有发现新产生的错误以及来自前面步骤的错误，从而导致一定数量的错误通过了当骤的错误，从而导致一定数量的错误通过了当前步骤。在某些情况下，从前面步骤传过来的前步骤。

7、在某些情况下，从前面步骤传过来的错误在当前步骤中会被放大（放大倍数为错误在当前步骤中会被放大（放大倍数为x）。）。将开发步骤方框进一步细分可以说明这些特点将开发步骤方框进一步细分可以说明这些特点及错误检测的有效性百分比，错误检测的有效及错误检测的有效性百分比，错误检测的有效性百分比是评审完善性的函数。性百分比是评审完善性的函数。缺陷放大模型图12-1 缺陷放大模型实例：缺陷放大无评审图12-2 缺陷放大无评审实例：缺陷放大有评审图12-3 缺陷放大有评审评审度量及其应用v软件工程组织要定义一套可以用来评估其工作效率的度软件工程组织要定义一套可以用来评估其工作效率的度量来理解每项活动的有效性。量

8、来理解每项活动的有效性。v可以为所进行的每项评审收集以下评审度量数据：可以为所进行的每项评审收集以下评审度量数据：v准备工作量准备工作量Ep在实际评审会议之前评审一个工作产品所需的工在实际评审会议之前评审一个工作产品所需的工作量（单位：人时）。作量（单位：人时）。v评估工作量评估工作量Ea实际评审工作中所花费的工作量实际评审工作中所花费的工作量(单位：人时单位：人时)。v返工工作量返工工作量Er修改评审期间发现的错误所用的工作量修改评审期间发现的错误所用的工作量(单位：人单位：人时时)。v工作产品规模工作产品规模WPS被评审的工作产品规模的衡量被评审的工作产品规模的衡量(例如例如UML模型模型

9、的数量、文档的页数或代码行数的数量、文档的页数或代码行数)。v发现的次要错误发现的次要错误Errminor发现的可以归为次要错误的数量（要求发现的可以归为次要错误的数量（要求少于预定的改错工作量）。少于预定的改错工作量）。v发现的主要错误发现的主要错误Errmajor发现的可以归为主要错误的数量（要求发现的可以归为主要错误的数量（要求多于预定的改错工作量）。多于预定的改错工作量）。v通过将所评审的工作产品类型与所收集的度量数据相关联，这些度通过将所评审的工作产品类型与所收集的度量数据相关联，这些度量数据可以进一步细化。量数据可以进一步细化。分析度量数据v总评审工作量总评审工作量Ereview和

10、发现的错误总数和发现的错误总数Errtot定义为定义为: Ereview=Ep+Ea+Er Errtot=Errminor+Errmajorv错误密度表示评审的每单位工作产品发现错误密度表示评审的每单位工作产品发现的错误数。的错误数。 错误密度错误密度=Errtot/WPS分析度量数据v如果是对一些不同类型的工作产品（如需求模如果是对一些不同类型的工作产品（如需求模型、设计模型、代码、测试用例）进行评审，型、设计模型、代码、测试用例）进行评审，可以通过所有评审所发现的错误总数来计算每可以通过所有评审所发现的错误总数来计算每次评审发现的错误百分比。此外，也可以计算次评审发现的错误百分比。此外，也

11、可以计算每个工作产品的错误密度。每个工作产品的错误密度。v在为多个项目收集到许多评审数据后便可利用在为多个项目收集到许多评审数据后便可利用其错误密度的平均值估计一个新的项目中将发其错误密度的平均值估计一个新的项目中将发现的错误数。现的错误数。v在进行了测试之后，有可能收集到另外一些错在进行了测试之后，有可能收集到另外一些错误数据，包括在测试期间发现和纠正错误所需误数据，包括在测试期间发现和纠正错误所需要的工作量，以及软件的错误密度。可以将测要的工作量，以及软件的错误密度。可以将测试期间发现和纠正错误的相关成本与评审期间试期间发现和纠正错误的相关成本与评审期间的相比较。的相比较。评审的成本效益v

12、若要实时地测量任何技术评审的成本效益若要实时地测量任何技术评审的成本效益都是困难的。只有在评审工作已经完成，都是困难的。只有在评审工作已经完成，已收集了评审数据，计算了平均数据，并已收集了评审数据，计算了平均数据，并测量了软件的下游质量（通过测试）之后，测量了软件的下游质量（通过测试）之后，软件工程组织才能够对评审的有效性和成软件工程组织才能够对评审的有效性和成本效益进行评估。本效益进行评估。v课本实例课本实例评审的成本效益vWie02在他的有关同行评审的书中讨论了从在他的有关同行评审的书中讨论了从大公司得到的传闻数据，这些大公司已经使用大公司得到的传闻数据，这些大公司已经使用审查审查（一种比

13、较正式的技术评审）作为软件质（一种比较正式的技术评审）作为软件质量控制活动的一部分。量控制活动的一部分。HP称审查有称审查有10:1的投资的投资回报率，并指出实际产品交付时间平均提前了回报率，并指出实际产品交付时间平均提前了1.8月。月。AT&T公司表示，审查使软件错误总成公司表示，审查使软件错误总成本降低到原来的十分之一，质量提高了一个数本降低到原来的十分之一，质量提高了一个数量级，而且生产率提高了量级，而且生产率提高了14%。技术评审。技术评审(为设为设计和其他技术活动计和其他技术活动)提供了明显的成本效益，并提供了明显的成本效益，并且确实节省了时间。且确实节省了时间。v对软件评审

14、行业数据的收集已有对软件评审行业数据的收集已有20多年，如图多年，如图12-4所示。所示。评审的成本效益图12-4 有评审和没有评审时花费的工作量评审：正式程度v应该以某种正式程度应用技术评审，该正式程应该以某种正式程度应用技术评审，该正式程度应该适合所生产的产品、项目的时间线和做度应该适合所生产的产品、项目的时间线和做评审工作的人。图评审工作的人。图12-5描述了技术评审的参考描述了技术评审的参考模型，该模型中的模型，该模型中的4个特性有助于决定进行评审个特性有助于决定进行评审的形式。的形式。v参考模型的每个特性有助于确定评审的正式程参考模型的每个特性有助于确定评审的正式程度。评审的正式度提

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

16、编程评审。v与同事进行的简单桌面检查或临时会议是与同事进行的简单桌面检查或临时会议是一种评审。但是，因为没有事先规划或筹一种评审。但是，因为没有事先规划或筹备工作，没有会议的议程或结构，没有对备工作，没有会议的议程或结构，没有对发现的错误进行后续的跟踪处理，这种评发现的错误进行后续的跟踪处理，这种评审的有效性大大低于更为正式的方法。审的有效性大大低于更为正式的方法。非正式评审v提高桌面检查评审效能的一种方法是为软件团提高桌面检查评审效能的一种方法是为软件团队的每个主要的工作产品制定一组简单评审检队的每个主要的工作产品制定一组简单评审检查单。检查单中提出的问题都是常见问题，但查单。检查单中提出的

17、问题都是常见问题，但有助于指导评审人员检查工作产品。有助于指导评审人员检查工作产品。v评审人员指出的任何错误和问题由设计人员记评审人员指出的任何错误和问题由设计人员记录下来以在稍后的时间进行解决。桌面检查可录下来以在稍后的时间进行解决。桌面检查可以以一个特别的方式安排，或者也可以授权作以以一个特别的方式安排，或者也可以授权作为良好的软件工程实践的一部分。一般来说，为良好的软件工程实践的一部分。一般来说，桌面检查评审材料的数量相对较少，总体上花桌面检查评审材料的数量相对较少，总体上花费时间大致在一两个小时。费时间大致在一两个小时。非正式评审v结对编程是一种强大的技术，可以有效创结对编程是一种强大

18、的技术，可以有效创造高品质的软件产品。两人一起工作和分造高品质的软件产品。两人一起工作和分享思想共同解决复杂的软件开发。他们不享思想共同解决复杂的软件开发。他们不断进行检查彼此的产品，从而以最有效的断进行检查彼此的产品，从而以最有效的形式尽早去除缺陷。此外，他们彼此一心形式尽早去除缺陷。此外，他们彼此一心一意专注于手头的任务。一意专注于手头的任务。v如果作为结对编程的结果生产出的工作产如果作为结对编程的结果生产出的工作产品的质量明显优于单个人的工作，在质量品的质量明显优于单个人的工作，在质量方面的节约，足以弥补结对编程带来的方面的节约，足以弥补结对编程带来的“冗余冗余”。正式技术评审v正式技术

19、评审（正式技术评审（FTR）是一种由软件工程师）是一种由软件工程师(以以及其他人及其他人)进行的软件质量控制活动。进行的软件质量控制活动。FTR的目的目标是标是:(1)发现软件的任何一种表示形式中的功能、发现软件的任何一种表示形式中的功能、逻辑或实现上的错误；逻辑或实现上的错误；(2)验证评审中的软件是验证评审中的软件是否满足其需求；否满足其需求；(3)保证软件的表示符合预先指保证软件的表示符合预先指定的标准；定的标准；(4)获得以统一的方式开发的软件；获得以统一的方式开发的软件；(5)使项目更易于管理。使项目更易于管理。vFTR实际上是一类评审方式，包括走查实际上是一类评审方式，包括走查(w

20、alkthrough)和审查和审查(inspection)。每次。每次FTR都是以会议形式进行的，只有经过适当的计都是以会议形式进行的，只有经过适当的计划、控制和参与，划、控制和参与，FTR才能获得成功。才能获得成功。评审会议vFTR关注的是某个工作产品。开发这个工作产关注的是某个工作产品。开发这个工作产品的个人品的个人(生产者生产者)通知项目负责人通知项目负责人“该工作产品该工作产品已经完成，需要进行评审已经完成，需要进行评审”。项目负责人与评。项目负责人与评审主席取得联系，由评审主席负责评估该工作审主席取得联系，由评审主席负责评估该工作产品是否准备就绪，制作产品材料副本，并将产品是否准备就

21、绪，制作产品材料副本，并将这些副本分发给这些副本分发给2到到3位评审员以便事先做准备。位评审员以便事先做准备。每位评审员应该用每位评审员应该用1到到2个小时来评审该工作产个小时来评审该工作产品，通过做笔记或者其他方法熟悉该工作产品。品，通过做笔记或者其他方法熟悉该工作产品。同时，评审会主席也应该评审该工作产品，并同时，评审会主席也应该评审该工作产品，并制定评审会议的日程表，通常会安排在第二天制定评审会议的日程表，通常会安排在第二天开会。开会。评审会议v评审会议由评审会主席、所有评审员和开评审会议由评审会主席、所有评审员和开发人员参加。其中一位评审员还充当记录发人员参加。其中一位评审员还充当记录

22、员的角色，负责记录在评审过程中发现的员的角色，负责记录在评审过程中发现的所有重要问题。所有重要问题。FTR一般从介绍会议日程一般从介绍会议日程并由开发人员做简单的介绍开始。然后由并由开发人员做简单的介绍开始。然后由开发人员开发人员“走查走查”该工作产品，并对材料该工作产品，并对材料做出解释，而评审员则根据预先的准备提做出解释，而评审员则根据预先的准备提出问题。当发现了明确的问题或错误时，出问题。当发现了明确的问题或错误时，记录员逐一加以记录。记录员逐一加以记录。评审会议v在评审结束时，所有在评审结束时，所有FTR与会者必须做出与会者必须做出以下决定中的一个：以下决定中的一个：(1)可以不经修改

23、而可以不经修改而接受该工作产品；接受该工作产品；(2)由于严重错误而否由于严重错误而否决该工作产品决该工作产品(错误改正后必须再次进行错误改正后必须再次进行评审评审)；(3)暂时接受该工作产品暂时接受该工作产品(发现了发现了一些必须改正的小错误，但是不再需要进一些必须改正的小错误，但是不再需要进行评审行评审)。做出决定之后，所有。做出决定之后，所有FTR与会者与会者都需要签名，以表示他们参加了此次都需要签名，以表示他们参加了此次FTR，并且同意评审小组所做的决定。并且同意评审小组所做的决定。评审报告和记录保存v在评审会议结束时，要生成一份在评审会议结束时，要生成一份“评审问评审问题清单题清单”

24、。此外，还要完成一份。此外，还要完成一份“正式技正式技术评审总结报告术评审总结报告”。评审总结报告中要回。评审总结报告中要回答以下答以下3个问题：个问题： 1.评审的产品是什么？评审的产品是什么？ 2.谁参与了评审？谁参与了评审？ 3.发现的问题和结论是什么发现的问题和结论是什么?v评审总结报告通常只是一页纸的形式。它评审总结报告通常只是一页纸的形式。它是项目历史记录的一部分，有可能将其分是项目历史记录的一部分，有可能将其分发给项目负责人和其他感兴趣的参与方。发给项目负责人和其他感兴趣的参与方。评审报告和记录保存v评审问题清单有两个作用：评审问题清单有两个作用：(1)标识产品标识产品中存在问题

25、的区域；中存在问题的区域；(2)作为行动条目检作为行动条目检查单以指导开发人员进行改正。通常将评查单以指导开发人员进行改正。通常将评审问题清单附在总结报告的后面。审问题清单附在总结报告的后面。v为了保证评审问题清单中的每一条都得到为了保证评审问题清单中的每一条都得到适当的改正，建立跟踪规程非常重要。只适当的改正，建立跟踪规程非常重要。只有做到这一点，才能保证提出的问题真正有做到这一点，才能保证提出的问题真正得到得到“解决解决”。方法之一就是将跟踪的责。方法之一就是将跟踪的责任指派给评审会主席。任指派给评审会主席。评审指导原则v评审工作产品，而不是评审开发人员。评审工作产品，而不是评审开发人员。v制定并遵守日程表。制定并遵守日程表。v限制争论和辩驳。限制争论和辩驳。v要阐明问题，但是不要试图解决所有记录的问要阐明问题，但是不要试图解决所有记录的问题。题。v做笔记