功能点估算法（四）

范例

     以员工管理系统为范例，在添加一个员工资料时会使用到员工的一般信息、员工的教育情况、工作经历和家属信息。员工又会隶属于某个部门，在本系统中会有一个对部门进行维护的功能。员工的工资是由另外一个财务系统提供的。因此其用例图如下所示：

图 员工管理系统用例图   

Ø 假设员工基本信息如下所示：

员工ID（标签控件）

员工名称

性别

生日

婚否

所属部门ID（标签控件）

所属部门名称

——受教育的时间

——学校名称

——所学专业

——工作时间

——工作单位

——工作部门

——工作职务

——亲属的姓名

——之间关系

——亲属年龄

——工作单位

Ø 假设部门信息如下所示：

部门ID（标签控件）

部门名称

Ø 假设工资表信息如下所示：

员工ID（标签控件）

员工姓名

金额

单位 

本范例识别出来ILF和EIF功能点个数如下表所示。

ILF内部逻辑文件	RET	DET个数	复杂度	未调整的FP个数
员工信息	员工基本信息、员工受教育情况、工作经历、亲属信息，共4个。	18个	低	7
部门信息	部门基本信息，共1个。	2个	低	7
EIF外部接口文件	RET	DET个数	复杂度	未调整的FP个数
工资表	员工基本信息、工资信息，共2个。	4个	低	5
合计：19个

    

本范例识别出来EI、EQ和EO功能点个数如下表所示。

EI	FTR	DET个数	复杂度	未调整的FP个数
添加员工信息	员工、部门、工资表	员工信息的两个标签控件的内容不是用户输入的，因此不算。共16个。部门信息与员工信息中的部门字段重复，因此一个都不算。工资表中的员工ID和名称不能重复，因此只能算金额和单位，所以共2个18个	高	6
修改员工信息	员工、部门、工资表	18个同上	高	6
删除员工信息	员工、部门、工资表	1个员工ID	中等	4
添加部门信息	部门	1个一个标签控件的内容不是用户输入的，因此不算	低	3
修改部门信息	部门	1个一个标签控件的内容不是用户输入的，因此不算	低	3
删除部门信息	部门	1个部门ID	低	3
合计：25个
EQ	FTR	DET个数	复杂度	未调整的FP个数
查询员工信息	员工、部门、工资表	20个	高	6
查询部门信息	部门	2个	低	3
合计：9个
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。如果大家对功能点的内容有什么不懂或有其他意见，请通过张瑾的博客jinzhang.csai.cn与我进行探讨。