整理的功能点计算法.docx
《整理的功能点计算法.docx》由会员分享，可在线阅读，更多相关《整理的功能点计算法.docx（27页珍藏版）》请在冰豆网上搜索。
整理的功能点计算法
功能点描述
功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要，如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及，对软件项目范围的估算有很多种方法，常见的就是LOC代码行和FP功能点法，它们之间的区别和关系如下：
1、 FP功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高，假如这个时候使用LOC代码行估算法，则误差会比较大。
2、 使用FP功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法与软件开发技术密切相关。
3、 FP功能点法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算的。
4、 通过一些行业标准或企业自身度量的分析，FP功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测，在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同，因此在项目结束时还需要对项目的范围情况进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点的公式：
● 功能点的原始计算公式：
FPCount=UFP*VAF
● 新开发项目有时新开发的软件项目也需要与其他现存的软件系统进行整合，例如：
一个企业新开发的MIS内部管理系统经常会与财务系统进行整合。
这个时候除了考虑本身项目的功能点个数外，还要考虑系统整合或数据迁移部分的工作量，因此其功能点计算公式如下：
FPCount=（UFP+CFP）*VAF
●二次开发的项目有时新开发的软件项目是在原有基础上进行二次开发的，只是为了增加一些新的功能，因此其功能点计算公式如下：
FPCount=ADD*VAF
术语
英文
中文含义
ADD
Addedfunctionality
被添加的功能点个数
CFP
Conversionfunctionality
被转换的功能点个数
CHGA
UFPofchangedfunctionalityafterenhancement
功能增强后所改动的功能所贡献的未调整的功能点个数
DEL
Deletedfunctionality
被删除的功能点个数
UFP
Unadjustedfunctionalpointcount
未调整的功能点个数
VAF
ValueadjustmentfactorVAF=（sumof（DI）*0.01）+0.65
功能点的调整因子的计算公式VAF=（sumof（DI）*0.01）+0.65
VAFA
Valueadjustmentfactorafterenhancement
功能增强后的功能点调整因子
VAFB
Valueadjustmentfactorbeforeenhancement
功能增强前的功能点调整因子
UFP：
未调整的功能点个数
1、人机交互（程序复杂度）
（1）、 EI:
ExternalInput外部输入
（2）、 EO:
ExternalOutput外部输出
（3）、 EQ:
ExternalInquiry外部查询
2、数据存储（数据库复杂度）
1、 ILF：
InternalLogicalFile内部逻辑文件
2、 EIF:
ExternalInterfaceFile外部接口文件
识别功能点的重要原则
ILF、EIF要与EI、EO、EQ分开计算。
对ILF和EIF复杂度的计算可以简单理解为对数据库复杂度的计算。
对EI、EO、EQ复杂度的计算可以理解为对程序开发复杂度的计算。
一般软件项目都是由数据和程序构成的，因此计算ILF、EIF和计算EI、EO、EQ之间没有任何关系。
参数介绍 ：
•数据单元类型（DataElementType,DET）
•用户可识别的无递归、不重复的信息单元。
•记录单元类型（RecordElementType,RET）
•在ILF或EIF中，用户可识别的数据域的子集，可以通过检查数据中的各种逻辑分组来识别它们。
•引用文件类型（FileTypeReferenced,FTR）
•被事务功能读取或维护的内部逻辑文件（ILF），或者是被事务功能读取的外部接口文件（EIF）。
（1）EI、EQ和EO的技术复杂的计算
复杂性取决于FTRs和DETs的数量。
FTR是被一个事物操作读取或维护的一个ILF，或者是被一个事物操作读取的一个EIF。
EI中识别FTR规则
● 每一个ILF应该算做一个FTR。
● 通过EI读取操作的每个ILF或EIF都应该被计算为一个FTR。
● 即被EI维护又被读取的ILF仅计算一个FTR。
EI中识别DET规则
● 在EI的过程中，以用户角度识别的，通过应用系统边界输入系统内部的非重复的字段，那么该字段应算一个DET。
● 如果在EI过程中，只要没有通过系统边界输入，就算它存在于系统内的一个ILF中，也不能算为一个DET。
✓ 例如外贸订单系统中，订单的金额是被单价和数量自动计算的，那么金额是没有通过系统边界输入的，因此在EI操作中就不应该算做一个DET。
● 在应用程序的EI操作时，系统提示的错误信息或完成操作的信息，应该被分别计算为一个DET。
✓ 例如在网站注册用户信息时，由于输入错误系统会显示提示信息，那么这些提示信息应该被逐个计算为一个DET。
✓ 当EI操作完成时系统提示并显示出来的信息，应该被计算为DET。
● 在EI操作中如果遇到主外键的字段，应该算作一个DET。
EO和EQ计算FTR的规则
● 通用规则：
每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR
● EO额外的FTR计算规则
✓ 在EO处理过程中每个被维护的ILF算一个FTR
✓ 在EO处理过程中既被读取又被维护的ILF算一个FTR
EO和EQ计算DET的通用规则
● 用户可识别的非重复的字段，进入应用边界并且指明处理什么，何时处理或处理方式，并且由EO/EQ返回或产生，那么这样的每个字段算一个DET
✓ 例如在报表中的每个字段都是一个DET
● 在应用边界内以用户角度识别的，非重复字段算一个DET。
✓ 例如在报表上起到解释或备注作用的文字信息，不管它是一个字、一个词或一段话，都当作一个DET
✓ 例如某种编号或日期，就算它被物理存储在不同字段中，但从用户角度来看是一个整体的信息，因此被算作一个DET
✓ 例如在饼图中百分比和分类算作不同的DET。
● 在EO或者EQ操作中，如果对系统进行输入或读取操作时，相同的字段只计算一个DET。
✓ 例如在报表查询时，输入的字段在报表上也有显示，那么将算作同一个DET
● 在应用程序的EO或EQ操作时，系统提示的错误信息或完成操作的信息，应该被计算为DET。
✓ 例如用户查询一个列表时被拒绝，那么拒绝的提示信息就算为一个DET。
● 在EO或EQ操作中如果遇到主外键的字段，应该算作一个DET。
● 如果在EO或EQ过程中，只要没有通过系统边界输入，就算它存在于系统内的一个ILF中，也不能算为一个DET。
✓ 在公司发工资的时候，员工对应的状态信息被更新，但这个状态信息的更新是没有通过系统边界输入的，因此也不能算做一个DET。
● 页面的标题等类似的信息不计算DET
● 系统字段生成的记号不能被算作一个DET。
✓ 例如：
页码、位置信息、时间、上一页、下一页等信息。
EI复杂度计算矩阵
1~4个DET
5~15个DET
多于16个DET
0~1个FTR
低
低
中等
2个FTR
低
中等
高
大于2个FRT
中等
高
高
EO和EQ复杂度计算矩阵
1~5个DET
6~19个DET
多于20个DET
0~1个FTR
低
低
中等
2~3个FTR
低
中等
高
多于4个FTR
中等
高
高
未调整前功能点对应矩阵EI、EO、EQ、ILF和EIF计算出来的技术复杂度对应的功能点如下表所示
低
中等
高
EI
3
4
6
EO
4
5
7
EQ
3
4
6
ILF
7
10
15
EIF
5
7
10
DET识别规则
用户可识别，非重复的字段，通过基本流程处理ILF/EIF时获得。
eg:
如果员工号在一个ILF或EIF中出现两次，一次是作为员工记录的主键，一个是作为家属信息的外键，员工号记为一个DET.
当两个应用程序维护或引用相同的ILF、EIF，但是各自使用不同的DET，那么仅计算它使用到的DET。
eg:
应用程序A使用到的地址信息包括：
streetaddress,city,state,zipcode.应用程序B可能把地址当做一个整体而未细化到个体，因此应用程序A计数有4个DET，而应用程序B计数有1个DET。
每个被用户用来和其他ILF或EIF建立关系的数据也是一个DET。
eg:
在HR系统中，员工信息是一个ILF，员工职位名称也算作是员工信息的一部分，被算作一个DET，因为它可以把员工和职位联系起来，这类DET成为外键。
RET识别规则
RET是指一个EIF/ILF中用户可以识别的DET的集合。
如果把DET简单理解为字段的话，那RET就可以简单地理解为数据库中的表。
如：
订单内部逻辑文件由于存在订单头和明细关联引用，RET应该算2个
（2）内部逻辑文件与外部接口文件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。
或者
● 如果一个ILF/EIF没有子集合，则ILF/EIF被计算为一个RET。
✓ 例如：
在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。
那么订单系统ILF中RET为：
1、 订单信息（必选的）
2、 客户信息（必选的）
3、 部门信息（可选的）因此ILF中RET的个数为3个。
Ø ILF/EIF复杂度的矩阵如下
1~19个DET
20~50个DET
超过51个DET
1个RET
低
低
中等
2~5个RET
低
中等
高
6个以上RET
中等
高
高
外部输入EI的DET识别规则：
规则1：
在EI的过程中，以用户角度识别的、通过应用系统边界输入系统内部的非重复字段，算作一个DET。
规则2：
在EI的过程中，只要没有通过系统边界输入，即使它存在于系统内的一个ILF中，也不能算为一个DET。
例如：
在外贸订单系统中，订单的金额是被单价和数量自动计算的，那么金额是没有通过系统边界输入的，因此在EI操作中不能算作一个DET。
规则3：
EI操作中系统提示的错误信息或完成的操作信息，应该分别算作一个DET。
例如：
在网站注册用户信息时，如果输入错误，系统会显示提示信息，那么这些提示信息应该被逐个计算为一个DET；而当EI操作正确完成时，系统提示并显示出来的信息，也应该被计算为一个DET。
外部输入EI的FTR识别规则：
规则1：
它所维护的每一个ILF算做一个FTR。
规则2：
通过EI读取的每个ILF/EIF算作一个FTR。
规则3：
既被EI维护又被读取的ILF仅计算一次。
类别
功能点
涉及的文件类型
FTR（filestypeReferrenced）
数据元
（DataElements）
1～4
5～15
大于15
人机交互
（程序复杂度）
EI
少于2种
低（3）
低（3）
普通（4）
2
低（3）
普通（4）
高（6）
多于2种
普通（4）
高（6）
高（6）
EO
涉及的文件类型
FTR（filestypeReferrenced）
数据元
（DataElements）
1～5
6～19
大于19
少于2种
低（4）
低（4）
普通（5）
2
低（4）
普通（5）
高（7）
多于2种
普通（5）
高（7）
高（7）
EQ
涉及的文件类型
FTR（filestypeReferrenced）
数据元
（DataElements）
1～5
6～19
大于19
少于2种
低（4）
低（4）
普通（5）
2
低（4）
普通（5）
高（7）
多于2种
普通（5）
高（7）
高（7）
数据存储
（数据库复杂度）
ILF
记录元素类型
RET（recordelementtypes）
数据元
（DataElements）
1～19
20～50
大于51
1
低（7）
低（7）
普通（10）
2~5
低（7）
普通（10）
高（15）
6种以上
普通（10）
高（15）
高（15）
ELF
记录元素类型
RET（recordelementtypes）
数据元
（DataElements）
1～19
20～50
大于51
1
低（7）
低（7）
普通（10）
2~5
低（7）
普通（10）
高（15）
6种以上
普通（10）
高（15）
高（15）
VAF：
计算调整因子
功能点的调整因子系数是通过通用系统特性及其影响程度来评定的，对每个常规系统特性的评估由其影响程度（DI）而定，分为0－5级：
0 毫无影响1 偶然影响2 适度影响3 一般影响4 重要影响5 强烈影响 然后依次对以下14个系统常规特性进行打分，并带入以下计算公式算出功能点的调整因子。
ValueAdjustmentFactor=（sumof（DI）*0.01）+0.65
1数据通讯
数据通讯指的是应用程序直接与处理器通讯的程度。
通常我们都是通过某种通讯手段来实现在一个应用中所使用的数据或者控制信息的。
连接到本地控制器上的终端被认为是使用通讯设施，而协议指的是两个系统或者两个设备之间进行通讯时所使用的一种约定。
所有的数据通讯链接都需要某种协议。
0
应用程序是单纯的批处理或者PCstand-alone
1
应用程序是一种批处理过程，但是包含远程数据的录入或远程打印
2
应用程序是一种批处理过程，但是包含远程数据的录入和远程打印
3
应用程序包括在线数据收集或者包括批处理或查询系统的远程处理的前端应用
4
应用程序不单只是前端应用，但是仅支持一种远程处理通讯协议
5
应用程序不单只是前端应用，还支持多于一种的远程处理通讯协议
2分布式数据处理
分布式数据处理是应用在内部组件之间传递信息的程度。
这个特性是在应用边界内体现的。
0
应用程序不支持组件之间的数据传输和处理功能
1
应用程序为用户可能进行的处理准备数据（例如使用电子表格或者数据库等）
2
应用程序所准备的数据是为了在系统另外一个组件上传输和处理。
并非为终端用户所处理。
3
分布式处理和数据传输是在线的，并且是单向的
4
分布式处理和数据传输是在线的，并且是双向的
5
由系统中最恰当的组件动态地执行处理功能
3性能
性能是吞吐量、处理时间等指标对开发的影响。
用户所提出的性能要求将直接影响到系统的设计，实施，安装和支持。
0
用户没有提出性能方面的要求
1
用户提出了性能和设计方面的要求，但不需要采取特定措施
2
响应时间和吞吐量在系统峰值时是关键的，但是不需要采取相应的CPU 使用方面的特殊设计。
处理的最后期限是在下一个工作日。
3
在任何时候响应时间和吞吐量都是关键的，但是不需要采取相应的CPU 使用方面的特殊设计。
处理的完成期限比较严格
4
除了上面一项的要求外，由于对需求的要求比较严格，在设计阶段就要进行性能分析
5
除了上面一项的要求之外，在设计和实施阶段需要使用性能分析工具来判断性能要求的完成情况
4大业务量配置
大业务量配置指的是计算机的资源对应用开发的影响程度。
大业务量的运行配置对设计有特殊要求，是必须考虑的一个系统特性。
0
没有提出明确的运行方面的限制
1
有运行方面的限制，但是不需要采取特别的措施以满足运行限制
2
提出了一些安全和时间方面的限制
3
应用程序的某些部分对处理器有特定的要求。
4
提出的运行限制对应用的中央处理器或者专用处理器有特殊的要求
5
除上面一项之外，还对应用的分布式组件提出了限制
5事务处理率
事务处理率是业务交易处理速度的要求对系统的设计，实施，安装和支持等的影响。
0
预计不会出现周期性的高峰事务处理期
1
预计会有周期性的高峰事务处理期（例如：
每月、每季、每年）
2
预计每周都会出现高峰事务处理期
3
预计每天都会出现高峰事务处理期
4
用户在应用程序需求或者服务级别协议中对事务率要求很高，因此必须在设计阶段进行性能分析。
5
用户在应用程序需求或者服务级别协议中对事务率要求很高，因此必须进行性能分析并在设计、开发和安装阶段中使用到性能分析工具。
6在线数据输入
在线数据输入是指数据通过交互的方式输入系统程度。
系统中包括在线数据输入和控制信息功能。
0
所有事务都是批处理的。
1
1%~7%的事务是以交互式的方式进行数据录入
2
8%~15%的事务是以交互式的方式进行数据录入
3
16%~23%的事务是以交互式的方式进行数据录入
4
24%~30%的事务是以交互式的方式进行数据录入
5
30%以上的事务是以交互式的方式进行数据录入
7最终用户效率
最终用户效率是指对应用的人文因素以及使用的便捷方面的考虑程度。
如下功能设计是针对最终用户效率的：
Ø 页面导航
Ø 菜单
Ø 在线帮助或文档
Ø 光标自动跳转
Ø 可以滚动
Ø 在线远程打印
Ø 预定义的功能键
Ø 在线做批量提交任务
Ø 光标可以选取界面上的数据
Ø 用户使用大量反白显示、重点显示、下划线或其他的标识
Ø 在线copy用户文档
Ø 鼠标拖动功能
Ø 弹出窗体
Ø 使用最少的界面完成某种商业功能
Ø 双语言支持（如果选择了这个就算4项）
Ø 多语言支持（如果选择了这个就算6项）
0
以上的一个都不包括
1
包括以上的1~3个
2
包括以上的4~5个
3
包括以上的6个或以上，但是没有用户对于效率的要求
4
包括以上的6个或以上，对用户使用效率有较高要求，因而必须考虑用户方面的设计（例如，最少击键次数、尽可能提供默认值、模版的使用）
5
包括以上的6个或以上，用户对效率的要求使得开发人员必须使用特定的工具和流程以判定用户对效率的要求已经被达成
8在线更新
在线更新是指内部逻辑文件ILF 被在线更新的程度。
应用系统提供在线更新内部逻辑文件的功能。
0
没有在线更新
1
包含1~3 个控制文件的在线更新。
更新的流量低，恢复容易
2
包含对4 个以上控制文件的在线更新。
更新的流量低，恢复容易
3
包含对主要ILF 的更新
4
除了3 之外，在设计和实施中要考虑对数据丢失的防范。
5
除了4 之外，大量的数据恢复工作要考虑成本因素，同时包含了高度自动化的恢复流程。
9复杂处理
复杂处理描述了逻辑处理对应用开发的影响程度。
它包含以下要素：
Ø 敏感控制（例如特殊的审核过程）和/或程序特定的安全处理
Ø 大量的逻辑处理
Ø 大量的数学处理
Ø 因为例外处理造成的需要重新处理的情况（例如，由TP中断、数据值缺少和验证失败导致的ATM事务）
Ø 多种可能的输入/输出造成的复杂处理
0
上面一个都不满足
1
只满足一个
2
只满足两个
3
满足三个
4
满足四个
5
都满足
10可复用性
应用系统中的应用和代码经过特殊设计、开发和支持，可以在其他应用系统中复用。
0
没有可复用的代码
1
代码在应用之内复用
2
应用中被其他用户复用的部分不足10%
3
应用中被不止一个用户使用的部分超过10%
4
应用遵从一种易于复用的方式被打包和文档化。
用户在源代码级客户化该应用
5
应用按照一种易于复用的方式被打包和文档化。
用户使用用户参数来对该应用进行客户化
11.易安装性
易安装性指应用系统的转换和安装容易度对开发的影响程度。
系统测试阶段提供了转换和安装计划和/或转换工具。
0
升级会员 