1 背景<br />McDonnell Douglas宇航局软件工程部（MDA）的1000多个工程师从事大规模的导弹、飞机、地面系统和其他支持系统项目的开发工作。为了减少成本、保持有力竞争地位的持续改进活动，在1991年MDA管理层致力于软件过程改进，这最初是建立在SEI的能力成熟模型（CMM）上。早在1992年，他们就对一些少量CMM2级航空电子项目进行了SEI认证。从那以后，MDA在1994年确立取得CMM3 级的组织目标，这个目标后来要求由的重大的飞机和导弹部门来实现。由软件工程过程组（SEPG）负责建立组织过程和培训人员，以实现3级目标。SEPG建立了一个标准组织软件过程（OSSP）作为过程改进的基本工具。MDA对OSSP的执行是多层面的。公司以书面形式制定了实施CMM的政策。一个标准生命周期模型和一组过程要求被记录在软件工程过程手册中（SEPM）；过程和产品规格被记录在软件工程规格手册中(SEMM)。SEPG还编写了一些指导书，作为同行评审、配置管理、软件开发计划等过程的入门指导。本书一个主要章节就讨论到同行评审，它包括如下小节：<br />&amp;Oslash; 简介MDA软件同行评审过程<br />&amp;Oslash; 定义参加者的任务和职责<br />&amp;Oslash; 描述实际的同行评审过程，包括正是检查、走查和同行评审<br />&amp;Oslash; 列举和描述收集的规格<br />&amp;Oslash; 项目过程裁减的指南<br />SEPG还制定了一个同行评审培训课程以支持该过程传播到全组织。该课程包括在工作时间内的五个小时培训；包括概述该过程以及随后的两个试验环节，在试验环节进行了一个简易的检查。要求所有的软件工程师、软件质量工程师和软件承包商都参加该培训。自从1992年以来许多MDA软件项目一直在使用同行评审过程。过程要求项目收集同行评审中发现的缺陷数据。

2 问题<br />MDA软件项目这些年来一直在进行检查和缺陷数据收集工作。同行评审过程支持MDA取得了CMM 3级的目标，因此我们大多数项目都将它作为已定义的软件开发过程的一部分。这些项目一直在积累缺陷报告，但没有用这些数据（1）度量同行评审过程的有效性，或（2）指出同行评审过程或软件开发过程中需要改进的地方。他们将数据记录在纸张上，却不知道怎么解释它们；不知道它们潜在的用处。这种情况使人们质疑他们为什么首先在收集数据。我们接下来的挑战是CMM 4级。从3级评估中我们发现有必要考虑定量过程管理这个KPA（4级的一个KPA）。与此KPA有关的计划包括：SEPG培训统计过程控制技术和组织全面度量程序的执行。我们度量组需要一些“活”数据，这样才能从度量分析中获得经验。我们还希望评估3级活动中过程执行的好处，并支持我们向4级发展。<br />1995年，MDA建立了一个度量组支持与组织度量相关的4级活动。这个小组的第一个任务中包括编制一个调查，并分发到MDA所有软件人员手中，以帮助度量活动制定目标。调查结果显示软件工程组织中度量的基本用处是进度监督。然而，回答者希望从度量中得到更多，而不仅仅是软件开发进度或完成比率。因为大多数回答者都是开发人员，结果显示我们需要对开发人员有益的度量。从回答者中我们还发现一个普遍的主题就是要求充分理解度量数据收集背后的理由。许多回答者意识到收集度量的好处却不能实现它们；其他人想在使用前了解它们的用处。接着度量组评审了软件度量手册中定义的度量，并确定何处是软件工程师实现收集和分析度量数据的好处的最佳出发点。度量组将同行评审数据分析作为一种向项目提供即时度量的方法。

