容积 KPI 说明了在开发中生成的逻辑或其它相关工件的总量。在一些组织中，逻辑的容积可能有关联性的想法已经引起争论，有时候会受到某种程度的怀疑，甚至轻视。然而，“容积”的基本思想对三种软件开发规程来说是重要的：项目预测、质量保证，和程序设计。
影响维护成本的重要因素是正被讨论的代码基数的大小。一般确实是比起较小的代码基数，大型的代码基数要用更多的人来维护制度上的存储并且保持最新。人们可能争论维护工作是否与代码基数的大小线性相关，而事实上对此问题的回答可能是因素的功能，包括软件设计方法、组件化的程度、资源技能水平、集中对分布的团队，以及外包或境外人员的使用。然而，对于您的管理层要明确维护团队的大小和组成与团队所维护的项目的大小和组成之间的关联的最好方法是开始度量并应用容积 KPI。
这种 KPI 可以为项目预测增加好处，因为它允许软件团队来沟通，概括地说，响应客户需求的团队的效率和生产力、增加请求，和软件缺陷。在依据软件开发的客户投资的模型的环境中，例如许多公司的 IT 部门，容积 KPI 可以作为有价值的可视化工具在同样的页面上从字面上加入软件团队及其业务单元副本。
容积还对质量保证很重要，由于软件产品的大小是缺陷密度比率的分母。随着时间观察容积的趋势，显示出了关于缺陷密度的一些细小区别，并且帮助加强对这种 KPI 的洞察。举例来说，在质量保证有机会发现并进入与新代码有关的缺陷之前，产品的容积可能在一小段时间内快速扩展，这将产生表面上减少缺陷密度的影响，因此掩饰了一个事实，实际的情况可能需要增加测试脚本或测试自动化来审计新的代码。类似的情况出现在当重构代码，将代码基数分为更谨慎地合理的程序或组件集合的时候。当整体代码大小下降时，缺陷密度上升，看起来好像整体的质量水平更糟糕了，既使代码基数已经转移到改进的可维护性和较多的代码覆盖的地方。通过监控容积 KPI，以及缺陷密度，质量保证可以观察这些重要的趋势，从而计划。
程序设计人员易于对容积有相当本能的反应，但是一般看不到代码基数大小的整体变更趋势，例如，趋势可能是耗时的，并且很难得到并看出。但程序设计人员的内脏检查非常有意义，并且直入问题的心脏。程序设计人员知道什么时候他们将处理肿胀的代码，并且意识到 —— 经常强烈地 —— 对项目的负面影响。在这种情况下，就像缺陷密度是程序设计效率的追溯的量度一样，程序设计人员可能直观地将容积应用于软件设计的效率的追溯的量度。当程序设计人员看到时，容积的快速，未预期的增长是糟糕设计的暗示。它们揭示了一米宽一寸深的，不鼓励可测性或可维护性，以及一般会破坏设计雅致的技术栈。
容积的典型量度包括 LOC、SLOC、ELOC、语句、分号、方法数、类数和文件数。行业一般支持一种或另一种 LOC 作为大小的指示，如根据每 LOC 的缺陷计算的几乎不变的缺陷密度所示。
因为一些人将容积认为是引起争议的量度，有时候组织陷入争论，什么容积量度是“最好的”。在一定程度上，如果您根本没有度量容积，那么详述此争论就没有意义。几乎没有什么软件量度是伟大的，但是许多(像 LOC)是好的，重要的是增强管理的治理能力，以及团队对他们工作的重要维度的可见性，KPI 可以并将随着时间改进。
通常，推荐在同样的基础上评估易变率和容积。如果您根据 LOC 中的随时间变更的总量度量易变率，那么您会希望也根据 LOC 中随时间的净变更度量容积。
工作产品 KPI
有许多可以用于评估软件工作产品(不论是组件、子系统、服务，或应用程序)的质量和完整性的工具。这些工具的选择和使用形成了组织治理计划的主要部分。
通常，这些工具向静态(源代码)或动态(运行时)环境应用一组规则。当引入治理计划时，违反规则的行为一般都确定为对项目标准的违规行为。乍一看，这可能听起来有点苛刻，在缺少对一线希望的偏移的情况下过分强调负面。但是存在一个实际的理由：测试违规行为相对容易，但是不同于缺少违规行为，测试遵循要难得多。这个治理主题有时候会引起争论，含糊地听起来有哲学的，像“好的仅仅是缺少邪恶吗?”虽然对其的回答有一点困难，但是肯定的是工具可以找出确实邪恶的安全性漏洞、复杂的代码，和性能瓶颈。
当引起管理层的注意时，来自这些工具的输出就成为了工作产品 KPI。关于这些工具的问题是，他们是被设计用来由个别开发人员使用的，还是在运行时环境中(在该环境中按照不规律的频率执行评估，并且结果不保留)使用的。为了参与治理计划，这通常意味着将工具和一致的框架相集成，进行分析和报告。
承认了厂商，例如 SourceIQ 已经跨接了工具和管理报告之间的间隔，让我们来分析可以快速并积极影响开发治理的工作产品 KPI： 编码规则、语言规则，和复杂性。
编码规则
组织出于最佳的理由采用编码规则。按照公共的规则开发的代码在团队成员之间更易接受和维护，更容易在大型组织中分享，并且在维护中更节约成本，特别是当转给不是原始工作一部分的团队时。
不幸的是，经常出现的情况是，团队中的个人随着时间有选择的应用并侵蚀这些规则。在没有工作产品 KPI 的情况下，在管理层无意识的情况下，出现了代码基数的退化。因此，当新的团队成员艰难地符合速度时，同行审查难以达到不可行的程度，或者维护成本上升，根本原因是对试图修正问题的管理层不可见。
思想上的重要转变出现于团队成员看出了他们对同事的职责，并且加入了另每个人的工作更简单的编码规则。有许多可以用于自定义组织的特殊编码规则的工具和脚本。当这些工具加入到治理环境中时，管理层就能够在增加的法规遵循方向上轻推开发组织。在途中，可能有一些挫折，但它是健康的事情，因为它可以进一步改善规则。累积影响倾向于非常积极，团队成员能够共享代码，在团队中调试，并且概括地了解彼此的工作。
语言规则
语言规则类似于编码规则，但是一般来自于开发组织之外，而不是从内部。举例来说，Sun Microsystems 发布了一组 Java 语言 9 的编码约定。商业和开源工具可以自动地根据语言厂商的规则评估代码，一般使用令调整规则使其满足开发治理计划的需求很容易，的规则引擎和语法检查。在某些情况下，语言厂商的规则相当良好，并且可能只影响到代码的表示或维护的某个小方面。然而，在其他情况下，代码中违反规则的表现可以是一个红色的标记，即使编译器让其通过，在运行时也会严重地出错。
随着工具，例如这些工具并入治理计划，在今天的行业中，软件工具正经历快速的变更和演进是毫无意义的。IBM® 最近收购了 Watchfire，强调了可以查明安全弱点的工具之间的成熟度，并且考虑与开发目标和审查需求相关的这类工作产品 KPI 的关系对您来说是有意义的。重要的事情是保持行业趋势的优势，并且消息灵通。
复杂性
上面提到的工作产品评估一般是性质上的，复杂性分析形成了强大工作产品 KPI 的基础。甚至超过编码规则，复杂性分析是在您的系统中确定最有风险的，更容易出错的，最困难且维护成本最高的代码的基础。许多组织没有成功地利用这一关键量度，因为它被认为是，对已经有负担的开发团队来说是太花费时间或太困难了。但是随着源自管理量度的自动化系统的到来，例如 SourceIQ，管理层现在可以将复杂性作为至关重要的维度加入到开发治理计划中。
从 IBM Rational ® 工具中获得 KPI
组织根据表示为 KPI 的标准评估，利用他们的 Rational 基础架构实现与那些标准相关的真正的法规遵循报告。
这可能类似于一点小跳跃，但让我们抛开某个历史的包袱。一些人将 Rational 套件视为工具的集合：开发人员使用 IBM Rational ClearCase®，质量保证团队使用 IBM Rational ClearQuest®，等等。但是 Rational 基础架构远不止一组工具。它是一组集成工具，包含了关于关键开发过程的事实和事务的宝藏，并且可以对于根据标准的法规遵循报告进行挖掘和分析。
Rational 基础架构是获得有效治理所需的管理 KPI，以及确保前面提到的动态治理三元组仍旧完整，有快速的响应，并且跨团队(不论是本国的、境外的，或全球分布的)有效，的基础。有了统一变更管理(Unified Change Management，UCM)，该基础架构甚至更强大，而其洞察力甚至更集中。
Rational 套件的三个成员提供了您需要的所有基础：ClearQuest、ClearCase 和 IBM Rational Build Forge®。
ClearQuest 提供关于评估过程 KPI(允许对开发过程的端点的治理)所需的增强的请求和缺陷的事实和事务的编年存储库：输入的请求和输出的审查。很明显存在 ClearQuest 的替代方案，但是它拥有关于 UCM 的特别优势，如下所述。
ClearCase 是编年的存储库，可以从其中获得不同时间的过程和工作产品的状态。有了 UCM，ClearCase 增加了治理价值，发现了用于许多外部审计所需的变更的永不改变的存储库的想法。下一个部分中将探究该存储库的非凡价值，读者当然要熟悉关于 ClearCase 的配置选项，例如 UCM 和多站点 10 。
ClearQuest 启用的 UCM 是向开发治理计划授权牵引力的理想配置。不论您的开发方法是 Agile 或是瀑布的，这个技术减少了将开发过程标准化的困难，并且提供通过变更顺序、编码，和测试表示变更的事务的至关重要的环境。
虽然 ClearQuest 和 ClearCase 提供了数据和环境，但是 Build Forge 是自动地生成法规遵循报告的工具。由于许多组织每晚构建或连续的集成，这解决了法规遵循报告频率和周期性的问题，并且令管理者更敏感地处理违规行为的情况。
多么持久?
软件开发行业在不断地彻底改造自己，拆用老的思想和方法，并将它们转换为一些新的，不同的，且有希望更好一点的东西。这种流直接影响了可以设置的标准、可以施加的管理控制，以及可以实现的治理。
举例来说，许多组织热切地希望从动态语言，例如 Ruby 和 PHP 中获得好处。但是许多这些同样的组织不能接受伴随他们认为是“作家，发布”的开发过程的风险，该过程缺少伴随传统语言在编译和连接阶段的更结构化的检查点，以及关于那些步骤的工具。
有时候退回一步，评估优先权，并询问问题是有帮助的：什么是真正要紧的?在和许多开发组织一起分析了该问题之后，SourceIQ 得到了相当出乎意料的回答，它与我们在软件开发行业中看到的波动相关。
在我给出答案之前，让我们来看看事物是如何波动的。软件工具相当快速地波动，厂商每年发布主要的新更新，有时候甚至更快。程序设计语言波动的少一些，每七到十年主要变化一次。形成 KPI 的知识基础的软件量度波动的更缓慢，许多回溯到二十到三十年前。
但是从经验出发，我们已经发现了软件开发最持久的资产是组织生成的实际的源代码本身。一旦创建了，它可能就要经受看上去不停的维护。但是代码的夕阳看来很少到来。60 年代做主机 IT 开发的公司仍旧在原始的逻辑上运行核心系统。
需求、软件设计，甚至测试脚本与代码比较有相对短的预期寿命。虽然重要，但是它们似乎很快就过时了，失修或停用，并且报废了。但是代码不仅是耐用的，它甚至可以获得一再构建于系统中的隐匿的质量，即使很久以后，它不再被任何东西参考!
本讨论绝不是说拿开应该应用于需求定义、设计，和测试的精确和审查等级。如果有什么的话，来自这些规程的工件可能得益于像代码那样在长期过程中是完整的。
但是从纯实际的立场出发，代码的持久特性强调了开发治理计划的优先权。程序设计人员将来往于项目中。代码可能转移到不同的大陆上。它运行的平台将变更。办公大楼上的公司名称甚至可能变更，但是代码将以违背信念的方式持久下去。因此，管理层对项目的代码基数、起源和当前状态，及根据有意义的 KPI 的核心集合的评估了解的越多，团队将在调整代码基数以满足未来的需求方面得到更多的授权。
我如何开始?
如果您拥有 IBM Rational 基础架构，一个开发治理的需求，并且您正渴望开始一些管理 KPI，那么要做的第一件事情是开始询问一些问题。已经有什么标准了?缺少什么标准?标准的遵循对开发组织来说是优先的吗?如果您有外包或境外合伙人，那么您的标准是他们的服务等级协议的一部分吗?
如果治理将受到变更管理基础架构的促进，并且以变更管理基础架构为基础，那么您将想要标准使用模型。这些模式适当地处于或跨越项目和团队了吗?
另一组问题与管理 KPI 的受者相关。虽然量度没什么新的，但是一些人可能需要更新他们对 KPI 的理解，以及那些 KPI 与完成开发治理之间的相关性。构建一致并共享的理解的最佳方法是涉及所有受到开发治理影响的接受者：架构师、开发人员、质量保证分析人员、发布工程师，也许甚至有业务单位联络人。当人们开始讨论并彼此问问题时，他们开始与结果有利害关系了，并且取得了成功执行治理计划的所有权。
最后，治理是管理功能，反对不得不停在某处。谁负责治理?谁是有责任的?负责实施治理、按标准实现，并且评估法规遵循的人有权与工作功能的执行相适合吗?
随着标准开始成型，着重于将要在开发团队间共振的量度和 KPI 的小的核心集合，提供上级管理洞察，可以在短期内采用并理解。本文介绍了用大部分团队完成了该工作的一个集合。您的团队可能有其自己的复杂性，或者细微差异，并且可能需要不同的东西，但“less is more”的指导原则仍旧可用。
一旦您到达了最初的标准集，就是时候计划实现了。除非管理 KPI 对强制的法规遵循来说是完整的，否则它们需要一点提升来帮助它们获得牵引力。最好的方法是确保 KPI 向管理接受者提供价值，并且确保很快发现好处。一旦管理层开始使用过程 KPI 来通过过程和审计跟踪回顾来向前获得可溯性，并且当软件项目转移到运行时更低的维护成本，改进的健壮性的状态时，结果就实现了。
在项目接着项目，或者团队并团队的基础上进行实现。尝试项目和代码一致的企业跨度的计划的组织倾向于不超越他们自己的官僚权力，并且因此在工作中受挫。通过向先遣团队授权来强调项目的成功的更精益的方法更可能产生热情和成功，并且增加了培育开发人员的好处，他们会将所学到的有价值的经验传到下一个项目中。
最后，记住利用您的 Rational 基础架构。管理 KPI 通常不出自于开发者 IDE 或者在书架上接尘土的工具。它们出自于坚固的基础架构组件，像 Rational，这些组件安全，可以进行外部的详细审计，并且给出一致的答案。
关注此文的读者还看过：
