一、软件成本估算贯穿于整个软件生命周期
项目初期粗略的成本估算是必要的，它往往用于确定项目的可行性分析。在项目计划阶段还需对项目进行详细的成本估算，设定项目工作分解表中每项任务可能的成本，作为项目执行阶段进行成本控制的基准。并且，在项目执行阶段，当项目实际成本与计划成本出现差异时，还需对项目后期的成本重新进行必要的估算。因此，项目成本估算在项目的管理和控制中占据着非常重要的地位。而在软件项目中，由于在人员、开发周期、项目范围及技术难度等方面与其它项目相比具有更大的不确定性，故准确估算其成本就显得特别困难。因而合理估算软件项目成本就尤其重要。
二、软件项目中的成本估算模型项目管理论坛
现有的大多数软件成本估算模型适于预算、权衡分析、计划、控制和投资分析等范畴。成本估算模型技术多采用经验公式对软件项目进行成本估算。在大多数估算模型中，软件规模是决定成本的主要因素。有两种衡量软件规模的常规方法：基于代码行的估算方法和基于功能点的估算方法。许多成本估算模型中将代码行或功能点数作为主要的输入参数。
1.面向代码行的成本估算模型training.mypm.net
代码行(lines of code，LOC)是衡量源代码长度的最常用的方法。NCLOC(non-comments source lines ofcode缩写)用于表达不含注解的源代码行数。NCLOC也常常被当作为有效的代码行数(effective lines of code，ELOC)。在很多情况下，为了日后更清楚地阅读和理解程序，提高系统的可维护性，在程序开发中往往要求在程序中附上详细的注解，在这种情况下，包含注解的源代码行数也是一个有效的度量标准。CLOC(commented source line of code缩写)用于表达含注解的源代码行数。综上所述，我们给出代码行的定义如公式1所示：总长度(LOC)=NCLOC+CLOC(1)
2.面向功能点的成本估算模型bbs.mypm.net
面向功能点(Function points，FP)的成本估算模型是用系统的功能数量来测量软件规模的。该方法先评估产品所需功能，然后根据技术复杂度因子(权)对其成本进行量化和修正，估算出最终的软件成本。
其基本步骤是：
(1)计算未调整的功能点(UFC)数目这里所谈的功能点数并非最终软件中实际的功能数量，最终软件实际功能模块的个数在软件开发之前是不可能精确估算的。在此，我们首先将软件的所有功能分为外部输入、外部输出、外部查询、外部文件及内部文件五大类，并估算每类功能的数量(FPi)，然后依据待开发软件的特点评估各类功能的复杂度权重(Wi)，在依据公式2可得未调整的功能点数(UFC)。UFC=SUM(FPi*Wi)
(2)外部输入由用户提供的、描述面向应用的数据外部输出系统向用户提供的、面向用户的数据外部查询要求回答的交互式输入外部文件对其他系统可读的文件内部文件系统里的逻辑主文件权重因素(Wi)项简单一般复杂外部输入3 4 6外部输出4 5 7外部查询3 4 6外部文件7 10 15内部文件5 7 10(2)计算调整后的功能点数考虑到用户对系统性能的不同要求，我们还需从表3中反映的14个方面对UFC作进一步的调整，从而计算出待开发系统的技术复杂度因子(technical complexity factor，TCF)。表3技术复杂度因子第12期舒小仙：软件项目管理的成本估算81F1可靠的备份和恢复F2数据通信F3分布式处理F4性能F5大量使用的配置F6联机数据输入F7操作简便性F8在线升级F9界面的复杂性F10数据处理的复杂性F11代码的复用性F12安装的简易性F12多重站点F14易修改性表3中的因子Fi(其中：i=1，2，……14)取值范围在0-5之间[1]，值0表示该因子对系统无影响，值5表示该因子是对系统有强大的影响。技术复杂度因子的计算公式如公式3所示：TCF=0.65+0.01(SUM(Fi))(3)由UFC乘以技术复杂度因子(technical complexityfactor，TCF)得到调整后的功能点数FP，参见公式4。FP=UFC×TCF(4)
3.基于回归分析的成本模型
成本模型提供工作量的直接估算，通常有一个主要的成本因素和若干个次要的调整因素。该模型是利用过去软件项目中收集的数据进行回归分析导出待开发软件的成本模型[1]。其整体结构如公式5所示：E=A+B×SC(5)ABC为经验性的导出常数，E为每个月的投入，S为主要输入(常用源代码行数LOC或功能点数FP)[1]。以LOG为主要输入参数来计算的成本模型的例子：E=5.2×(KLOC)0.91 Walston-Felix模型E=3.2×(KLOC)1.05 COCOMO基础模型以FP为主要输入参数来计算的成本模型的例子：E=-12.39+0.0545FP Albrecht and Gdffney模型E=585.7+15.12FP Matson，Barnett，和Mellichamp模型
4.各类模型存在的问题分析
当一个模型有75%的准确性时，我们认为是可以接受。但目前大多数的模型无法达到这个标准[1]。从前面模型中不难看出，无论是模型结构、复杂度或软件项目规模，都是靠开发者的经验估计出来的，而这些参数在开发的早期很难预测。大多数模型在当初导出它们的工作范围内工作的很好，但应用于普通情况时表现很差。软件需求是复杂的，有差异的。虽许多模型包含解决差异的调整因素，评估员可依靠调整因素去解决当前问题的任何变动，然而这种方法常常是不适当的。实际上，许多因素会相互影响，有时会导致过度忽略了某个因素的重要性。同时，这些方法也非常具有主观性，常常带有开发者的个人倾向。另外，调整因素的计算过程也过于复杂，不是一个容易确定的值。一般模型要求对软件规模进行估算，但项目初期很难预测。对规模的估计结果也很主观，并要求模型的规模度量与用于实际中的规模度量相同，否则不能给出准确的结果。
三、软件项目成本管理中的直觉思维
直觉思维是指不受某种固定的逻辑规则约束而直接领悟事物本质的一种思维形式。许多项目管理人凭借直觉对项目成本的进行估算。项目管理人利用多年的经验和能力预测项目成本，有时这种估算很准确。同时这种以真实经验为基础的人为的判断也有利于对特殊情况的调整。项目管理人员在成本估算时常会借鉴以往的相似的项目经验，但项目管理人员很少考虑到相似项目的风险，如先前项目的成本是什么?先前项目所用的专有技术是什么?先前项目是否按计划完成?先前项目有哪些地方出过错误?项目管理人员在进行成本估算时倾向于“软性”的经验，而忽视先前项目执行时的“硬性”证据。管理人员倾向依据少量的——大多数情况下仅一两次——以往经验作出决定。缺乏足够的经验，作出的估算是不可信的。另一个问题是倾向于依靠项目“专家”的定性阐述。项目管理者经常会过度乐观地看待项目的进展，会给出与事实偏离的现状报告，这很容易造成错误的分配或浪费掉不可缺少的资源。研究证明，大多情况下主观的判断甚至不如最简单的统计模型。这也表现出直觉思维的局限性——非逻辑思维是非必然的。试验表明系统的分析整合工具和项目管理技术能够改善项目的开发和管理。项目管理者不相信统计的结果是正常的，当统计分析的结果明显低于项目总成本时，项目管理人常常调高估算，这是一种对成本估算的有效调整措施。所以，关键是如何将项目管理者主观估算的能力和利用模型系统估算成本有机地结合起来。
四、结论
项目管理中的成本估算是非常困难的，它受很多因素的影响。用数学模型去估算成本时，有时不总是有效。许多项目管理人依靠自己的直觉去作出最佳估测，这种方法简单易行，但它也存在很大的差异性。因此将数学模型与直观判定结合使用构造合理估算，可同时具备各技术的优点，是一种较好的方法。在软件项目成本估算中，我们可以使用数学模型做初步估算，然后运用项目管理人的直觉调整结果。另外，在项目执行和控制中也可以对特殊情况进行人为的判断调整。现在将两种或多种技术结合来估算成本的合成技术估算方法应用较为广泛。