软件项目中的成本估算模型有哪些呢
现有的大多数软件成本估算模型适于预算、权衡分析、计划、控制和投资分析等范畴。成本估算模型技术多采用经验公式对软件项目进行成本估算。在大多数估算模型中，软件规模是决定成本的主要因素。有两种衡量软件规模的常规方法：基于代码行的估算方法和基于功能点的估算方法。 许多成本估算模型中将代码行或功能点数作为主要的输入参数。
1。面向代码行的成本估算模型
代码行(lines of code，LOC)是衡量源代码长度的最常用的方法。NCLOC(non-comments source lines ofcode缩写)用于表达不含注解的源代码行数。 NCLOC也常常被当作为有效的代码行数(effective...全部
现有的大多数软件成本估算模型适于预算、权衡分析、计划、控制和投资分析等范畴。成本估算模型技术多采用经验公式对软件项目进行成本估算。在大多数估算模型中，软件规模是决定成本的主要因素。有两种衡量软件规模的常规方法：基于代码行的估算方法和基于功能点的估算方法。
许多成本估算模型中将代码行或功能点数作为主要的输入参数。
1。面向代码行的成本估算模型
代码行(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。
面向功能点的成本估算模型
面向功能点(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]。
从前面模型中不难看出，无论是模型结构、复杂度或软件项目规模，都是靠开发者的经验估计出来的，而这些参数在开发的早期很难预测。大多数模型在当初导出它们的工作范围内工作的很好，但应用于普通情况时表现很差。
软件需求是复杂的，有差异的。虽许多模型包含解决差异的调整因素，评估员可依靠调整因素去解决当前问题的任何变动，然而这种方法常常是不适当的。实际上，许多因素会相互影响，有时会导致过度忽略了某个因素的重要性。
同时，这些方法也非常具有主观性，常常带有开发者的个人倾向。另外，调整因素的计算过程也过于复杂，不是一个容易确定的值。一般模型要求对软件规模进行估算，但项目初期很难预测。对规模的估计结果也很主观，并要求模型的规模度量与用于实际中的规模度量相同，否则不能给出准确的结果。
收起
