软件成本估算

软件开发成本估算主要指软件开发过程中所花费的工作量及相应的代价。 不同与传统的工业产品，软件的成本不包括原材料和能源的消耗，主要是人的劳动的消耗。另外，软件也没有一个明显的制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此，软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、集成测试到认证测试，整个开发过程所花费的代价作为依据的。

软件开发成本估算的经验模型

Putnam 模型
1978年Putnam提出的，一种动态多变量模型。
L = Ck * K1/3 * td4/3
其中： L-----------源代码行数(以LOC计)
K-----------整个开发过程所花费的工作量（以人年计）
td-----------开发持续时间（以年计）
Ck----------技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异，见下表

Ck的典型值 开发环境 开发环境举例
2000 差 没有系统的开发方法，缺乏文档和复审
8000 好 有合适的系统的开发方法，有充分的文档和复审
11000 优 有自动的开发工具和技术

从上述方程加以变换，可以得到估算工作量的公式： K = L3/(Ck3*td4)
还可以估算开发时间： td = [L3/(Ck3*K)]1/4

COCOMO模型(constructive cost model)
这是由TRW公司开发，Boehm提出的结构化成本估算模型。是一种精确的、易于使用的成本估算方法。
COCOMO模型中用到以下变量：
DSI-------源指令条数。不包括注释。1KDSI = 1000DSI。
MM-------开发工作量（以人月计） 1MM = 19 人日 = 152 人时 =1/12 人年
TDEV-----开发进度。(以月计)

COCOMO模型中，考虑开发环境，软件开发项目的类型可以分为3种：

组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（<50000行）

嵌入型(embedded): 要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在一起。对接口，数据结构，算法的要求高。软件规模任意。如大而复杂的事务处理系统，大型/超大型操作系统，航天用控制系统，大型指挥系统等。

半独立型（semidetached）： 介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。

估算公式：
基本COCOMO模型估算工作量和进度的公式如下
工作量： MM = r*(KDSI)c
进度： TDKV = a(MM)b
其中经验常数 r, c, a, b 取决于项目的总体类型。

COCOMO模型按其详细程度可以分为三级：基本COCOMO模型，中间COCOMO模型，详细COCOMO模型。其中基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。 中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。

基本COCOMO模型

通过统计63个历史项目的历史数据，得到如下计算公式。

总体类型 工作量 进度

组织型 MM = 10.4*(KDSI)1.05 TDKV = 10.5(MM)0.38

半独立型 MM = 3.0*(KDSI)1.12 TDKV = 10.5(MM)0.35

嵌入型 MM = 3.0*(KDSI)1.20 TDKV = 10.5(MM)0.32

进度计划是从时间的角度对项目进行规划，而成本估算则是从费用的角度对项目进行规划。这里的费用应理解为一个抽象概念，它可以是工时、材料或人员等。

　　成本估算是对完成项目所需费用的估计和计划，是项目计划中的一个重要组成部分。要实行成本控制，首先要进行成本估算。理想的是，完成某项任务所需费用可根据历史标准估算。但对许多工业来说，由于项目和计划变化多端，把以前的活动与现实对比几乎是不可能的。费用的信息，不管是否根据历史标准，都只能将其作为一种估算。而且，在费时较长的大型项目中，还应考虑到今后几年的职工工资结构是否会发生变化，今后几年原材料费用的上涨如何，经营基础以及管理费用在整个项目寿命周期内会不会变化等问题。所以，成本估算显然是在一个无法以高度可靠性预计的环境下进行。在项目管理过程中，为了使时间、费用和工作范围内的资源得到最佳利用，人们开发出了不少成本估算方法，以尽量得到较好的估算。这里简要介绍以下几种。

1．经验估算法

　　进行估计的人应有专门知识和丰富的经验，据此提出一个近似的数字。这种方法是一种最原始的方法，还称不上估算，只是一种近似的猜测。它对要求很快拿出一个大概数字的项目是可以的，但对要求详细的估算显然是不能满足要求的。

