软件开发成本评估：我们知道和不知道的那些事

软件开发成本评估：我们知道和不知道的那些事

大量证据表明，软件项目存在成本超支的情况，平均来看，会超支30%左右¹。此外，对比20世纪80年代的成本评估精度和当前的研究报告，我们会发现评估精度并没有多大的改变（只有Standish group组织的分析中提到了对评估精度有较大提升，而他们报告中提到的这种提升，是根据一些出现问题的项目总结的私有评估方法，对大部分项目来说还属极端案例²），评估方法也没有变化。尽管评估模型被广泛研究，但主要的方法仍然是专家判断³。

其实，对评估精度没有显著提高，并不意味着我们相对于过去，对软件成本评估没有更多的理解。本文中，我总结了几点内容，有些是对提供评估精度有潜在影响的因素；有些则阐明了估算精度得不到提高的可能原因；还有一些，是成本评估工作中我们知道和不知道的那些事。这些基于经验的论证我在我其它的文章中也有提及¹。

我们知道的那些事

回顾对软件项目成本评估的研究，我这里列举了7点研究的结果。

1）没有最好的评估模型和方法

大量的研究将不同的评估模型和方法进行比较，想找出哪种方法是最优的⁴，但比较的结果却是：具有不确定性。主要原因是一些核心的关系因素在不同项目情况下是不同的，比如开发成本和项目大小的关系，在不同情形下是有区别的⁵。此外，最影响开发成本的变量因素也是不同的，因此，需要我们根据实际情况来量身选择使用的评估模型和方法。

核心关系的不稳定性也解释了，为什么和简单模型比起来先进的模型也并没有将评估精度提高很多。从统计上看，先进的评估模型更像是对历史数据的过度匹配，使得项目环境变化时反而比简单模型精度更差一些。这个发现就表明软件公司应该根据他们专有的项目领域和情况建立自己的评估模型，而不是期望通用模型或者工具就能解决他们的问题。

2）客户对低价格的青睐是成本超支的主要原因

当前，在竞价环境下低估项目成本的倾向是很容易发生的，比如招标流程。但不在竞价的环境下，则没有这种倾向，比如内部软件开发，有时甚至会多估成本。所以成本超支的一个主要的原因是，采购方选择软件供应商时，更关注低价格的供应商，也就是说，低成本的项目更容易被选择。这也表明，采购方会通过压低价格、增加供应商之间的竞争来防范项目成本超支。

3）最大值最小值估算方法中，取值范围有很大局限性

使用最大最小值估算法时，即使置信度能达90%，也很难反映真实的项目成本。尽管各文献也明确指出了我们无法确定最大值和最小值的精确取值，但当今的评估方法中，仍然假设这种评估有效。尤其在PERT分析方法中（三点估算），期望成本是由最可能值、最大值和最小值推算出来的。

相比用专家判断法来设置最大值和最小值，软件专家们更应该参考历史经验数据来设置最大最小值⁶。

4）评估易受误导并很难从误导中恢复

所有软件开发项目的成本评估都需要专家判断，即使使用正式的评估模型也是如此。不过尽管专家判断比较的精确，可还是很容易产生误差。在评估工作的开始或进行中，当评估人考虑到项目预算、客户期望、建设时间或者其他相关的因素（即所谓的评估指标）时，这时也许是最容易产生误差的。不知不觉的，人们就会向靠近这些指标的值来进行评估，因为知道客户总是期望低价格或使用更少的工作量，因而就很容易导致低估项目成本。比如，专家判断就容易被以下的话误导：“这种简单又小的项目，会花多少成本？”

尽管对于如何从误导中恢复、并折中这样的偏差影响有大量的研究工作，但至今也没有发现什么特别有效的方法，主要的方法还是让评估人尽量不受这些误导性的或不相关的信息的影响，比如，将这些不相关的信息从需求文档中删除掉。

5）相关历史数据和检查表有助于提高估算精度

一种很好的、文档化的提高评估精度的方法就是使用历史数据和评估检查表。当公司组织资产中有相关历史数据和检查表可以使用时，项目活动就不容易被遗漏，很多相关风险也会被识别出来，原有项目经验可以得到重用，这使评估工作更接近现实情况，尤其对简单项目，我们可以使用类比估算⁷来提高评估的精准度。

然而，尽管历史数据和评估检查表很具实用性，当前很多公司也并没使用其中的任一种来提高他们的估算精度。

6）联合独立评估来提高评估精度

将不同人的评估结果取平均值，要比大多数单独评估的结果更加精确。一个关键假定是这些评估相互之间是独立完成的，评估人来源于不同的专业、背景，使用不同的评估方法，类似于德尔菲法，就像计划扑克那样(Planning Poker，是一个促使达成团队一致意见的团队构建活动)，团队成员同时亮出手中的评估结果（扑克牌），然后再将结果取平均值，这种方法在软件项目的评估工作中十分有用。

基于组的、结构化的评估过程比单纯机械的合并结果更具价值，因为分享知识会提高知识的总量，比如，基于组判断可得到完成项目的全部活动。基于组判断的负面影响，如集体审议会增加项目风险等，尚未有文献记录这种影响在软件评估中存在。

