本篇主要介绍在功能点分析法FPA中，如何计算一个处理元（EI/EO/EQ）有多少个功能点。ILF/EIF的功能点是根据其包含的DET和RET来确定的；EI/EO/EQ的功能点则是根据其包含的DET和FRT来确定的。计算流程也与ILF/EIF的功能点计算流程类似，分为四小步。
1.         统计EI/EO/EQ中的数据元素类型FTR。
2.         统计EI/EO/EQ中的记录元素类型DET。
3.         参照FTR/DET——复杂度对照表，确定该IEI/EO/EQ的复杂度。
4.         参照复杂度——功能点对照表，确定该EI/EO/EQ的功能点数。
IFPUG根据大量的项目统计数据，分别为EI、EO和EQ给出了FTR/DET——复杂度——功能点数的对照表。我们只需按图索骥即可，不需要任何的数学计算公式。
计算EI/EO/EQ的功能点数，应当在列出所有的EI/EO/EQ后进行。本系列笔记四介绍了如何是识别EI/EO/EQ。

1.           文件类型引用FTR

FTR (File Type Referenced)在IFPUG CPM中的定义有两条：An ILF read or maintained by a transactional function; Or An EIF read by a transactional function。其实说白了就一条，在一个处理功能中涉及到的所有逻辑文件。处理功能可能是EI/EO/EQ；逻辑文件是ILF/EIF。
CPM分别讲述了在EI、EO和EQ中统计FTR的规则，归纳起来其实都一样，十分简单明了。
l  在EI/EO中每一个被维护的ILF计为一个FTR。
l  在EI/EO/EQ中每一个被读入的ILF/EIF计为一个FTR。
l  如果在一个EI/EO中，一个ILF既被读入，也被维护，只计一个FTR。
所谓“维护”，在本系列笔记的前面某篇最后中有介绍，是指创建、添加、修改或删除一个ILF。由于EQ中不可能有维护ILF的操作，所以它一定没有和维护相关的FTR。
 

2.           数据元素类型DET

处理功能中统计的DET，和ILF/EIF中统计的DET，定义是一样的：A data element type is a unique user recognizable, non-repeated field。它们可以算是同一个东西，只不过计数规则不同。
l  每一个满足下列所有条件的字段都要计为一个DET.
n  用户可识别的。
n  不重复的。
n  为完成相应的处理元而进入或退出系统边界的。
l  没有穿越系统边界的字段不能计为DET，这些字段通常是有两种情形：
n  由系统从ILF中获取的字段，
n  系统衍生的并保存在ILF中的字段。
n  硬编码的文本，如标题。
n  系统生成的时间戳。
n  系统生成的变量，如页码、行列号等位置信息、向前向后等导航信息。
l  如果系统具有向外界发送处理状态消息的机能，将该机能计为一个DET。处理状态消息通常用来
n  指示处理异常。
n  指示处理已完成。
n  确认处理是否继续。
l  对每一个输入的操作指令计为一个DET。只要指令要求的操作一样，无论有多少个方式输入指令，都只计一个DET。直观的看，一个按钮或菜单项就是一个DET。但键盘快捷键十有八九不是。
 
 
 

3.           FTR/DET——复杂度——功能点数的对照表

同ILF/EIF的功能点数对照表类似，EI/EO/EQ也是按照三级复杂度来确定功能点数。EI、EO和EQ的复杂度和功能点数对照表各不相同。归纳如下面量表所示。
表格 2 处理元复杂度矩阵
EI 复杂度
EQ/EO 复杂度
DET 个数
RET 个数
1 ~ 4
5 ~15
 >=16
DET 个数
RET 个数
1 ~ 5
6 ~19
 >= 20
1
低
低
中
1
低
低
中
2
低
中
高
2 ~ 3
低
中
高
>= 3
中
高
高
>= 4
中
高
高
 
表格 3 处理元功能点计算表
复杂度
低
中
高
EI/EQ 功能点数
3
4
6
EO 功能点数
4
5
7
 
得到每一个EI/EO/EQ的功能点数后，把它们的功能点数简单加和起来，就是整个系统的处理功能点数了。

4.           案例——员工信息表

一个简单的员工信息维护界面，如下图所示，不涉及任何EIF。
FPA笔记六 计算EI/EO/EQ的功能点_第1张图片
图表 1 员工信息界面
l  它只有一个FTR，就是ILF员工信息。
l  EI保存处理元有8个DET：六个字段，加两个按钮。取消按钮不算。
l  EI上除处理元有3个DET：六个字段算一个DET，两个按钮算两个DET。