2．因素估算法

　　这是比较科学的一种传统估算方法。它以过去为根据来预测未来，并利用数学知识。它的基本方法是利用规模和成本图。如图所示，图上的线表示规模和成本的关系，图上的点是根据过去类似项目的资料而描绘，根据这些点描绘出的线体现了规模和成本之间的基本关系。这里画的是直线，但也有可能是曲线。成本包括不同的组成部分，如材料、人工和运费等。这些都可以有不同的曲线。项目规模知道以后，就可以利用这些线找出成本各个不同组成部分的近似数字。

　　这里要注意的是，找这些点要有一个“基准年度”，目的是消除通货膨胀的影响。画在图上的点应该是经过调整的数字。例如以1980年为基准年，其他年份的数字都以1980年为准进行调整，然后才能描点划线。项目规模确定之后，从线上找出相应的点，但这个点是以1980年为基准的数字，还需要再调整到当年，才是估算出的成本数字。此外，如果项目周期较长，还应考虑到今后几年可能发生的通货膨胀、材料涨价等因素。



　　做这种成本估算，前提是有过去类似项目的资料，而且这些资料应在同一基础上，具有可比性。

3．WBS基础上的全面详细估算

　　即利用WBS方法，先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：

　　①对项目需求作出一个完整的限定。
　　②制定完成任务所必需的逻辑步骤。
　　③编制WBS表。

　　项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。

　　一旦项目需求被勾划出来，就应制定完成任务所必需的逻辑步骤。在现代大型复杂项目中，通常是用箭头图来表明项目任务的逻辑程序，并以此作为下一步绘制CPM或PERT图以及WBS表的根据。

　　编制WBS表的最简单方法是依据箭头图。把箭头图上的每一项活动当作一项工作任务，在此基础上再描绘分工作任务。

　　进度表和WBS表完成之后，就可以进行成本估算了。在大型项目中，成本估算的结果最后应以下述的报告形式表述出来：

　　①对每个WBS要素的详细费用估算。还应有一个各项分工作、分任务的费用汇总表，以及项目和整个计划的累积报表。
　　②每个部门的计划工时曲线。如果部门工时曲线含有“峰”和“谷”，应考虑对进度表作若干改变，以得到工时的均衡性。
　　③逐月的工时费用总结。以便项目费用必须削减时，项目负责人能够利用此表和工时曲线作权衡性研究。
　　④逐年费用分配表。此表以WBS要素来划分，表明每年（或每季度）所需费用。此表实质上是每项活动的项目现金流量的总结。
　　⑤原料及支出预测，它表明供货商的供货时间、支付方式、承担义务以及支付原料的现金流量等。

　　采用这种方法估算成本需要进行大量的计算，工作量较大，所以只计算本身也需要花费一定的时间和费用。但这种方法的准确度较高，用这种方法作出的这些报表不仅仅是成本估算的表述，还可以用来作为项目控制的依据。最高管理层则可以用这些报表来选择和批准项目，评定项目的优先性。 以上介绍了三种成本估算的方法。除此之外，在实践中还可将几种方法结合起来使用。例如，对项目的主要部分进行详细估算，其他部分则按过去的经验或用因素估算法进行估算。

FunctionPoing的目的是基于软件需求产生软件规模的估计。功能点是基于应用软件的外部、内部特性以及软件性能的，一种间接的软件规模的测量。功能点与软件成本具有重大的成本估计关系（CER ：Cost EstimatingRelationship ）。功能点可以作为经验统计参数化软件成本估计公式和模型的输入，以对软件的成本进行估计。功能点方法被广泛的认可在信息系统、数据库密集型、4GL 应用系统开发的规模测量。

加一本书的介绍
用例点估算方法

...人们设想，基于用例模型来估算规模和工作量是可能的。因为用例模型被广泛用于捕捉功能需求，所以人们认为，应该有基于用例的估算方法来代替功能点方法。然而，有几点困难可能阻碍基于用例的估算方法的应用(Smith,1999)：....