2.8.3　单位缺陷成本度量方法的经济学问题

软件质量经济学研究中最为古老的度量方法是单位缺陷成本。虽然不能确定之前是否也有应用，但可以确定的是，这个度量方法在20世纪60年代末就已被IBM应用于软件，并且很有可能早在20世纪50年代就应用于硬件了。

根据通常的计算方法，单位缺陷成本度量方法会测量与缺陷修复相关的小时数和修复的缺陷个数，然后乘以每小时的负担费用。

单位缺陷成本度量方法已发展成为一个都市传奇，文献中存在很多论断说早期的缺陷检测和清除要比后期的廉价，前者的成本不及后者的1/10。

这个都市传奇在数学上是正确的，但是单位缺陷成本计算方法有个问题。由于存在固定成本，发现缺陷个数最多的时期单位缺陷成本总是最低的。随着质量的提升，单位缺陷成本变得越来越高，直到再也找不到缺陷，而此时单位缺陷成本变为无穷大。

更重要的是，单位缺陷成本度量方法往往会忽略质量提升的主要经济价值：缩短了开发周期，并减少了除明确的缺陷修复之外的开发成本。

单位缺陷成本的典型数据在不同的研究中有所不同，但都与下面这个在大量的文章和书籍中出现过的模式类似：

需求中发现的缺陷=250美元

设计中发现的缺陷=500美元

编码和测试中发现的缺陷=1250美元

发布后发现的缺陷=5000美元

虽然这种说法从数学上而言通常是正确的，但是单位缺陷成本中存在以下3个隐蔽的问题，一般不会在软件文献中讨论。

1）单位缺陷成本不利于质量，而且发现bug个数最多的时期单位缺陷成本最低。

2）因为开发初期发现的bug要比末期多，所以单位缺陷成本的增加是虚假的。实际的缺陷修复时间和活动研究表明从开始到结束只有很小的变化。

3）即使计算正确，单位缺陷成本也不能度量软件质量提升的真正经济价值。除了查找和修复bug的成本之外，高质量还能缩短开发周期，并减少整体开发成本。计算单位缺陷成本时不包含这些成本的节省，所以这种度量方法将质量真正价值低估了几倍。

下面通过3个说明了我们的主要观点的案例来思考一下这3个问题。

所有这3个案例（A、B和C）假定测试人员每周工作40个小时，其报酬为每周2500美元或者说是每小时75.75美元，这是全部的负担费用。假定所有这3个要测试的软件特性的规模为100个功能点。