CMMI之功能点估算法:调整因子
计算调整因子
功能点的调整系数是通过通用系统特性及其影响程度来评定的,对每个常规系统特性的评估由其影响程度(DI)而定,分为0-5级:
0 毫无影响
1 偶然影响
2 适度影响
3 一般影响
4 重要影响
5 强烈影响
然后依次对以下14个系统常规特性进行打分,并带入以下计算公式算出功能点的调整因子。
Value Adjustment Factor=( sum of (DI) * 0.01 ) + 0.65
1. 数据通讯
数据通讯指的是应用程序直接与处理器通讯的程度。通常我们都是通过某种通讯手段来实现在一个应用中所使用的数据或者控制信息的。连接到本地控制器上的终端被认为是使用通讯设施,而协议指的是两个系统或者两个设备之间进行通讯时所使用的一种约定。所有的数据通讯链接都需要某种协议。
0 |
应用程序是单纯的批处理或者PC stand-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 |
用户对安装没有特定的要求 |
1 |
用户对安装没有特定的要求,但有特定的安装环境要求 |
2 |
用户提出了安装和转化的要求,转化/安装指南被经过测试提供给用户。但是转化的影响对该应用不重要 |
3 |
用户提出了安装和转化的要求,转化/安装指南被经过测试提供给用户。转化的影响对该应用来说是重要的 |
4 |
除了2 的要求之外,需要提供经过测试的自动化的安装和转化工具。 |
5 |
除了3 的要求之外,需要提供经过测试的自动化的安装和转化工具。 |
12. 易操作性
易操作性指的是应用对运行的影响程度,如有效启动、备份和恢复规程的影响。
易操作性是应用提供的一种特性,它最小化了手工操作的要求。
0 |
用户没有指定除正常备份程序外的其它特定操作 |
1 |
提供高效的启动、备份和恢复进程,但需要人手操作 |
2 |
提供高效的启动、备份和恢复进程,不需要人手操作(当作两项计算) |
3 |
应用程序对磁带的需求最小化 |
4 |
应用程序对硬拷贝处理的需求最小化 |
5 |
程序设计成无人操作模式。无人操作模式的意思是除了启动和关闭之外,不需要对系统进行操作。程序的其中一个功能就是错误自动恢复。 |
13. 多场地
多场地指应用系统经特殊设计、开发可以在多个组织、多个地点应用的程度。
0 |
用户需求不含多场地和组织的要求 |
1 |
考虑了多场地的要求,但是设计要求应用在不同的场地使用相同的软硬件环境 |
2 |
考虑了多场地的要求,但是设计要求应用在不同的场地使用类似的软硬件环境 |
3 |
考虑了多场地的要求,同时设计支持应用在不同的场地使用不同的软硬件环境 |
4 |
在1 或者2 的要求之上,提供了经过测试的多场地的文档和支持计划 |
5 |
在3 的要求之上,提供了经过测试的多场地的文档和支持计划 |
14. 支持变更
支持变更指的是应用在设计上考虑支持处理逻辑和数据结构变化的程度。
可以具有如下的特性:
提供可以处理简单要求的弹性查询和报告功能,如对一个ILF进行与(或)逻辑Ø
提供可以处理一般复杂度要求的弹性查询和报告功能,如对多于一个的ILF进行的与(或)逻辑(当作两项计算)Ø
提供可以处理复杂要求的弹性查询和报告功能,如对一个或多个ILF进行的与(或)逻辑的组合(当作三项计算)Ø
业务控制数据被保存到用户通过在线交互进程维护的表中,但变更只会在第二个工作日生效Ø
业务控制数据被保存到用户通过在线交互进程维护的表中,且变更即时生效Ø
0 |
一个都不满足 |
1 |
合计满足一个 |
2 |
合计满足二个 |
3 |
合计满足三个 |
4 |
合计满足四个 |
5 |
合计满足五个 |
计算调整后的功能点个数
国际的IFPUG组织将软件项目分为三类,功能点估算法适用于任何一类项目,其计算公式中的术语请详见表1。
功能点的原始计算公式:FP Countl =UFP * VAF
新开发项目l
有时新开发的软件项目也需要与其他现存的软件系统进行整合,例如:一个企业新开发的MIS内部管理系统经常会与财务系统进行整合。这个时候除了考虑本身项目的功能点个数外,还要考虑系统整合或数据迁移部分的工作量,因此其功能点计算公式如下:
FP Count =(UFP+CFP)* VAF
二次开发的项目l
有时新开发的软件项目是在原有基础上进行二次开发的,只是为了增加一些新的功能,因此其功能点计算公式如下:
FP Count = ADD * VAF
功能增强的项目l
对于功能增强的项目功能点估算比较复杂,在功能点增强前大家需要计算有哪些是新增加的功能,有哪些是被修改的功能,还有哪些是属于数据迁移或系统整合的功能。然后计算新系统技术复杂度的调整因子“VAFA”,并在此基础上计算系统功能点的数量。当然此类项目也会去掉一些原有功能,那么在原有系统的技术复杂度基础上重新计算功能点的调整因子“VAFB”,再计算所去掉功能贡献的功能点数量,因此其功能点计算公式如下:
FP Count = [(ADD+CHGA+CFP)* VAFA]+(DEL * VAFB)
表1 功能点技术公式术语
术语 |
英文 |
中文含义 |
ADD |
Added functionality |
被添加的功能点个数 |
CFP |
Conversion functionality |
被转换的功能点个数 |
CHGA |
UFP of changed functionality after enhancement |
功能增强后所改动的功能所贡献的未调整的功能点个数 |
DEL |
Deleted functionality |
被删除的功能点个数 |
UFP |
Unadjusted functional point count |
未调整的功能点个数 |
VAF |
Value adjustment factor VAF=(sum of(DI)* 0.01)+ 0.65 |
功能点的调整因子的计算公式 VAF=(sum of(DI)* 0.01)+ 0.65 |
VAFA |
Value adjustment factor after enhancement |
功能增强后的功能点调整因子 |
VAFB |
Value adjustment factor before enhancement |
功能增强前的功能点调整因子 |