随着技术的进步和软件应用领域的拓展，用户需要更大规模、更可靠的软件，此时，软件度量工作显得更为重要了。如果一个组织能够对其生产的产品做出预测和承诺，那么就可以说这个组织是成功的。有效度量的作用在于能够帮助软件组织认清自己的能力，根据对度量数据结果的分析，进一步为他们的生产和服务制订出可行的计划；及时找到变化趋势，预测问题，发现或者采取有效手段预防缺陷；不断改进软件开发过程。

需求的变更直接导致规模的变更、进度的延期以及成本的增长，公司要求项目经理定期度量需求变更（包括新增的、修改的和删除的需求数）的数量及需求总数的变化，控制需求变更并采取相应的措施。

图7-1中两条线分别表示需求总数的变更以及每周需求变更的数量。曲线中的数据表明，第二周的需求评审后，第三周需求总数又有了明显的增长，而且第三、第四和第五周需求变更的数量都很大。

（点击查看大图）图7-1  需求总数与每周变更曲线

为了查找具体原因，须继续分析更加详细的数据，如图7-2所示。
　

（点击查看大图）图7-2  每周需求的变化情况（增、删、改）

图7-2中显示，经过了第二周的"第1次评审"，需求变更还是很大，其中大量的需求处于修改状态。而且第七周"第2次评审"后，需求在相当长的时间内依旧没有稳定下来。目前，项目已经进入到设计阶段，大量的需求变更是项目失败的一个隐患。

为了控制不断需求的变更，项目可能采取包括重新分配资源，重新估计规模、工作量和进度等具体措施。

另外，还可以详细地分析需求变更的具体原因（如误解、不清楚、不完善和不正确等）、需求变更的类型（如功能、性能和接口需求等）以及细化跟踪的粒度到每个模块。

通过这些详细的分析，可确定造成需求频繁变更的根本来源，以便有针对性地采取措施。

7.1  软件度量及其方针

其实，度量在我们的开发过程中一直在使用，例如代码行或者工作量人月数的度量等。

软件度量是针对软件开发项目、过程及产品进行数据定义、收集以及分析的持续性定量化的过程。

软件度量实际上包括度量和分析两大部分，其中度量是基于一定的目的，采用一定的办法或者标准，对目标事物进行观察，得到客观的评价结果，以量化管理定义项目过程，完成项目已建立的质量和过程性能目标；分析是采用一系列数学函数，对数据进行处理，发现问题并确定过程的发展趋势。

软件度量的目的一般在于：

（1）理解，作为研究或开发的部分，通过搜集到的软件过程及项目数据可以了解过程和状态。

（2）评价，评定软件工作产品或开发活动是否符合规定的准则及条件。

（3）控制，根据度量获得的数据控制软件开发过程中关键活动。

（4）预测，度量数据是有效估计的基础，可以在软件开发效率或者趋势方面进行推理并提示采取措施。

（5）改进，根据度量信息，确定改进的机会。

软件度量活动一般是在项目级开始，逐步向上扩展为过程度量和产品度量，在处理组织级或者本组织信息需要方面，提供足够的度量能力；向下扩展为个体行为度量，目的是了解个体开发过程中行为的详细原因，并实施行动进行改进。

其中，产品度量是描述诸如大小、复杂性、设计特征、性能和质量等级的产品特征的度量；过程度量是可用于改善软件开发和维护过程的度量，用于建立组织基线，确定改进活动，例子包括开发过程中缺陷排除的有效性、维护过程的响应时间等；项目度量是了解项目实时质量情况，获得项目特征和执行情况，例子包括开发人员的数目、软件生命周期上的人员成本、进度和生产率等；个体行为度量可以了解个体的开发优势和不足，了解个体缺陷产生的详细原因，确定如何去提高质量并实施行动进行改进，例子包括引入缺陷最多的阶段、引入缺陷的累积百分比、编码阶段常犯错误、缺陷排除有效方法等。

软件度量中最关键的内容是度量模型的建立和资源模型曲线的绘制及应用，本章稍后的部分我们将分别介绍这两个模型。

软件度量应遵循的方针：

（1）根据信息需要和目标建立测量目标并予以维护；

（2）软件度量方法只是达到目的的手段，而其本身并不是目的；

（3）以应用度量结果为中心，而不是单纯为收集数据而搜集数据；

（4）规定度量元，以处理度量目标，但是要注意度量数据本身肯定存在着瑕疵、不精确也不稳定；

（5）说明如何获得并存储度量数据，让软件开发者参与软件度量活动；

（6）规定如何对度量数据进行分析和报告，并且安排优先顺序，同时从小处着手，以局部为重点，逐步深入；

（7）提供度量结果，以便处理信息需要和目标。包括：获得指定的度量数据；分析并解释度量数据；管理并存储度量数据、度量规范和分析结果；向所有有关的利益相关者报告度量和分析活动的结果。

（8）将特定情景中的过程行为相关知识存储到经验数据库中。

　 7.2  度量活动

在整个开发过程中，到底度量些什么，是一个非常困难的课题。因为度量数据的真正用户不仅仅是项目组，更多的是管理者。当管理层不关心组织的过程能力时，软件度量就会失去方向和目标；而如果项目组和管理层不关心组织的过程性能时，度量则失去了其存在的作用和意义。

这两个方面中，一定要首先确定度量活动的首要目标。度量内容（即下面所论述的"度量元"）必须由企业的商业目标确定，并且是针对特定问题的。换句话说，软件度量一定由公司的管理层决策、参与和支持，提出监控的大方向（如工作量、进度、生产率、缺陷密度等方面的控制值），同时有资深的项目管理和开发人员讨论、参与和支持，一起定义具体细节。

例如，公司中的项目类型可能有很多，包括特定的项目开发（从需求获取到发布）、平台移植项目（从Windows到Linux或者UNIX）、本地化项目（汉化国外产品）、售后服务类项目以及外包项目（从详细设计到编码阶段和纯测试项目）等，针对不同类型项目的度量元肯定是不同的。其中，项目开发可以有编码阶段的代码生产率，也可以算出从头到尾的平均代码生产率。对于本地化项目，工作量是将英文翻译成中文（其中没有代码开发的任务），此时需要度量的是翻译阶段的翻译生产率。而对于移植项目（有些代码是自己写的，有的是复制原来的，有的是修改的）、纯测试项目（测试某个产品的各个功能，可能没有代码或写了一些测试驱动）、外包服务（客户的需求频繁变化，虽然可以统计编码阶段的生产率，但其中的返工工作量很大）、客户支持服务（远程支持、指导，没有任何代码）等，凡此林林总总的特例，如何进行度量的定义、统计、分析，都是比较现实的问题。

7.2.1  度量目标

确定度量目标、选择适当的度量元是做好度量的基础。我们确定度量目标时，常用的是目标问题度量（Goals-Questions-Metrics，GQM）方法（见图7-3）。GQM方法由马里兰大学的巴士利博士（Dr.Victor Basili）及其助手提出，用以告诉组织或者机构应该采集哪些数据。GQM方法隐含的假设是"每一个组织、项目均有一系列目标要实现；而要实现每一个目标，均要回答一系列问题才能知道目标是否实现；而对提出的每个问题，都可以找到一个完整、可以量化的满意解答"。GQM过程如下：

（1）制定一系列目标；

（2）设定一系列描述目标的问题；

（3）定义需要回答这些问题的度量标准；

（4）开发数据收集和分析的机制；

（5）收集、确认、分析数据，并采取正确的行动；

（6）通过事后剖析的方式分析数据以评估是否与目标一致，并为其后的改善提供建议；

（7）为利益相关者提供反馈信息。

（点击查看大图）图7-3  GQM方法

度量目标是由信息需求发展来的，可能的来源涉及诸如估计项目计划参数、实施项目状态的监督、已建立的管理目标、商业计划、正规需求或合同义务、其他项目或组织级实体的经验，以及过程改进计划等内容。

现分类举例如表7-1所示。

表7-1  度量目标举例

7.2.2  度量元

度量元简单地描述为软件度量的内容，再确切地可以定义为"一个软件企业要对它的产品、项目或者过程进行量化管理时，需要关注的信息对象基本属性的描述"。度量元根据度量数据的获得方式划分为基本度量元（直接度量元）和派生度量元（间接度量元）两种。基本度量元的数据可直接度量获得，派生度量元的数据来自其他数据，通常由两个或多个基本度量组合而来。

软件工程权威Barry Boehm概括了软件开发活动中最主要的10个软件度量元，准确地描述了使用传统的软件过程产生的某些基本的经济学关系。简单描述如下：

（1）在交付之后找到并修复一个软件问题的成本，是在设计早期找到并修复该问题的成本的100倍，这是过程改进的理论基础。

（2）软件开发进度至多能够压缩25%，主要是因为缩减进度需要增加人力资源，从而增加管理开销。

（3）在开发中，每花费1美元，在维护中就得花费2美元，因此要注意度量改进维护的度量元。

（4）软件的开发成本和维护成本主要是源代码行数的函数。这是因为采用定制软件，缺乏商业构件和缺乏重用的结果。

（5）人与人的不同导致了软件生产率的最大差异，雇用优秀人才是传统的至理名言。

