| 本文内容包括:
本文来自于 Rational Edge：这篇文章介绍了一种需求审查的方法，它结合了基于视角的阅读技巧（Perspective-Based
Reading，PBR）与 Rational 统一过程（Rational Unified Process，RUP）的需求规程部分，合并成为一个扩展版本。本文提供了广泛的基于该方法的例子和案例研究数据，来阐述它的价值和好处。
审查是一个非常重要的，但同时也是软件质量保证经常未被充分利用的一个方面。审查的目的是在开发生命周期的早期检查并修正软件缺陷。已经被普遍认识到的是：1
在编码阶段检查并修正一个缺陷的成本比需求开发阶段这样做的成本要高五到十倍还不止。如果这个缺陷直到维护阶段才发现，那么修正它所花的成本比需求阶段修正的成本高200多倍。2
在这篇文章中，我们介绍了一种为了审查需求工件而扩展 Rational 统一过程?,
或者 RUP?, 审查需求指导方针的方法，同时合并了基于视角的阅读技巧(PBR)3 。从那些提供被检测工件的参与者的观点来看，PBR
技术是支持缺陷识别的。它是通过提供特殊的场景来完成的，这个场景可以帮助说明从特定的角度寻找什么来发现潜在的缺陷。PBR
为设计人员、测试人员或客户的观点提供指导。为了有效地整合 PBR 和 RUP，我们在 RUP 的需求规程中精心制作了新的与参与者相应的场景：系统分析师，需求阐释员和软件构架师。
为了评估我们的方法的成本/收益的权衡，我们称其为 PBR-UP，我们在一个小的软件开发项目环境中做了一个案例研究（一个基于对象的信息系统）。我们利用了
GQM 范例依照 AINSI 指导方针4 指导了这个案例研究。5 我们的结果证实了 PBR-UP 帮助测试人员用成本高效的方法在需求开发过程产生的工件中找到了严重的错误。
基于视角的阅读技巧
软件检测是一个良好定义并遵守原则的过程，一组有资格的专业人员在这个过程中分析软件工件，这样做是为了在开发过程中尽早检测到缺陷，防止高代价的返工并为软件的改善做出一定的贡献。6
审查过程对于在一个产品生命周期中产生的绝大多数工件中都是适用的，比如需求说明、设计模型、源代码、测试计划等等。
为了帮助评审人员更有效地审查需求，Victor Basili 和他的同事们开发了一种称作基于视角的阅读（Perspective-Based
Reading，PBR)技术，这种技术可以精确地指导评审人员们进行搜索，这样使他们能够在更短的时间找到更多的缺陷。这种技术认为在需求开发阶段有很多使用被生成文档的客户。PBR
为每个评审人员提供一个对每种类型客户的详细而精确的视图或者透视图，从而对需求进行审查。透视图与软件开发过程中不同的检查者角色密切相关。PBR
背后的思想是简单易懂的：如果审查人员从不同的角度来对文件进行分析，那么这个文件将会更可靠地反映真实的需求。
透视图的 PBR 定义表示了客户、测试人员以及设计人员。从这些不同的角度，审查员要运用一个基于场景的方法来读取这些需求。7
每个场景包括一组问题和行为，它们可以通过将需求和具体的项目参与者的正常工作实践联系起来的方法来指导这个审查的过程。在回答问题和执行行为的过程中，审查员要注意潜在缺陷的发现，它们可能会防碍项目涉众的典型职责。
PBR 的基于场景的读取技术的主要目的是为识别缺陷类别创造条件，这些缺陷可能只有在工件交付之后或者正常开发行为的过程中，被审查工件的用户才能够发现。例如，从一个测试人员的角度来看，审查员应该核查是否为这些需求创建了一个合适的测试计划。当审查员在这个过程中遇到麻烦时――可能是因为不清楚或者不完整的需求――需求缺陷就会被发现。用这种方式，PBR
为每个审查员提供一个详细的、良好衔接的焦点。
介绍 PBR-UP
为了从 PBR 技术获得更大的利益，为每一个应用的透视图创建一个全面的场景是十分重要的。这将可以定义一套可以跨越许多需求规范文件的问题和行为，对于这些规范的读者来说也是可以理解的。为了有效地整合
PBR 和 RUP，为 RUP 需求规程的参与者精心制作特殊的场景是十分必要的。8
正如图1所示，我们将下面的主要角色看作是需求开发过程中活跃的参与者：系统分析人员、软件构架师以及需求阐释员。这些角色在他们产生支持软件开发过程的意义上是“活跃的”。每个参与者都不得不将软件的质量看作是他们角色的一部分，因为他们需要保证他们生产的各种不同产品的质量都达到企业所期望的同一水平。
图1：与 RUP 的需求规程相关的关键角色和工件9 从开发与系统分析人员相关的问题和场景的角度看，比如我们关注的是支持审查员，来证实需求是否以正确描述参与者和用例的方法归档
，关键术语是否在术语表中详细说明，需求是否支持用例模型，从而使功能的重用更容易。总之，我们关注的是有疑问的特定角色目标，是为了确保这些需求工件有足够优良的质量来使它们实现。
为 PBR-UP 开发新的场景
正如上述所述，在一个基于场景的审查中为不同审查员提供的场景，需要审查员创建高水级别的被审查的工件模型作为缺陷检测的一部分。每个模型对应于一种工作产品的类型，这种工作产品将在项目主要职涉中的典型活动中创建。通过创建这样的模型，审查员需要带着审查中的信息在更有经验的水平上工作，与传统的使用基于清单的审查技术进行的相对被动的审查案例相比较，这样使他们能够更有效地发现缺陷。此外，基于场景的审查过程中创建的模型能够为以后在软件开发过程中各个项目涉众创建的工作产品奠定基础，这可以为以后的生命周期节省了时间和精力。和审查清单不同，这些模型不是一次性的工件，而是有用的输入，它可以有效改善审查中实际模型。比如，用例模型由需求审查员创建，扮演着系统分析师的角色，在改进真实的用例模型过程中，它可以变成对于系统分析人员的输入。因此，基于场景审查过程的产物不仅仅是一个缺陷的目录，而是可重用的模型.
一个特定的场景包括一系列需要审查员回答的问题和对审查员应该执行行为的描述，这样是为了使大量缺陷的识别都在需求工件上。由于基于场景方法的需求，每个角色的检查活动都聚焦于一组特定的职责来避免其它角色职责的冗余。
下面的部分，我们描述了如何应用基于场景的方法来为图1中定义的每个角色创建需求检查：系统分析师、需求阐释员以及软件构架师。10
系统分析师场景
根据 RUP，“系统分析师通过描述系统的功能并为系统划定界限来指导和调整需求的引出以及用例的建模；比如，确定存在什么角色以及当与系统交互时需要什么样的用例。”系统分析师在其它活动中也起到一定的作用“定义公共词汇表，在系统的所有文本描述中都可以用到，尤其在用例的描述中。”为了完成这个任务，系统分析师应该执行一系列活动来建立这个系统环境。这个目标是清楚地确定这个系统的界限，决定什么应该在范围之内，什么应该在范围之外。这些界限根据对参与者和用例的识别来定义。图2展示了一个系统分析师所负责工件的总览图。这个
PBR-UP 系统分析师的检查关注焦点是用例模型和术语表。最初的 PBR 已经提供了能够支持远景和补充说明工件审查过程的场景。
图2展示了系统分析师所负责工件的总览图。PBR-UP 系统分析师审查场景的重点是用例模型和术语表。最初的
PBR 已经提供了能够支持远景和补充说明工件审查过程的场景。
图2：在需求开发过程中由系统分析师产生的工件和活动 为这个透视图所开发的场景需要审查者集中在通过统一建模语言用例模型传达的系统需求规范上，它通常还包含
Use-Case Packages 和 Use-Case Outlines。这些于场景相关的行为需要审查者鉴定包含于
Use-Case 模型产物中的重要元素。这样做，审查者扮演的是 System Analyst 的角色，创造了基于信息的高水平产物，这些信息由正在检查中的工件提供，它们能够在稍后的过程中被现有的
System Analyst 重新利用。这些由基于场景审查过程所提出的问题可以帮助审查者核查主要功能的性能（比如用例），参与者（比如人和系统）以及术语在被审查的工件中是否被准确获得。这些由基于场景审查过程所提出的问题还可以帮助审查者校验提供的信息是否足够详细，从而能够保证其它依赖于由
System Analyst 产生的工件的软件开发行为的顺利完成。总之，场景可以帮助审查者校验完全性，易懂性以及检查中工件的正确性。
图表1示范了一个 PBR-UP System Analyst 场景的例子，它为负责评估在需求过程中产生的工件质量的技术审查者提供了读取的指导方针。这个基于场景的审查是由其它审查文档和窗体来支持的，通过这些文档和窗体技术审查者能够为他们找到的缺陷编制目录。
IBM Rational 工具比如 IBM Rational ClearQuest?和 IBM Rational RequisitePro?,
能够用来使缺陷编制目录的过程自动操作，因此提高了审查过程的效率。
需求阐述者场景
这个角色的主要任务是分析需求，从而获得本应该在用例中找到的事件流程的详细描述，得到每个用例开始和终止的清楚的条件并确定所有与参与者的交互作用。用例详细说明的主要来源是用例模型，概述了用例和术语表。图3简要说明了在需求开发阶段由需求阐述者产生的关键工件。
PBR-UP 场景的重点是，它是“详述一个用例”行为的主要产物;
图3：需求开发阶段由需求阐述者产生关键工件 软件架构师场景
软件构架师能够利用像类、子系统和组分等结构元素，从技术的角度控制系统构架的开发。这个系统构架是建立在很多迭代之上的，主要在精化阶段执行并在软件构架文档中详细阐述，这个文档中有众所周知的4＋1构架视图。每一次迭代都包含需求、分析、设计、执行以及测试环节，并且每一次迭代都由它们自己具体表现为系统的大多数相关案例形式的构架模型来支持。
划分用例优先级是那些被预先安排用于系统的主要技术和事务的风险的。因此，这个从构架师的角度创造的场景包括创建一个含有构架中最重要参与者和案例的用例模型。图4展示了一个在需求开发阶段产生和使用的关键工件的总表。值得注意的是，尽管软件架构师参与者在整个生命周期的阶段都存在，但是
PBR-UP 场景的重点却仅仅是这个软件架构师在需求开发的阶段所扮演的角色；那就是说，重点在软件架构文档的用例视图上。
图4：行为和工件是由软件架构师在需求开发阶段产生的 PBR-UP
案例研究
为了度量这个在 PBR-UP 作用下需求审查过程的成本效率，我们进行了一个案例研究，在这个案例中为一个真实的软件项目设立了六个审查员对这些需求进行审查。我们通过一个叫做软件结果审查登记表的表格来收集和组织这个审查结果。11
在这些检查员完成了他们的审查工作时，我们对他们进行了采访。
设定案例研究
进行案例研究前的第一步是选择一个项目来对它进行研究。为了运用PBR-UP技术，选择的项目必须根据RUP原则来进行管理是十分重要的。我们选择的这个项目是巴西戈亚斯州戈亚尼亚市政大厅的测验以及咨询管理系统的开发。这个系统的目的是对相关健康和法律服务信息的管理。它包含三十个用例。
已经找到了通过它可以指导我们研究的项目，并且这个项目还带有测试和咨询管理系统的需求工件，我们接下来要做的是确定一个专职人员，他将利用PBR-UP来对这些需求进行审查。审查人员的先决条件是他们必须是大学专科信息技术专业的学历（比如分析师、程序员、设计师等等。），还必须有基于对象分析和UML的经验。最后，我们选择六个不同经验水平的系统分析师。这些审查员既不能用已经审查过的系统进行工作，也不能在研究之前接触系统工件。
审查的准备工作
我们给每个审查人员系统的需求工件，同时还给他们三个我们开发的PBR-UP场景。另外，我们还给每个审查人员一份软件需求审查注册表的空白拷贝，简化他们的工作并帮助他们组织记录他们审查结果的过程。
然后我们将为这些审查人员进行一场90分钟的训练课程，在这个训练期间我们将给他们解释PBR-UP技术以及如何运用。我们要求审查人员尽可能遵从场景进行工作。每个场景都会指导他们完成一个支持性表格，尤其是软件需求审查注册表，同时要求他们严格观测每个活动所花费的时间。这个耗时的阅读参考资料也要算作预备工作的时间。
进行检审查
所有的审查人员都是独立完成他们的检查工作的。在进行审查期间，他们大多数都会要求帮助填写表格，还会要求对他们要提供的细节等级进行反馈。至于后面的问题，我们建议审查人员应该运用他们认为最合适的细节等级。在审查的最后阶段，每个审查员都要交给我们一份完整的软件需求审查注册表格。
召开审查会议
审查工作结束以后，我们要坐下来分别跟每位审查员讨论他或者她的审查结果。因而发生的相互解释和意见交换可以帮助我们更好地鉴别错误的缺陷。为了评估技术的效能计算出实际和不真实的缺陷数量。
案例研究的结果
为了确定成本和收益参数的广泛范围，我们深入分析了这个案例的结果，包括缺陷的严重程度，与它们相关的工件，审查人员的工作效率以及PBR-UP技术的成本效率。
缺陷的严重程度
表格2显示了按照缺陷严重程度分组的审查结果。这些数据说明了PBR-UP技术在不同重要性的水平鉴定缺陷的功效。被定位成“严重的”缺陷反映了参与者对构架上重要用例的疏忽。绝大多数缺陷被定为“简单的”，包括了术语表中的矛盾以及参与者和案例中命名不一致的情况。“中等的”缺陷主要是与普遍性和构效关系相关联的，它们既没有被认真考虑也没有被不恰当地描述。最大数量的缺陷被定位成“简单的”，表明需求分析家没有对术语表投入足够的精力――这是一个常见的问题。然而，每个审查员发现的中等的和严重的缺陷的数目都差不多，这事实上是假设被开发的系统是相对简单的。
缺陷的根源 表格3显示了按照已发现的缺陷的来源进行分组的审查结果。这些数据表明哪些需求工件包含了最多的缺陷。大多数的缺陷都与参与者，用例以及他们的之间的关系有关。根据收集在需求审查注册表在中审查人员的观测资料，我们很容易就看出整个远景文档的质量与其它工件中缺陷发生的关系。（审查人员根据质量评估问卷调查表将项目的远景文档定未中等质量水平。）值得注意的是在参与者和案例中比在术语表本身之中会发现更多的缺陷。这表明对系统功能性能的高度重视，是部分开发者的自然偏见。
审查员效率 表格4显示了审查员的效率：意思是在审查过程中每个人时可以找到三个缺陷。根据我们案例研究，利用PBR进行审查的审查员比那些使用审查清单的能够发现更多的缺陷。使用PBR技术的找到缺陷所需的人时也少得多。使用PBR,找到一个缺陷平均花费56分钟，而利用审查清单找到一个缺陷要花费132分钟。在这方面，我们的结果与其它人报道的结果是相似的。13
那些花了较少的时间进行审查却被认为获得了较高的效率指数；然而，这归功于他们没有花费时间来填写一些表格的事实。在一个案例中效率指数很低，审查员表现出极少的工作动机并且对技术的忠诚程度也很低。在另一个低效率的例子中，审查员缺乏系统开发行为的经验，导致审查时间比通常情况都短，最后只找到数量较少的缺陷。这个审查员还有比其他人更多的“误确认”，从而影响了其结果的效力。总之，那些花费更多时间进行审查的人员，无论是对工作有更强的动机还是对技术有更强的忠诚程度，与其他同事相比较他们产生了更一致的结果。
* 评审员的经验分值
成本效率 成本效率是对生产一定数量的产品所消耗项目资源量的度量。在PBR-UP技术背景下，测量成本效率是为了证实对利用这个技术产生一定量的成效所投资的资源与它的应用是否是恰当的。表达效力的定量因素被定义为成效获利（找到缺陷的数量）和这个过程的投资（检查成本），表达公式如下：
由PBR-UP技术找到的缺陷的数量可以由鉴定错误的媒介数量来表达，考虑到所有的审查人员。审查成本由两个变量衍生而来：时间消耗（数量）和人力资源（数量和价值），也包括所有的审查员。通过这种测量，在这个案例中PBR-UP技术的成本效率大约是每个错误10美圆。注意这个结果仅仅与鉴定缺陷成本相关，而没有考虑相关联的审查过程的成本，比如重复工作以及随后的成本。因此比较利益包括：
在一个21个月的300次检查过程中，每个缺陷的审查成本在90至120美圆之间（平均为105美圆），包括寻找的精力成本，整理成本以及对缺陷正确性核实的成本。
在另一个案例中，与一系列软件开发过程相交叉的审查过程的成本是这个项目预算的5％到15％之间。在我们的研究中，我们发现这三个透视图之一的审查成本大约是整个需求开发成本的4.2%。如果我们将三个透视图都考虑到，并假设在其它生命周期阶段的成本依然不变，那个在这些限定条件下我们项目的审查成本将会降低。
PBR-UP技术的功效
为了测量功效（请看图表5），我们标注了通过审查发现的实际缺陷的数量与缺陷报告数量的关系。在这个分析中我们忽略吊简单的缺陷，因为它们很大程度上与术语表中对术语的定义相关。由于我们考虑到无论这个术语是否是这样的，他们都可能对它进行争论，我们不是要判定这些报告的缺陷是否是实际缺陷。
基于这些假设条件，我们发现这个案例研究中PBR-UP技术的效力平均在70％以上。这个高效率可能归功于审查人员都在认真进行研究的事实，我们相信只要审查人员密切并且有条不紊地按照技术的指导方针进行审查就能够达到这种高的效力（尽管任何一个审查成本的增加都是因为坚持技术原则而所需时间的增加而导致的）。
* 不考虑简单的缺陷
不考虑简单的缺陷审查人员的陈述 在审查过程结束以后我们会见了这些审查人员，目的是获得关于PBR-UP更多的信息。下面是我们从这些审查人员中获得的主要的几点。
审查人员1：“对于这个技术，它的用途是协助工作来证实需求阶段产生文件的质量。然而，重复分析工作是没有价值的，仅仅可以用来在稍后的过程中与当前文件进行比较。重复工作仅仅在它应用于更高规格的级别是有效的，比如，Fa?ade
用例。”
审查人员2：“这个技术是有效的，并且可以更精确地鉴定由需求原则而提出的工件。另一个相关点存在于这个技术团体主要由其它范例元素组成的事实中（结构分析，数据分析等等）。如果没有充分的指导变更范例就会更加困难。琐碎的文件在这个区域（理想的技术，因为RUP本身通常是不够充分的。）已经被介绍了，这些文件使它变成一个十分重要的技术，企业为了提高工件质量而执行的技术。”
审查人员3：“为了提高产品质量规范已经尝试过很多做法，大多数方法是靠专业人员的经验来支撑的，并且没有遗留任何可以竞争的事情。问题因此而逐渐减少，但是在这个发展的系统中我们不可能依靠一些人的经验来保障质量。我在这个项目的用例评估中使用了需求审查的方法，让我得到了极大的满足，原因有以下几点：首先，因为它不是靠人们的经验来支持的，而是由定义好的规则来支持的；其次，因为它介绍了一个任何分析师都可以遵守的简单导向；最后，因为审查产品显示了这个方法的应用，对节省时间和规范的质量的提高有重大意义。”
审查人员4：“由于审查工作通常是根据审查清单进行的，很多时候我们并不清楚有些问题的原因，事实上是与模型质量性质相关的。当它建立在场景的基础上，由于那些利用在这个项目中，在项目分析师之前对审查过程的理解和对缺陷的解释就会容易很多。因此，我认为场景的利用是十分合适的。尽管执行审查会需要更多的时间，但是结果会更可靠。”
结论
根据我们案例研究的结果，这个PBR-UP技术被证明是一个相当有价值的提高软件质量的审查方法。对于这个技术的关键积极的方面，正如我们会见的审查人员所表达的一样，包括：
它为基于案例需求的审查工作提供了坚固的指导方针。
它识别了经常被分析师忽略的工件的问题。
它揭示了需求收集过程产生的大量缺陷。
它为组织审查结果提供了一个有用的方法。
分析师自己可以利用PBR-UP过程的产物来指导系统的开发。
这个技术学起来很容易。
运用这个技术在组织内部展开了“探究质量”的文化活动。
根据接收到的反馈，我们还可以确定下面对PBR-UP技术的重大挑战：
设计高水平模型应该仅在中等细节水平进行，因为增加了准备审查会议所需的时间。
要利用PBR-UP技术进行审查需求，必须具备RUP和UML知识。
尽管在软件审查注册表中有一个主要缺陷的清单，但是通常情况下由于每个审查人员个人原因，在他或者她的内部带有结束影响审查结果类型的特殊的知识，仍有可能发现新的缺陷类型。在运用这个技术过程中，可能观察到缺陷的鉴定与那些表格中的目录是不一样的。这些缺陷需要文件著作者来讨论从而使其能够被更好地理解。然而，很多误确认缺陷来源于审查人员对这个功能区没有完全理解而产生的误解。会议主持人在审查会议上应该解决审查人员和生产者直接的任何可能出现的疑问。因此，我们不需要将审查会议看作可选择的：相反，在这个案例研究中我们获得的经验是让我支持审查会议。
随着我们对PBR-UP的运用，我们已经获得缺陷鉴定审查过程的效力更深入的经验主义证据。例如，当我们用系统分析师的观点，我们关注的是找到一系列缺陷，比如功能特性不被觉察或者某些参与者的关系不再像以前一样明显。利用一个特殊的观点聚焦于审查过程上，可以使生产力更高，因为通常的特别评估已经被一个有良好驱动和控制的过程取代。随着场景不断被PBR-UP提出来，审查人员能够在审查会议的准备工作中鉴定大多数缺陷。这个事实影响了审查的生产率，因为这个会议仅仅是用来介绍和合并被找到的缺陷的。审查过程中所产生的工件不但能在审查中帮助判断，还为分析师使用的一些文件提供基础，使意见交流对系统的开发有所帮助。
这个过程的效力很明显是取决于规格标准的特性和审查者的经验的。组织机构使用可以反映生产质量需求的测试程序的需求模板，在这个方面有所帮助。这样的模板通过诱导分析师提供更多完整的信息来帮助需求的确认。如果有更富有经验的分析师来充当审查者的角色，有时会导致一个基于他们直觉或者先前经验的审查过程，而不是依靠假定的一个可以对对审查方法有效性给出错误感知的场景。在这个案例中，目的是从审查者身上学习经验，利用他们所开发的经验来改善审查的步骤。
|