软件项目成本估算研究

摘要：软件项目成本估算是软件项目成本管理的基础，也是整个软件项目管理中的一个难点。对软件项目成本估算步骤以及常用方法进行了初步探究，并着重介绍了IFPUG和COCOMO这两个参数模型的应用方法。

关键词：软件项目成本估算；软件估算；IFPUG；COCOMO

中图分类号：TP301 文献标识码：A 文章编号文章编号：16727800（2014）001002003

作者简介作者简介：龚银锋（1983-），男，硕士，宁波数字电视有限公司项目经理，研究方向为软件项目管理、业务运营支撑系统。

0 引言

项目的成本管理，是指在规定时间内，为确保项目目标的实现，对项目实际发生的成本支出采取的各种控制措施和控制过程。其管理活动包括：资源需求预测、成本估算、成本预算和成本控制[3]。成本估算是后续成本管理活动的前提，也是成本管理中的重点与难点。

软件项目的成本估算，并非传统资金意义上的估算。由于人的脑力劳动是软件开发的主体活动，因此软件开发的主要投入在于支付开发人员脑力劳动的报酬。不同软件开发单位的薪资水平存在很大差别，所以从普适性考虑，软件项目成本估算研究的主要范围是软件项目的工作量和工作进度[6]。因此，衡量软件成本的常用单位有人天、人月、人年等形式，并且有转换系数可在不同单位间进行换算。在估算出软件开发所需的人力成本之后，再根据开发单位的实际情况和项目内的其它费用即可估算出相应的成本[4]。

1 软件项目成本估算阶段

软件项目的成本估算，一般需要经过以下3个阶段：

（1）规模估算阶段。规模估算是指对软件的大小进行量化衡量，它是后续工作量估算的前提。估算软件大小有两种基本方式：估算软件所解决问题的大小和数量，比如功能点，因此也称功能规模的度量；估算解决方案的大小即技术规模的度量，比如代码行数。一般在项目初期主要以估算问题大小为主，随着项目的开展逐步采用以估算解决方案大小的方式。

（2）工作量和进度估算阶段。工作量估算是对软件开发所需人力的估算，这是软件项目的主要成本。进度估算将估算项目各任务单元可支配的时间，并制定里程碑计划。工作量估算和进度估算共同决定了项目团队的规模和结构[4]。

（3）估算反馈阶段。包括对成本估算方法本身的反馈，以及估算实践中的阶段性结果反馈[6]。在初期对项目掌握的情况较少并且仍有较多不确定性，随着项目开展可了解到更多的信息以及既成事实后的情况。因此，通过不断地进行阶段性估算结果反馈，有利于调整估算方法相关数据，从而提高估算结果的精确性。

2 软件成本估算方法

软件成本估算方法主要有以下4种：类比估算法、项目分解法、专家估算法和参数模型法。

（1）类比估算法。类比估算法也称基于案例的推理[2]，即从已完成的类似项目的实际成本来估算新项目的成本。估算过程中，需确定项目之间的各项差异，并确定各项修正系数，对各项数据加以运算调整。

（2）项目分解法。需要对项目进行分解，根据分解的先后顺序不同，可分为自上而下估算法和自下而上估算法。自上而下估算法的思想是从项目整体进行推算，将已估算出的项目整体工作量，按比例分摊至项目的各项活动中去。该方法比较适合在项目初期的总体设计中运用[8]。自下而上估算法与自上而下估算法正好相反，这种方法是将项目逐层分解成足够基本明确工作量的子任务，在测算各子任务成本后，将它们累计起来就是整个软件项目的成本。这种方法更适用于项目后期或分解后的子项目成本估算。

（3）专家估算法。邀请对软件应用领域或开发环境有丰富知识的专家对该软件项目进行工作量估算，当遇到一个与已有软件项目类似的新项目时，可邀请熟悉原软件项目的人员作为专家。

为了避免单个专家主观因素的偏向性，该方法大都采取邀请多个专家进行估算，并对多个估算结果进行综合。其中由美国兰德公司（RAND Corporation）推广的Delphi法正是汇集多个专家意见的技术，其步骤大致如下[10]：①组织者向各专家提供软件规格说明书和估算表格供他们进行研究。估算表中应包括软件成本估算的最小值（ai）、最有可能值（mi）、最大值（bi）以及简要说明和填表时间；②在专家研究软件规格说明后，组织者召集他们召开讨论会议。会上专家可向组织者提问，组织者也可向专家介绍类似软件的有关情况，专家之间也可展开讨论；③专家填写估算表格，并匿名提交；④组织者对表格数据进行汇总和分类摘要，并将结果反馈给各专家。Delphi法中的估算值汇总可用三点估计法，设各专家的估算期望值为Ei，最终估算期望中值为E，则有Ei=（ai+4mi+bi）/6，E=sum（Ei）/n；⑤组织者召集专家开会，对估算结果进行讨论；⑥各专家研究估算结果，重新提交一份估算表格。重复④至⑥步骤，直至获得一个大多数专家认可的估算值。

Delphi法可以避免集体讨论盲目屈从权威或多数的缺陷，消除相互间的影响，能让专家充分表达各自见解，集思广益。然而该方法实施过程繁琐，并且非常耗时。

（4）参数模型法，即通过采用一个或多个数学公式得出估算值的方法。这些数学公式一般是在搜集大量历史软件项目数据的基础上，进行数学建模得出经验公式，使用起来比较方便快捷。但一般都需要经过一定的校准之后才具有实际参考意义。

3 IFPUG