（6）在总体上，软件和硬件成本之比仍然在继续上升：在1955年是15:85；1985年是85:15。这说明对软件的需求、应用范围及其复杂性几乎没有限制地持续增长。

（7）只有15%的软件开发工作是专用于编码的，因此要重视需求管理、设计、测试、计划、项目控制、变更管理和工具开发等。

（8）随着软件系统规模的增大，其成本成倍增长，呈现1:3:9的关系，称之为软件产业的非规模经济现象。

（9）走查可以发现60%的逻辑缺陷和风格缺陷，但很难发现诸如资源争夺、性能瓶颈、控制冲突问题。

（10）20%的贡献者做出了80%的贡献。

在日常的开发管理过程中，我们建议使用的基本度量元包括如下一些方面内容：

（1）进度性能度量元（里程碑进展、工作包完成情况等）。

（2）成本性能度量元（实际与计划的对照，用来衡量成本的不一致情况）。

（3）工作量性能度量元（人时数、人月数实际与计划的对照，用来衡量工作量的不一致情况）。

（4）需求管理度量元（需求追踪矩阵中增加的、删除的、修改的需求数量，衡量需求易变性）。

（5）程序规模度量元（源码行数、页数，实际与计划的对照）。

（6）测试性能度量元（需要执行的测试用例数、已经执行通过的测试用例数）。

（7）度量度量元（未解决的问题、解决完成的问题、缺陷数、严重缺陷数、缺陷密度、缺陷来源）。

（8）过程性能度量元（完成的任务、行动项数）。

（9）计算机资源利用情况度量元（内存占有量、CPU占有量）。

（10）管理计划项目过程的性能度量元（对照实际进展做估计、重计划、项目总结数据）。

派生度量元通常表示为比率、复合指标或其他累计度量，有更加量化的可靠性和有意义的解释。可能使用的派生度量元如下：

（1）挣值（Earned Value，EV）。

（2）进度性能指标（Schedule Performance Index，SPI）。

（3）缺陷密度（Defect Density），发现的缺陷数目与规模的比值。

（4）同行评审覆盖率（Peer Review Coverage）。

（5）测试或验证覆盖率（Test or Verification Coverage）。

（6）可靠性度量（Reliability Measures），如平均故障间隔时间（Mean Time to Failure）等。

（7）质量度量（Quality Measures），如严重缺陷数/总缺陷数（Number of Defects by Severity/Total Number of Defects）等。

以上这些度量元中，对过程改进和开发最为关键的基本度量元包括项目的规模、投入的成本、工作量、项目进度，这些控制量的期望值及其阈值。而衡量软件质量的度量元，除这些外，还包括了生命周期不同阶段的缺陷数据及各种分布情况，确保缺陷被准确地记录和跟踪，并客观地依据缺陷状况对软件过程和最终发布进行决策。

7.2.3  度量模型

度量模型是指关于要度量哪些度量元的需求规格说明。它是通过生命周期、直接度量元或间接度量元3个方面来描述的。

（1）在生命周期各个阶段，要用到和要度量哪些度量元？它们与企业的商业目标有什么联系？

（2）其中哪些是直接度量？由谁度量？是否可以采用工具来度量？

（3）其中哪些是间接度量？如何由直接度量导出？

其中，需要根据度量的目的设计不同的度量元。例如，是为了了解发现产品当前的质量情况；是为了了解组织过程能力；还是只是为了奖惩相关人员的数据参考？不同的目的，需要设定不同的度量元，比如为了衡量产品质量，那么考察每个开发人员的代码量意义就不大。

为方便理解，使用度量信息的层次图说明一下（见图7-4）。

图7-4  度量信息的层次

（1）通过标识度量目标即项目信息需求，对涉及的数据信息进行分类，选择可度量的属性。

其中可能的信息分类包括了进度和进展、资源和费用、产品规模和稳定性、产品质量、过程性能、技术有效性、客户满意度7个方面。

（2）针对每个信息需求或者可以度量的属性，至少选择一个可度量概念，对于关键的或优先级较高的信息需要，可以选择多个可度量概念。确定合适的度量方法，获得基本度量元信息。

（3）通过度量函数对基本度量元进行适当的运算，获得相应的派生度量元数据。

（4）从与每个度量分类相关的基本度量元和派生度量元中选出最合适的度量元，此时要考虑到潜在的度量要素和信息需求的协调，同时考虑度量元本身的效率、有效性，以及项目产生这些度量元数据的能力。

（5）形成分析模型和数据指示器（例如图表、图形等方式），直观进行度量数据和信息的展现。

度量模型的构建基础是企业自身项目的实施数据。为了保证数据的真实、有效、及时，企业需要进行合理的度量定义，实施简单易用的数据搜集工作。

值得一提的是，在产品或项目的维护阶段有5个特别重要的度量元，即需求变化率以及同一需求的变化次数、配置项变化率以及同一配置项的变化次数、缺陷驻留时间（按驻留时间长短的逆序进行排列），这几个度量元对缺陷预防、缺陷发现有着至关重要的影响，北航的周伯生教授形象地把它们称之为"前人栽树、后人乘凉"。因为根据1:2公理，开发费用是1，维护费用是2，通过这5个度量元的度量数据，对于发现或者发生的缺陷问题，可以通过查找是否是由变化最多的需求引起的，是不是由变化最大的配置项引起的，这样做可以减少缺陷的定位时间，减少缺陷发现的工作量，可以使维护的效率提高40%左右。所以，这5个度量元必须包含在度量模型之中。

在项目的各种活动中，监控要求的度量模型内容如下。

（1）需求开发与管理活动度量的例子包括：

增加的需求数、删除的需求数、修改的需求数。

需求变化次数。

需求易变性（已变更需求所占的百分比） （增加的需求数＋删除的需求数＋修改的需求数）/原有的需求数。

某个需求的变更引起的工作量。

（2）项目计划活动度量的例子包括：

制定项目计划所花的工作量。

项目计划的修订次数。

每次修订计划时的成本、进度和工作量与原计划的差异。

（3）项目监督与控制活动度量的例子包括：

打开和关闭的纠正行动数。

项目里程碑日期（如计划和实际的里程碑及延迟的里程碑）。

要执行的评审次数和类型。

评审进度（计划与实际的及延迟的目标日期）。

（4）PPQA活动度量的例子包括：

计划的和实际执行的客观过程评价的偏差。

计划的和实际执行的客观工作产品评价的偏差。

（5）配置管理活动度量的例子包括：

配置项的变更次数。

配置审计次数

组织级需求度量模型示例如表7-2所示，实现阶段度量模型示例如表7-3所示。

7.2.4  基本过程

度量什么？如何度量？度量得到的数据说明了什么问题？过程如何操作？怎样才能判断某个对象是一个信号？应该对哪些信号做出反应呢？如何反应？如图7-5所示。

（点击查看大图）图7-5  度量过程示意图

在软件开发过程中，不管哪种软件度量方法，都包括了基本的软件度量过程。软件度量的基本过程如下：

（1）度量承诺：根据软件开发的技术和管理过程对软件度量的需求，确定度量目标，选择度量元，确定实施软件过程度量的侧重点，这是具有针对性地推进软件度量的第一步骤，也是高层管理者参与决策并提供相应的资源的重要环节。

（2）度量计划：基于确定的软件度量目标，根据软件开发的技术、管理、流程、问题等信息制定软件度量计划。在计划中正式确认产品、流程、角色、责任和资源相关问题及属性，为实施软件度量提供书面的、计划性的、具有可行性的、得到资源支持的保证。

（3）度量实施：根据软件度量计划对软件开发的项目、产品和过程等度量对象实施度量。通过度量收集、存储、分析有效的软件度量数据，并将度量和分析结果用于控制和改善软件过程。

（4）度量评估：对软件度量过程本身进行评估，对度量标准、度量流程、度量方法、度量对象、度量效用等做出评估，发现度量作业的问题点，总结度量作业的资产，并提出度量作业改善方案。

（5）度量改善：根据度量作业的改善方案在后续的度量作业中加以实施，将改善方案导入下一次软件度量过程之中。改善并不是水平方向上的简单重复作业，而是基于经验和教训的螺旋式上升过程，将软件度量的效用在软件开发过程中展现出来。

一旦根据商业目标，确定了需要度量哪些方面的内容、方法和责任人，就可以开始数据采集了。

7.2.5  度量方法与采集（1）

很多人都认为当度量定义完成以后，度量数据的收集应该没有什么大碍。而事实恰恰相反。实际调查表明，在用GQM方法来进行过程改进的企业中，数据收集这一活动的成本是最高的，甚至超过其他改进活动成本的总和。难点到底在哪里呢？度量一定要避免的是"垃圾进，垃圾出"。如果定义得不准确，度量数据就没有意义，肯定得不到有意义的分析。

选择可应用的度量元，按需求阶段、设计阶段、实现阶段、测试阶段、整个生命周期选择度量元，填入《度量与分析计划》。

度量的具体操作活动开始于采集数据。为采集和保存数据而定义规程，需要贯穿软件过程中，而且应具有可操作性。这意味着要把适当的人员、工具以及事件放入过程中的适当位置，为随后的分析过程改进活动捕获采集和存储数据。如图7-6所示为日志采集界面示意图。

（点击查看大图）图7-6  日志采集界面示意图

