Humphrey眼中的过程性能预测模型是怎样的？

对软件世界带来改变的CMM让Watts Humphrey登上了质量大神的地位，CMM汇总了软件工程方方面面的优秀实践，让过程和软件质量衔接上了。其中定义的高成熟度级别，更让全球软件组织为之努力。

2021年中国完成了近3000次评估，超过全球总数的80%，通过四级、五级的组织数量也是遥遥领先。但几乎没有例外，这些组织在改进和评估过程中有两个普遍：第一个普遍是几乎都被高成熟度实践要求的过程性能模型折腾的焦头烂额。第二个普遍是到头来觉得它为项目管理和组织改进活动带来可观价值少之又少。如果我们做个CAR的话，定能发现一堆根因，其中不可回避的一个问题是：数学统计模型真的能用在软件场景吗？

最近做培训时，有同学问了一个问题：在最早的CMM软件模型中，Humphrey是怎么定义过程性能模型的？对于这样的好问题，我向来不惜笔墨回答。

上个世纪九十年代流行的CMM一共有五个高成熟度的关键过程域（KPA– key process area），四级有量化过程管理（Quantitative Process Management），软件质量管理（Software Quality Management）；五级包含了缺陷预防（Defect Prevention），技术变更管理（Technology Change Management），过程变更管理（Process Change Management）。其中过程性能基线（process performance baseline）在四、五级活动中非常醒目，但过程性能模型（process performance model）这个词自始至终未出现过。

那么Humphrey没有考虑过预测模型吗？非也！在为推动普及CMM而写的“管理软件过程”一书中，他也提到了软件质量预测模型（Software Quality Models）。老人家提到的质量模型是用来估算软件质量情况，指导项目的质量策划、管理工作，同时用来支持软件组织过程改进，通过缺陷预防分析，识别针对性的整改，不断减少泄露缺陷。

老人家眼中的预测模型不是中规中矩的数学模型，他认为数学模型不适用的原因是它们都需要严格的假设，这些假设非常不适用于软件过程，如下列假设（重点来了！敲黑板！）：

• 缺陷是相互独立的

• 缺项数是常数

• 每个缺陷修复后测试才能继续

• 所有缺陷都是可以发现的

• 测试可以等同运行环境的深度和广度

• 缺陷率和当前系统遗留缺陷数相称

• 事故间距是独立的

• 不同级别的缺陷同等重要

• 在测试和修复过程中不会引入新的缺陷

• 在调试和运维期间缺陷率会不断下降

那么Humphrey眼中的软件预测模型应该是什么样的呢？他是这么说的：

模型必须体现软件开发的方式，找不出漂亮的数学模型也没什么，我们完全可以用类似算法的方式做出质量预测。

软件过程虽然远远不是高度一致，但其中一些重要特征是可以追溯、并且是有规律的，如：

不同程序模块质量差异很大，二八原则基本适用，少部分模块包含了大部分缺陷；

其他模块会包含一些随机分布的缺陷，需要一个个排除；

缺陷类别是偏态分布的，大部分缺陷会集中在少数类别中；

程序变更极易引入新的缺陷，所有变更都必须视为潜在的缺陷植入机会。

上述四个特征虽然算不上模型，但可以用来指导质量规划，每个软件组织需要根据自己的产品研发经验确定应该用什么样的模型。

这里给大家介绍两个Humphrey给出的预测模型例子，图1是一个缺陷分布帕拉图，它的使用价值一目了然，我们可以看到三类最常见的缺陷，成为我们质量策划及改进的聚焦点。它真是简单、轻量、有价值。

老人家在其另一本书中给出了另一个著名模型例子：捕获-再捕获分析（capture recapture analysis）。通过同时执行2次独立的测试，用各自收集到的缺陷数及两次都发现的缺陷数，团队可以估算出缺陷总数及遗留缺陷数（见图）。

捕获再捕获模型

过程性能模型是六西格玛的杰作之一，在合适的场景下可以发挥重要作用。但软件有自己的规律，我们也许应该重温下质量大师的提醒，看看什么样的软件预测模型有高性价比，软件的高成熟度应该具备什么样的能力。特别希望5000B的实践者能够走出一条CMMI可以借鉴、学习的路。

(文章来源于老丛讲桌微信讲桌作者：丛斌博士）

了解更多：CMMI

文章源于网络，如有侵权或者不当，请告知删除

CMMI认证中文网

CMMI V2.0

Humphrey眼中的过程性能预测模型是怎样的？