FP功能点估算方法

是否适用该规则
每个字段都是唯一 的
计算EI\EO\EQ的复杂度
EO
FTR
获取银行信息
1
DET个数 复杂度 未调整的FP个数
FTR计数规则
是否适用该规则
在基本进程的处理过程中每读取 读取card_bin_info_mgr 一个ILF或EIF计为一个FTR
每个被维护的ILF计为一个FTR 否
即被读取又被维护的ILF算作一个 否 FTR
中文含义
未调整的功能点复杂度 功能点的调整因子的计算公式 新增的功能点复杂度 修改的功能点，未调整的功能点复杂度 转换功能的功能点复杂度 升级后的功能点调整因子 被删除的功能点复杂度 升级前的功能点调整因子 改造前的未调整的功能点复杂度 修改的功能点，修改之前的功能点复杂度
小结
FP计算过程 • 收集可得到的文档 • 确定计数范围和边界，识别功能用户需求 • 度量数据功能 • 度量事务功能 • 调整因子，计算功能规模
监控不足？
项目延期
资源投入 不够？
提口号时拍脑袋 做事情时拍胸脯 出事情后拍大腿 最后拍屁股走人
1.FP估算方法概述
概念
功能点估算
• 用于对软件规模进行度量 • 软件量化管理的基础
• 非标准度量方法——主观性强，难以保证估算的一致性
软件源代码行、对象点、需求数量、用例数、文档页码
• 标准度量方法——客观标准，保证估算的一致性
• 二次开发项目（若有前期估算基础） • EFP= [(ADD＋CHGA＋CFP)×VAFA]＋ (DEL×VAFB)
• 功能增强（若有前期估算基础） • AFP= [(UFPB＋ADD＋ CHGA)－(CHGB＋DEL)]×VAFA
术语
UFP VAF ADD CHGA CFP VAFA DEL VAFB UFPB CHGB
是用功能点分析（FPA）方法来度量软件功能规模的活动。
FP的目的
• 一个成功的软件项目首先要有一个好的起点，也就是一个 合理的项目计划；一个好的项目计划，离不开一个准确的、 可信的、客观的项目估算数据作为基础。
• 之所以要先制定项目计划，目的就是为了让项目更加可控。
• 加班是对不负责任的进度承诺的惩罚。
影响程度级别
0 1 2 3 4 5
● 8. 在线更新 ● 9. 复杂的处理 ● 10. 可重用性 ● 11. 安装的简易性 ● 12. 运行的简易性 ● 13. 多场地 ● 14. 允许变更
影响状况
不存在或者没有影响 偶尔的影响 轻微的影响 中等的影响 显著的影响 强烈的影响
计算结果输出
• 新开发项目 • DFP = UFP * VAF
1
DET个数 6
复杂度 低
未调整的FP个数 7
RET计数规则
是否适用该规则
ILF或EIF的每个可选的或强制的分组算 无强制分组 作一个RET
如果没有分组，则将ILF或EIF作为一个 一个ILF RET
DET计数规则 唯一的字段，通过程序维护的用户可区分的非重复字段， 算作一个DET
当两个程序引用同一个ILF\EIF，但各自维护、引用的是各 自的DET，则只计算各自使用的DET 用户需要用来与另一个ILF\EIF建立关系的每一条数据都计 算为一个DET---主外键
多场地 允许变更
影响程度等级（TDI）
5
1
3 0
影响程度 级别
影响状况
3
0
不存在或者没有影响
5
1
偶尔的影响
0
2
轻微的影响
3
3
中等的影响
0
3
4
显著的影响
0
5
强烈的影响
0
0
3
TDI=26
(调整系数)VAF=0.65+0.01*TDI=0.91
计算结果
UFP=11
TDI=26
EI、EO、EQ、ILF、EIF的复杂度总和 调整因子总和
功能点估算方法
Functional Size Measurement，FSM
FPA
2014年1月
内容
FP方法概述 • 概念 • 价值 • 应用 FP估算过程 • 步骤 • 规则 FP估算案例 • 案例一 • 案例二 FP估算演练
不够敬业？
加班赶工期
项目倒排期
技能不够？
不思进取？
资源抱怨压 力太大
RET
DET个数 复杂度 未调整的FP个数
（调整前）总FP的个数:UFP=11
计算调整因子 调整因子
参数
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14
参数名称
数据通讯 分布式数据处理
性能 使用强度高的配置
交易速度 在线数据输入 最终用户的效率
在线更新 复杂的处理
可重用性 安装的简易性 运行的简易性
EO
FTR
获取银行信息
1
DET个数 7
复杂度 低
未调整的FP个数 4
EO-DET计数规则 用户可识别的非重复的字段进入应用边界并且指明处理什么、 何时处理或处理方式并且由EO/EQ返回或产生，那么每个字段 算一个DET
每个发出应用边界的用户可识别的非重复字段算一个DET
如果字段同时进入发出边界，对该EO/EQ来说，只算一个DET
VAF=0.65+0.01*TDI=0.91调整系数
DFP = UFP * VAF=11*0.91=10.0FP1计算结果
案例二：客户交易记录处理
用户需求
• 用户要求保存客户的销售交易情况。在信息保存之前，可 以查看每项交易金额的交易总额。若用户不存在提示出错。
Customer Name： Transaction Date：
商品库 销售记录
EI EO EQ
EI
FTR
DET个数 复杂度 未调整的FP个数
客户姓名、交易
日期、单项、数
销售记录 保存
销售商品、 销售记录
2
量、商品单价、 商品总价、交易 小计、销售税、 交易合计、F1保
中
4
存、报错信息
11
保存算一个EI，查询并汇总算一个EO吗？
数据功能 EIF
销售商品
ILF 销售记录
20世纪70年代提出，演进为一个总标准（ISO14143） 与5个子标准
MarkII、COSMIC、NESMA、FISMA、IFPUG
概念
✓ 软件功能规模是指通过量化功能用户需求而得到的软件规模。
软件规模用功能点（FP）来表示，即功能点是IFPUG功能规模的度量单位。
✓ IFPUG功能规模度量（Functional Size Measurement，FSM）
• 用户通过界面向系统输入，目
逻辑文件
的是维护ILF或更改系统的行为。 • 用户角度识别的，被系统边界内
• 如：增、删、改的操作。
维护的数据或控制信息。
• 数据库的表、独立的文件
• EO: External Output外部输出
• 用户看到的一个完整业务逻辑对
• 系统向用户输出，通过逻辑处
象，在系统内部可能对应多个数
• 事务型
• 获取银行信息—接收卡bin，查询对应银行信息，返回结果； 对卡bin进行参数校验，校验不通过则返回校验失败信息。
确定数据分类
• card_bin_info_mgr
用户可识别的数据表或控制信 ✓ BankNo※
息，并且数据是逻辑成立的 ✓ CardBin
✓ CardType※
数据表是被边界内的基本处理 ✓ BankName※
• 数据存储类的复杂度 • DET：具体数据存储文件的数据项（字段）的数目。 • RET：一个EIL\ILF中用户可以识别的DET的集合。
• EI复杂度计算规则 • EO/EQ复杂度计算规则 • ILF复杂度计算规则 • EIL复杂度计算规则
调整影响因子
● 1.数据通讯 ● 2. 分布式数据处理 ● 3. 性能 ● 4. 使用强度高的配置 ● 5. 事务处理率 ● 6. 在线数据输入 ● 7. 最终用户的效率
理派生数据。
据表。
• 如：导出、报表、打印、出错 信息。
• EIF: External Interface Files外 部接口文件
• EQ: External Queries外部查询
• 系统向边界外发送数据，该数 据未经加工。
• 被其他系统维护的，本系统需要 调用的数据
• 如：查询
几个关注点
✓ 每个事务功能都是唯一的基本过程 ✓ 每个基本过程都由一个或多个处理逻辑来实现 ✓ 代码数据不能算作数据功能 ✓ 数据功能的维护、获取都需要通过事务功能来进行 ✓ 控制信息是影响基本过程的数据，也需要考虑数据功能
数据功能度量过程 • 识别数据功能（借助识别规则） • 分类数据功能ILF\EIF • 判断RET和DET（借助计算规则） • 根据复杂度判定表计算复杂度 • 根据复杂性转换表计算功能规模
事务功能度量过程 • 识别事务功能（借助识别规则） • 分类事务功能EI\EO\EQ • 判断FTR和DET（借助计算规则） • 根据复杂度判定表计算复杂度 • 根据复杂性转换表计算功能规模
3.FP估算案例
案例一：卡bin风控接口
• 业务方提供卡bin，卡bin 系统匹配后返回相应的发卡 行机构代码 、发卡行名称、 卡片类型。匹配失败则返回 “无匹配结果”
需求描述
用例图
参数校验
风控
获取银行信息
区分功能点
• 数据型
• card_bin_info_mgr-ILF
• BankNo※ • CardBin • CardType※ • BankName※ • RespCode-系统计算结果 • RespDesc-系统计算结果
解和描述的； • 相关应用之间的边界是由用户看到的不同功能区域来划分
，而不是由技术考虑来划分的； • 应用之间初始的边界不会因为功能点分析而改变。
在升级项目中，如果原先的应用已经识别了边界，则边界不需要重新识别
区分功能点
• 事务功能
• 数据功能
• E I : External Input外部输入
• ILF: Internal Logical Files内部
VAF=0.65+0.01*TDI
6.输出计算结果
确定项目的计数范围
• 新开发项目 • 开发并交付软件应用的第一个正式版本项目
• 升级项目 • 开发并交付修改后的项目，包括所有被增加、修改和删除的 功能
• 功能增强性项目 • 单一功能改造的项目
分析需求，识别边界
IFPUG标准中给出了识别应用边界的规则 • 边界的定义必须基于用户的视角，边界必须是用户能够理
是否适用该规则 否
6
如果应用能够发送一个系统响应信息（如：说明过程中发生错 1 误，确认处理过程已经完成，确认处理过程应该继续）到应用 边界之外，这种能力算一个DET
即使有多种方法调用同一逻辑过程，也只能为这一特定动作计 算一个DET
对那些虽然被保存、返回、派生的没有穿越边界的字段不计算 DET
文字的，页面的，系统产生的标签不计算DET
缺乏有效的估算方法与过程导致无法制 定出准确的项目计划
FP的价值ቤተ መጻሕፍቲ ባይዱ
✓ 更准确的项目规模 ✓ 更客观的项目进度和预算 ✓ 项目的可预测性 ✓ 更早的风险识别
监控
计划
FP估算
• 仅仅通过估算实践本身并不能获得准确的估算结果，还需要 通过有效的项目控制。
• FP的首要目标不是预测项目的结果，而是确定项目目标是否 足够现实，从而让项目在可控的状态下达到这些目标。
过程来维护的
✓ RespCode-系统计算结果
✓ RespDesc-系统计算结果
结论：一个ILF
确定事务分类
• 获取银行信息
该事务是否符合EI/EO/EQ的目 的？
EI：以修改ILF为目的 EO: 返回一个经过计算的结果 EQ：返回查询的结果
结论：一个EO
计算ILF\EIF复杂度
ILF
RET
card_bin_info_mgr
• 估算无需非常准确，但是要有用。
FP的应用
✓ 工作量估算 项目功能点/生产率=项目工作量 ✓ 人力成本预算 资源个数＊平均工资=资源成本
生产率
FP
工资
平均成本
项目能否按期交付？ 项目的收益？
2.FP估算过程
FP估算步骤
1.确定项目的计数范围 2.分析需求，识别边界 3.识别功能点类型
4.计算功能复杂度 5.调整影响因子TDI
Cost
Item
F1=Save
Sales Transaction
Qty
at
￥.
￥.
￥.
￥.
Item Cost ￥. ￥. ￥. ￥.
Sub Total ￥ Sales Tax ￥
. .
Total ￥ .
Item Total
• 客户姓名 • 交易日期 • 单项 • 数量 • 商品单价 • 商品总价 • 交易小计 • 销售税 • 交易合计
功能点识别规则
• 识别EI\EO\EQ的规则有哪些？ • EI的识别规则 • EQ\EO的识别规则
• 如何正确区分EI\EO\EQ？ • EI\EO\EQ的区分
• 如何正确识别ILF\EIF？ • ILF的识别规则 • EIF的识别规则
计算功能点的复杂度
• 事务型功能点复杂度 • DET：通过界面录入的具体数据项 • FTR：事务功能需要操作的数据文件的数目