在规模估算阶段，比较流行的参数模型有IFPUG（International Function Point Users Group，国际功能点用户协会）功能点分析法。该方法最初是由IBM公司的工程师Allan Albrecht所设计的自顶向下法，后被IFPUG所采用、发展和推广，并出版了多个版本的功能点计算实践手册[7]。该方法是目前应用最广泛的软件规模度量技术，在我国的软件行业软件工程定额标准（2009版）中也参考了该方法。该方法的基本步骤如下：

（1）把软件系统分解为如表1所示的5类功能点，并估算各类功能点的数量（FPi）[1]。

（2）给各功能点分配复杂度权重（Wi），如表2所示[2]。

在给各功能点分配权重时，有定量的判断规则。判断ILF和EIF的复杂度依据的是其中所包含的数据元素类型数（data element type，DET）和记录元素类型数（record element type，RET）。它们的判断表格如表3所示[5]。

而对EI、EO和EQ复杂度的判断，除了DET外还需要依据所涉及的文件类型数（file type referenced，FTR），并且有所不同。EI的复杂度判断表格如表4所示[5]，EO和EQ复杂度判断表格如表5所示[5]。

（3）计算出一个未修正的功能点数（Unadjusted Function Point Count，UFPC）[9]：

UFPC=sum（FPi×Wi）。

（4）计算调整后的功能点数。仅从功能点数和其本身的复杂度，不能全面地反映系统规模，为此IFPUG还引入了14个系统特性（general system characteristic）对UFPC进行修正：数据通信、分布式数据处理、性能、可配置性、事务效率、实时数据输入、终端用户易用性、在线升级、复杂运算、代码复用性、安装简易程度、操作方便性、多场合适应性、易于调整变更[1]。将该系统特性（Fi）按对系统规模的影响程度划分为6个级别，从无影响到最大影响分别用数字0～5表示，这样最终的功能点数FP可由以下公式计算得出：

FP= UFPC×（0.65+0.01×sum（Fi））

上式中的0.65和0.01均为经验常量。

4 COCOMO

在工作量估算阶段，常用的参数模型有COCOMO（Constructive Cost Model， 结构化成本模型）。该模型是由Barry Boehm在1981提出的（因此也称为COCOMO81模型），是他研究了美国TRW公司的大量软件项目后，推导出的一个成本估算模型[7]。该模型按详细程度，分成基本型、中等型和详细型。基本型按以下公式构建[10]：

E=a×Sb。

其中，E表示工作量，是按人月度量的；S是指规模，是按千行源代码为单位的；a、b是常量，常量的选择与软件项目的类型有关，Boehm把系统类型分为3种，如表6所示[10]。

中等型模型的计算公式最终调整为：

E=a×Sb×EAF ，其中EAF=∏15[]i=1Fi

详细模型是对中等模型的进一步扩展，其基本公式与中等模型的公式相同。它把系统划分为系统层、子系统层、模块层，按这3层提供不同的成本驱动因素表，供不同层次估算使用。同时还将模型常量按开发阶段的不同进行一定的调整。

COCOMO81推出后，在软件业得到了广泛应用，也取得了良好效果。但软件工程技术突飞猛进，新的软件过程模型不断涌现，COCOMO81的应用渐渐遇到了更多的困难。为了适应新的需要，Boehm与其合作者对COCOMO进行了不断改进，在1996年正式了第一个版本的COCOMOⅡ[6]，在COCOMOⅡ中对COCOMO81做了较大变更，比如划分为应用组装模型、早期设计模型、后构架模型。早期设计模型和后架构模型的计算公式均为[6]：

PM=A×SE×∏n[]i=1EMi

其中，PM为工作量，单位为人月，A为常量3.13（CO COMOⅡ2003版），S是指规模（按千行源代码为单位），EMi为工作量系数，类似于COCOMO81中的工作量因素，在早期设计模型中概括为7个（式中n=7），而在后架构模型中扩展为17个（式中n=17）。E由以下公式计算所得[6]：

E=B+0.01×∑5[]i=1SFj

其中，B为常量0.93（COCOMOⅡ2003版）[6]， SFj为：有先例、开发灵活性、架构/风险解决方案、团队凝聚力、过程成熟这5个特性各按6个等级取值而来的比例因子[6]。

5 结语

软件项目估算的目的不是预测项目实施的结果，而是帮助确定项目目标，使其在合理范围内，从而能让项目在可控状态下达成项目目标[11]。软件的估算离不开历史数据的支撑，虽然有行业数据参考，但其准确度非常低，不同开发组织的生产率水平相差非常大，因此需要尽早积累开发组织自身的历史数据。可从一组少量的数据开始，例如：每人每月完成的代码行数、交付一个用户故事的平均时长、BUG出现的概率以及修复时长等。

参考文献参考文献：

[1] IFPUG.Function point counting practices manual[M].Westerville：IFPUG，1999.

[2] BOB HUGHES，MIKE COTTERELL.软件项目管理[M].第5版.北京：机械工业出版社，2010.

[3] 池仁勇.项目管理[M].第2版.北京：清华大学出版社，2009.

[4] 房东.软件项目估算模型研究与实践[D].济南：山东大学，2006.

[5] 胡云龙.软件规模度量方法介绍[J].计算机时代，2006（7）：1721.

[6] 蒋敏迪.软件成本估算模型及其实现[D].广州：中山大学，2004.

[7] 李莉.基于功能点的COCOMOⅡ估算模型研究和应用[D].厦门：厦门大学，2008.

[8] 刘瑞河，陈志成.软件项目管理中的成本估算[J].江西理工大学学报，2007，28（1）：3639.

[9] 舒小仙.软件项目管理的成本估算[J].中国水运，2008，8（12）：8081.

[10] 郑人杰，殷人昆，陶永雷.实用软件工程[M].第2版.北京：清华大学出版社，1997.

[11] STEVE MCCONNELL.软件估算——“黑匣子”揭密[M].北京：电子工业出版社，2007.