软件项目的规模、工作量和成本是如何进行估算的
急切-楚汉相争
软件项目的规模、工作量和成本是如何进行估算的
2010-08-23
来源：网络
1. 基于代码行和功能点的估算
软件项目的规模是影响软件项目成本和工作量的主要因素。在基于代码行（loc，line of
code）和
功能点（function point）的估算方法中，利用代码行和功能点来表示软件
系统的规模，并通过对软件
项目规模的估算进而来估算软件项目的成本和工作量。
显然,一个
软件项目的代码行数目越多，它的规模也就越大。软件代码行的数目易于度量，许多软
件开发组织和项目
组都保留有以往软件项目代码行数目的记录，这有助于在以往类似软件项目代码
行记录的基础上对当前软
件项目的规模进行估算。
用代码行的数目来表示软件项目的规模简单易行，自然、直观且易于度量。但
是其缺点也非常明
显。在软件开发初期很难估算出最终软件系统的代码行数；软件项目代码行的数目通常
依赖于程序
设计语言的功能和表达能力；采用代码行的估算方法会对那些设计精巧的软件项目产生不利的
影响；
该方法只适合于过程式程序设计语言，不适合于非过程式程序设计语言（如函数式或者逻辑语言）
。
针对上述问题，人们提出用软件系统的功能数目来表示软件系统的规模。1979年ibm的alb
recht
提出了计算功能点的方法。该方法需要对软件系统的二个方面进行评估，即评估软件系统所需
的内
部基本功能和外部基本功能，然后根据技术复杂度因子对这二个方面的评估结果进行加权量化，产<
br>生软件系统功能点数目的具体计算值。具体的，以下是软件系统功能点的计算公式。
fp =
ct× (0.65 + 0.01×sfi) （i=1..14）
其中，ct是5个信息量的“加权和”，fi是14个因素的“复杂性调节值”（i
=1..14），0.65和0.01
是经验常数。
ct的计算方法如表 3所示，ct
=（简单用户输入数×3 ＋一般用户输入数×4＋复杂用户输入数×6）
+（简单用户输出数×4＋一
般用户输出数×5＋复杂用户输出数×7）+（简单用户查询数×3＋一般用户
查询数×4＋复杂用户查
询数×6）+（简单文件数×7＋一般文件数×10＋复杂文件数×15）+（简单外部
界面数×5＋一
般外部界面数×7＋复杂外部界面数×10）。其中，用户输入数是指由用户提供的、用
来输入的应用数
据项的数目；用户输出数是指软件系统为用户提供的、向用户输出的应用数据项的
数目；用户查询数是指
要求回答的交互式输入的项；文件数是指系统中主文件的数目；外部界面数
是指机器可读的文件数目（如
磁盘或者磁带中的数据文件）。
表 3. ct值的加权计算
加权因子
简单
一般
´4
´5
复杂
最终值
用户输入数
´3
用户输出数
´4
´6
´7
参数取值加
权
用户查询数
´3
文件数
´7
´4
´10
´7
´6
´15
´10
外部界面数
´5
ct=
f
i
（i=1..14）14个因素的“复杂性调节值”取值见表 4。
表
4. f
i
的取值表
序号
i
f
1
系统需要可靠的备份和复原码
f
2
系统需要数据通信吗
f
3
系统有分布处理功能吗
f
4
性能是临界状态吗
f
5
系统是否在一个实用的操作系统下运行
f
6
系统需要联机数据项吗
f
7
联机数据项是否在多屏幕或多操作之间进行切换
f
8
需要联机更新主文件吗
f
9
输入、输出、查询和文件很复杂吗
f
10
内部处理复杂吗
f
11
代码需要被设计成可重用吗
f
12
设计中需要包括转换和安装吗
f
13
系统的设计支持不同组织的多次安装吗
f
14
应用的设计方便用户修改和使用吗
例如，假设项目组要开发一个软件项目a。根据用户的需求描述，该软件项目的ct取值如表
5所
示。进一步的，假设该软件项目的14个复杂性调节值全部取平均程度。那么根据表
5可知，该软
件项目的ct=341，14个复杂性调节因素的累加值sfi=42，因而根据公式fp
= ct× (0.65 + 0.01×sfi)
（i=1..14）可知，该软件项目的功能点fp=341× (0.65 + 0.01×42)
= 364.87，即该项目的功能点数目大
致为364。
表 5. 软件项目a的ct值
参数取值加
权
用户输入数
用户输出数
用户查询数
文件数
外部界面数
简单
6´3
7´4
2´3
0´7
2´5
一般
2´4
6´5
0´4
3´10
3´7
加权因子
复杂
5´6
5´7
5´6
3´15
4´10
最终值
56
103
36
75
71
4-较大影响
5-严重影响
平均影响
0-没有影响
1-偶有影响
2-轻微影响
问题
fi的取值（0,1,2,3,4,5）
ct= 341
用功能点
来表示软件项目规模的好处是：软件系统的功能与实现该软件系统的语言和技术无关，
而且在软件开发的
早期阶段（如需求分析）就可通过对用户需求的理解获得软件系统的功能点数目，
因而该方法可以较好地
克服基于代码行软件项目规模表示方法的不足。其不足主要体现在：该方法
没有直接涉及算法的复杂度，
不适合算法比较复杂的软件系统；功能点计算主要靠经验公式，主观
因素比较多；此外计算功能点所需的
数据不好采集。
大量的实践表明：针对特定的程序设计语言，软件系统的功能点和代码行二者之间存在
某种对应
关系（如表 6所示）。根据该表的数据，一个功能点如果用汇编语言来实现大约需要320行
代码，
如果用c语言来实现大约需要150行代码，如果用smalltalk语言来实现大约需要21
行代码。从另一
个角度上看，该表反映了不同程序设计语言的描述能力是不一样的。
表 6.
功能点和代码行之间的转换表
序号
1
2
3
4
5
6
7
8
9
10
程序设计语言
汇编语言
c
cobol
fottran
pascal
ada
pl1
prologlisp
smalltalk
代码生成器
代码行功能点
320
150
105
105
91
71
65
64
21
15
假设用l表示软件系统的
规模（或者用loc表示，或者用fp来表示）。针对一个具体的软件项目，
可以采用自顶向下或者自底
向上等多种方式来估算出软件项目规模的乐观值a、悲观值b和一般值
m，然后根据以下公式估算出软件
项目规模的期望值e：
e = (a + 4´m + b)6
根据软件项目规模的期望值e以及下列公式，就可以估算出软件项目的成本和工作量。
生产率
pm = l e
其中，l表示软件项目的规模（单位：loc或者fp)，e表示软件工
作量（单位：人月），pm表示
单个人月能够生产的功能点或者代码行数。
平均成本
ckl = s l
其中，s为软件项目总开销，l表示软件项目的规模（单位：loc或者fp)，
ckl表示每行代码或者
每个功能点的平均成本。
对于一个特定的软件开发组织或者项目组而
言，其软件生产率和平均成本在不同的软件项目实施
中可能是比较稳定的。如果有以往软件项目的历史信
息，可以很容易地获得关于软件开发组织或者
项目组的pm和ckl值。因此，一旦估算出了软件项目的
规模，获得了软件开发组织或者项目组的
pm和ckl的值，就可根据公式ckl = s
l计算出软件项目的成本s = ckl´ l，也可根据公式pm = l
e
计算出软件项目的工作量e= l pm。
例如，假设项目组要开发一个软件项目a，经
过估算该项目的规模是364个功能点。进一步的，
根据以往的历史数据，该项目组软件开发的生产率是
8fp人月，每个功能点的平均成本为12000元
人民币，那么该软件项目的开发成本s =
6800元人民币´ 364 = 247，5200元人民币，工作量为e= 364
8 =
45.5人月。
基于经验模型的估算
基于经验模型的估算根据以往软件项目实施的经验数据
（如成本、工作量和进度等）建立相应的
估算模型，并以此为基础对软件项目开发的有关属性进行估算。
构造性成本模型cocomo（constructive
cost
model）是目前应用最为广泛的经验模型之一。
在二十世纪七十年代后期，boehm对多达63
个软件项目的经验数据进行了分析和研究，在此基
础上于1981年提出了cocomo模型用于对软件
项目的规模、成本、进度等方面进行估算。boehm把
cocomo模型分为基本、中间和详细三个层
次，分别支持软件开发的三个不同阶段。基本cocomo模
型用于估算整个软件系统开发所需的工作量
和开发时间，适合于软件系统开发的初期。中间层次的
cocomo模型用于估算各个子系统的工作量和
开发时间，适合在获得各个子系统信息之后对软件项目
的估算。详细层次的cocomo模型用于估算独
立的软构件，适合在获得各个软构件信息之后对软件项
目的估算。由于篇幅限制，本书仅介绍基本coc
omo模型，其模型形式描述如下。
e = a * (kloc)b
。其中e是软件系统的工作量(单位：人月) ，a和b是经验常数，其取值见表 7，
kloc是软件
系统的规模（单位：千行代码）。该公式描述了软件系统的规模与工作量之间的关系。
d = c *
ed。其中d是开发时间（单位：月），c和d是经验常数，其取值见表
7。该公式描述了
软件系统的开发时间与工作量之间的关系。
表 7.
基本cocomo模型参数的取值
软件类型
组织型
半独立型
嵌入型
a
2.4
3.0
3.6
b
1.05
1.12
1.20
c
2.5
2.5
2.5
d
0.38
0.35
0.32
适用范围
各类应用程序
各类实用程序、编译程序等
各类实时软件、os、控制程序等
cocomo模型是一个综合经验模型，它考虑了诸多因素
，因而是一个比较全面的估算模型。cocomo
模型有许多参数，其取值来至于经验值。该估算模型比
较实用、易于操作，在欧盟国家应用较为广
泛。
例如，针对上面所述的软件项
目a，如果已估算出该项目的软件规模是33.3kloc，而且该项目属
于半独立型，即cocomo
模型中的参数a、b、c、d的取值分别是3.0、1.12、2.5、0.35，那么根据模
型公式e
=a *
(kloc)b可以估算出该项目的工作量是3.0*(33.3)1.12，即152人月；然后根据公式d
= c
* ed可以估算出该项目的开发时间是2.5*(152)0.35，即14.5月。
2. 其它估算方法
其它估算方法包括：专家估算、类比估算等等。
专家估算方
法是由一组专家来对软件项目所需的成本、工作量和进度等进行估算。一般地，这些
专家具有应用领域或
者开发环境方面的知识、参与了以往类似软件项目的开发。为了避免专家估算
的片面性，专家估算方法一
般要求每位专家给出估算的最小值a、可能值m和最大值b，然后计算
出每位专家估算的平均值esti
=（a+4m+b）6，最后根据各位专家的估算情况计算出最终的估算值
est=(est1+est
2+est3+……+estn)n。如果软件开发组织或者项目组拥有一批经验丰富的专家，可以考
虑
采用该方法。专家估算方法具有人为因素多、主观因素大的特点，一般应用于软件开发的初期阶
段，此时
软件项目组往往难以获得估算软件项目所需的各种数据和信息。
类比估算方法是指估算人员根据以往类
似软件项目实施所积累下来的数据，通过分析待开发软件
项目和以往软件项目二者之间的相似性，估算出
软件项目的开发工作量、成本和进度等。使用该方
法的前提是：待估算的软件项目和以往的软件项目必须
具有一定的相似性（如它们均属于同样的应
用领域），并且拥有以往类似软件项目的开发数据（如工作量
、周期、参与的人数、规模和成本等）。
软件估算发生在事前，因而估算的结果与实际的结果有所偏差
是不可避免的。但是，如果估算的
偏差过大，那么估算的结果将会对软件项目的实施和管理产生消极的影
响，甚至可能导致软件项目
的失败。因此，在对软件项目的规模、成本和工作量等进行估算的过程中，要
避免低劣的估算，尽
可能地获得合理和准确的估算数据。