平均来看，使用评估模型没有专家判断的评估精确度高，然而正是因为两种方法的不同，将二者结合起来使用，才更有益于提高软件的评估精度。

7）评估也会产生弊端

评估工作不仅是预测项目也会影响项目后续的建设。过低的成本评估会导致产品质量降低，将来存在返工的可能，而且会增加项目失败的风险；而根据帕金森定律，过高的成品评估会降低项目生产力，拉长项目的完成时间。

这就是为什么我们要考虑清是否做成本评估这件事的重要性，如果我们真的不需要，或者后续阶段才需要评估，那么不评估、或等后续获得更多信息再评估，反而更安全。敏捷开发就是规避早期评估潜在弊端的一种有效方法，因为它是根据前一版本的反馈来制定下一个版本的计划。

我们不知道的那些事

有时尽管我们有大量的研究，评估工作仍有很多挑战，对此我们没有简单有效的解决方法，这里主要列举了3个疑难问题，由此也可以看出，要想得到满意的答案，我们还有很长的路要走……

1）如何精确地评估大型、复杂的软件项目

大型项目对成本评估有更高的要求，不仅因为大型项目有更多风险因素，还因为相关经验和可获得的历史数据比较少。大型项目中很多活动看上去都很难精确地进行评估，比如组织结构方面，大项目就包含了非常多的干系人，另外，大型项目也存在业务流程变化、干系人关系复杂、以及和已有软件应用的对接问题。

2）如何确定软件规模和复杂度

关于软件的规模和复杂度，尽管我们已经有多年的研究，然而真正开始做项目成本评估的时候，研究中推荐的方法都不是特别的有效。虽然也有些软件的规模和复杂度可以做比较精确的评估，但这种情况还只是少数。

3）如何测量和预估软件的开发效率

即使你有很好的方法来测量软件的规模大小及复杂度，你仍需要预测团队或个人完成相关工作的开发效率。这种预测是很难的，因为不同的软件开发者或团队，工作效率可能有很大不同。对于这种预测，除了对实际工作进行测试外，没有什么好的办法。

当前，我们甚至不知道软件项目有经济规模（生产力随项目规模增加而增加）还是没有经济规模（生产力随项目规模增加而降低）。大多数基于经验的研究表明：软件项目平均来看有经济规模，然而软件从业者却认为没有经济规模。不幸的是，这个研究结果只是一种推论，仅仅给出分析结果是如何得出的，而没有过多阐明软件规模和生产力的潜在关系。

 

我们当前所知道的这些关于软件工作及成本评估的知识，不能真正的使我们解决软件行业中评估工作存在的挑战，然而，这些知识为我们提高评估精准度提供了指导。特别是以下几点，如果软件公司做到了这些，评估的精准度是可以得到提高的：

l   根据具体项目情况开发和使用简单的评估模型，同时结合专家判断；

l   运用历史经验数据来设置最大值、最小值；

l   避免受不相关及误导信息影响；

l   根据自有结构使用评估检查表；

l   使用结构化的、基于组的评估流程，并保证评估相互之间的独立性；

l   避免基于极不完整项目信息的早期评估工作。

 

竞争激烈的招标流程中，采购方更多聚焦于价格低廉的软件，然而这样的选择方式显然是对投标人过度乐观，因为接下来很可能产生项目成本超支和质量下降，这在其他领域中被称做“赢家的诅咒”。从长远来看，大部分的采购方将会开始意识到，他们对固定价格、低价格的强调将对项目的成功产生负面影响，到那时，软件公司也应该提高他们的意识，当他们因为价格优势而中标时，应该好好想想如何避开这“赢家的诅咒”。

 

英文原文地址：http://www.infoq.com/articles/software-development-effort-estimation?utm_source=infoq&utm_medium=popular_links_homepage

 

参考

1. T. Halkjelsvik and M. Jørgensen, “FromOrigami to Software Development: A Review of Studies on Judgment-BasedPredictions of Performance Time,” Psychological Bulletin, vol. 138, no. 2, 2012,pp. 238–271.
2. M. Jørgensen and K. Moløkken-Østvold, “How Large Are Software Cost Overruns?A Review of the 1994 CHAOS Report,” Information and Software Technology, vol.48, no. 4, 2006, pp. 297–301.
3. M. Jørgensen, “A Review of Studies on Expert Estimation of SoftwareDevelopment Effort,” J. Systems and Software, vol. 70, no. 1, 2004, pp. 37–60.
4. T. Menzies and M. Shepperd, “Special Issue on Repeatable Results in SoftwareEngineering Prediction,” Empirical Software Eng., vol. 17, no. 1, 2012, pp. 1–17.
5. J.J. Dolado, “On the Problem of the Software Cost Function,” Information andSoftware Technology, vol. 43, no. 1, 2001, pp. 61–72.
6. M. Jørgensen and D.I.K. Sjøberg, “An Effort Prediction Interval ApproachBased on the Empirical Distribution of Previous Estimation Accuracy,”Information and Software Technology, vol. 45, no. 3, 2003, pp. 123–136.
7. B. Flyvbjerg, “Curbing Optimism Bias and Strategic Misrepresentation inPlanning: Reference Class Forecasting in Practice,” European Planning Studies,vol. 16, no. 1, 2008, pp. 3–21.