要进行采集，需要指定如何为每个要求的度量采集和存储数据。比如：要明确地说明数据如何采集？从何处采集？以及何时采集？要指定采集有效数据的规程。为了分析数据，数据要按可访问的方式存储，并且要确定是否为可能的重新分析或文档目的而保存。通常要考虑的问题如下：

（1）是否已经确定了采集频率和在何处进行度量的过程点了?

（2）是否已经建立需要的时间线来将度量结果从采集点移到仓库、其他数据库或最终用户?

（3）谁负责获得数据?

（4）谁负责存储、检索数据和数据的安全性？

（5）必要的支持工具已经开发或获得了吗？

在适当和可行的地方，支持数据的自动采集，自动化的支持可以帮助采集更准确和完整的数据。自动化支持的例子包括：

（1）带时间戳的活动日志；

（2）静态或动态制品分析。

例如，据相关机构统计，经过度量后得到的软件行业数据如下：

对于开发生产率，印度是209LOC/人月，美国为270LOC/人月，欧洲为436LOC/人月，日本达到了469LOC/人月。

对于产品质量（以交付后一年内的缺陷密度表示），美国为0.400个缺陷/KLOC，印度为0.263个缺陷/KLOC，欧洲是0.225个缺陷/KLOC，日本达到了0.020个缺陷/KLOC。

在下面举两个实际工作的度量例子，请大家体会一下。

1．任务类型工作量

"任务类型工作量"的度量方法如下表所示。

度量指标	活动工作量分布
指标表示	用表格按周统计各类活动的总工作量 用连线图按周表示各类活动的工作量
分析方法	查看各类活动的工作量分布，根据分布的情况可以看出工作量的比重
加工数据	各种任务类型的活动的总工作量
加工方法	将每一类活动的工作量相加
统计数据	每日各种活动的实际工作量
统计方法	计算各类型活动的总工作量
统计来源	日志管理系统
统计单位	人日

续表

例如：各类活动的工作量（资源模型）如下表及图所示。

任务类型工作量

7.2.5 度量方法与采集（2）

2．功能规模稳定性

"功能规模稳定性"的度量方法如下表及图所示。

"功能规模稳定性"度量示例如下表所示。

功能规模稳定性（需求稳定性）

7.3 资源模型

过程改进达到了一定的程度，需要建立资源模型。

获得软件度量的数据并不是至关紧要的，更重要的是需要根据这些数据做出合理分析，预测趋势、发现问题。其中包括：

（1）是否有在需求分析阶段可以预测项目规模的特征。

（2）在设计阶段预测软件系统潜在的错误。

（3）在软件的设计模型中，抽取定量特征从而预测软件的可维护性。

（4）在设计说明书中，抽取出定量属性来预测开发过程实现设计要求所需要的必需工作量。在程序模块代码中，寻找一些定量的关键属性预测测试的困难程度，以及通过某种程度测试后隐含在模块中残余错误数量。

（5）确定一个设计的质量，使用怎样的软件度量手段来衡量。

7.3.1 资源模型的定义

资源模型是对项目中的人员工作量花费情况建立的模型，具体包括了生命周期某个阶段的时间跨度占生命周期总时间跨度的百分比、生命周期某个阶段花费的工作量占生命周期总工作量的百分比，以及生命周期某个阶段各种工作类型的工作量占该阶段总工作量的百分比3个方面的内容。

使用资源模型可以有效地估计、分析和预测过程的实施情况，寻找改进机会，并策划、监督和控制项目资源的合理使用，从而为缺陷的预防、清除和管理提供有效的支持。

制作资源模型时，需要从组织级和项目级做一定的准备，这些准备工作是进一步开展有效度量的基础，也是有效减少缺陷的有力保证。

从组织级来讲，需要定义各种生命周期类型、定义系统类型、定义产品的物理规模衡量标准和统计生产率的规模、确定统一的个人日志模板，公司应使用自动汇集日志数据的日志系统等工具。

从项目级来讲，要求每个项目组成员遵循"日填、周报、月分析"的原则，按项目分别填写个人日志。填报时日志的"工作时间"单位最好精确到分钟，在开始时也可以以0.5小时的整数倍填报，逐步积累。此时间间隔若过小，操作必然繁杂，过大则会失去度量的意义。同时，要求在项目结束时，进行有效的项目总结，说明这个项目的成功程度。

为便于操作，说明以下几点。

（1）企业中定义的任务类别可以按照产品或项目的生命周期来划分。比如可以分为需求、设计、实现、测试、发行与维护、项目管理、配置管理及变更、产品过程质量保证、过程管理、评审、其他（适合所有人）11大类。

（2）任务细类可以包含需求、概要设计、详细设计、编码、单元测试、过程和产品质量保证（PPQA）、项目管理（PM）、配置管理、会议、请假、出差。任务细类应该根据任务类别关联，只列出某个任务类别大类的细类，如表7-4所示。

表7-4 任务大类和细类

（3）系统类型

系统类型一般可以分为操作系统、编译系统和业务系统三类，当然也可以根据公司情况进一步细分。这些系统类型与任务估计有很大的关系，它们之间的具体比例规律是1:2:4（此规则内容见附录D"各种公理的说明"）。

下面是一个数据采集的示意模板，具体的应用可以采用日志系统实现。

7.3.2  项目级资源模型

每个项目应该有一个独立的资源模型（统计数据和绘制曲线），如何创建项目级资源模型呢？

先决条件：

（1）由组织级统一定义和采用的有关工作类型、产品规模、软件/系统类型和生命周期类型。

（2）项目按软件/系统的类型、产品规模和生命周期类型分别建立资源模型。

（3）定义和采用统一的日志表模板。

（4）项目组每个成员要每日填写日志表，按周将个人日志中填写的数据汇集。

（5）要日填、周报、月分析：日志表要日填，数据要周统计和月分析。

（6）各个项目组自动地累计个人日志表的数据，并自动形成项目组周报。

（7）在项目结束后，应该注明这个项目是非常成功的、成功的或不成功的。

绘制步骤：

（1）在生命周期模型的每个阶段，形成每个角色类型的资源花费曲线；

（2）在生命周期模型的每个阶段，形成所有角色类型的资源花费曲线；

（3）按照生命周期模型，一个阶段接着另一个阶段，形成所有角色类型在生命周期模型全过程的资源花费曲线。这就是该项目的资源花费曲线，即该项目的资源模型，如图7-7所示。

（点击查看大图）图7-7  项目级资源模型图

可以看到，在项目的中期（12～19周），实现工作量很大，此时需求和设计基本没有变动，说明需求相对稳定；项目中后期（19周以后），其他任务的工作量显著增多。

7.3.3  组织级资源模型

组织级资源模型是根据组织内部的各个项目级资源模型创建的，要建立有效的资源模型，组织中至少需要有五六个有效的项目级资源模型。在已经完成的项目基础上，按照统计控制理论，使用聚类方法，选择系统类型、产品规模、生命周期类型相似的项目，执行资源模型合并，从而建立组织级的资源模型。

建立组织级资源模型时，要考虑这些模型的典型参数，否则资源模型的数据是不可比较的。在典型参数中，首先需要考虑的是系统类型，因为系统类型不一样，所花的资源是1:2:4的比例关系（参见附录D"各种公理的说明"）；其次需要考虑产品规模，一个简单的软件系统和一个大的产品系统，每一行语句工作量是1:3:9的关系（参见附录D"各种公理的说明"）；第三需要考虑生命周期模型，一般来说不同生命周期项目比较的意义不是很大。

具体步骤如下：

（1）把各个项目级资源模型一个一个地分别转换为无量纲的等价模型。这些曲线的最后一个点都等于100%，所有曲线中各个不同的里程碑点，都表达为对应时间百分比（%）。

（2）根据各个有效的项目级的等价模型，计算各个里程碑处时间跨度的平均值。在最后一个里程碑处，其平均值等于100%，组织级资源模型中所有其他里程碑处的平均值，都表达为不同的百分比（%）。

（3）根据各个有效的项目级的等价模型，计算各个阶段各个角色的工作量平均值。各个阶段不同角色工作量总和为100%，将每个角色在这个阶段的工作量对其和之比表达为百分比（%）。

（4）计算整个生命周期工作量的平均值，整个生命周期总工作量为100%，其中每个开发阶段的工作量表达为相应的百分比（%）。

注：在步骤（1）～（4）中所阐述的所有的100%和其他百分比（%）值，都要对其时间跨度和/或工作量说明其绝对值。

组织级资源模型图如图7-8所示。

（点击查看大图）图7-8  组织级资源模型图

7.3.4  软件质量度量

软件产品的度量主要针对作为软件开发活动成果的工作产品质量，独立于其开发过程。软件的质量是由一系列质量要素组成的，每一个质量要素又由一些衡量标准构成，这些衡量标准是通过度量元加以刻画而得到的。

质量度量贯穿于软件工程的全过程以及软件交付之后，在软件交付之前的度量主要包括程序的复杂性、模块的有效性和总的程序规模，在软件交付之后的度量则主要包括残存的缺陷数和系统的可维护性等方面内容。

