功能点估算法（四）

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

zhangjin 发表于 2008/11/20 16:56:00 阅读全文 | 回复(0) | 引用通告 | 编辑 | 收藏该日志

发表评论：