3 选择一组数据 <br />我们第一步是在整个开发周期内建立一个过程支持在对检查数据的分析。我们的小组选择了两个项目为分析提供缺陷数据。这些项目有现存的缺陷数据记录，第一个项目处于软件开发后期，另一个已经完成了软件发布。本文描述我们怎样分析第一个项目的数据。<br />该项目提供的数据是在9个月内通过212次检查获得的。这些检查包括详细设计、代码和单元测试计划。表B-1显示用来记录每次检查的概括性信息的检查报告；表B-2显示用来记录每次检查发现的缺陷报告。<br /><br /><br />图 B-1：检查报告<br /><br />项目 发布 阶段： 工作包： 检查<br />产品描述<br />产品 缺陷 返工<br />类型 页码 行 单元类型 代码 严重程度 种类（范畴） 初始阶段 缺陷描述 完工 检验<br />(上面是个Excel表，是用来记录数据的）<br />　 　 　 　 　 　 　 　 　 　 　<br />　 　 　 　 　 　 　 　 　 　 　<br />　 　 　 　 　 　 　 　 　 　 　<br />图B-2：缺陷报告<br />我们没有依靠提供这些缺陷数据的项目；没有去了解正在开发中或过程产品。我们只有该项目记录在案的同行评审过程和检查报告——没有得到详细的缺陷报告。使用提供数据的一个好处是我们的分析完全客观。不知道被检查的是由哪个工程师开发的，或者谁参加了任何一个同行评审。

数据分析—第一步<br />微软Excel提供了减少数据和分析数据所需的能力，因此我们将所有的数据输入电子表格中。概括性数据包括检查ID、日期、各种缺陷的数量（分类）和用于每个检查的评审软件包的大小。该项目没有将代码行数量使用在代码检查中，他们有一个计算整个评审软件包的总行数的程序。这个计数包括原文段落（可能是文档的）、代码和注释。由于无法得到源代码行（SLOC）数，我们选择“行数”作为数据度量化的手段。我们首先设计了一个饼图（图B-3），描绘每种缺陷与总缺陷数的比率。该图显示检查中出现最频繁的那些缺陷类型。由于该项目使用了15种缺陷类型，因此那些总缺陷数很小的缺陷类型就没有记录下来。用行数度量化数据允许我们为每行中的缺陷数使用一个属性控制图（c控制图）。属性控制图用来决定一个过程是否处于“受控”状态。我们使用的c控制图看起来很合理——它们显示大多数的检查产生的量化“缺陷数”都在控制界限内。但是，它们代表什么呢？我们认为我们需要一些帮助，我们得到MDA“减少变化（VR）”组的支持，他们的目的是提供培训——用统计工具支持全组织进行过程改进。VR组的工作基本上是负责MDA 的生产过程，这个工作使他们有机会将统计控制技术运用到软件中。<br /><br />图B-3:代码审查饼图<br />图B-4：代码审查C控制图<br />我们的VR专家指出：只有各个检查的样本量大小都相同，c控制图才有效。这种情形在软件检查中是不太可能的，因为它要求在相同大小的评审材料上进行综述，也就是总是检查同样数量的SLOC或同样数量的段落、页面等。因此，我们需要u控制图。U控制图是另一种属性控制图，但是不同于c控制图，前者可用于样本量不同的情形。VR组还建议我们使用排列图，帮助决定如何进行。

5 数据分析—第二步<br />发现第一步有误后，我们停下来决定我们到底想从数据中得到什么。此外，我们发现有太多的数据要处理，应当将它们分解成更多可管理的部分。小组决定集中在124个代码检查上，将详细设计和测试评审留待将来分析。我们选择代码检查作为第一个类别，因为它们经常使用在MDA的项目中，它们将提供关于实际软件执行问题的更多信息。<br />首先，我们想确定“重击手”和“关键的少数”缺陷类别。于是我们建立了一个排列图（图B-5），确定了15个缺陷类别。“重击手”是标准、逻辑和修缮性。在代码检查中发现的1896个缺陷中，704个或37%的缺陷都属于此，对此我们提出如下问题，“他们为什么发现如此多的标准性错误？”。和该项目的同行评审过程负责人讨论后发现，（1）他们有很多文档和代码标准；（2）他们的客户认可这些标准；（3）许多软件开发人员对于这个项目仍相当陌生，而且在标准使用方面没有得到足够的培训。然而，排列图没有告诉我们那些“关键的少数”。量大并不意味着很重要，因此我们需要使用“严重程度”来加权这些缺陷。<br />图B-5：代码审查排列图<br />其次，我们要回答问题：“过程受控吗？”，也就说，“忽略被检查产品的大小，开发过程前后一致吗？”。为了回答这个问题，我们建立了最主要的三个缺陷类别的属性控制图（u控制图）。我们计算了所有代码检查的控制上限（UCL）和下限（LCL）和中心线（U ar），结果如图B-6所示。在该图中，缺陷数据用U表示。<br />图B-6：逻辑U控制图<br />从逻辑缺陷的U图中，我们发现只有6%的审查出现比预期更多的逻辑错误，这就说，该过程是受控的。我们找出每个检查中超过UCL的缺陷，并将它们报告给项目经理。为了决定它们的根原因，项目经理仔细检查了缺陷报告，试图寻找开发过程、资源和人员方面的变化或问题。这些都可能导致过程失控。

6 第二步的综合报告<br />经过第二回合的数据分析，我们决定过多的标准性和修缮性缺陷可能歪曲了我们的数据，使得我们无法集中在那些可能影响软件功能性的缺陷上。我们获得了一个代码标准检验程序，将它用在该项目中，帮助减少将来的标准缺陷。该项目开始评估诸如“pretty printers”等工具，为了在同行评审前帮助检测或消除修缮性错误。根据我们提供的数据，该项目决定通过合并“可理解性”、“过于详细”、“不完整设计”、“上游设计”、“需求不足”和“需求遗失”等减少缺陷类别的数量。项目组和度量组都一致认为较少的缺陷类别将减少分析数据的工作量，而且仍能提供关于该过程足够的信息。

7 数据分析—第三步<br />根据从以上活动中得到的经验，在第三步数据分析中我们决定调查其他一些数据。首先，我们合并了一些缺陷类别以配合该计划所作的变化，然后重新建立了一个排列图。这个变化很小，然而，由于缺陷类别数量减少，这些图看起来更加整洁。尽管这些图看起来更好，但它们并没有告诉我们更多的信息。<br />为了确定“关键的少数”，我们决定根据合并后缺陷类别的“重要程度”分类和“次重要程度”分类加权这些缺陷。在最初的分析中，我们只是将主要缺陷和次要缺陷数量相加，确定每个类别的唯一的总数。相应的排列图（如图B-7所示）突出显示了每个软件开发阶段最重要的缺陷类别，标准性和修缮性缺陷移到了第四和第五的位置。加权系数为10时，我们发觉终于找到了“关键的少数”。<br />图B-7：混合代码审查<br />我们继续进行分析。项目过程人员对逻辑错误超过UCL的12个检查进行调查发现，较高的缺陷数量可能是由某些特殊原因造成的，如新的软件人员加入、专业化软件模型等。根据控制图理论，我们除去这12个检查，并重新计算逻辑错误的控制上、下限和中心线。新的u控制图显示只有两个检查中出现的错误落在控制界限外。来自原始u控制图的数据显示在图B-8中。该图是一个短期的属性控制图，为了提高可读性我们对UCL 和LCL进行了标准化。图B-9是关于12个有“特殊原因”的检查被消除后的剩余数据的控制图。<br />图B-8：逻辑错误的短期属性控制图<br /><br />图B-9：消除特殊原因后的逻辑错误短期属性控制图<br /><br /><br /><br />同行评审时发现的缺陷 需求 设计 代码<br />需求 0 <br />设计 9 1711 <br />代码 1 113 1935<br />图B-10：缺陷总数

8 第三步的综合报告<br />我们再次咨询了VR专家，对分析进行仔细检查。随着对问题的理解加深，我们开始担心运用的统计方法是否有效。与u控制图有关的假设是在某个检查中发现的缺陷数量呈现泊松分布。我们想知道是否有必要测试实际的分布。<br />这绝对必要，因为将所有缺陷计算在内的话，每行的缺陷数大约是0.01。当我们限制了缺陷类型的数量时，这个数值甚至更小。这次会议让我们确信我们有坚实的理论基础。<br /><br />9 结论 <br />我们小组普遍认为从以上过程中获得了许多可贵的信息。发现来自同行评审的缺陷数据可用于着重说明需要过程改进的地方；还发现，如果我们假设同行评审过程是稳定的，就可能判断从同行评审中发现的缺陷数量的范围，这取决于评审软件包的大小。这个概念最适合如下情形——同一个软件团队进行了一个完整的软件开发周期，且将该过程重复在另一个开发工作中。我们还发现该项目对我们的报告非常感兴趣。根据我们收集的数据，他们在软件开发<br />过程和同行评审过程中进行改变，如在同行评审前增加使用了一个标准代码检验程序，合并了一些缺陷类别以减少消耗在材料评审上的时间。还发现另一个重要方面是：像SEPG这样的组织团队能够开发一个过程来支持单个项目的过程改进，这可以减少项目人员的工作量。<br /><br />10 将来的计划<br />度量组已经策划了几个活动作为上述研究的后继活动。我们的计划包括开发一个标准同行评审数据分析过程，并将该过程扩展到其他软件缺陷类型上，如测试和发布后发现的缺陷。首先，我们计划分析第二个项目的检查数据，以决定我们使用的分析技术是否能用在开发不同软件的项目中。如果我们对第二个项目的数据集进行同样的分析，并且能为他们的过程提出改进意见，我们将建立一个记录过程，将这个应用推广到其他的MDA软件项目中。为了帮<br />助该过程引入到我们的软件组织中，将调查支持数据收集和数据分析的工具。VR组的成员推荐使用统计分析系统（SAS）来建立一个分析软件同行评审缺陷的应用程序。我们正在调查通过使用Excel macros，缺陷数据进入、收集和分析过程的自动操作系统。<br />建立同行评审数据分析后，我们将开始寻找软件开发过程后期的缺陷。计划在整个组织中收集系统测试和发布后发现的缺陷，然后计划建立一些有助于整个软件开发过程的缺陷分析技术。接着，我们用该过程去度量过程改进对产品质量的影响。

这个案例中选择一个非常短小的“过程”来度量。所以他们找到了数据。我们在跟踪中是否也会关注这些”短小“的过程呢？我想很少人、很少公司能够做到这一点。<br /><br />我们所关注的过程就是需求、概要、详细这种大段，但是当这种大段没有细分下去的话，它还是不可控、混乱的。同样你的关注点就不能确定。你会关注文档有那些问题吗？你会关注界面有那些问题吗？如果不清楚这些问题，就难以采取行动，也就难以改进。同样如果不用数据说话，不但说服不料自己，也说服不料别人，更难以分清主次轻重。