通过将软件质量要素进行分层定义，勃姆（Barry W. Boehm）在《软件风险管理》（Software Risk Management）中第一次提出了软件质量度量的层次模型，麦考尔（McCall）等人又进一步将软件质量分解到能够度量的程度，提出FCM 模型（参见表7-5），该模型指出几个最主要的比较高层的因素影响着软件的质量，分为软件质量要素（factor）、衡量标准（criteria）和量度标准（metrics）3个层次，这几个因素又是由一些比较低层的如模块化、数据通用性等标准决定的，实际的度量是针对这些标准而言的。该模型描述了因素和它们所依赖的标准之间的一致性。

表7-5  软件质量度量FCM模型

层级	名称	内容
第一层	质量要素：描述和评价软件质量的一组属性	功能性、可靠性、易用性、效率性、可维护性、可移植性等质量特性，以及将质量特性细化产生的副特性
第二层	衡量标准：衡量标准的组合，反映某一软件质量要素	精确性、稳健性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、文件完备性等
第三层	量度标准：可由各使用单位自定义	根据软件的需求分析、概要设计、详细设计、编码、测试、确认、维护与使用等阶段，针对每一个阶段制定问卷表，以此实现软件开发过程的质量度量

其中，可以简单地描述使用缺陷密度（缺陷数量/软件规模）、缺陷检出率（某阶段当时发现的缺陷/该阶段的全部缺陷 100%）、发布前缺陷去除率（发布前发现的缺陷/（发布前发现的缺陷 软件运行的前3个月发现的缺陷） 100%）、潜在缺陷数（(100% 发布前缺陷去除率) 缺陷密度）、平均失效时间（软件持续运行时间/缺陷数量）、平均修复时间（∑缺陷修复时间/缺陷数量）等作为产品质量的指标。

在软件质量度量活动中，同样需要建立一条性能基线，作为软件产品的质量、软件测试性能评估的起点，并作为对系统评估是否通过的标准。缺陷评测的基线是对某一类或某一组织的结果的一种度量，这种结果可能是常见的或典型的，如10 000行源程序（LOC）是程序规模的一个基准，每一千行代码有3个错误是测试中错误发现率的基准。基准对期望值的管理有很大帮助，目标就是相对基准而存在，也就是定义可接受行为的基准，如表7-6所示。

表7-6 某个软件项目质量的基准和目标

关于质量度量的内容，在本书7.6节"缺陷度量"中将进一步展开。

7.4  数据质量

在数据采集过程中，需要在数据质量保证方面注意以下几点。

7.4.1  数据的真实性

使用的数据必须是已经通过检查，保证按照规则采集、无误的数据。包括：

（1）具有正确的类型：如数字型、字符型。

（2）具有正确的格式：如数据元素特有的格式，比如日期、货币。

（3）在规定的值域内：有效的值域可以是合格名称列表、合格日期或值的数字值域。

（4）完整性：度量数据要有基本的数据元素，还要包含相关定义，以及理解和解释数值所需要的上下文环境（上下文）信息。例如：每个记录纸都应该根据下列信息辨别：度量的实体、发生时间、采集时间、度量工具等。

（5）数学上是正确的：如果采集的数据包含有通过数学计算得到的数值，应当保证数学计算是正确的。

在一个稳定的组织中，各方面数据的关系都是比较稳定的。如果某个产品的数据有异常，那么就需要审慎地查看该产品的相关过程。其结果是，它可能会成为别人学习的榜样，也可能不得不忍痛取消该产品。此时，防止数据失真的手段，一方面是通过大量数据标本过滤、屏蔽掉异常数据，根据统计数字发现倾向；另一方面是通过多方面相关联的数据互相印证（例如单元测试的缺陷发现数和系统测试发现数比值，或者相同条件下多个产品的数据相互对照）。

7.4.2  数据的同步性

当两个或多个属性的数值在发生时间上相互关联时，可以认为这些度量是同步的。例如，计算生产率是经过一段时间的输出对输入的比较得到的。如果实际消耗的资源与生产的产品或度量的时间段不匹配，则生产率就会被误解出错；如果没有考虑执行过程的时间，过程内部的延迟就意味着输出统计和输入统计不对应。也就是说，没有正确的因果关系，那么用于生产率度量的输出对输入的关系可能没有意义。

7.4.3  数据的有效性

需要制定过程度量以监视不断演进的系统，其中包括设计过程中的改动、在不同的回顾或测试阶段发现的错误等。使用严格定义的度量元来指定对软件质量和性能的要求，以便使这些要求可测试。例如系统必须"可靠"，可用如下更具体的文字加以描述"平均错误时间必须大于15个CPU时间片"。

最起码的要求，要能够证明用于描述一个属性的值真实地反映了该属性。例如，项目的估计起始/结束日期为2007/3/12-2007/4/30，而实际的起始/结束日期为2007/3/12-2007/5/8。项目确实是2007/5/8结束的，延迟了1天。如果没考虑五一放假7天，就以为项目延迟了8天。

7.4.4  数据的一致性

一致性难于确定。因为这意味着检查者要能够判定一致性，就必须充分了解以前记录的数据。不过要避免错误地分析，重要的时间差是否有异常或不可能的数据元素，并验证其正确性。如果定义或采集度量的方式不一致，则会导致分析无效。比如：按照日历月份报告的工作费用含有不同的工作天数。

因此，如果数据不一致，在数据收集的过程中会发现收集的数据前后对不上。

度量定义阶段追求完美，大量增加度量元，结果无法收集数据。这是一个非常常见的现象。在度量定义的过程中，总觉得这也要收集，那也要收集。有的公司，收集的项目多达300余项。实在搞不懂这些数据真正能起到多大的作用。因此，我们不仅要关注度量的理论性，更要关注度量的可收集性，"少而精"永远是我们的追求目标，宁缺毋滥。

从日常应用的体会来看，最难统计的是Effort（工时）。因为时间进度比较清楚，哪个开发阶段从哪一天开始，哪一天结束，通过Project工具可以一目了然；代码量可以通过SLOC工具统计出来总共多少行，多少注释行等；缺陷数，应用缺陷管理工具，也不难完成缺陷的统计。但是工时就难了：

一天工作8个小时，但是实际只做了4个小时。算一天，还是半天？

一天工作8个小时，结果加班到了晚上10点多，算12小时？

项目中有系统设计师、资深工程师、一般工程师，还有实习的学生，工时标准是否一律平等？

半夜两点钟在家里和到美国出差的上司通过Skype开了一个会，又给老美来回几封E-mail，是否算2点上班？

从以上实际例子可以看出，Effort的统计是不容易的。没有好的管理手段和统计机制，极容易得到虚假数据。当只有两三个项目时，可能还监管得过来，当同时有十几个以上的项目时，各种奇怪的问题和现象都会挑战度量的定义。

软件度量是增进软件理解、预测、评价、控制和改善的方法，不过如果寄希望于以统计为基础的度量活动来获取软件开发的所谓"银弹"，就需要重温那句富有讽刺意味的名言"谎言有三种，即谎言、该死的谎言、统计数据"。

7.5.1  增加度量正确性的措施

度量是应该的，但做什么事情也都有其负面作用，为了避免度量带来的作假行为，可以考虑使用辅助策略来减小副作用。例如：

（1）将度量和考核分离。如果开发人员知道软件度量的结果会影响到自己的绩效评价、加薪升职，势必会导致开发人员有意无意的"作假"行为，失去度量工作的真正意义。例如，可能为了提高代码生产率，开发人员倾向于写冗余的代码，将本该写在一行中的语句分多行来写等。

（2）尽量减少度量对人的影响以及人员对度量的影响。软件工程包含了众多人力过程，度量活动会影响它，即当人员得知自己被观察时，效率会发生很大的变化。

（3）利用专门的系统或者专人进行统计度量工作，可以在一定程度上避免统计度量部分当事人作假。

（4）增加评审、复查、抽查等环节，避免当事人在关键环节作假。

（5）增加新度量项的试运行环节，正确度量参数在正式度量时能够尽可能合理。

（6）加大作假惩罚力度，作假说明诚信有问题，一旦发现直接开除，看看还有多少人愿意冒险，当然制度制定后是要执行的。 　

7.5.2  软件过程性能

软件过程能力描述了通过执行某软件过程能够实现预期结果的程度，一个软件开发组织或者项目组的软件过程能力提供了一种预测该组织或项目组承担下一个软件项目时最可能的预期结果的方法。

软件过程性能表示在遵循一个软件过程时得到的实际结果。过程性能数据体现了过程的实际能力，是能力的具体体现，可以把过程性能理解为在某个方面的基准，是以后项目用来参考和对照的，它是一个范围值。在低成熟度级别的过程中（如CMMI ML2和ML3），经常使用阈值（threshold）来表示，但是阈值是相对主观的值，更多地依赖于项目经理和成员的经验；过程性能基线（Process Performance Baseline）是比较客观的值，需要一定量的相同性质的数据通过统计方法得到。这个值需要时间积累得到，需要很多类似项目数据支持，从而提高了过程的客观性和透明度（数据管理），也提高了项目管理能力。

过程性能的度量包括两方面的内容，一方面是对过程的度量（如工作量、评审效率、缺陷移除等），另一方面是对产品质量的度量（故障数、缺陷密度）等。虽然过程性能包含了质量，但是为了强调质量，在过程域里面常用的词仍然是质量和过程性能目标，它覆盖了产品质量、服务质量和过程性能。

