实用的软件系统开发成本估算法软件成本管理含例子.docx
《实用的软件系统开发成本估算法软件成本管理含例子.docx》由会员分享，可在线阅读，更多相关《实用的软件系统开发成本估算法软件成本管理含例子.docx（43页珍藏版）》请在冰点文库上搜索。
实用的软件系统开发成本估算法软件成本管理含例子
.
软件系统开发成本估算法
功能点估算含例子
教育资料．
.
一、功能点估算法概念.........................1
二、功能点估算法的特点.......................1
三、功能点分析的步骤（含例子）...............1
3.1识别项目的类型..........................................2
3.2识别项目的范围和边界....................................2
3.3按不同功能点计算........................................3
3.3.1功能点估算分类.....................................3
3.3.2识别功能点的重要原则...............................4
3.3.3内部逻辑文件与外部接口文件.........................4
3.3.4事务类型功能点的计算规则...........................9
3.3.5计算调整因子......................................14
3.3.6计算调整后的功能点个数............................25
3.4总结...................................................33
教育资料．
.
一、功能点估算法概念
功能点估算法是软件项目管理众多方法中比较有技术含量的一个，也是最实
用的一个。
在软件项目管理中项目计划制定的优劣、合理直接关系到项目的成败，
项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一
个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那
么项目计划也就没有存在的意义。
二、功能点估算法的特点
项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉
及。
对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下：
功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算?
则误差会代码行估算法，其结果的准确性比较高。
假如这个时候使用LOC
比较大。
代码行估算法则使用功能点估算法无需懂得软件使用何种开发技术。
LOC?
与软件开发技术密切相关。
代码行估算法则是以技术为功能点估算法是以用户为角度进行估算，LOC?
角度进行估算。
通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为?
代码行的。
LOC
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目
开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结
果会与当初估计的不同。
因此，在项目结束时还需要对项目的范围情况重新进
行估算，这个时候估算的结果才能最准确反映项目的规模。
三、功能点分析的步骤（含例子）
本文将以国际标准IFPUG（InternationalFunctionPointUsersGroup）
组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示，首先大家应该
了解功能点估算法的使用步骤。
教育资料．
.
功能点估算法的步骤图1
具体步骤包括：
识别功能点的类型。
1.
识别待估算应用程序的边界和范围。
2.
计算数据类型功能点所提供的未调整的功能点数量。
3.
4.计算人机交互功能所提供的未调整的功能点数量。
5.确定调整因子。
计算调整后的功能点数量。
6.
识别项目的类型3.1
功能点估算法适用于任何一类项目：
国际IFPUG组织将软件项目分为三类，
新开发项目?
二次开发的项目?
功能增强的项目?
识别项目的范围和边界3.2
”用例图是以用户角度进行识别项目范围和边界的UseCaseUML的“使用
我们可以知最好方法，在画用例图时就必须明确系统的边界。
通过系统的边界，
为例：
2道哪些功能要计算功能点，哪些功能点是外部系统负责计算的。
以图
一个外贸订单系统只包含录入、修改、删除、查询和统计订单的功能，而汇率查
务是不属于该系统的。
询转换服
教育资料．
.
应用程序边界的识别规则大家一定要牢记，不能从技术角度去思考，必须从
用户角度来定义；如果项目牵扯到多个系统，那么必须将这多个系统的边界全部
描述清楚。
图2外贸订单系统用例图
3.3按不同功能点计算
3.3.1功能点估算分类
功能点估算法将功能点分为以下5类：
1.ILF：
InternalLogicalFile内部逻辑文件
2.EIF:
ExternalInterfaceFile外部接口文件
3.EI:
ExternalInput外部输入
4.EO:
ExternalOutput外部输出
5.EQ:
ExternalInquiry外部查询
教育资料．
.
其中，ILF和EIF属于数据类型的功能点，EI、EO、EQ属于人机交互事务
类型的功能点。
以外贸订单系统项目为例：
录入订单、修改订单、删除订单是EI；?
查询订单是EO?
统计订单是EQ?
汇率查询转换系统为EIF?
订单和客户是ILF?
3.3.2识别功能点的重要原则
ILF、EIF要与EI、EO、EQ分开计算。
对ILF和EIF复杂度的计算可以简单
理解为对数据库复杂度的计算。
对EI、EO、EQ复杂度的计算可以理解为对程序
开发复杂度的计算。
一般软件项目都是由数据和程序构成的，因此计算ILF、EIF
和计算EI、EO、EQ之间没有任何关系。
3.3.3内部逻辑文件与外部接口文件
ILF内部逻辑文件
内部逻辑文件是指一组以用户角度识别的、在应用程序边界内且被维护的逻
辑相关数据或控制信息。
ILF的主要目的是通过应用程序的一个或多个基本处理
过程来维护数据。
EIF外部接口文件
外部接口文件是指一组在应用程序边界内被查询，但在其他应用程序中被维
护的、以用户角度来识别的、逻辑上相关的数据。
因此，一个应用程序中的EIF
必然是其他应用程序中的ILF。
EIF的主要目的是为边界内的应用程序提供一个
或多个通过基础操作过程来引用的一组数据或信息。
EIF所遵循的规则：
从用户角度出发识别的一组逻辑数据。
?
这组数据是在应用程序外部，并被应用程序引用的。
?
教育资料．
.
计算功能点的这个应用程序并不维护该EIF。
?
ILF被维护的。
这组数据是作为另一个应用程序中的?
ILF和EIF的复杂性计算
ILF和EIF的复杂性是取决于RET（Recordelementtype）和DET
（Dataelementtype）的数量。
DET是一个以用户角度识别的、非重复的、有
业务逻辑意义的字段。
DET计算的规则如下：
通过一个基本处理过程的执行，对ILF进行维护，或从ILF/EIF中返回一?
个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个
DET。
例如：
添加一个外贸订单时需要保存“订单号码、订单日期、地址、
邮编”，那么对于ILF订单来说它的DET就是4个。
再如：
保存订单时还会保存订单的明细。
订单的明细往往作为一个子表
进行保存，那么“订单号码”在主表和子表中都同时存在（主外键）。
但以用户
角度来识别时，存盘操作是一个最小的单位，那么订单号码只能算做一个DET。
当两个应用程序维护和/或引用相同的ILF/EIF，但是每个应用程序分别?
维护/引用它们相应的DET时，这些DET在这两个应用程序的维护/引用中
将单独计算。
例如，一个应用程序的两个“ElementaryProcess”基本处理过程
都需要使用到“地址”的信息，地址信息又可以细分为“国家、城市、街道、邮
编”。
那么对于其中一个基本处理过程来说，它将整个地址信息作为一个整体
进行处理，只算一个DET；另外一个基本处理过程使用每个地址的详细信息，那
么DET就是4个。
RET计算的规则如下：
RET是指一个EIF/ILF中用户可以识别的DET的集合。
如果把DET简单
理解为字段的话，那RET就可以简单理解为数据库中的表。
RET在ILF/EIF中
教育资料．
.
分为两种类型：
可选的（Optional）和必选的（Mandatory）。
计算RET的规则
为以下两点：
在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET。
?
RET。
如果一个ILF/EIF没有子集合，则ILF/EIF被计算为一个?
例如：
在外贸订单系统中添加一个订单时会保存“订单信息、客户
的ID、部门的ID”。
那么订单系统ILF中的RET为：
1.订单信息（必选的）
2.客户信息（必选的）
3.部门信息（可选的）
因此ILF中RET的个数为3个。
ILF/EIF复杂度的矩阵如下：
1~19个DET20~50个DET超过51个DET
1个RET低低中等
2~5个RET低中等高
6个以上RET中等高高
软件项目管理中的功能点估算法将功能点分为5类：
ILF（InternalLogical
File，内部逻辑文件）、EIF（ExternalInterfaceFile，外部接口文件）、EI
（ExternalInput，外部输入）、EO（ExternalOutput，外部输出）和EQ（External
Inquiry，外部查询）。
其中，ILF和EIF属于数据类型的功能点，EI、EO、EQ
属于事务类型的功能点。
EI、EO、EQ的比较
教育资料．
.
EI是处理来自应用程序边界外部的一组数据输入，它的主要目的是
维护一个或多个ILF，以及/或者更改系统的行为。
EO是输送数据到应用程序边界外部的过程。
它的主要目的是通过逻辑处
理过程向用户呈现信息。
该处理过程必须包含至少一个数学公式或计算方法，或
生成派生数据。
一个EO也可以维护一个或多个ILF，并/或改变系统行为。
EQ是向应用程序边界外发送数据基本处理的过程。
其主要目的是从ILF
或EIF中通过恢复数据信息来向用户呈现。
该处理逻辑不包括任何数学公式或计
算方法，也不会生成任何派生数据。
EQ不会维护任何一个ILF，也不会改变应用
程序的系统行为。
EO和EQ的共同点是，其主要目的都是通过基本操作过程展现数据给用
户。
EI、EO、EQ的比较见下表。
表1EI、EO、EQ的主要目的
目的EIEOEQ
改变应用程序的属性或行为主要目的次要目的不允许
维护一个或多个ILF主要目的次要目的不允许
显示信息给用户次要目的主要目的主要目的
表2EI、EO、EQ的主要行为
教育资料．
.
EQEO行为EI
至少选择
数学公式或计算被执可可
至少选择至少选择被修至少一IL可
可EI被引可IL至少一
可数据被重新恢可
至少选择派生数据被创可
至少选择至少选择应用程序的行为或属性被修
必可准备或呈现信息到系统边界
可接受进入系统边界内的数据的能必
选
教育资料．
.
3.3.4事务类型功能点的计算规则
在IFPUG的定义中有一个重要的单词“ElementaryProcess”——基本处理
过程。
该过程对用户来说是一个有意义的、最小的活动单位，并且是一个自包含
的活动。
功能点的分类，EI、EO、EQ的识别都是基于“ElementaryProcess”
基本处理过程的。
EI的计算规则
1.从应用边界之外收到数据。
2.如果进入系统边界内的数据不是一个改变系统行为的控制信息，那么
至少一个ILF应该被改变。
3.对于已识别的处理过程，至少满足下面三个条件之一。
该基本处理过程的逻辑与本应用系统中其它基本处理过程的逻辑不同。
该?
不能存在两个完全一模一样的存盘例如：
基本处理过程应该具有唯一性。
操作。
该基本处理过程所使用的这组数据应该与其他基本处在应用程序边界内，?
理过程所使用的数据不同。
是不同于其它基本ILF或EIF在应用程序边界内，基本处理过程所引用的?
EIF。
处理过程所引用的ILF或
EO和EQ通用计算规则
必须全部满足以下内容才能被视为一个EO或EQ：
1.从外部发送数据或控制信息到应用程序边界内。
2.为了识别这个过程，以下三点必须满足一个：
该基本处理过程逻辑上必须是唯一的，该唯一性是指其在应用程序中与其?
EQ在逻辑性上保持唯一。
他EO或
该唯一性是指其在应用程序该基本处理过程所使用的数据应该是唯一的，?
所使用的数据不同。
EO或EQ中与其他
该唯一性是指其EIF文件应该是唯一的，该基本处理过程所引用的ILF或?
文件不同。
或所引用的或在应用程序中与其他EOEQILFEIF
教育资料．
.
EO补充的计算规则
除了要满足上面的通用规则外，还要满足下面其中一条：
在基本操作过程中至少包含一个数学公式或计算方法?
在基本操作过程中要产生派生数据?
ILF在基本操作过程中至少要维护一个?
在基本操作过程中要改变系统的行为。
?
EQ补充的计算规则
除了要满足上面的通用规则外，还要满足下面其中一条：
基本操作过程从ILF或EIF中获取数据。
?
基本操作过程不能包含数学公式或计算方法。
?
基本操作过程不能生成派生数据?
基本操作过程不能维护任何一个ILF?
基本操作过程不能改变系统的行为?
EI、EQ和EO的技术复杂性计算
复杂性取决于FIRs和DETs的数量。
FTR是被一个事物读取或维护的ILF，
或者是被一个事物读取的EIF。
EI中识别FTR规则
每一个ILF应该算做一个FTR。
?
。
或EIF都应该计算为一个FTREI通过读取的每个ILF?
FTRILF仅计算为一个。
既被EI维护又被读取的?
EI中识别DET规则
在EI的过程中，以用户角度识别的、通过应用系统边界输入系统内部的?
。
非重复字段，应算作一个DET
的过程中，只要没有通过系统边界输入，即使它存在于系统内的一EI在?
DET。
中，也不能算为一个个ILF
例如，外贸订单系统中，订单的金额是被单价和数量自动计算的，
那么金额是没有通过系统边界输入的，因此在EI操作中就不应该算做一个DET。
教育资料．
.
在应用程序的EI操作时，系统提示的错误信息或完成操作的信息，应该?
被分别计算为一个DET。
例如，在网站注册用户信息时，由于输入错误系统会显示提示信息，
那么这些提示信息应该被逐个计算为一个DET。
再如，当EI操作完成时系统提示并显示出来的信息，应该被计算为一个
DET。
在EI操作中，如果遇到主外键的字段，应该算作一个DET。
?
EO和EQ计算FTR的规则
1.通用规则：
每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR?
2.EO额外的FTR计算规则
在EO处理过程中每个被维护的ILF算一个FTR?
FTR处理过程中既被读取又被维护的ILF算一个在EO?
EO和EQ计算DET的通用规则
用户可识别的非重复字段，进入应用边界并指明处理什么、何时处理或处?
理方式，并且由EO/EQ返回或产生，那么这样的每个字段算一个DET。
例如，报表中的每个字段都是一个DET。
在应用边界内以用户角度识别的非重复字段算一个DET。
?
例如，在报表中起到解释或备注作用的文字信息，不管是一个字、
一个词或一段话，都当作一个DET。
再如，某种编号或日期，即使它被物理存储在不同字段中，但从用户角
度看是一个整体的信息，因此被算作一个DET。
还有，在饼图中百分比和分类算作不同的DET。
在EO或EQ操作中，如果对系统进行输入或读取操作时，相同的字段只计?
算一个DET。
教育资料．
.
例如，在报表查询时，输入的字段在报表上也有显示，那么将算作
同一个DET。
在应用程序的EO或EQ操作时，系统提示的错误信息或完成操作的信息，?
应该被计算为DET。
例如，用户查询一个列表时被拒绝，那么拒绝的提示信息就算为一
个DET。
在EO或EQ操作中如果遇到主外键的字段，应该算作一个DET。
?
就算它存在于系统内的EQ过程中，只要没有通过系统边界输入，在EO或?
中，也不能算为一个DET。
一个ILF
例如，在公司发工资的时候，员工对应的状态信息被更新，但这个
状态信息的更新是没有通过系统边界输入的，因此也不能算做一个DET。
页面的标题等类似信息不计算DET。
?
DET。
系统字段生成的记号不能被算作一个?
例如，页码、位置信息、时间、上一页和下一页等信息，都不能算
作一个DET。
EI复杂度计算矩阵
1~4个DET5~15个DET多于16个DET
0~1个FTR低低中等
2个FTR低中等高
大于2个FRT中等高高
EO和EQ复杂度计算矩阵
教育资料．
.
DET个DET多于201~5个DET6~19个
中0~FTR
中FTR2~
FTR中多个
未调整前功能点对应矩阵
技术复杂度对应的功能点如下表所示：
ILF和EIF、EIEO、EQ
一
634EI
754EO
64EQ3
157ILF10
1075EIF
用功能点估算法计算软件项目功能点时会用到调整因子（或称调整系数）。
对每个常规系统功能点的调整系数是通过通用系统特性及其影响程度来评定的，
教育资料．
.
特性的评估由其影响程度（DI）而定，分为0－5级：
0毫无影响
1偶然影响
2适度影响
3一般影响
4重要影响
5强烈影响
然后依次对以下14个系统常规特性进行打分，并带入以下计算公式
算出功能点的调整因子。
ValueAdjustmentFactor=（sumof（DI）*0.01）+0.65
3.3.5计算调整因子
1.数据通讯
数据通讯指的是应用程序直接与处理器通讯的程度。
通常我们都是通过
某种通讯手段来实现在一个应用中所使用的数据或者控制信息。
连接到本地控制
器上的终端被认为是通讯设施，协议则指两个系统或设备之间进行通讯时使用的
一种约定。
所有的数据通讯链接都需要某种协议。
0应用程序是单纯的批处理或者PCstand-alone
应用程序是一种批处理过程，但是包含远程数据的1
录入或远程打印
应用程序是一种批处理过程，但是包含远程数据的
2录入和远程打印
教育资料．
.
应用程序包括在线数据收集或者包括批处理或查3
系统的远程处理的前端应
应用程序不单只是前端应用，但是仅支持一种远
4处理通讯协
应用程序不单只是前端应用，还支持多于一种的5程处理通讯协议
分布式数据处理2.
分布式数据处理是应用在内部组件之间传递信息的程度。
这个特性是在
应用边界内体现的
0
应用程序不支持组件之间的数据传输和处理功能
应用程序为用户可能进行的处理准备数据（例如使1用电子表格或者数据库等）
应用程序所准备的数据是为了在系统另外一个组件2
上传输和处理，并非为终端用户所处理。
分布式处理和数据传输是在线的，并且是单向的3
分布式处理和数据传输是在线的，并且是双向的4
由系统中最恰当的组件动态地执行处理功能5
教育资料．
.
3.性能
性能是吞吐量、处理时间等指标对开发的影响。
用户所提出的性能要求
将直接影响到系统的设计、实施、安装和支持。
0
用户没有提出性能方面的要
用户提出了性能和设计方面的要求，但不需要采1特定措
响应时间和吞吐量在系统峰值时是关键的，但是
2需要采取相应CP使用方面的特殊设计。
处理的最
期限是在下一个工作日
在任何时候响应时间和吞吐量都是关键的，但是
3需要采取相应CP使用方面的特殊设计。
处理的完
期限比较严格
除了上面一项的要求外，由于对需求的要求比较4
格，在设计阶段就要进行性能分析
除了上面一项的要求之外，在设计和实施阶段需要5使用性能分析工具来判断性能要求的完成情况。
4.大业务量配置
大业务量配置是指计算机资源对应用开发的影响程度。
大业务量的运行
配置对设计有特殊要求，是必须考虑的一个系统特性。
教育资料．
.
0没有提出明确的运行方面的限
有运行方面的限制，但是不需要采取特别的措施1
满足运行限
提出了一些安全和时间方面的限2
应用程序的某些部分对处理器有特定的要3
提出的运行限制对应用的中央处理器或者专用处4器有特殊的要
除上面一项之外，还对应用的分布式组件提出了5
制
5.事务处理率
事务处理率是业务交易处理速度对系统的设计、实施、安装和支持等的
影响。
0
预计不会出现周期性的高峰事务处理期
预计会有周期性的高峰事务处理期（例如：
每月、1
每季、每年）
预计每周都会出现高峰事务处理期2
教育资料．
.
3预计每天都会出现高峰事务处理
用户在应用程序需求或者服务级别协议中对事务4要求很高，因此必须在设计阶段进行性能分析
用户在应用程序需求或者服务级别协议中对事务
要求很高，因此必须进行性能分析并在设计、开发和5
装阶段中使用到性能分析工具。
6.在线数据输入
在线数据输入是指数据通过交互的方式输入系统的程度。
系统中包括在
线数据输入和控制信息功能。
0
所有事务都是批处理的
1%~7%的事务是以交互式的方式进行数据录入1
的事务是以交互式的方式进行数据录入28%~15%
的事务是以交互式的方式进行数据录入316%~23%
24%~30%的事务是以交互式的方式进行数据录入4
以上的事务是以交互式的方式进行数据录入530%
最终用户效率7.
教育资料．
.
最终用户效率是指对应用的人文因素
升级会员 