电子政务工程软件项目费用构成及概算方法.docx
《电子政务工程软件项目费用构成及概算方法.docx》由会员分享，可在线阅读，更多相关《电子政务工程软件项目费用构成及概算方法.docx（19页珍藏版）》请在冰点文库上搜索。
电子政务工程软件项目费用构成及概算方法
电子政务工程软件项目费用构成及概算方法
（V1.0）
（征求意见稿）
为规范电子政务工程项目软件的价格行为，维护价格公平竞争，同时为电子政务软件项目进行经费概算提供科学可信的依据，广东软件行业协会组织有关专家和企业，经过多次研究和修订，提出以下电子政务工程软件项目费用构成及概算方法。
一、名词解释
开发阶段：
开发阶段是指从软件项目启动到项目实施前的这一时间段。
因此，开发阶段的工作包括详细需求分析、系统设计、编码、测试等方面的工作。
实施阶段：
实施阶段是指软件项目从实施开始到项目正式验收的这一时间段。
因此，实施阶段的工作包括系统安装、系统调试、用户培训等方面的工作，但不包括各实施点的本地化开发工作。
运行维护阶段：
运行维护阶段是指从软件项目正式验收到合同规定的一年项目维护期
结束的这一时间段。
因此，维护阶段的工作包括系统在维护期内所需要提供的原系统完善性修改和服务等工作（不包括新增需求和原功能的重大变更）。
功能点：
功能点是对软件功能和大小的间接度量单位，一般通过必须和用户交互的情
况的数目来测算程序工作量的大小。
功能点分析法是目前国际上软件行业普遍接受的软件项目规模度量模型。
成本系数：
成本系数是指完成某个功能点（FP）的规定活动所需要投入的人工时，因
此成本系数的单位为：
人工时/FP。
如开发阶段的成本系数，则是指一个功能点（FP）需
要完成“详细需求分析”、“系统设计”、“编码”和“测试”等工作所需要投入的人工时。
其他如实施阶段成本系数、运行维护阶段成本系数的定义以此类推。
软件人员月人工费用：
软件人员月人工费用是指一个软件人员工作一个月平均需要的所有成本开销（包括工资、奖金、福利、办公成本、国家各种税费、管理费用等等）及软件企业合理利润的总和。
、软件项目费用构成
电子政务软件项目的费用构成因素很多，为准确描述，我们依据软件工程理论，从角色和项目阶段两个维度来描述项目的费用构成。
从角色维度来看，电子政务工程项目建设中主要包括建设方、承建方、第三方测试机构和监理方四个主体；从项目阶段维度来看，可以分为前期咨询、开发、实施、验收、维护五个阶段。
用一个二维表来表示角色、项目阶段和项目费用的对应关系，如下表所示。
电子政务软件项目费用构成表
\阶段
角色\
立项前期工作
开发
验收
实施
运行维护
建设方
需求分析、系统初步设
计、招标、造价等咨询
服务费用
承建方
开发费用
实施费用
运行维护费用
（维护期内）
测评机构
测试费用
监理方
工程监理费用
从表中我们看出，软件项目经费概算应考虑到如下方面的费用：
咨询服务费、项目建设费（包括软件开发、实施、维护阶段费）、验收测试费、工程监理费。
其中项目建设费是整个项目费用构成中的最主要和最重要的部分。
此外，由于软件项目的需求往往在项目建设之初很难精确描述、在项目的建设过程总会有一定量的变更，因此电子政务的软件项目经费概算中还要考虑到因为需求变更导致工作量增加而追加的费用。
、取费依据
（一）咨询服务费P
指软件项目立项前期，请专业机构或者专家进行可行性分析、技术咨询、项目初步需求分析，造价评估、方案初步设计、项目招投标等方面工作所发生的费用。
该部分费用可根据项目预计投入的建设费按照一定比例计取，也可以根据所投入的人月数进行计取，此外还可以由双方协商确定。
软件行业咨询服务取费标准
收费项目
收费
基数
基准费率（％0）
100万
以内
101万
-300万
301万
-500万
501万-
1000万
1001万
-3000万
3001万
以上
软件项目价格概算
项目预
3.6
3.0
2.5
2.2
1.8
1.5
投入费
系统设计，包括初步
项目预、
8.3
7.8
7.3
6.7
5.4
4.5
需求分析、概要设计
投入费
等
技术咨询
每人
1000元〜1500元
每日
注：
（1）参考建筑行业及通信行业的造价编制取费标准，结合软件行业项目建设实践，提出
以上造价咨询取费标准表，仅供参考。
（2）按上表计费不足10000元的，按10000元收费。
（3）技术咨询按耗用工时（日）计费，为完成委托任务发生的差旅、交通费由委托方另行支付。
项目建设费M
根据上述软件项目开发过程的划分及费用构成，项目建设费为以承建方为主体的各阶段
费用总和，包括：
开发阶段费用、实施阶段费用、维护阶段费用。
故：
项目建设费M二开发费用D+实施费用S+维护费用W
1、开发费用D
指对项目进行详细需求分析、系统设计、编码、测试等方面的工作而需支出的费用。
取费主要是依据项目规模（功能点）、开发成本系数和软件人员月人工费用计取。
开发费用D二工作量（人月）*软件人员月人工费用
=（项目功能点*开发成本系数/7.5/22）*（3.23B）
（其中7.5是指一天7.5个工作时，22指一月22个工作日，下同）。
开发成本系数的大小主要是考虑项目的非技术难度，如开发周期、协调难度、业务的
复杂程度、需求的不确定性等因素。
根据对实际数据的测算，开发成本系数一般为：
3000个功能点以下（含3000）:
3.5人工时/FP—4.0人工时/FP；
3000到8000（含8000）个功能点以下：
4.0人工时/FP—4.5人工时/FP；
8000个以上功能点：
4.5人工时/FP—5.0人工时/FP。
针对个别项目，如果有特殊情况（如某些业务特殊要求是一般项目中从未出现过的、
业主需要项目组到用户现场开发等），则经专家组评判，开发成本系数可以超出此范围上限
的限制
项目功能点的估算方法参见附录一《软件项目功能点估算方法》软件开发人员月人工费用计算方法参见附录二《软件人员月人工费用计算办法》。
2、实施费用S
由于电子政务项目的实施范围因项目而异（有些项目只实施一个单位、有些需要实施多个单位、有些甚至需要全市、全省甚至全国实施），所以实施阶段的费用也会有很大的差异。
实施费用可依据项目规模（功能点）、实施成本系数和软件人员月人工费用计取。
实施费用S二工作量（人月）*软件人员月人工费用
=（项目功能点*实施成本系数/7.5/22）*（3.23B）
根据项目是集中式实施还是分布式实施，实施成本系数可以采用如下两种方式之一确定：
1）集中式实施的项目，实施成本系数与“用户数”相关，确定方法如下：
实施成本系数=开发成本系数*t。
根据软件工程理论和实际情况，t一般采用如下标准：
当0<用户数<=100时，t=0.2；
否则，t=0.2+（（用户数-100）/100）*f（四舍五入取两位小数）；
f是调节因子，f取值如下：
0.03<=f<=0.05，具体取值依项目实施难度而定
2）分布式实施的项目，实施成本系数与“实施单位（点）数”相关，确定方法如下：
实施成本系数=开发成本系数*（0.2+（n-1）*k）
其中n代表需要实施的单位（点）数；k是比例因子。
根据软件工程理论和实际情况，k一般采用如下：
0.08<=k<=0.15，具体取值依项目实施难度而定。
3）个别项目，如果对实施有特殊要求（这些特殊要求是一般项目中从未出现过的或有本地化开发工作的），则经专家组评判，实施成本系数可以超出此范围上限的限制。
3、运行维护费用W
软件项目通过验收后，需进行一年的系统维护。
维护内容包括：
运行管理、系统平台
维护、应用软件维护、数据维护等。
根据不同的用户要求，系统维护服务可分为以下两种：
A级
软件企业派出技术人员常驻用户处，解决日常运行中发生的问题。
则⑷二软件（系统）维护费/年=派驻的人员数*12（月）*软件人员月人工费用*q
其中q为调整因子，1.5<=q<=2.0。
B级
软件企业每周5天，每天8小时（即5*8小时）响应，按双方约定的条件和时间到达现
场，且每月（或定期）派技术人员到现场进行软件（系统）性能调试，使之运行处于良好
状态。
B级维护阶段费用依据项目规模（功能点）、实施成本系数和软件人员月人工费用计
取。
运行维护费用W二工作量（人月）*软件人员月人工费用
=（项目功能点*维护成本系数/7.5/22）*（3.23B）
维护成本系数=（开发成本系数+实施成本系数）*p
根据软件工程理论和实际情况，p一般为15%—20%,具体取值依项目维护难度而定。
针对个别项目，如果对维护有特殊要求（这些特殊要求是一般项目中从未出现过的），则经专家组评判，维护成本系数可以不受此限制。
备注：
系统后期维护：
系统运行一年之后的系统维护，需另行签订系统维护合约。
为了有利于保证用户的利益和扶植软件企业，在维护范围不变的前提下，如果新维护合同的维护费用不超过上一年度维护金额的115%，则用户有权和原承建商直接签定维护合同，否则由政府相关部门进行招投标并确定新维护合同的承建公司。
（三）验收测试费C
项目完成后，需要委托第三方专业测评机构对项目进行验收测试、性能测试等方面工作。
第三方验收测试可根据软件项目开发费按百分比计取。
故验收测试费用为：
C二开发费D*按规定计取的百分比a
验收测试费率表
\费用序号\
软件开发费D（万元）
第三方验收测试费率g（%）
1
D<200
>5
2
200>4.5
3
500>3.5
4
1000>2.8
5
2000>2.5
6
5000>2.0
7
D>10000
>1.0
（四）工程监理费用G
软件项目监理收费既考虑了信息系统软件项目的特点，又参照了其它监理行业的收费标准。
其收费参考标准内容如下：
监理费G=项目建设费M*计取费率S
计取费率S=基本费率a*地域调整系数b*工期调整系数c
故：
G=M*（a*b*c）
（D+S+W）*（a*b*c）
相关系数说明:
1、不同规模的软件项目计取费率不同，基本费率a可参照下表。
序号
项目建设费M（万元）
费率a
1
M<200
>12
2
200VM<500
>9
3
50（XM<1000
>7
4
1000>6
5
2000>5
6
500«M<10000
>4
7
M>10000
>3
2、鉴于信息系统工程项目分布的地域不同，因此，监理的费率应在监理的各阶段费率的基础上考虑地域的因素，地域调整系数b如下：
1）、集中建设的信息系统工程项目：
地域调整系数b为1;
2）、地市范围的信息系统工程项目：
地域调整系数b为1〜1.2;
3）、全省范围的信息系统工程项目：
地域调整系数b为1.2〜1.5;
4）、全国范围的信息系统工程项目：
地域调整系数b为1.5〜2。
3、鉴于软件项目工期长短不一，因此，监理的费率应在监理的各阶段费率的基础上考虑工
期的因素。
工期调整系数c
序号
工程工期T
（年）
工期调整系数c
1
T<1
C>0.9
2
1vT<2
C>1.1
3
T>2
C>1.4
收费其它情况说明
如果信息系统工程项目建设中有下列情况，监理附加报酬取费可以按照下列方式计
取：
1）对于非监理原因造成工程延期而产生的监理附加工作，监理单位有权获得监理附加
报酬，监理附加报酬率=GX附加工作月数/12。
2）对于维护阶段的监理取费由业主单位和监理单位协商解决。
3）本参考标准未作规定的，可参考国家相关标准。
四、电子政务软件项目经费概算
一）项目初始建设费计算
在立项阶段，需聘请专业技术咨询机构或者专家，进行系统可行性分析和需求分析，在此基础上确定项目规模并对项目开发工作量进行评估，根据开发工作量计算出软件开发费用；项目建设完后，需第三方软件测试机构进行验收测试，此外，项目建设过程还会请监理机构进行全过程或某个阶段的监理。
故整个项目初始预估建设费为：
项目初始建设费Q二咨询服务费P+项目建设费M+验收测试费C
＋工程监理费G
二咨询服务费P+（软件开发费D+实施费S
+维护费W）+验收测试费C+工程监理费G
=P+（D+S+W）+C+G
（二）需求变更费评估
由于软件开发过程中，用户的需求有可能不断变化，从而导致开发工作量的变化，费用追加。
故在立项阶段即要请专业机构或者专家对需求变更的风险性进行评估，以预申请出足够应付需求变更的经费。
风险系数f可依据以下因子确定：
1）项目的成熟度：
如果是新项目，则开发过程需求变更的可能性很大，风险系数高，
如果是成熟项目，则需求变化小，风险系数低；
2）项目的规模大小：
如果项目规模小，需求变更的几率就小，反之就大；
3）用户业务的稳定性和管理的规范性：
用户单位业务的变化和业务流程的调整，都有可能带来开发过程中需求的变化。
（该系数取值范围以后将通过经验统计方法给出。
根据国外权威机构的调查，该系数
一般为25%到400%。
）
项目需求变更一般发生在项目建设过程中，立项阶段的咨询服务不受需求变化的影响。
但验收测试和工程监理工作量会随着需求变化而加大，所以需求变更费为：
需求变更费B=（项目建设费M+验收测试费C+工程监理费G）*需求变更风险系数f
=（D+S+W+C+G）*f
（三）项目总经费概算
由此，可得出电子政务软件项目经费概算为：
项目经费概算=项目初始预估建设费Q+需求变更费B
=P+（D+S+W）+C+G+（D+S+W+C+G）*f
=P+（D+S+C+G+W）*（1+f）
五、其他事项
项目完成后，根据最终的系统功能点数和性能要求，可由专业评估机构再次进行评估，
根据评估结果确定最终项目合同金额。
其中因需求变更而追加的费用一般不能超过预计的
需求变更费，如果由于需求发生巨大变更而导致需求变更费用可能超过项目预留的需求变更费，承建方需要及时向建设方提出申请，由专家进行评估后决定是终止需求的变更或追签新合同。
项目概算过程中要充分发挥专家和中介机构在管理与决策过程中的咨询和评议作用。
参考文献：
1.《软件开发和服务项目价格构成及评估方法》，中国软件行业协会制定，上海市软件行业协会编写；
2．《信息系统工程造价指导书》，深圳市信息工程协会和广东省价格协会编制。
3．《基于COCOMOII模型的软件评估软件一系统设计及实现》，李鹏，山东大学硕士学位论文，2004.11。
4．《软件工程项目管理——功能点分析方法与实践》，李帜、林立新、曹亚波，清华大学出版社。
5•《软件成本估算COCOMOII模型方法》，BarryW.Boehm等着，李师贤等译，机械工业出版社。
6．《通信软件开发成本评估系统研究》，李文，电子科技大学工程硕士学位论文，2004年
10月
附录一：
软件项目功能点估算方法
附录二：
软件人员月人工费用计算方法
附录一：
软件项目功能点估算方法
软件开发工作量指完成该项目所需要投入的人月数。
一个人月表示一个软件人员在一个月的时间内从事软件开发项目的时间数。
工作量大小由软件项目规模所决定。
软件项目规模大小可根据历史经验、类比等方法来估算，但目前国际上通行的也比较科学的估算方法是采用功能点分析方法。
功能点分析方法是通过一种基于软件功能的预测模型，以各种与软件项目功能有关的因素作为软件开发工作量的度量。
一旦项目的需求分析确定，就可以大致得出软件的各项功能要素，并进行相应的功能点计算，以功能点表示软件的规模，并转化为工作量大小。
功能点方式目前被广泛认可并应用在信息系统、数据库密集型、4GL应用系统开发等。
本方法采用功能点分析法来估算软件项目的功能点数。
一、软件开发工作量的功能点估算流程
功能点是对软件功能和大小的间接度量单位，一般通过必须和用户交互的情况的数目来测算程序工作量的大小。
其工作流程如下：
1、确定计算范围：
确定功能点的计算规范、划定应用程序的边界。
2、功能点分析：
识别和估算与软件数据和事务功能有关的各种要素及其数量。
要确定功能点的数目，需要对软件的用户输入数、用户输出数、用户查询表、内部逻辑文件数、外部逻辑文件数的数量进行评估。
3、功能点计算（初步）：
预估出五个要素的数量后，根据复杂度加权因子，计算出初
步的功能点数UFC；
4、确定技术复杂度因子：
根据项目具体情况，对14个技术复杂度参数进行调整。
得
出技术复杂度调整参数TCF；
5、功能点调节：
计算出经调节后的功能点数：
FP=UFC*TCF
二、功能点分析功能点分析是从软件用户的角度来评估一个软件系统的功能，它将软件的功能分为五
个基本要素：
其中两个表示终端用户的数据需求：
内部逻辑文件（InternalLogicalFileS,外部接口文件（ExternalInterfaceFiles，）另外三个表示用户对数据的获取处理的事务功能：
用户输入（ExternalInPuts）,用户输出（ExternalOutputs）,用户查询（ExternalInquiries。
它们的详细定义如下：
1、内部逻辑文件（ILF）：
是一个用户可识别的逻辑相关的数据组，它在应用程序边界内，由用户输入来维护。
它可能是某个大型数据库的一部分或是一个独立的文件。
2、外部接口文件（EIF）：
是一个用户可识别的逻辑相关的数据组，但仅仅是起参考的作用，且数据完全存于软件边界之外，由另一个应用程序进行维护，是另一个应用程序的内部逻辑文件。
3、用户输入（EI）:
是来自于软件外部的数据输入，可以是控制信息，也可是事务数据输入。
如果是事务数据，它必须维护一个或多个内部逻辑文件。
也就是说那些最后没有保存的中间计算结果和消息发送，都不算作数据输入单元。
输入数据可来自于一个数据输入屏
幕或其他应用程序
4、用户输出（E0）:
是“经过处理”的数据，由程序内部输出到外部。
这里“经过处理”
是指其区别于用户查询数据，是将一个或多个ILF、EIF中取出数据经过一定的组合、计算、总结后得出的输出数据。
5、用户查询（EQ）：
是一个输入输出的组合过程，从一个或多个ILF、EIF中取出数据输
出到程序外部。
其中的输入过程不更新任何ILF，输出过程不进行任何数据处理。
注：
对软件项目进行估算的有效性和准确性取决于所掌握的有关项目的原始资料的完备性。
这些原始资料包括：
需求说明书、系统规格说明书、或者软件需求说明书等。
从这些原始资料中可分析得出以上5类要素。
如果以上5类要素的数据不准确，将直接影响到评估的结果。
三、功能点计算（初步值UFC）
一旦估算出应用程序中每个功能要素的数量后，就可以将每个计数与一个复杂度值（加权因子）相乘，最后进行合计，算出一个初步的总的功能点数UFC。
复杂度加权因子表如
下：
功能要素复杂度加权因子表（ComplexityweightsFacto）
功能要素
复杂度
X
低
平均
高
用户输入数
EI
3
4
6
用户输出数EO
4
5
7
用户查询表EQ
3
4
6
内部逻辑文件数ILF
7
10
15
外部接口文件数EIF
5
7
10
例如，假设每个功能要素的复杂度都是平均的。
若有一个由25个数据登记表、5个接
口文件，15个报告、10个外部查询和20个逻辑内部表单组成的系统，其功能点为：
UFC
=（25*4）+（5*7）+（15*5）+（10*4）+（20*10）=450个功能点。
每个功能要素的复杂度可通过下表进行分析判断。
功能要素复杂度判别表（Determinethecomplexity-level）
ILF（内部逻辑文件）和
EIF（外部接口文件）
EO（用户输出）和
EQ（用户查询）
EI（用户输入）
记录
单兀
数据单元
文件
类型
数据单元
文件
类型
数据单元
1-19
20-50
51+
1-5
6-19
20+
1-4
5-15
16+
1
低
低
平均
0或1
低
低
平均
0或1
低
低
平均
2-5
低
平均
高
2-3
低
平均
高
2-3
低
平均
高
6+
平均
高
高
4+
平均
高
高
4+
平均
高
高
从表中可以看出，EI（用户输入）、EO（用户输出）和EQ（用户查询）是由文件类型和数据单元的数量来决定的。
而ILF（内部逻辑文件）和EIF（外部接口文件）则是由记录单元和数据单元来决定的。
通过上面的两维表即可确定各个功能要素的复杂度是低、平均，还是高。
注：
表中三种数据项定义如下：
•记录单元类型RecordElementType（RET）:
指在ILE或EIF中，用户可识别的数据域的
子集，可以通过检查数据中的各种逻辑分组来识别它们。
（例如一个客户文件，包括客户姓
名、地址等个人信息，以及客户的信用卡和卡号，一个客户有多张信用卡。
该文件含有两个记录单元：
客户信息和信用卡信息）
•文件引用类型FileTypeReferenced（FTR指在一个事务过程中，所引用到的各种文件，可以是内部逻辑文件，也可以是外部接口文件。
•数据单元类型DataElementType（DET）:
是用户可识别的无递归，不重复的信息单元。
DET是动态的，而非静态的，可以读自于文件，或由FTR的数据单元创建。
另外，一个
DET也可是对一个事务处理过程的唤醒，或是事务的有关信息。
四、确定技术复杂度因子TCF
算出功能点总数UFC后，还需要根据项目具体情况，对各个技术复杂度参数进行调整，技术复杂度一共考虑了14个调节参数，他们分别是：
技术复杂度因子表
EM1
Datacommunications
数据通讯
EM2
Performanee
软件性能
EM3
Heavilyusedconfiguration
可配置性
EM4
Transactionrate
事务效率
EM5
Onlinedataentry
实时数据输入
EM6
Enduserefficiency
用户界面复杂度
EM7
Onlineupdate
在线升级
EM8
Complexprocessing
复杂运算
EM9
Reusabilityease
升级会员 