1．有效的度量

（1）如果要考察开发小组的素质，可以使用所编文档的页数、所编代码的行数、花费在各个开发阶段或花费在各个开发任务上的时间（以分钟为度量单位）、在各个开发阶段中注入和改正的缺陷数目、在各个阶段对最终产品增加的价值等5项基本度量元。当然，它们是针对软件产品开发的，对软件产品的维护或提供其他服务，可以参照这些条款给出类似的陈述。

（2）当考察软件过程质量时，对应的度量数据应该是设计工作量大于编码工作量；设计评审工作量至少应占一半以上的设计工作量；代码评审工作量应占一半以上的代码编制的工作量；每千行源程序在编译阶段发现的差错不应超过10个；每千行源程序在测试阶段发现的差错不应超过5个等5项基本度量元。

（3）为了合格，需要度量产品和过程的属性，例如看一个产品是否合格，可以度量产品的一些特性，如"Beta测试阶段少于20个错误"或"每个模块的代码行不超过100行"，开发过程的一些属性，如"单元测试必须覆盖95%以上的用例"等。

（4）需要度量当前已存在的产品和过程的属性，以便预测将来的产品。例如：通过度量软件规格说明书的大小来预测目标的大小，通过度量设计文档的结构特性来预测将来维护的"盲点"，通过度量测试阶段的软件的可靠性来预测软件今后操作、运行的可靠性。

2．度量数据如何分析

当得到有效的度量数据并且项目的度量数据积累到一定规模时，就有必要进行度量数据的分析和预测。过程能力基线（Process Capability Baseline，PCB）的产生就尤为重要，PCB的用途有：

（1）为管理层提供整个组织的项目运行性能报告；

（2）为市场团队提供整个组织的项目开发总体性能，帮助售前的估计和竞标；

（3）为项目开发团队提供整个组织的项目开发总体性能，指导项目经理估计、管理和监管项目。

度量分析最常用的工具在第8章"缺陷管理"中将有比较详细的介绍，主要也是7种工具，在度量中最常用的就是控制图。

3．如何应用度量数据

度量的核心是应用组织的PCB来更好地估计、管理和监控项目。例如：

（1）整个组织的项目工作量偏差（Total Effort Variance）；

（2）工作量的分布（Effort Distribution）；

（3）编码阶段的代码生产率（Code Productivity in Coding phase）。

通过上面列出的度量目标和软件开发活动可以发现：软件度量的目标可大致概括为两类，一是用来进行估计，从而同步地跟踪一个特定的软件项目；二是应用度量获得的数据预测项目的一些重要特性。但是，不能过分夸大这些预测，甚至认为只要使用合适的模型和工具，所获得的预测可以精确到只需使用极少的其他度量（甚至根本就不用使用度量），这种期望显然是不现实的。

7.5.3  度量过程的常见问题

度量过程中有很多值得注意的问题，这里把一些常见的问题和简单对策列出。

（1）度量过度：度量中最大的一个问题是过分进行度量，尽管技术上可以保证能够捕获几乎所有想要获得的信息，但搜集了很多的度量数据，最终进行决策的还是项目经理，还需要人，人的精力只能保证注意力集中在有限数量的数据上。选择度量元的数量时，可以根据80-20法则，将精力集中于少数与最终输出和决策有关的数据上。

（2）度量过少：度量过程中的另一个极端问题是度量太少太晚。没有足够的度量元，不能够足以真实反映项目、产品的属性。

（3）缺少管理承诺：经常将度量与评价考核混杂，度量数据用于评价个体的工作业绩会导致对雇员缺乏信任，并会影响到度量数据的质量。对度量数据进行收集与分析的唯一目的在于对产品与过程的质量实施持续的改进。

（4）缺乏度量数据的一致解释和理解：仅仅满足于数据的收集，而不使用，或者对于组织中不同的部门来说，各有各的度量重点，度量定义不严密，口径无法统一，造成对度量数据的曲解。

（5）在度量方面缺乏灵活性：在度量过程中，只是墨守成规地收集并分析数据，对于新现象和变化不敢面对，需要及时抛弃旧有的数据进行有效调整。

（6）缺乏明确的责任人：在组织和项目中，需要指定专人负责数据采集、分析与报告，明确规定每项活动相应的负责人，同时每个人都应该明白自己的责任，包括如何收集数据、谁负责收集、如何收集、多长时间收集/分析一次、分析数据报告给什么人等。

（7）将度量作为一项强制活动：在度量活动进行中，经常会给员工一种被监视的感觉。这一点需要在度量活动开始时，做好培训和管理承诺，消除那种"被强迫执行"的感觉，让有关人员在一开始就参与到有关活动中，并由他们确定度量的内容和相关数据。

（8）度量是干完"正事"之外才做的"额外工作"：如果在设计度量时没有考虑到此因素，它就会变成额外的工作，员工会抱怨度量占用了他们过多的时间，无法同时满足项目进度和产品度量方面的工作。如何设置良好的基础平台，从而保证度量与项目生命周期活动紧密结合，而不再需要什么额外的步骤去完成有关的度量。

（9）反馈信息不够迅速：度量数据应该"度以致用"，需要将度量数据分析的结果及接下来所要采取的措施在一个合理时间段内与有关人员沟通。

（10）使用同样的工具处理不同的度量需求：度量工具的功能是在确定所要度量的内容之前就已经决定的，浪费了大量的人力，导致失败。

7.6  缺陷度量

缺陷度量是软件度量的一部分，其本身并不能发现缺陷、剔除缺陷，但是有助于这些问题的解决。另外，当正确、持续地进行了缺陷度量时，产品以及过程的质量属性的数据为实施和管理过程改进活动提供了有效的基础。

数据的质量等因素，我们在本章7.4节中已经考虑了，这里仍将遵循。

7.6.1  什么是缺陷度量

软件产品质量度量，主要集中在软件的缺陷度量上。

缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰，然后通过采用一系列数学函数，对数据进行处理，分析缺陷密度和趋势等信息，从而提高产品质量和改进开发过程。一般来说，在软件质量保证过程中，需要度量的缺陷数据包括6大类缺陷发现手段发现的所有缺陷。如测试相关的缺陷，需要度量包括测试投入的工作量和成本数据、测试任务完成情况、测试规模数据、测试结果数据（包括缺陷数据、覆盖率数据）等。

（1）组织级缺陷度量，目的是了解组织的整体缺陷情况，了解客户对组织的质量满意度，建立组织基线，确定改进活动。

（2）项目级缺陷度量，目的是了解项目实时质量情况（很多项目只在最后度量，包括那些迭代式开发的项目，实际上为时已晚），预测缺陷造成的发布后维护工作量，了解客户对项目的质量满意度。

（3）个体缺陷度量，目的是了解个体缺陷产生的详细原因，并实施行动进行改进。

前两种度量大家接触较多，但第三种度量常常被忽略。这常常导致：

项目反复得到关于自己的质量评价，但很难了解如何去提高；

测试组常常能做一些改进（如增加测试覆盖、延长测试周期）来提高缺陷排除效率，但开发组没有降低缺陷产生数量的有效措施；

软件开发遵循了编码规范，但似乎对提高质量没有太多帮助。

度量得到的缺陷相关数据，分析方法可参见本章稍后的"缺陷分析"相关内容。

7.6.2  缺陷度量元

缺陷度量元的选择，也需要从度量目标出发，确定适当的度量元。例如，可以按照如下表所示的思路确定组织整体或者项目组个体使用哪些缺陷度量元。

信息需要	可度量概念	度量目的	度量元	派生度量元
通过模块的各类型缺陷数来评价软件质量	模块缺陷分布	反映缺陷按类型、严重程度、所属模块分布情况。通过度量可以客观上看出哪个模块的缺陷比较高，这样可加大对这个模块的开发投入	每个模块的各类缺陷数目	各模块的缺陷个数百分比
通过总体的各类型缺陷数来评价软件质量	总体缺陷分布	反映总体缺陷的分布情况，可看出软件的缺陷主要是哪些方面的缺陷，可帮助项目组找出问题，提高质量	每类缺陷的数目	每类缺陷占总缺陷的比例

续表

除了上边重点描述的度量元外，还可以考虑其他与缺陷度量有关的因素。例如：缺陷分布度量、基于时间的缺陷到达模式、PTR累积模型、测试用例的深度、质量和有效性、测试执行的效率和质量、基于需求的测试覆盖评估、基于代码的测试覆盖评估。

再说一下前面的"前人栽树、后人乘凉"的5个度量元。通过需求变化率、同一需求变化次数、配置项变化率、同一配置项变化次数、同一缺陷变化率这5个度量元的度量数据，查找一下是不是由变化最多的需求引起的，是不是由变化最大的配置项引起的，可以使维护的效率提高40%左右。有效选择缺陷度量元，对缺陷预防、缺陷清除和缺陷管理有着至关重要的意义和作用。

7.6.3 缺陷密度的定义

对于一个软件工作产品，软件缺陷可以分为通过评审或测试等方法发现的已知缺陷（known defect）和尚未发现的潜在缺陷（1atency defect）两种。

