这种 KPI 可以为项目预测增加好处，因为它允许软件团队来沟通，概括地说，响应客户需求的团队的效率和生产力、增加请求，和软件缺陷。在依据软件开发的客户投资的模型的环境中，例如许多公司的 IT 部门，容积 KPI 可以作为有价值的可视化工具在同样的页面上从字面上加入软件团队及其业务单元副本。
容积还对质量保证很重要，由于软件产品的大小是缺陷密度比率的分母。随着时间观察容积的趋势，显示出了关于缺陷密度的一些细小区别，并且帮助加强对这种 KPI 的洞察。举例来说，在质量保证有机会发现并进入与新代码有关的缺陷之前，产品的容积可能在一小段时间内快速扩展，这将产生表面上减少缺陷密度的影响，因此掩饰了一个事实，实际的情况可能需要增加测试脚本或测试自动化来审计新的代码。类似的情况出现在当重构代码，将代码基数分为更谨慎地合理的程序或组件集合的时候。当整体代码大小下降时，缺陷密度上升，看起来好像整体的质量水平更糟糕了，既使代码基数已经转移到改进的可维护性和较多的代码覆盖的地方。通过监控容积 KPI，以及缺陷密度，质量保证可以观察这些重要的趋势，从而计划。
程序设计人员易于对容积有相当本能的反应，但是一般看不到代码基数大小的整体变更趋势，例如，趋势可能是耗时的，并且很难得到并看出。但程序设计人员的内脏检查非常有意义，并且直入问题的心脏。程序设计人员知道什么时候他们将处理肿胀的代码，并且意识到 —— 经常强烈地 —— 对项目的负面影响。在这种情况下，就像缺陷密度是程序设计效率的追溯的量度一样，程序设计人员可能直观地将容积应用于软件设计的效率的追溯的量度。当程序设计人员看到时，容积的快速，未预期的增长是糟糕设计的暗示。它们揭示了一米宽一寸深的，不鼓励可测性或可维护性，以及一般会破坏设计雅致的技术栈。
容积的典型量度包括 LOC、SLOC、ELOC、语句、分号、方法数、类数和文件数。行业一般支持一种或另一种 LOC 作为大小的指示，如根据每 LOC 的缺陷计算的几乎不变的缺陷密度所示。
因为一些人将容积认为是引起争议的量度，有时候组织陷入争论，什么容积量度是“最好的”。在一定程度上，如果您根本没有度量容积，那么详述此争论就没有意义。几乎没有什么软件量度是伟大的，但是许多（像 LOC）是好的，重要的是增强管理的治理能力，以及团队对他们工作的重要维度的可见性，KPI 可以并将随着时间改进。
通常，推荐在同样的基础上评估易变率和容积。如果您根据 LOC 中的随时间变更的总量度量易变率，那么您会希望也根据 LOC 中随时间的净变更度量容积。
工作产品 KPI
有许多可以用于评估软件工作产品（不论是组件、子系统、服务，或应用程序）的质量和完整性的工具。这些工具的选择和使用形成了组织治理计划的主要部分。
通常，这些工具向静态（源代码）或动态（运行时）环境应用一组规则。当引入治理计划时，违反规则的行为一般都确定为对项目标准的违规行为。乍一看，这可能听起来有点苛刻，在缺少对一线希望的偏移的情况下过分强调负面。但是存在一个实际的理由：测试违规行为相对容易，但是不同于缺少违规行为，测试遵循要难得多。这个治理主题有时候会引起争论，含糊地听起来有哲学的，像“好的仅仅是缺少邪恶吗？”虽然对其的回答有一点困难，但是肯定的是工具可以找出确实邪恶的安全性漏洞、复杂的代码，和性能瓶颈。
当引起管理层的注意时，来自这些工具的输出就成为了工作产品 KPI。关于这些工具的问题是，他们是被设计用来由个别开发人员使用的，还是在运行时环境中（在该环境中按照不规律的频率执行评估，并且结果不保留）使用的。为了参与治理计划，这通常意味着将工具和一致的框架相集成，进行分析和报告。
承认了厂商，例如 SourceIQ 已经跨接了工具和管理报告之间的间隔，让我们来分析可以快速并积极影响开发治理的工作产品 KPI： 编码规则、语言规则，和复杂性。
编码规则
组织出于最佳的理由采用编码规则。按照公共的规则开发的代码在团队成员之间更易接受和维护，更容易在大型组织中分享，并且在维护中更节约成本，特别是当转给不是原始工作一部分的团队时。
不幸的是，经常出现的情况是，团队中的个人随着时间有选择的应用并侵蚀这些规则。在没有工作产品 KPI 的情况下，在管理层无意识的情况下，出现了代码基数的退化。因此，当新的团队成员艰难地符合速度时，同行审查难以达到不可行的程度，或者维护成本上升，根本原因是对试图修正问题的管理层不可见。
文章来源于领测软件测试网 https://www.ltesting.net/
