回复: 案例详解:功能点估算法
EI、EQ和EO的功能点数 本范例识别出来EI、EQ和EO功能点个数如下表所示。
| EI | FTR | DET个数 | 复杂度 | 未调整的FP个数 |
| 添加员工信息 | 员工、部门、工资表 | 员工信息的两个标签控件内容不是用户输入的,因此不算。共16个。 部门信息与员工信息中的部门字段重复,因此一个都不算。 工资表中的员工ID和名称不能重复,因此只能算金额和单位,所以共2个。 18个 | 高 | 6 |
| 修改员工信息 | 员工、部门、工资表 | 18个 同上 | 高 | 6 |
| 删除员工信息 | 员工、部门、工资表 | 1个 员工ID | 中等 | 4 |
| 添加部门信息 | 部门 | 1个 一个标签控件的内容不是用户输入的,因此不算 | 低 | 3 |
| 修改部门信息 | 部门 | 1个 一个标签控件的内容不是用户输入的,因此不算 | 低 | 3 |
| 删除部门信息 | 部门 | 1个 部门ID | 低 | 3 |
| EQ | FTR | DET个数 | 复杂度 | 未调整的FP个数 |
| 查询员工信息 | 员工、部门、工资表 | 20 | 高 | 6 |
| 查询部门信息 | 部门 | 2 | 低 | 3 |
| EO | FTR | DET个数 | 复杂度 | 未调整的FP个数 |
| 统计员工年薪 | 员工、工资表 | 员工ID、员工名称、年份、年薪、单位
共5个 | 低 | 4 |
本系统的通用系统特性及其影响程度如下表所示。
| 系统特性 | 分数 |
| 数据通讯 | 3 |
| 分布式数据处理 | 2 |
| 性能 | 0 |
| 高强度配置 | 0 |
| 交易速度 | 0 |
| 在线数据输入 | 5 |
| 最终用户效率 | 2 |
| 在线更新 | 3 |
| 负责的处理 | 0 |
| 可复用性 | 3 |
| 易安装性 | 0 |
| 易操作性 | 0 |
| 多场地 | 0 |
| 支持变更 | 1 |
合计:19 |
调整因子 = 19 * 0.01 + 0.65 = 0.84 |
最终调整后的功能点数量为:
(19 + 25 + 9 + 5)* 0.84 = 48.72个
总结 功能点估算法是一个非常有用的对软件规模进行估算的国际通用技术,是项目管理人员必须掌握的工具。为了便于大家对功能点的技术进行理解和记忆,这里对其进行总结:
由于计算机软件就是为了实现无纸办公,那么在估算功能点时应该多以用户的纸质表单为依据,每个表单就是一个ILF或EIF,表单上显示的字段都是DET,一个表单上的“核心”内容不管是由几个数据表来分别存放数据的,每个表都是一个RET。
简单来讲,ILF和EIF可以被看作数据库中的数据表,但是主、从表将被视为一个ILF或EIF。那么,ILF和EIF的复杂度就是由数据表中的字段DET和一个ILF或EIF自身所包含的主、从表个数RET来决定。在计算DET时主、外键只能算作一个。
EI就是对应用户增加、修改、删除的操作,EO和EQ都是用于用户查询的操作。EO和EQ的区别是,EO查询时使用了数学公式或计算方法。EI、EQ和EO的复杂度是由FTR和DET决定的。FTR的个数由ILF和EIF的个数决定,可以由主表中主、外键的个数来计算。在计算EI的DET时,只有用户在界面上直接输入的信息才算作DET,通过页面自动计算或转换的数据不能算作EI的DET。在EO和EQ计算DET时,报表的标题、页码等信息不能被计算为一个DET。
如果大家对功能点的内容有什么不懂或有其他意见,请通过张瑾的博客
http://space.itpub.net/?12876822与我进行探讨。