Myers有一个关于软件测试的著名反直觉原则：在测试中发现缺陷多的地方，还有更多的潜在缺陷将会被发现。这个原则背后的原因是，发现缺陷越多的地方，漏掉的缺陷可能性也会越大，或者说测试效率没有被显著改善之前，在纠正缺陷时将引入较多的错误。其数学表达就是缺陷密度的度量--每KLOC或每个功能点（或类似的度量--对象点、数据点、特征点等）的缺陷数，缺陷密度越低意味着产品质量越高。

缺陷密度的定义如下：

缺陷密度=已知缺陷数量/产品规模

缺陷密度与缺陷率、整体缺陷清除率、缺陷趋势、预期缺陷发现率等都有一定的关系，相关内容可以参考7.7节"缺陷分析"。

使用缺陷密度时，有一点需要注意：百分比度量表示相对频率，需要给出足够的上下关系信息。通常的描述在使用百分比和比率时不够小心，例如："需求缺陷占总数的15%，设计缺陷占总数的25%，编码缺陷占总数的50%，其他的缺陷占总数的10%"。还不能提供更加详细有力的信息，如果按照如下所述，将可以得到更多的信息，即"一个包含了8 000行代码的工程，在其开发期间，检测并排除了约200个缺陷，因此缺陷排除率为每千行代码25个缺陷。在这200个缺陷中，需求缺陷占总数的15%，设计缺陷占总数的25%，编码缺陷占总数的50%，其他的缺陷占总数的10%"。

7.6.4 缺陷密度的用途

缺陷密度是软件缺陷的基本度量，可用于设定产品质量目标，支持软件可靠性模型（如Rayleigh模型）预测潜伏的软件缺陷，进而对软件质量进行跟踪和管理，支持基于缺陷计数的软件可靠性增长模型（如Musa-Okumoto模型），对软件质量目标进行跟踪并评判能否结束软件测试。

如果缺陷密度跟上一个版本相同或更低，就应该分析当前版本的测试效率是不是降低了？如果不是，意味着质量的前景是乐观的；如果是，那么就需要额外的测试，还需要对开发和测试的过程进行改善。

如果缺陷密度比上一个版本高，那么就应该考虑在此之前是否为显著提高测试效率进行了有效的策划，并在本次测试中得到实施？如果是，虽然需要开发人员更多的努力去修正缺陷，但质量还是得到更好的保证；如果没有，意味着质量恶化，质量很难得到保证。这时，要保证质量，就必须延长开发周期或投入更多的资源。

当软件产品或者项目首次发布，并规定使用LOC计数时，可以比较容易地说出它的计划或者实际的质量等级，如"本产品共有83KLOC，在今后的3年时间里，潜在的缺陷率是2.0个缺陷/KLOC"。但当进行了修改、增强后进行产品的后续发布时，问题就会越来越复杂。

缺陷跟踪：缺陷必须被跟踪到版本源头，其中包含此缺陷的代码段，以及在哪个版本中加入、修改或增强的。当计算整个产品的缺陷率时，要用到所有缺陷；当计算新的和更改代码的缺陷率时，则只需要包含新的和更改代码的版本源头中的缺陷即可。

缺陷率度量在每个单位的基础上度量代码质量。

从用户的角度来看，缺陷率远没有缺陷总数那么重要，对他们来说，产品应该确保缺陷总数与发布版本大小无关，而随着发布版本下降。如果一个新发布版本的大小比它的前一版本大很多，则需要新的和更改代码的缺陷率应该明显地好于以往版本。

我们可以考虑如下假设的例子：

产品A最初发布时代码总量为50KLOC，估计残留缺陷总数是100个，平均有2个缺陷/KLOC。

发布第二版时，新增代码行为20KLOC，包括修改原来的4KLOC行代码（需要剔除，避免重复计算），可以计算出该版本代码总数为50 20 4 66KLOC，该版本对上一版本的缺陷率有10%的改进，估计当前版本残留缺陷新增总数可以控制在36个以内，则平均残留缺陷数为1.8个/KLOC。此时，由于此次发布版本较小，在缺陷率有10%的改进的同时，用户在缺陷数方面经历了(100 36)/100 64%的明显下降。

如果进行第三版的发布时，新增代码行为40KLOC，这比第二次发布大得多，其中包括修改原来的10KLOC行代码，则该版本代码总数为66 40 10 96KLOC，为了使用户的缺陷体验不至于失望，增加的缺陷总数不应该多于上个版本的36个，所以缺陷率目标需要控制在36/40 0.9或者更低，即该版本的缺陷率必须比第二版的好50%。

7.6.5 缺陷管理库

从缺陷发现、缺陷修复，直到缺陷解决、经验证、关闭缺陷为止，在缺陷管理的整个生命周期中记录了大量相关资料，它们是进行缺陷分析、提高产品质量所需要的宝贵信息。度量这些缺陷的发现成本、修改效益，对缺陷管理及其改进是非常有帮助的。

一般地，要求将通过同行评审、测试、管理评审、PPQA发现、项目组内部发现以及客户反馈等几种手段发现的缺陷，都需要统一存放在缺陷跟踪系统（如TD、BUGZILLA等）中，进行统一管理、统计。其中涉及缺陷的基本信息在第1章已经描述过，包括缺陷标识、缺陷描述/主题、发现时间、所处阶段、发现手段、缺陷原因、发生条件、发生缺陷的子系统、所处的模块、发生缺陷的机器、软硬件平台、严重程度、优先级、缺陷状态、缺陷起源、发现人、计划修正时间、修正方法、跟踪验证人等信息项。

其中，软件发布前的缺陷原因关键字，可能包括以下几种：

（1）需求文档：需求分析文档不明确、不详尽等原因引起。

（2）信息交流：信息交流不畅，开发成员间沟通不及时引起。

（3）编程：原始编程出错，没有客观原因。

（4）修改：由于修改缺陷而引入的新缺陷，并且引发的变更与原变更的错误是相关的。

（5）外部问题：涉及软件模块外部问题而引起。

（6）培训：项目组新成员培训不充分，或使用新工具不熟练引发。

（7）其他：指以上各种原因之外所产生的缺陷。

软件发布后缺陷原因的关键字，可以有以下几种实例：

（1）需求分析：需求分析不足等原因引起。

（2）系统设计：软件系统设计种种原因引起。

（3）程序编码：软件开发阶段中编程错误引起。

（4）维护：软件发布后程序维护时引起。

（5）实施：实施人员做软件初始化设置或系统参数设置不当等所引发。

（6）用户：泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。

（7）数据异常：运行中不明原因引起的用户数据混乱和异常。

（8）升级：软件版本升级过程中发生的问题，包括用户在升级时未按规程操作产生的问题。

（9）外部问题：所涉及软件外部问题引起的变更，包括操作系统、数据库软件、第三方软件所引起的问题。

（10）其他：指以上各种原因之外的变更，包括变更原因不明。

但需要强调，记录缺陷信息的关键是注意信息正确性。不能有人为因素失真，尤其像变更产生根本原因、变更测试情况。只有正确的信息，才能保障正确的分析结果。

7.7 缺陷分析

缺陷分析是在形成的缺陷管理库基础上，对缺陷的信息进行分类和汇总统计，计算分析指标，编写分析报告的活动。通过缺陷分析，发现各种类型缺陷发生的概率，掌握缺陷集中的区域，明晰缺陷发展趋势，了解缺陷产生的主要原因，从而有针对性地提出遏制缺陷发生的措施，降低缺陷数量。对于改进软件开发，提高软件质量有着十分重要的作用。

缺陷分析的方法很多，从简单的缺陷计数到严格的统计建模。其中，基于缺陷分析的产品质量评估包括缺陷密度（软件缺陷在规模上的分布，上节介绍过）、缺陷率（缺陷在时间上的分布）、整体缺陷清除率、阶段性缺陷清除率、缺陷趋势、预期缺陷发现率、软件产品性能评估技术等方法。基于方法论的有：不同的缺陷发现方法的效率，根据二八定理确定系统中的薄弱环节，根据二八定理分析测试用例的有效性，根据各个缺陷的发现时间和修复时间，计算出各个缺陷在系统中的驻留时间，并按逆序排序，预测在所交付的系统中的残留缺陷，缺陷年龄分析等。

缺陷分析报告中的统计数据及分析指标既是对软件质量的权威评估，也是判定软件是否能发布或交付使用的重要依据。

7.7.1 缺陷种类分析

下面以一个项目的系统测试故障为例进行分析，如图7-9所示。

图7-9  系统测试缺陷类型分布图

从系统测试故障来看，有较多故障是由接口原因造成的，细分有以下几种原因。

（1）跨项目间的接口：接口设计文档的更改没有建立互相通知的机制，导致接口问题到系统测试时才暴露出来；

（2）部门内部跨子系统的接口：由于本项目设计文档按功能规划编写，而不是按照产品组件编写，一般由主要承接功能工作的组编写该文档，接口内容可能不为其他开发组理解并熟悉，导致因接口问题而出错；

（3）系统设计基线化后，更改系统接口：没有走严格的变更流程，进行波及分析，导致该接口变更只在某个子系统中被修改，而使错误遗留下来。

根据图7-9，可以制定有针对性的改进建议：

（1）对接口文档的评审，一定要识别受影响的相关干系人，使他们了解并参与接口设计的把关；

