考虑相对于 CMMI，展开与开发过程相关的标准范围，并且令管理层注意到提升对这些标准的遵循的关联性和可见性，是从成熟度级别为 2 的“受管理的过程”转化到 成熟度级别为 3 的“定义的过程”的关键成分。随着转化为分别与 成熟度级别为 4 和 5 相关联的“数量上的管理”和“最佳化”状态，过程 KPIs 增加了关联性和效用。
过程 KPI 的细节与过程本身相关，并且为此，必须稍微了解开发方法、实践和规程。然而，过程拥有跨方法边界应用的某些一般的特征。也许您拥有带有强组件倾向的软件工厂，或者也许您对服务于业务单元部门的开发竖井垂直地分层。也许您正使用瀑布开发方法，或者您已经采用 Agile。不论您为开发设置的什么过程，该过程拥有离散的过程。这些过程有希望由团队很好地定义，并且广泛地了解，但是甚至是成熟度级别为 1 的组织都在勉强追求过程。此外，过程拥有确定定义的特征。它们拥有输入、输出，和检查点，否则将其置于一个 CTO 的更多彩的语言中，它们会有“gazintas、gazoutas，和 ga-whaaaaat”?
过程 KPI
过程 KPI 基于上面介绍的一般特征，并且分为两个部分：易变率和容积。
过程 KPI 的接受者一般是那些负责了解并优化过程的人，以及负责随着时间监控趋势，产生了关于过程遵循（非遵循）的洞察 8 。从开发治理立场上讲，过程 KPI 对管理程序设计活动的人来说更有效且可诉，对负责质量保证的人来说没那么有效且可诉。若是真的，那么一般的理由是质量保证没察觉自己会影响开发方法，或者命令对它的变更，这是功能规程的传统分离，“12 尺的砖墙是用程序设计人员和 QA 之间的剃刀线盖成的”在行业中仍旧普遍。在较进步的开发文化中，开发人员和质量保证合伙人更积极地参与测试方法和法规遵循，建立对要应用的标准的一致同意，并且用过程 KPI 实现更多结果。然而，不论是传统的或是进步的，对易变率和容积的理解是评估软件项目的基础。
易变率 KPI
随着过程从开始到结束，它经受着特定量的易变率。易变率度量着完成目标过程中波动的数量和比率。易变率一般有两种度量方式：预计的和实际的。预计的易变率表明了完成任务、里程碑，或项目中所出现的总波动的估计量，然而实际的易变率度量了实际出现的波动。从管理的立场出发，易变率是熟悉的概念，与同样包含了“预算对实际”的概念的项目计划实践相关联。
当管理层了解了预计的对实际的易变率时，就能够评估与计划的差异，并且设法控制正要脱离控制的项目。从根本上，这是个治理问题：评估对标准的遵循 —— 预计的项目易变率曲线 —— 从而使管理层适当地使团队完成成功的项目成果。如果您想要完成标准的，可预测的过程，那么就致力于那些过程的易变率的评估和管理。这对软件维护活动尤其正确，它们经常比新的开发更容易地遵循已建立的模式。
易变率的一个杰出的量度是单位时间的总变更，以及该量度随着时间的趋势的整体评估。有各种各样的方法来度量总变更：代码行（lines of code，LOC），修正、确定的故障、感到满意的增强请求，等等。团队应该在安排一个或其它的方法之前，讨论相对于他们的手段和方法的这些选择，并且应该随着他们能力的提高，以及新技术和方法的可用，虚心地演进该量度。作为起始点，对跨项目阶段的单位时间内变更的总 LOC 的简单度量将绘制出项目的轨道，并展示出项目是否达到了与成功地在完成日期着陆相适合的“下滑轨道”。甚至成熟的开发组织都经常会发现，在对易变率 KPI 的首次观察中，他们的过程遭受着偷偷通过同行审查，以及质量保证审查的未预期且未报告的“迟的破坏（late-breaking）”变更，或者发现他们的过程包含与期望的 Agile 方法相反的潜伏期和延迟时间。
容积 KPI
容积 KPI 说明了在开发中生成的逻辑或其它相关工件的总量。在一些组织中，逻辑的容积可能有关联性的想法已经引起争论，有时候会受到某种程度的怀疑，甚至轻视。然而，“容积”的基本思想对三种软件开发规程来说是重要的：项目预测、质量保证，和程序设计。
影响维护成本的重要因素是正被讨论的代码基数的大小。一般确实是比起较小的代码基数，大型的代码基数要用更多的人来维护制度上的存储并且保持最新。人们可能争论维护工作是否与代码基数的大小线性相关，而事实上对此问题的回答可能是因素的功能，包括软件设计方法、组件化的程度、资源技能水平、集中对分布的团队，以及外包或境外人员的使用。然而，对于您的管理层要明确维护团队的大小和组成与团队所维护的项目的大小和组成之间的关联的最好方法是开始度量并应用容积 KPI。
文章来源于领测软件测试网 https://www.ltesting.net/