（2）对基线化的接口设计文档的变更一定要提交变更单给CCB决策，并做好充分的波及影响分析，以便同步修改所有关联的下游代码；

（3）概要设计文档按子系统规划，详细设计文档按模块规划，通过相关组参加评审的办法来协调接口设计。

以上例子的缺陷分类只是为了描述方便，本身描述并不尽合理。实际定义缺陷分类可能有很多个维度，可以将前面所说的6种缺陷发现方法发现的缺陷，按照缺陷严重程度、缺陷来源、缺陷类型、注入阶段、发现阶段、修复阶段、缺陷性质、所属模块等方面进行分类和统计，计算以下各种缺陷的分布情况。

（1）缺陷按发现方法的分布；

（2）缺陷按生命周期注入阶段的分布；

（3）缺陷按生命周期修复阶段的分布；

（4）缺陷按严重程度等级的分布；

（5）缺陷按系统模块的分布，并按模块缺陷密度排序。

7.7.2 缺陷根源分析

对于同行评审、测试出来的缺陷进行缺陷分类，按照其类型分布，找出那些关键的缺陷类型，进一步分析其产生的根源，从而制定针对性的改进措施。

通过对功能上的分布情况进行分析，可以了解哪些模块处理比较难，哪些模块程序质量比较差，有利于程序质量的改进和提高。缺陷起源分布报告，显示了缺陷产生的根本原因上的分布情况，这种分析会帮助改进程序代码质量。

利用鱼骨图、柏拉图等分析缺陷产生的根本原因，根据这些根本原因采取措施，可以改进开发和测试过程，有重点地避免缺陷发生，提高软件产品的质量。

7.7.3 缺陷注入-发现矩阵

缺陷有"注入阶段"和"发现阶段"两个重要指标，注入阶段和发现阶段可以是软件生命周期的各个阶段。根据这两个阶段可以绘制出一个"缺陷注入-发现矩阵"，从中分析出软件开发各个环节的质量，找到最需要改进的环节（见表7-7）。

表7-7 缺陷注入-发现矩阵

在分析例子之前，先简单介绍一下其中的一些基本概念。

缺陷注入 分析矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数；矩阵的每列表示该阶段或活动注入的缺陷泄漏到后续各环节的缺陷数。

还可以通过修复阶段、缺陷性质、所属模块这样的整理（这部分内容见上一节"缺陷根源分析"），进一步扩展成缺陷注入 发现 修复矩阵，但是此矩阵表现起来就不会像"缺陷注入 发现矩阵"那么直观了。

缺陷移除率定义为：

缺陷移除率=（本阶段发现的缺陷数/本阶段注入的缺陷数） 100%

如需求阶段一共注入了21个缺陷，需求评审时只发现了4个，设计过程中发现了13个，编码和单元测试阶段发现了2个，还有2个直到系统测试阶段才被发现。这样，需求阶段的缺陷移除率 4/21 100% 19%。它反映的是该活动阶段的缺陷清除能力。

相应的还有一个概念就是"缺陷泄漏率"，即有多少本阶段注入的缺陷没有在本阶段发现而是被泄漏到后阶段环节才被发现。其计算公式为：

缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数） 100%

显然，它等于（1 缺陷移除率）。它反映的是本阶段质量控制措施落实的成效。

从表7-7可以看到，编码过程的缺陷大部分依赖系统测试发现。很显然，项目开发过程中的单元测试和集成测试活动开展不够深入。我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。

另外，我们看到，需求阶段注入的缺陷绝大部分是在设计阶段发现的。这大概是目前国内公司大部分项目的现实，需求不稳定、不明确，很多东西需要在设计过程中才能明确下来。从分析结果也可以看出，在设计评审时，也需要重新审视需求规格说明书，必要时可利用需求追踪矩阵辅助发现上游需求的缺陷。

当然，实际规划"缺陷注入 发现矩阵"时，可以依据自己的管理要求，对缺陷的发现活动和注入阶段进行细分或粗分，并且在Bug系统中提交时，需要准确地填写这些属性字段。

7.7.4 收敛趋势分析

进行趋势分析的前提是研发过程稳定，其质量表现大体一致，这样数据反映的趋势才具备可信度。本节先给出一个比较常用的分析图（见图7-10），管理者可以从中发现一些简单的缺陷发展趋势（这种缺陷可以是本文论述的广义缺陷发现手段确定的，也可以是单纯的测试手段发现的），从而了解软件质量趋势。更严格和准确的趋势分析图，可以参考8.3节"质量控制工具"和8.4节"统计技术应用"。

图7-10  缺陷发展趋势图

横轴（时间轴）：若干个均匀的时间点，以天、周或者月为单位，视项目的规模而定。

纵轴：同一类性质的缺陷数量的个数。

根据具体的缺陷发现情况，可以绘制出如下4条曲线。

（1）发现数，累计的所有被发现的缺陷数量。

（2）关闭数，累计的所有被关闭的缺陷数量。

（3）日发现，当日（当期）发现的缺陷数量。

（4）日关闭，当日（当期）关闭的缺陷数量。

其中，发现数和关闭数是两条关键的趋势曲线。

对于使用如此分析的缺陷趋势图，可以初步分析出如下几种情况。

（1）可以关闭的情况（见图7-11）

当发现数和关闭数两条曲线刚好汇集在一起时，表明所有发现的缺陷都已经被关闭了，但此时仍然存在风险。因为对于最新的这个版本，只完成了回归，还需要一些时间再进行最后一轮（甚至几轮）验证。

图7-11  可以关闭的趋势图

图7-12  暂时不能结束的趋势图

图7-12中发现和关闭的缺陷都比较少，两条曲线没有汇集，区间也还比较大，但是都很平。可能是研发和几种缺陷发现的效率都有了问题。

进展受到影响，关闭数的那条曲线很平，可能是发生了比较严重的技术难题，同时这个难题影响了测试进度（发现数曲线也很平，表明测试发现问题的进度也明显受到了影响）。

（3）无休止的情况（见图7-13）

图7-13  无休止的趋势图

发现数和关闭数两条线都呈上升趋势，而且都比较高，说明研发和缺陷发现的效率都比较高。但是，严重的是，两条线的开口越来越大，短期内看不到汇集的趋势。

关闭数持续走高，代表了3种情况：要么是产品代码质量不高，存在大量问题；要么是大量已关闭的问题又重新被打开；再有可能就是测试经理把关不严，导致重复提单。

此时，需要PPQA以及管理人员介入，协助指导发现问题所在。

（4）比较理想的状态（见图7-14）

该图中，发现数和关闭数两条曲线已经汇集，并持续了一段时间，此时的产品质量应该视为比较稳定，可以批准对外发布。

图7-14  比较理想的趋势图

这是缺陷发现 关闭趋势图的几种典型状况解析，有利于在质量管理过程中及时观察现象，通过对过程的监控来降低产品质量风险。

7.7.5  回归分析

所谓回归分析法，是在掌握大量观察数据的基础上，利用数理统计方法建立因变量与自变量之间的回归关系函数表达式（称回归方程式）。在回归分析中，当研究的因果关系只涉及因变量和一个自变量时，叫做一元回归分析；当研究的因果关系涉及因变量和两个或两个以上自变量时，叫做多元回归分析。此外，在回归分析中，又依据描述自变量与因变量之间因果关系的函数表达式是线性的还是非线性的，分为线性回归分析和非线性回归分析。通常线性回归分析法是最基本的分析方法，遇到非线性回归问题，可以借助数学手段转化为线性回归问题处理。

回归缺陷是由于修正当前缺陷时而引起相关的、新的缺陷，所以即使在测试阶段，也会产生新的缺陷。

我们的一个项目数据表明，严格地执行需求/设计评审和代码审查，可以使开发质量有200%的提高，其因果分析表明，常有一些缺陷本来可以在开发周期的早期发现，对缺陷源数据的分析指出，代码开发阶段的缺陷注入是最高的。强烈重视评审和代码审查，使得审查覆盖率更高，效果更好。

可以分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，但到了某个时间点处，发现的缺陷数反而呈上升趋势，那么，这些点往往发生了一些特殊的事件。例如：

（1）在该时间段，送测的回归版本增加了新的功能，导致缺陷注入；

（2）该回归版本开发部没有进行集成测试就直接送测。

类似等等问题。

前面反复强调，越到后端发现的缺陷，用于问题复现、问题定位和缺陷修复花费的时间和成本就越多，软件工程经济学中"1:10:100规则"也揭示了这种情况。那么有什么方式可以在项目早期识别哪些活动没有充分投入，或者没有运用合适的技术方法导致缺陷被泄漏到下游，从而防范于未然呢？

我们可以在组织的典型项目中运用一定的抽样原则，抽样出某个阶段的若干个缺陷，从技术、流程、方法等方面去分析更适合、更经济的清除方法，然后把这些方法固化到日常的项目实施过程中，就可以逐步降低上游对后端的缺陷泄漏。

下面以一个项目的系统测试阶段发现的故障为例，进行过程有效性回归分析，如表7-8所示。

表7-8  回归分析举例

从表7-8可以看出，真正需要遗留到系统测试阶段才能发现的故障只有7%，大部分故障在集成测试和设计评审过程中就应该被发现。

导致在集成测试过程中未能充分发现这些缺陷的原因主要有：

（1）测试环境不具备，导致部分测试项必须到系统测试阶段才具备测试条件；

（2）测试设计中某些测试项的缺失，需要加强测试设计的评审工作；

（3）在回归测试过程中，开发部只对测试进行了验证，而对缺陷修复波及的范围缺乏分析和验证。

针对这些分析结论，我们就可以制定针对性的整改措施。例如：

（1）加强开发部的缺陷波及分析和验证工作；

（2）项目计划中加强对测试需求的关注，提前采购和协调必要的测试环境；

（3）每次回归对泄漏的缺陷，开发部都要作回归测试，并根据结果，完善单元测试和集成测试的测试设计。

7.7.6 缺陷排除分析

前面我们已经讨论过软件缺陷和失效的定义，失效是缺陷的实例化，通过观测失效的不同原因数目可以近似估算软件中的缺陷数目；还可以通过缺陷排除数据，进行有效的缺陷排除分析。

缺陷率的通用概念是一定时间范围内的缺陷数与错误几率的比值。软件产品缺陷率，即使对某个特定的产品，在其发布前后不同时段内也是不同的。例如，对应用软件的角度来说，90%以上的缺陷是在发布后两年内被发现出来，而对操作系统，90%以上的缺陷通常在产品发布后需要4年的时间才能被发现出来。

1．整体缺陷清除率

假设F为描述软件规模用的功能点， 为在软件开发过程中发现的所有缺陷数， 为软件发布后发现的缺陷数，D为发现的总缺陷数，则D = = 。那么，对于一个应用软件项目，有如下计算软件质量的方程：

质量= /F

缺陷注入率= D/F

整体缺陷清除率= /D

如果某个系统有100个功能点，开发过程中发现了120个错误，提交后又发现了22个错误，则：

=120，=22，D===142

质量（每功能点的缺陷数）=/F=22/100=0.22（22%）

缺陷注入率=D/F=142/100=1.42（142%）

整体缺陷清除率=/D=120/142=0.845（84.5%）

有资料统计，美国的平均整体缺陷清除率目前只达到大约85%，而对一些具有良好的管理和流程等著名的软件公司，其主流软件产品的缺陷清除率可以超过98%。

2．基于阶段的缺陷排除分析

阶段性缺陷清除率是测试缺陷密度度量的扩展，除测试外，还跟踪开发周期其他阶段中的缺陷，包括需求评审、设计评审、代码审查。基于阶段的缺陷排除分析一般称为DRM模型，这个模型概括了3种度量之间的关系，它们分别是缺陷注入、缺陷排除和有效性。该模型把一组错误注入率和一组阶段有效性作为输入，然后一步一步为缺陷排除模式建模。

下面通过一个稍微复杂些的注入 发现矩阵例子，介绍一下DRM建模的分析过程。在矩阵中，由于某种特殊原因，没有进行正式的需求评审，但是在需求阶段注入缺陷的可能性更大，在以后开发阶段会发现。测试阶段的对角线值表示不良修复数量，本例中，所有不良修复都是在同一阶段内被检测并修补好的。

通过公式的计算，这样就有了上表的简化视图，它是这样工作的：

开发阶段出口处存在的缺陷数=前一阶段泄露的缺陷数+本阶段注入的缺陷数-本阶段排除的缺陷数

其中，概要设计评审有效性可以根据此阶段排除的缺陷数730、从入口处（需求阶段）泄露的缺陷数122，以及当前阶段注入的缺陷数859计算得出：

730/(122 859) ′100%=74%

单元测试有效性是通过单元测试排除的缺陷数332、入口处存在的缺陷数（从以前各阶段泄漏的缺陷数）122+859+ 939+1 537 - 730 - 729-1 095= 903，以及当前阶段注入的缺陷数2计算得出的：

332/(903+ 2)′100% =37%

其他的缺陷排除有效性计算类似，得到表7-9。

表7—9 有效性计算结果

续表

例如，如果对新的软件发布版本制定质量计划，就可以根据将要进行的改进计划修改模型参数值，如计划对单元测试的有效性改进10%，最终产品的质量会提高多少？之前每阶段在该阶段开发完成前的缺陷率新目标又是多少？如果在技术培训和强化培训方面投入，并计划是错误注入率下降20%，结果又会如何？

这是一个组织的积累数据，如果基于相同的过程经验还要开发类似的软件产品，就可以对表7-9中的数据建模后进行分析并得到答案。这种执行的效果是显而易见的，遗憾的是，目前国内数据度量、过程管理方面，类似的应用不足。

7.7.7 ODC缺陷分析

ODC，英文全称为Orthogonal Defect Classification，译作"正交缺陷分类"，由IBM 的waston中心推出。

当需要分析与开发者和测试人员相关、与开发阶段相关、与顾客的满意程度相关的产品质量的外部属性时，据IBM介绍可以通过ODC分析这些属性的结果提高软件的质量。

ODC技术对于以下3种情况特别适用：

（1）开发生命周期相对来说是一个很漫长的过程，包括后续的改进工作。例如，这个项目包括多个软件版本或者一个版本有多次迭代。

（2）潜在的缺陷数目是相当大的。缺陷数目越多，客观的分析结果也越多，对我们了解软件质量越有好处。

（3）这个项目已经将"高质量"设定为它的主要目标之一。

ODC技术将每一个缺陷按不同维度进行分类。当缺陷数量较多时，也可以对缺陷进行抽样分析。目前ODC技术的主要维度包括发现问题的活动（分为8类）、触发因素（分为36类）、结果影响（分为13类）、问题根源对象（分为6类）、缺陷类型（分为39类）、缺陷界定（分为3类）、责任来源（分为5类）、缺陷年龄（分为4类）8个，共114类。根据大量缺陷分类后产生的各类缺陷的统计数字，结合缺陷定位信息（所属子系统、模块、特性）进行多维度正交分析，就能准确确定产品主要质量问题区域，识别缺陷引入和去除过程的重点改进对象，实现对过程和产品的精确改进指导。将传统度量手段和ODC技术相结合，能实现对过程和产品的宏观评估和微观解剖。

将一个缺陷在生命周期各环节的属性组织起来，从单维度、多维度来对缺陷进行分析，从不同角度得到各类缺陷的缺陷密度和缺陷比率，从而积累得到各类缺陷的基线值，用于评估测试活动、指导测试改进和整个研发流程的改进；同时根据各阶段缺陷分布得到缺陷去除过程特征模型，用于对测试活动进行评估和预测。7.7节中前面几个小节描述中涉及的缺陷分布、缺陷趋势等都属于这个方法中的一个角度而已。

7.8 小结

软件度量是针对软件开发项目、过程及产品进行数据定义、收集以及分析的持续性定量化的过程。有效度量的作用在于能够帮助软件组织认清自身的能力，理解、评价、控制、预测和改进软件工作产品或软件过程。根据对度量数据结果的分析，进一步为它们的生产和服务制订出可行的计划；及时找到变化趋势，预测问题，发现或者采取有效手段预防缺陷；不断改进软件开发过程。

软件度量活动一般从项目级开始，逐步向上扩展为过程度量和产品度量，向下扩展为个体行为度量。软件度量中关键的内容是度量模型的建立和资源模型曲线的绘制及应用。

度量模型是指关于要度量哪些度量元的需求规格说明。它是通过生命周期、直接度量元或间接度量元来描述的。

资源模型是对项目中的人员工作量花费情况建立的模型，具体包括了生命周期某个阶段的时间跨度占生命周期总时间跨度的百分比、生命周期某个阶段花费的工作量占生命周期总工作量的百分比，以及生命周期某个阶段各种工作类型的工作量占该阶段总工作量的百分比3个方面的内容。资源模型可以有效地估计、分析和预测过程的实施情况，寻找改进机会，并策划、监督和控制项目资源的合理使用。

在产品或项目的维护阶段有5个特别重要的度量元，即需求变化率以及同一需求的变化次数、配置项变化率以及同一配置项的变化次数、缺陷驻留时间（按驻留时间长短的逆序进行排列）。

缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化，有序而清晰地统一管理分散的缺陷数据，然后对数据进行数学处理，分析缺陷密度和趋势等，从而提高产品质量和改进开发过程。一般来说，要度量的数据包括6大类缺陷发现手段发现的所有缺陷。为了达到判断出缺陷产生原因的目的，基本度量元可以选择缺陷数量排行、缺陷发现时间、缺陷清除时间，派生度量元可选择整体缺陷清除率、阶段缺陷清除率、缺陷驻留时间等。

缺陷分析是将软件开发、运行过程中产生的缺陷进行必要的收集，对缺陷的信息进行分类和汇总统计，计算分析指标，编写分析报告的活动。对泄漏的缺陷作回归测试和回归分析，可以完善单元测试和集成测试的设计；根源分析对缺陷进行分类，按照其类型分布，找出关键的缺陷类型，分析其产生的根源，从而制定有针对性的改进措施；趋势分析关注测试过程中两个重要的变化趋势：一个是缺陷发现数量的趋势，另一个是缺陷修复数量的趋势；解析缺陷发现 关闭趋势图的几种典型状况，有利于在质量管理过程中及时观察现象，通过对过程的监控来降低产品质量风险。