IFPUG 功能点分析介绍
引言
IFPUG 的功能点分析（FPA ）方法是一种目前被广泛接受的关于软件规模度量的有效方法。目前越来越多的组织在运用这个方法进行软件规模的度量。故在此对功能点分析做一些简单的介绍，以供大家了解。
FPA 简介
FPA 是从用户角度出发度量软件规模的一种方法。它从用户的角度出发，将系统分为数据功能和交易功能两大类，分别根据具体的规则来计算功能点，最后结合系统的特征因子来调整功能点数，从而得到最终的系统规模。
具体的度量步骤如下所示：
1. 确定功能点计数类型
2. 识别软件的应用边界
3. 识别数据功能以确定其复杂度以及UFP
4. 识别事务功能以确定其复杂度以及UFP
5. 确定UFP 数
6. 确定值调整因子
7. 计算调整FP 数
这里的用户指的是用户功能性需求的任何人和/或任何时候与软件通信或互动的任何人或事物。 所谓用户可识别是指为处理而定义的需求或/和能被用户和软件开发者赞同和读懂的数据组。
所以一定要注意功能点评估的方法一定是从用户角度出发，并能够得到用户的认可，它与具体采用何种开发语言，何种技术方案无关。
关于功能点计数类型
功能点计数类型在IFPUG 的FPA 中分为三类：新开发类型、增强类型、应用系统。
其中新开发类型简单的来说就是从无到有的开发一个系统；
增强类型简单的来说就是在原有系统基础上新增、完善甚至删除已有的功能。
应用系统则是指对已经存在的系统进行功能点计数。
这三种类型的系统在计算功能点的时候会采用不同的计算方法。
关于应用边界
在FPA 中强调在进行FPA 之前一定要定义应用的边界。因为这关系到后续在计算功能点的时候相关类型功能的识别以及最终的规模。
而所谓应用边界就是定义范围，从用户的角度出发，确定哪些业务包含在应用中，而哪些业务在应用之外。
关于数据功能
在FPA 中将数据功能分为两类：
1、内部逻辑文件（Internal Logical File, ILF）
2、外部接口文件(External Interface File, EIF)
这里的文件指的是一组用户可识别的逻辑数据或者控制信息。它与我们在具体实现时设计出来的物理模型是无关的。
内部逻辑文件（ILF ）指的是一组用户可识别的在应用边界内且被维护的逻辑相关数据或者控制信息。ILF 的主要目的是通过应用的一个或几个基本处理过程维护数据。
而外部接口文件（EIF ）指的是一组在应用边界内被查询，但是在其它应用中被维护的、用户可识别的、逻辑相关数据或者控制信息。
从以上的定义可以看出来ILF 与EIF 的最大区别在于ILF 会被应用维护，而EIF 不会被应用维护。 识别ILF 和EIF 的有效工具是数据流图。
具体的ILF 和EIF 的识别规则在这里不详述，可以参照IFPUG 的实践手册（CPM ）。
在我们识别了ILF 和EIF 之后，我们就需要计算它们的复杂度。在FPA 中采用下面两个指标来计算ILF 和EIF 的复杂度：
1、数据元素类型（Data Element Types, DET）
2、记录元素类型（Record Element Types, RET）
其中一个DET 就是一个唯一的用户可认知的，不重复的数据域。类似于数据库表中的字段，但不完全相同。
而一个RET 就是一个ILF 或者EIF 内用户可认知的数据元素子集。
在FPA 中有给ILF 和EIF 的DET 以及RET 定义详细的计算规则，可参考CPM 。
根据对每个ILF 和EIF 计算出来的DET 和RET 的数量，在FPA 中就会将ILF 和EIF 划分为低，中，高三个复杂度等级。具体的划分规则可参照CPM 。
关于交易功能
在FPA 中将交易功能划分为三种：
1、 外部输入（External Input, EI）
2、 外部输出（External Output, EO）
3、 外部查询（External inQuery, EQ）
这里的EI 指的是处理来自应用边界之外的数据或控制信息的基本处理过程。EI 的主要目的是维护一个或多个ILF 并且/或者改变系统的行为。
EO 指的是向应用边界之外发送数据或控制信息的基本处理过程.EO 的主要目的是通过逻辑处理方式向用户呈现信息，而不只是直接恢复数据或控制信息。该处理逻辑必须包含至少一个数学公式或计算过程，或生成派生数据。一个EO 也可能维护一个或多个ILF 和/或改变系统行为。
EQ 指的是向应用边界之外发送数据或控制信息的基本处理过程. EQ的主要目的是通过恢复数据或控制信息向用户呈现信息。该处理逻辑不包括任何的数学公式或计算过程，不会生成任何的派生数据。EQ 处理过程中既不会维护任何ILF ，也不会改变系统行为。
在FPA 中有定义详细的对EI 、EO 、EQ 三者的识别规则，在此不详述。通常，这三种功能就是对用户提出的功能性需求的分类。它关注的对象是具体的每一个功能。
对于交易功能，在FPA 中采用DET 和FTR （引用文件类型）两个指标来计算它们的复杂度。 其中FTR 指的是一个被交易功能读取或维护的ILF 或者是一个被交易功能读取的EIF 。
根据对每个EI 、EO 、EQ 计算出来的DET 和FTR 的数量，在FPA 中也将它们划分为低、中、高三个复杂度等级。具体划分规则可参见CPM 。
根据以上计算出来的数据功能和交易功能的复杂度，FPA 综合很多软件项目的数据，提供了一个复杂度与功能点的对应表，具体参见CPM 。
根据上表识别出每个数据功能和交易功能的功能点，然后求和即为未经调整的功能点数（Unadjusted Function Point）
关于调整系数
在上面计算出来的未经调整的功能点数没有考虑到系统的非功能性需求，因此，FPA 有定义14个系统调整因子来针对系统的非功能性需求来计算调整系数。这14个系统调整因子分别是：
1. 数据通讯 8. 在线升级
2. 分布式数据处理 9. 复杂处理
3. 性能 10. 可重用性
4. 资源需求 11. 易安装性
5. 事务频率 12. 易操作性
6. 在线数据输入 13. 多点运行
7. 终端用户效率 14. 易变更
对于以上的每一个影响因子，FPA 将其影响程度定义为以下的5个等级。
∙
∙
∙
∙
∙
∙ 0 毫无影响 1 偶然影响 2 偏下影响 3 一般影响 4 重大影响 5 强烈影响
每个特征因子都有定义详细的识别规则，可参考CPM 。
功能点调整系数（Value Adjustment Factor, VAF）=（TDI×0.01）+0.65。
其中TDI 指以上14个特征因子影响程度分值的和。根据以上的公式可以知道，VAF 的值在0.65～
1.35范围内。
计算已调整功能点（Adjusted Function Point， AFP ）
根据在第一步中识别的功能点计数类型，计算已调整功能点的公式有不同。其中新开发项目功能点计算公式为：
AFP=（UFP+CFP）×VAF
其中，UFP=未调整功能点总数
CFP=转换功能点
此处转换功能指系统安装时需要用到，但不直接提供给最终用户使用的功能。通常是实现诸如数据转换这样的功能。
有关其他两种类型的已调整功能点计算公式参见CPM 。
关于功能点的应用
功能点计算出来了，那它跟我们的工作有什么样的联系呢？通常，在项目规划及执行阶段，可以利用功能点来预估项目的人力费用、品质等。
例如，根据行业经验数据，Java 语言开发时，一个功能点的生产时间在1～1.4天内（此处的生产时间仅指软件开发活动，它通常包含需求分析、设计、编码、测试等活动，但不包含项目管理、软件维护等支持性且因项目要求的不同而差异较大的活动）。那么我们就可以根据计算出来的功能点推算出项目可能的人力。典型公式：项目总生产人力=项目功能点数×生产效率。
在项目结束后来计算功能点，有助于我们根据实际的生产时间来计算单位内部的生产效率等度量指标。典型公式：生产效率=项目总生产人力/项目功能点数
重要的是，由于功能点分析是一个从用户角度出发的，与实现细节无关的评估方法，所以利用功能点计算出来相关数据（诸如生产效率、缺陷率等），有助于增强企业间生产能力比较的可信度，也有助于在行业内形成有比较基准的数据，作为企业运营过程中的参考。
后记
以上仅仅对IFPUG 的FPA 的相关概念进行了简单的介绍。目的是起到一个引导的作用，让读者了解IFPUG 的FPA 的基本内容。真正要实践FPA 还需要读者仔细去研习CPM （Counting Practices Manual ），当前最新版本为4.2.1。
功能点分析（Function Point Analysis）学习笔记(一）
前段时间，有抽空余时间对功能点分析进行了较深入的研习。以下将研习过程中的内容摘要如下，以做备忘和参考：
IFPUG 维护的功能点分析（FPA ）是众多功能点评估方法中的一种，目前应用较广泛。当前最新版本是4.2.1.
为了推动Function Point的方法在行业中的应用，IFPUG 有推出CFPS 的认证。
FPA 是从用户角度出发度量软件规模的一种方法。其目标是：
1. 度量用户要求和能够接收到的功能
2. 提供一种与具体实施方法和技术无关的对软件开发和维护进行度量的手段
3. 提供一种相对来说比较简单的对规模进行度量的方法
4. 提供一种在不同的项目和组织之间能够保持一致的度量方法
相对于其他的软件度量方法而言（诸如代码行），其主要的特点是：该度量方法与技术无关，也就是说对于同一组用户需求，无论你采用什么开发语言，其规模都应该是一定的。且该度量方法是面向用户的，从用户角度出发的，而其他的度量方法多从技术角度出发，很难让用户接收。
这里先讲几个基本的概念：
用户：是指用户功能性需求的任何人和/或任何时候与软件通信或互动的任何人或事物
用户视角：它是对业务功能的描述，此为，它应该：
1. 被用户认可
2. 能够被用来计算功能点
3. 能以不同的文档形式出现
利用功能点分析的步骤如下图所示：
功能点分析（Function Point Analysis）学习笔记（二）
1、决定分析类型
功能点计算的类型分为：
∙
∙
∙ 开发项目——开发项目功能点计算度量的是项目完成、用户第一次安装系统时提供给用户的功能 升级项目——升级项目功能点计算度量的是项目完成对已存在的应用系统新增、修改或者删除的功能 应用程式——应用程式功能点计算度量的是已经安装运行的系统提供给用户的功能。
2、识别计算范围和应用边界
计算范围定义了一组（部分）被度量的软件
∙
∙
∙ 它由功能点计算的目的决定 它确定功能点计数中包括的功能 它可以包含一个或多个应用
应用边界指出了被度量的软件之间的分界线
∙
∙
∙
∙ 内部应用与外部用户时间的概念接口；起一种“膜”的作用，数据就是通过这层膜进出应用 包括被应用维护的逻辑数据 协助识别在应用中查询但不在应用中维护的逻辑数据 依赖于用于对应用外部业务的视角；与技术和/或是是方式相独立
识别计算范围和应用边界的规则
∙
∙
点。 边界是从用户的角度来划分和决定 应用之间的边界是以用户能够看得见的可分隔的功能域为基础，而不是以技术考虑为出发
功能点分析（Function Point Analysis)学习笔记（三）
3、计算数据功能
3.1、基本概念
3.1.1、数据功能类型
∙
∙ 内部逻辑文件 InternalLogical File （ILF ） 外部接口文件 External Interface File （EIF ）
此处的文件不是传统数据处理意义上的文件，而是指一组逻辑上相互关联的数据，并不是实现意义上的物理的数据集合。
3.1.2、ILF
∙
∙ ILF 是一组用户可识别的在应用边界内且被应用维护的逻辑相关数据或者控制信息。 它的主要目的是通用应用的一个或几个基本处理过程维护数据。
3.1.3、EIF
∙
∙ EIF 是一组在应用边界内被查询，但在其他应用中被维护的、用户可识别的、逻辑相关数据或者控制信息。 EIF 的主要目的是使数据在应用边界内通过一个或几个基本处理过程得以查询。这就意味着
一个应用中的一个EIF 必然是其他应用中的ILF 。
3.1.4、相关概念
∙
∙
∙
∙ 用户可识别——它是指为处理而定义的需求或/和能被用户和软件开发者赞同和读懂的数据组。 维护——它指的是可以通过一个基本处理过程更改数据的能力 控制信息——它是影响应用基本处理过程的数据。它指明了处理什么、何时处理或处理方式。 基本处理过程——一个基本处理过程就是一个用户可以理解的最小活动单元。
3.2、识别规则
3.2.1、ILF 识别规则
∙ 该组数据或控制信息是逻辑相关的且由用户定义。
∙ 以上两条规则都须同时满足，才能算做ILF 。
3.2.2、EIF 识别规则
∙
∙
∙
∙
∙ 该组数据或控制信息是逻辑相关的且由用户定义。 该组数据处于被计数应用之外，且被该应用查询。 被计数的应用不对该组数据进行维护。 该组数据被其它的应用维护。 以上四条规则都须同时满足，才能算做EIF 。
3.3、功能点计算
∙
∙
∙
∙ 根据ILF 和EIF 的复杂度和贡献度来计算其功能点。 ILF 和EIF 的复杂度和贡献度取决于以下两种类型元素的数量： 数据元素类型 Date Element Types （DET ） 记录元素类型 Record Element Types （RET ）
3.3.1、基本概念
∙
∙ DET ——一个DET 就是一个唯一的用户可认知的、不重复的数据域 RET ——一个RET 就是一个ILF 或EIF 内用户可认知的数据元素子集
3.3.2、DET 计算规则
∙
∙
∙ 如果通过一个基本处理过程的执行在ILF 维护或从ILF 或EIF 中返回一个特定的用户可识别的、非重复字段，那么每个这样的字段算一个DET 当两个应用维护和/或查询相同的ILF/EIF，但是每个应用单独维护/查询相应的DET ，只计算被每个应用使用的DET 对于那些用户要求与其他的EIF/ILF建立关联的数据字段来说，每个这样的数据字段都应算
一个DET
3.3.3、RET 计算规则
∙
∙ 每个ILF 或EIF 得可选或必选子组算一个RET 如果该ILF/EIF没有子组，那么就将该ILF/EIF算作一个RET
3.3.4、复杂矩阵
3.3.5、功能点复杂程度对应表
3.3.6、计算数据功能的提示
∙
∙ 一个应用可以在多个处理过程中用到同一个ILF/EIF，但是这个ILF/EIF只能被计算一次 在同一个应用中一个逻辑文件不能同时作为ILF 和EIF 来计算。如果一个数据集合同时满足
ILF 和EIF 的识别规则，则当作ILF 来计算。
∙
∙ 不要假设一个物理文件、表或对象等于一个从用户视角可以识别的数据逻辑文件 不要假设所有的物理文件都必须被计算为一个ILF/EIF，或是ILF/EIF的一部分
3.3.7、计算数据功能的注意事项
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 以下数据不会作为ILF/EIF计算 临时文件或不同迭代阶段的同一文件 工作文件/排序文件 摘录或视图文件（在打印或显示前，从ILF/EIF中提取） 由于技术原因引入的文件 可选索引、联合、关系或联接 审计数据或历史数据，他们和应用功能数据一起计算 除以上外，以下数据也不会作为ILF 计算 同一文件的复本 用作企业备份和恢复的数据（系统的基本特征） 包括不完整业务信息的中间数据 除以上外，以下数据也不会作为EIF 计算 从另外系统接收的数据，用于应用中的一个或多个ILF(EI) 由应用格式化后发给其他应用的数据
功能点分析（Function Point Analysis）学习笔记（四）
4、计算交易功能
4.1、相关概念
4.1.1、交易功能类型
∙
∙
∙ 外部输入 External Inputs（EI ） 外部输出 External Outputs（EO ） 外部查询 External inQuiries（EQ ）
4.1.2、EI
∙
∙ 是处理来自应用边界之外的数据或控制信息的基本处理过程。 EI 的主要目的是维护一个或多个ILF 并且/或者改变系统的行为
4.1.3、EO
∙
∙
∙ 是向应用边界之外发送数据或控制信息的基本处理过程。 主要目的是通过逻辑处理方式向用户呈现信息，而不只是直接恢复数据或控制信息。该处理逻辑必须包含至少一个数学公式或计算过程或生成派生数据 一个EO 也可能维护一个或多个ILF 和/或改变系统行为
4.1.4、EQ
∙
∙ 是向应用边界之外发送数据或控制信息的基本处理过程。 主要目的是通过恢复数据或控制信息向用户呈现信息。该处理逻辑不包括任何的数学公式或
计算过程，不会生成任何的派生数据。
∙ EQ 处理过程中既不会维护任何ILF ，也不会改变系统行为
4.1.5、EI 、EO 、EQ 都是逻辑处理
逻辑处理指的是用户提出的完成某个处理的请求。逻辑处理的例子包括： ∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 数据验证 数学公式和计算 数据的过滤和选择 分析适用的条件 更新一个或者多个ILF 引用一个或者多个ILF 或EIF 运用现有的数据生成衍生数据 改变系统的行为 向应用范围之外准备和显示数据 接受进入系统边界的数据或者控制信息 恢复和重新整理数据
4.2、识别规则
4.2.1、EI 识别规则
∙
∙
∙
∙
∙
∙ 数据或控制信息从应用边界之外输入。 如果穿过边界的数据不是改变系统行为的控制信息，那么至少应维护一个ILF 。 对于已识别的处理过程，至少满足下面三个条件之一 ： 处理逻辑与该应用中其它EI 所用的处理逻辑不同 该组已识别的数据元素不同于该应用中其它EI 的数据元素 所涉及的ILF 或EIF 不同于该应用中其它EI 所涉及的文件
4.2.2、EO 识别规则
∙
∙
∙
∙
∙
∙
∙
∙
∙ 数据或控制信息发送出应用边界。 对于已识别的基本处理过程，至少满足下面三个条件之一 ： 处理逻辑与该应用中其它EO 所用的处理逻辑不同 该组已识别的数据元素不同于该应用中其它EO 的数据元素 所涉及的ILF 或EIF 不同于该应用中其它EO 所涉及的文件 还需满足下述条件之一 处理逻辑包含至少一个数学公式或计算过程 至少一个ILF 被处理逻辑维护 处理逻辑改变了系统的行为
4.2.3、EQ 识别规则
∙
∙
∙
∙ 数据或控制信息发送出应用边界。 对于已识别的基本处理过程，至少满足下面三个条件之一 ： 处理逻辑与该应用中其它EQ 所用的处理逻辑不同 该组已识别的数据元素不同于该应用中其它EQ 的数据元素
∙
∙
∙
∙
∙
∙ 所涉及的ILF 或EIF 不同于该应用中其它EQ 所涉及的文件 还应该满足下述所有条件： 该处理逻辑从一个ILF 或EIF 返回数据或控制信息 该处理逻辑不包含任何数学公式或计算过程 该处理逻辑不改变系统行为 该处理逻辑不维护任何ILF
4.3、计算规则
4.3.1、基本概念
∙
∙
∙
∙ 根据EI ，EO ，EQ 的复杂度和贡献度来计算 EI, EO, EQ的复杂度和贡献度取决于以下两种元素的数量 引用文件类型 FTR (File Types Referenced) 数据元素类型 DET (Data Element Types)
4.3.2、FTR
∙
∙ 它是一个被交易功能读取或者维护的内部逻辑文件 或是一个被交易功能读取的外部接口文件
4.3.3、DET
∙ 一个DET 就是一个唯一的用户可认知的，不重复的数据域
4.3.4、EI 的功能点计算
4.3.4.1、FTR 计算规则
∙
∙
∙ 每个被维护的ILF 算一个FTR 每个在EI 处理过程中读取的ILF 或EIF 算一个FTR 由EI 维护和读取的ILF 只算一个FTR
4.3.4.2、DET 计算规则
∙
∙
∙
∙ 完成EI 的过程中，如果一个用户可识别的、非重复的字段穿越应用边界，那么该字段应算一个DET 如果在EI 过程中，系统取出或派生一个字段并且该字段存储在一个ILF 之内且没有穿越应用边界，则无须计算DET 如果应用能够发送一个系统响应信息（如：说明EI 过程中发生错误，确认处理过程已经完成，确认处理过程应该继续）到应用边界之外，则算一个DET 即使有多种方法调用同一逻辑过程，也只能为这一特定动作计算一个DET
4.3.4.3、注意事项
以下不能单独计算为EI
∙
∙
∙
∙
∙ 包含在查询或输出中的输入请求 用于导航或选择不维护ILF 的菜单窗口 帮助用户进行系统的登陆 激活同一逻辑的多种方法 刷新或取消窗口中的数据
∙
∙ 需要用户删除或其他事务消息的反应 在同一系统内部（线程与批处理或客户端到服务器）
4.3.4.4、复杂度矩阵
功能点分析（Function Point Analysis）学习笔记（五）
4.3.5、EO 、EQ 功能点计算
4.3.5.1、FTR 计算规则
∙
∙
∙
∙
∙ EO/EQ的FTR 计算规则 每个在EO/EQ处理过程中读取的ILF 和EIF 算一个FTR EO 额外的FTR 计算规则 每个在EO 处理过程中维护的ILF 算一个FTR 每个在EO 处理过程中读取和维护的ILF 算一个FTR
4.3.5.2、DET 计算规则
∙
∙
∙
∙
∙
∙
∙
∙ DET 数量等于根据下列规则确定的字段总数 用户可识别的非重复的字段进入应用边界并且指明处理什么、何时处理或处理方式并且由EO/EQ返回或产生，那么每个字段算一个DET 每个发出应用边界的用户可识别的非重复字段算一个DET 如果字段同时进入发出边界，对该EO/EQ来说，只算一个DET 如果应用能够发送一个系统响应信息（如：说明过程中发生错误，确认处理过程已经完成，确认处理过程应该继续）到应用边界之外，这种能力算一个DET 即使有多种方法调用同一逻辑过程，也只能为这一特定动作计算一个DET 对那些虽然被保存、返回、派生的没有穿越边界的字段不计算DET 文字的，页面的，系统产生的标签不计算DET
4.3.5.3、注意事项
以下不能单独计算为EO
∙
∙
∙
∙
∙
∙
∙ 数据值不同的相同报告 不包含公式或复杂计算的报告 帮助（EQ ） 退出系统 激活同一输出过程的多种方法 需要用户删除或其他事务消息的反应 在同一系统内部（线程与批处理或客户端到服务器）
4.3.5.4、复杂度矩阵
4.3.5.5、复杂度与功能点对应
功能点分析（Function Point Analysis）学习笔记（六）
5、计算未经调整功能点数
在分别识别并计算了数据功能（Data Function）和交易功能（Transaction Function）的复杂度之后，利用下表就可以计算出未经调整功能点数：
功能点分析（Function Point Analysis）学习笔记（七）
6、计算调整系数和功能点
6.1、调整系数（Value Adjustment Factor, VAF）
VAF=（TDI×0.01）+0.65
∙
∙ 其中TDI (Total Degree of Influence) 为所有系统特征因素影响程度的和 VAF 值的范围为0.65~1.35间
6.2、已调整功能点数（Adjusted Function Point）
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 开发项目（Development ）=（UFP+CFP）×VAF 应用（Application ）=ADD×VAF 增强项目（Enhancement ）=[(ADD+CHGA+CFP)×VAFA]+(DEL×VAFB) 其中： UFP 为未调整功能点总数 CFP 为转换功能点 ADD 为增加的功能点 CHGA 为增强后改变功能的UFP VAFA 为增强后调整系数 DEL 为被删除功能点 VAFB 为增强前调整系数
6.3、系统特征因子
有14个系统特征因子：
∙
∙
∙
∙
∙
∙
∙ 1、数据通讯 2、分布式数据处理 3、性能 4、资源需求 5、事务频率 6、在线数据输入 7、终端用户效率 8、在线升级 9、复杂处理 10、可重用性 11、易安装性 12、易操作性 13、多点运行 14、易变更
每个特征因子的影响程度分为6个级别：
∙
∙
∙
∙
∙
∙ 0 毫无影响 1 偶然影响 2 小影响 3 一般影响 4 重要影响 5 强烈影响
每个特征引子的影响程度都有自己的判定规则！
功能点分析（Function Point Analysis)学习笔记（八）
6.3.1、数据通讯（Data Communication）
∙
∙
∙
∙
∙ 0 应用程序是纯粹的批处理程序或者运行在独立的PC 上 1 应用程序是批处理程序，但是有远程数据输入或远程打印 2 应用程序是批处理程序，但是有远程数据输入和远程打印 3 对于批处理程序或者查询系统来说，应用程序包含在线数据收集或者一个远程处理前端 4 应用程序不仅是一个前端，他还支持一种类型的通信协议
∙ 5 应用程序不仅是一个前端，他还支持不止一种类型的通信协议
6.3.2、分布式数据处理（distributed data processing）
∙
∙
∙
∙
∙
∙ 0 应用程序不支持系统部件之间的数据传输或者处理 1 应用程序为系统其他部件上的用户处理、准备数据 2 为传输准备数据，将数据传输到系统的另一个部分进行处理（不是最终用户）【就是在系统个部件之间传输数据】 3 分布式处理和数据传输在线进行并且是单项的 4 分布式处理和数据传输是在线进行并且是双向的 5 多数系统相应部件上都是动态执行处理功能
6.3.3、性能（Performance ）
∙
∙
∙
∙
∙
∙
求 0 用户没有提出任何要求 1 提出并评审了性能，但不必采取专门措施 2 响应时间和吞吐量在业务峰值时段是至关重要的。但不必为了CPU 的利用率而采用专门设计。业务处理的截至日期在下一个工作日 3 响应时间和吞吐量在业务峰值时段是至关重要的。但不需要为CPU 利用率而采用专门的设计。业务处理的截至日期是有限制的 4 此外，已提出的用户性能需求已经迫切到了在设计阶段安排专门的性能分析任务 5 此外，需要在设计、开发和（或）实施阶段使用性能分析工具来满足已提出的用户性能需
6.3.4、资源需求（heavily used configuration）
∙
∙
∙
∙
∙
制 0 不包括任何直接或者间接的操作限制 1 确实存在操作限制，但是比通常的应用程序的约束要少一些。 2 包括一些安全性或者时间限制的考虑 3 应用程序的某个部分需要专门的处理器 4 已提出的操作限制需要在中央处理器或者一个专门的处理器中的应用程序上加上特殊限
5 此外，在应用系统的分布式部件上存在特殊的限制 ∙
功能点分析（Function Point Analysis）学习笔记（九）
6.3.5、事务频率（Transaction Rate）
∙
∙
∙
∙
∙
了 0 没有可预见的峰值处理时段 1 可以预见一个峰值处理时断（每月，每季度） 2 可遇见每周一次的高峰 3 每天一次的高峰 4 用户在应用程序需求或者服务中提出的高处理率已经需要在设计阶段安排性能分析工作
5 需求中的处理要求必须在设计阶段安排性能分析工作，且需在设计、开发部署阶段使用性能分析工具 ∙
6.3.6、在线数据输入（Online Data Entry）
∙ 0 没有
∙
∙
∙
∙
∙ 1 1% ~ 7% 2 8%~15％ 3 16%~23％ 4 24%~30% 5 >30%
6.3.7、终端用户效率（End User Efficiency）
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 考察界面的友好性 辅助导航（功能键，跳转，动态生成树的菜单） 菜单 在线帮助和文档 光标的自动移动 滚动 远程打印（在线处理） 定制功能键 在线处理提交的批处理作业 使用光标选定屏幕的数据 大量使用的翻转录像、高度、颜色、下划线和其他指示器 在线处理的硬拷贝文档用户 鼠标界面 弹出式菜单 用尽可能少的屏幕来完成一种业务功能 支持两种语言（这个规定要算4项） 多种语言支持（这个要算6项） 记分标准 0 0项 1 1~3项 2 4~5项 3 >=6项 ，但用户没有其他关于使用效率的专门需求 4 >=6项，但已经提出了其他关于使用效率的需求强烈到需要在设计阶段进行人性化设计分析的工作 5 >=6项，需要使用特殊的工具来满足要求
6.3.8、在线升级（Online Update）
∙
∙
∙
∙
∙
∙ 0 无要求 1 更新1~3个控制文件。数据量低，容易恢复 2 更新4个或者更多的控制文件。数据量低，易恢复 3 包含对主要内部逻辑文件的更新 4 除以上之外，防止数据丢失式一项基本要求，而且经过了专门的设计并已经实现 5 除以上之外，大数据量促使恢复过程要考虑成本问题。高度自动化的恢复过程只需要少量
的人工干预
功能点分析（Function Point Analysis）学习笔记（十）
6.3.9、复杂处理（Complex Processing）
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 根据逻辑对程序开发的影响需要考虑下面的部分 敏感性控制(特殊的审计处理) 和特定应用程序的安全处理 大量的逻辑处理 大量的数学处理 很多的例外处理，因此必须再次处理不完整的事物 应付多种输入/输出格式 记分标准 0 没有 1 1项 2 2项 3 3项 4 4项 5 所有项
6.3.10、可重用性（Reusability ）
∙
∙
∙
∙
∙
∙ 0 没有可重用代码 1 可重用的代码重用于应用程序内部 2 应用程序中少于10％的部分会被一个以上的用户使用 3 应用程序中大于等于10％的部分会被一个以上的用户使用 4 应用程序被专门打包和文档化以简化重用 5 除4之外，用户可以通过参数维护定制应用程序
6.3.11、易安装性（Installation Ease）
∙
∙
∙
∙
∙
∙ 0 没有提出安装要求，也无需考虑安装问题 1 没有提出安装需求，但是要考虑安装问题，进行相应的工作 2 提出安装需求，提供并测试了转换和安装的指南。项目中转换工作带来的影响并不重要 3 并给项目中的工作带来显著的影响 4 除2外，提供并测试自动安装工具 5 除3外，要求提供自动安装工具
6.3.12、易操作性（Operational Ease）
∙
∙
∙
∙
∙
∙
∙ 0 除了正常的备份处理程序，用户没有提出特殊的操作方面的额外考虑 1~4 从下列项目中选择准确的特性, 每个要点记1分： 提供有效地启动、备份、恢复备份处理，但是需要操作员人工干预 无需干预 需要人工安装磁带 需要人工穿空纸和穿孔纸带 5 应用程序无人值守，所有的操作都不需要人工干预。系统能够自动进行错误恢复
6.3.13、多点运行（Multiple Sites）
∙
∙
∙
∙
∙
∙ 0 没有需求 1 有需求，但应用得软硬件环境相同 2 软硬件环境相似 3 软硬件环境不相同 4 系统中有相应的设计和文档，其他同1，2 5 系统中有相应的设计和文档，其他同3
6.3.14、易变更（Facilitate Change）
∙
∙ 考察范围 提供能够处理简单请求的灵活查询以及报表支持 ，例如对一个ILF 的处理 (算1
项).
提供能够处理简单请求的灵活查询以及报表支持 ，例如对不止一个ILF 的处理(算
2项).
提供能够处理复杂请求的灵活查询以及报表支持，例如提供一个或者一个以上得处
理功能 (算3项).
业务控制数据保存在由用户通过在线交互处理维护的表中，但是变更只在下一个工
作日才生效 (算1项).
业务控制数据保存在由用户通过在线交互处理维护的表中，需立即生效生效(算2
项).
记分标准 ∙ ∙ ∙ ∙ ∙
∙
∙
∙
∙
∙
∙ 0 一个都不满足 1 满足以上的1个 2 满意以上的2个 3 满足以上的3个 4 满足以上的4个 5 满足以上的5个
IFPUG 功能点分析介绍
引言
IFPUG 的功能点分析（FPA ）方法是一种目前被广泛接受的关于软件规模度量的有效方法。目前越来越多的组织在运用这个方法进行软件规模的度量。故在此对功能点分析做一些简单的介绍，以供大家了解。
FPA 简介
FPA 是从用户角度出发度量软件规模的一种方法。它从用户的角度出发，将系统分为数据功能和交易功能两大类，分别根据具体的规则来计算功能点，最后结合系统的特征因子来调整功能点数，从而得到最终的系统规模。
具体的度量步骤如下所示：
1. 确定功能点计数类型
2. 识别软件的应用边界
3. 识别数据功能以确定其复杂度以及UFP
4. 识别事务功能以确定其复杂度以及UFP
5. 确定UFP 数
6. 确定值调整因子
7. 计算调整FP 数
这里的用户指的是用户功能性需求的任何人和/或任何时候与软件通信或互动的任何人或事物。 所谓用户可识别是指为处理而定义的需求或/和能被用户和软件开发者赞同和读懂的数据组。
所以一定要注意功能点评估的方法一定是从用户角度出发，并能够得到用户的认可，它与具体采用何种开发语言，何种技术方案无关。
关于功能点计数类型
功能点计数类型在IFPUG 的FPA 中分为三类：新开发类型、增强类型、应用系统。
其中新开发类型简单的来说就是从无到有的开发一个系统；
增强类型简单的来说就是在原有系统基础上新增、完善甚至删除已有的功能。
应用系统则是指对已经存在的系统进行功能点计数。
这三种类型的系统在计算功能点的时候会采用不同的计算方法。
关于应用边界
在FPA 中强调在进行FPA 之前一定要定义应用的边界。因为这关系到后续在计算功能点的时候相关类型功能的识别以及最终的规模。
而所谓应用边界就是定义范围，从用户的角度出发，确定哪些业务包含在应用中，而哪些业务在应用之外。
关于数据功能
在FPA 中将数据功能分为两类：
1、内部逻辑文件（Internal Logical File, ILF）
2、外部接口文件(External Interface File, EIF)
这里的文件指的是一组用户可识别的逻辑数据或者控制信息。它与我们在具体实现时设计出来的物理模型是无关的。
内部逻辑文件（ILF ）指的是一组用户可识别的在应用边界内且被维护的逻辑相关数据或者控制信息。ILF 的主要目的是通过应用的一个或几个基本处理过程维护数据。
而外部接口文件（EIF ）指的是一组在应用边界内被查询，但是在其它应用中被维护的、用户可识别的、逻辑相关数据或者控制信息。
从以上的定义可以看出来ILF 与EIF 的最大区别在于ILF 会被应用维护，而EIF 不会被应用维护。 识别ILF 和EIF 的有效工具是数据流图。
具体的ILF 和EIF 的识别规则在这里不详述，可以参照IFPUG 的实践手册（CPM ）。
在我们识别了ILF 和EIF 之后，我们就需要计算它们的复杂度。在FPA 中采用下面两个指标来计算ILF 和EIF 的复杂度：
1、数据元素类型（Data Element Types, DET）
2、记录元素类型（Record Element Types, RET）
其中一个DET 就是一个唯一的用户可认知的，不重复的数据域。类似于数据库表中的字段，但不完全相同。
而一个RET 就是一个ILF 或者EIF 内用户可认知的数据元素子集。
在FPA 中有给ILF 和EIF 的DET 以及RET 定义详细的计算规则，可参考CPM 。
根据对每个ILF 和EIF 计算出来的DET 和RET 的数量，在FPA 中就会将ILF 和EIF 划分为低，中，高三个复杂度等级。具体的划分规则可参照CPM 。
关于交易功能
在FPA 中将交易功能划分为三种：
1、 外部输入（External Input, EI）
2、 外部输出（External Output, EO）
3、 外部查询（External inQuery, EQ）
这里的EI 指的是处理来自应用边界之外的数据或控制信息的基本处理过程。EI 的主要目的是维护一个或多个ILF 并且/或者改变系统的行为。
EO 指的是向应用边界之外发送数据或控制信息的基本处理过程.EO 的主要目的是通过逻辑处理方式向用户呈现信息，而不只是直接恢复数据或控制信息。该处理逻辑必须包含至少一个数学公式或计算过程，或生成派生数据。一个EO 也可能维护一个或多个ILF 和/或改变系统行为。
EQ 指的是向应用边界之外发送数据或控制信息的基本处理过程. EQ的主要目的是通过恢复数据或控制信息向用户呈现信息。该处理逻辑不包括任何的数学公式或计算过程，不会生成任何的派生数据。EQ 处理过程中既不会维护任何ILF ，也不会改变系统行为。
在FPA 中有定义详细的对EI 、EO 、EQ 三者的识别规则，在此不详述。通常，这三种功能就是对用户提出的功能性需求的分类。它关注的对象是具体的每一个功能。
对于交易功能，在FPA 中采用DET 和FTR （引用文件类型）两个指标来计算它们的复杂度。 其中FTR 指的是一个被交易功能读取或维护的ILF 或者是一个被交易功能读取的EIF 。
根据对每个EI 、EO 、EQ 计算出来的DET 和FTR 的数量，在FPA 中也将它们划分为低、中、高三个复杂度等级。具体划分规则可参见CPM 。
根据以上计算出来的数据功能和交易功能的复杂度，FPA 综合很多软件项目的数据，提供了一个复杂度与功能点的对应表，具体参见CPM 。
根据上表识别出每个数据功能和交易功能的功能点，然后求和即为未经调整的功能点数（Unadjusted Function Point）
关于调整系数
在上面计算出来的未经调整的功能点数没有考虑到系统的非功能性需求，因此，FPA 有定义14个系统调整因子来针对系统的非功能性需求来计算调整系数。这14个系统调整因子分别是：
1. 数据通讯 8. 在线升级
2. 分布式数据处理 9. 复杂处理
3. 性能 10. 可重用性
4. 资源需求 11. 易安装性
5. 事务频率 12. 易操作性
6. 在线数据输入 13. 多点运行
7. 终端用户效率 14. 易变更
对于以上的每一个影响因子，FPA 将其影响程度定义为以下的5个等级。
∙
∙
∙
∙
∙
∙ 0 毫无影响 1 偶然影响 2 偏下影响 3 一般影响 4 重大影响 5 强烈影响
每个特征因子都有定义详细的识别规则，可参考CPM 。
功能点调整系数（Value Adjustment Factor, VAF）=（TDI×0.01）+0.65。
其中TDI 指以上14个特征因子影响程度分值的和。根据以上的公式可以知道，VAF 的值在0.65～
1.35范围内。
计算已调整功能点（Adjusted Function Point， AFP ）
根据在第一步中识别的功能点计数类型，计算已调整功能点的公式有不同。其中新开发项目功能点计算公式为：
AFP=（UFP+CFP）×VAF
其中，UFP=未调整功能点总数
CFP=转换功能点
此处转换功能指系统安装时需要用到，但不直接提供给最终用户使用的功能。通常是实现诸如数据转换这样的功能。
有关其他两种类型的已调整功能点计算公式参见CPM 。
关于功能点的应用
功能点计算出来了，那它跟我们的工作有什么样的联系呢？通常，在项目规划及执行阶段，可以利用功能点来预估项目的人力费用、品质等。
例如，根据行业经验数据，Java 语言开发时，一个功能点的生产时间在1～1.4天内（此处的生产时间仅指软件开发活动，它通常包含需求分析、设计、编码、测试等活动，但不包含项目管理、软件维护等支持性且因项目要求的不同而差异较大的活动）。那么我们就可以根据计算出来的功能点推算出项目可能的人力。典型公式：项目总生产人力=项目功能点数×生产效率。
在项目结束后来计算功能点，有助于我们根据实际的生产时间来计算单位内部的生产效率等度量指标。典型公式：生产效率=项目总生产人力/项目功能点数
重要的是，由于功能点分析是一个从用户角度出发的，与实现细节无关的评估方法，所以利用功能点计算出来相关数据（诸如生产效率、缺陷率等），有助于增强企业间生产能力比较的可信度，也有助于在行业内形成有比较基准的数据，作为企业运营过程中的参考。
后记
以上仅仅对IFPUG 的FPA 的相关概念进行了简单的介绍。目的是起到一个引导的作用，让读者了解IFPUG 的FPA 的基本内容。真正要实践FPA 还需要读者仔细去研习CPM （Counting Practices Manual ），当前最新版本为4.2.1。
功能点分析（Function Point Analysis）学习笔记(一）
前段时间，有抽空余时间对功能点分析进行了较深入的研习。以下将研习过程中的内容摘要如下，以做备忘和参考：
IFPUG 维护的功能点分析（FPA ）是众多功能点评估方法中的一种，目前应用较广泛。当前最新版本是4.2.1.
为了推动Function Point的方法在行业中的应用，IFPUG 有推出CFPS 的认证。
FPA 是从用户角度出发度量软件规模的一种方法。其目标是：
1. 度量用户要求和能够接收到的功能
2. 提供一种与具体实施方法和技术无关的对软件开发和维护进行度量的手段
3. 提供一种相对来说比较简单的对规模进行度量的方法
4. 提供一种在不同的项目和组织之间能够保持一致的度量方法
相对于其他的软件度量方法而言（诸如代码行），其主要的特点是：该度量方法与技术无关，也就是说对于同一组用户需求，无论你采用什么开发语言，其规模都应该是一定的。且该度量方法是面向用户的，从用户角度出发的，而其他的度量方法多从技术角度出发，很难让用户接收。
这里先讲几个基本的概念：
用户：是指用户功能性需求的任何人和/或任何时候与软件通信或互动的任何人或事物
用户视角：它是对业务功能的描述，此为，它应该：
1. 被用户认可
2. 能够被用来计算功能点
3. 能以不同的文档形式出现
利用功能点分析的步骤如下图所示：
功能点分析（Function Point Analysis）学习笔记（二）
1、决定分析类型
功能点计算的类型分为：
∙
∙
∙ 开发项目——开发项目功能点计算度量的是项目完成、用户第一次安装系统时提供给用户的功能 升级项目——升级项目功能点计算度量的是项目完成对已存在的应用系统新增、修改或者删除的功能 应用程式——应用程式功能点计算度量的是已经安装运行的系统提供给用户的功能。
2、识别计算范围和应用边界
计算范围定义了一组（部分）被度量的软件
∙
∙
∙ 它由功能点计算的目的决定 它确定功能点计数中包括的功能 它可以包含一个或多个应用
应用边界指出了被度量的软件之间的分界线
∙
∙
∙
∙ 内部应用与外部用户时间的概念接口；起一种“膜”的作用，数据就是通过这层膜进出应用 包括被应用维护的逻辑数据 协助识别在应用中查询但不在应用中维护的逻辑数据 依赖于用于对应用外部业务的视角；与技术和/或是是方式相独立
识别计算范围和应用边界的规则
∙
∙
点。 边界是从用户的角度来划分和决定 应用之间的边界是以用户能够看得见的可分隔的功能域为基础，而不是以技术考虑为出发
功能点分析（Function Point Analysis)学习笔记（三）
3、计算数据功能
3.1、基本概念
3.1.1、数据功能类型
∙
∙ 内部逻辑文件 InternalLogical File （ILF ） 外部接口文件 External Interface File （EIF ）
此处的文件不是传统数据处理意义上的文件，而是指一组逻辑上相互关联的数据，并不是实现意义上的物理的数据集合。
3.1.2、ILF
∙
∙ ILF 是一组用户可识别的在应用边界内且被应用维护的逻辑相关数据或者控制信息。 它的主要目的是通用应用的一个或几个基本处理过程维护数据。
3.1.3、EIF
∙
∙ EIF 是一组在应用边界内被查询，但在其他应用中被维护的、用户可识别的、逻辑相关数据或者控制信息。 EIF 的主要目的是使数据在应用边界内通过一个或几个基本处理过程得以查询。这就意味着
一个应用中的一个EIF 必然是其他应用中的ILF 。
3.1.4、相关概念
∙
∙
∙
∙ 用户可识别——它是指为处理而定义的需求或/和能被用户和软件开发者赞同和读懂的数据组。 维护——它指的是可以通过一个基本处理过程更改数据的能力 控制信息——它是影响应用基本处理过程的数据。它指明了处理什么、何时处理或处理方式。 基本处理过程——一个基本处理过程就是一个用户可以理解的最小活动单元。
3.2、识别规则
3.2.1、ILF 识别规则
∙ 该组数据或控制信息是逻辑相关的且由用户定义。
∙ 以上两条规则都须同时满足，才能算做ILF 。
3.2.2、EIF 识别规则
∙
∙
∙
∙
∙ 该组数据或控制信息是逻辑相关的且由用户定义。 该组数据处于被计数应用之外，且被该应用查询。 被计数的应用不对该组数据进行维护。 该组数据被其它的应用维护。 以上四条规则都须同时满足，才能算做EIF 。
3.3、功能点计算
∙
∙
∙
∙ 根据ILF 和EIF 的复杂度和贡献度来计算其功能点。 ILF 和EIF 的复杂度和贡献度取决于以下两种类型元素的数量： 数据元素类型 Date Element Types （DET ） 记录元素类型 Record Element Types （RET ）
3.3.1、基本概念
∙
∙ DET ——一个DET 就是一个唯一的用户可认知的、不重复的数据域 RET ——一个RET 就是一个ILF 或EIF 内用户可认知的数据元素子集
3.3.2、DET 计算规则
∙
∙
∙ 如果通过一个基本处理过程的执行在ILF 维护或从ILF 或EIF 中返回一个特定的用户可识别的、非重复字段，那么每个这样的字段算一个DET 当两个应用维护和/或查询相同的ILF/EIF，但是每个应用单独维护/查询相应的DET ，只计算被每个应用使用的DET 对于那些用户要求与其他的EIF/ILF建立关联的数据字段来说，每个这样的数据字段都应算
一个DET
3.3.3、RET 计算规则
∙
∙ 每个ILF 或EIF 得可选或必选子组算一个RET 如果该ILF/EIF没有子组，那么就将该ILF/EIF算作一个RET
3.3.4、复杂矩阵
3.3.5、功能点复杂程度对应表
3.3.6、计算数据功能的提示
∙
∙ 一个应用可以在多个处理过程中用到同一个ILF/EIF，但是这个ILF/EIF只能被计算一次 在同一个应用中一个逻辑文件不能同时作为ILF 和EIF 来计算。如果一个数据集合同时满足
ILF 和EIF 的识别规则，则当作ILF 来计算。
∙
∙ 不要假设一个物理文件、表或对象等于一个从用户视角可以识别的数据逻辑文件 不要假设所有的物理文件都必须被计算为一个ILF/EIF，或是ILF/EIF的一部分
3.3.7、计算数据功能的注意事项
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 以下数据不会作为ILF/EIF计算 临时文件或不同迭代阶段的同一文件 工作文件/排序文件 摘录或视图文件（在打印或显示前，从ILF/EIF中提取） 由于技术原因引入的文件 可选索引、联合、关系或联接 审计数据或历史数据，他们和应用功能数据一起计算 除以上外，以下数据也不会作为ILF 计算 同一文件的复本 用作企业备份和恢复的数据（系统的基本特征） 包括不完整业务信息的中间数据 除以上外，以下数据也不会作为EIF 计算 从另外系统接收的数据，用于应用中的一个或多个ILF(EI) 由应用格式化后发给其他应用的数据
功能点分析（Function Point Analysis）学习笔记（四）
4、计算交易功能
4.1、相关概念
4.1.1、交易功能类型
∙
∙
∙ 外部输入 External Inputs（EI ） 外部输出 External Outputs（EO ） 外部查询 External inQuiries（EQ ）
4.1.2、EI
∙
∙ 是处理来自应用边界之外的数据或控制信息的基本处理过程。 EI 的主要目的是维护一个或多个ILF 并且/或者改变系统的行为
4.1.3、EO
∙
∙
∙ 是向应用边界之外发送数据或控制信息的基本处理过程。 主要目的是通过逻辑处理方式向用户呈现信息，而不只是直接恢复数据或控制信息。该处理逻辑必须包含至少一个数学公式或计算过程或生成派生数据 一个EO 也可能维护一个或多个ILF 和/或改变系统行为
4.1.4、EQ
∙
∙ 是向应用边界之外发送数据或控制信息的基本处理过程。 主要目的是通过恢复数据或控制信息向用户呈现信息。该处理逻辑不包括任何的数学公式或
计算过程，不会生成任何的派生数据。
∙ EQ 处理过程中既不会维护任何ILF ，也不会改变系统行为
4.1.5、EI 、EO 、EQ 都是逻辑处理
逻辑处理指的是用户提出的完成某个处理的请求。逻辑处理的例子包括： ∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 数据验证 数学公式和计算 数据的过滤和选择 分析适用的条件 更新一个或者多个ILF 引用一个或者多个ILF 或EIF 运用现有的数据生成衍生数据 改变系统的行为 向应用范围之外准备和显示数据 接受进入系统边界的数据或者控制信息 恢复和重新整理数据
4.2、识别规则
4.2.1、EI 识别规则
∙
∙
∙
∙
∙
∙ 数据或控制信息从应用边界之外输入。 如果穿过边界的数据不是改变系统行为的控制信息，那么至少应维护一个ILF 。 对于已识别的处理过程，至少满足下面三个条件之一 ： 处理逻辑与该应用中其它EI 所用的处理逻辑不同 该组已识别的数据元素不同于该应用中其它EI 的数据元素 所涉及的ILF 或EIF 不同于该应用中其它EI 所涉及的文件
4.2.2、EO 识别规则
∙
∙
∙
∙
∙
∙
∙
∙
∙ 数据或控制信息发送出应用边界。 对于已识别的基本处理过程，至少满足下面三个条件之一 ： 处理逻辑与该应用中其它EO 所用的处理逻辑不同 该组已识别的数据元素不同于该应用中其它EO 的数据元素 所涉及的ILF 或EIF 不同于该应用中其它EO 所涉及的文件 还需满足下述条件之一 处理逻辑包含至少一个数学公式或计算过程 至少一个ILF 被处理逻辑维护 处理逻辑改变了系统的行为
4.2.3、EQ 识别规则
∙
∙
∙
∙ 数据或控制信息发送出应用边界。 对于已识别的基本处理过程，至少满足下面三个条件之一 ： 处理逻辑与该应用中其它EQ 所用的处理逻辑不同 该组已识别的数据元素不同于该应用中其它EQ 的数据元素
∙
∙
∙
∙
∙
∙ 所涉及的ILF 或EIF 不同于该应用中其它EQ 所涉及的文件 还应该满足下述所有条件： 该处理逻辑从一个ILF 或EIF 返回数据或控制信息 该处理逻辑不包含任何数学公式或计算过程 该处理逻辑不改变系统行为 该处理逻辑不维护任何ILF
4.3、计算规则
4.3.1、基本概念
∙
∙
∙
∙ 根据EI ，EO ，EQ 的复杂度和贡献度来计算 EI, EO, EQ的复杂度和贡献度取决于以下两种元素的数量 引用文件类型 FTR (File Types Referenced) 数据元素类型 DET (Data Element Types)
4.3.2、FTR
∙
∙ 它是一个被交易功能读取或者维护的内部逻辑文件 或是一个被交易功能读取的外部接口文件
4.3.3、DET
∙ 一个DET 就是一个唯一的用户可认知的，不重复的数据域
4.3.4、EI 的功能点计算
4.3.4.1、FTR 计算规则
∙
∙
∙ 每个被维护的ILF 算一个FTR 每个在EI 处理过程中读取的ILF 或EIF 算一个FTR 由EI 维护和读取的ILF 只算一个FTR
4.3.4.2、DET 计算规则
∙
∙
∙
∙ 完成EI 的过程中，如果一个用户可识别的、非重复的字段穿越应用边界，那么该字段应算一个DET 如果在EI 过程中，系统取出或派生一个字段并且该字段存储在一个ILF 之内且没有穿越应用边界，则无须计算DET 如果应用能够发送一个系统响应信息（如：说明EI 过程中发生错误，确认处理过程已经完成，确认处理过程应该继续）到应用边界之外，则算一个DET 即使有多种方法调用同一逻辑过程，也只能为这一特定动作计算一个DET
4.3.4.3、注意事项
以下不能单独计算为EI
∙
∙
∙
∙
∙ 包含在查询或输出中的输入请求 用于导航或选择不维护ILF 的菜单窗口 帮助用户进行系统的登陆 激活同一逻辑的多种方法 刷新或取消窗口中的数据
∙
∙ 需要用户删除或其他事务消息的反应 在同一系统内部（线程与批处理或客户端到服务器）
4.3.4.4、复杂度矩阵
功能点分析（Function Point Analysis）学习笔记（五）
4.3.5、EO 、EQ 功能点计算
4.3.5.1、FTR 计算规则
∙
∙
∙
∙
∙ EO/EQ的FTR 计算规则 每个在EO/EQ处理过程中读取的ILF 和EIF 算一个FTR EO 额外的FTR 计算规则 每个在EO 处理过程中维护的ILF 算一个FTR 每个在EO 处理过程中读取和维护的ILF 算一个FTR
4.3.5.2、DET 计算规则
∙
∙
∙
∙
∙
∙
∙
∙ DET 数量等于根据下列规则确定的字段总数 用户可识别的非重复的字段进入应用边界并且指明处理什么、何时处理或处理方式并且由EO/EQ返回或产生，那么每个字段算一个DET 每个发出应用边界的用户可识别的非重复字段算一个DET 如果字段同时进入发出边界，对该EO/EQ来说，只算一个DET 如果应用能够发送一个系统响应信息（如：说明过程中发生错误，确认处理过程已经完成，确认处理过程应该继续）到应用边界之外，这种能力算一个DET 即使有多种方法调用同一逻辑过程，也只能为这一特定动作计算一个DET 对那些虽然被保存、返回、派生的没有穿越边界的字段不计算DET 文字的，页面的，系统产生的标签不计算DET
4.3.5.3、注意事项
以下不能单独计算为EO
∙
∙
∙
∙
∙
∙
∙ 数据值不同的相同报告 不包含公式或复杂计算的报告 帮助（EQ ） 退出系统 激活同一输出过程的多种方法 需要用户删除或其他事务消息的反应 在同一系统内部（线程与批处理或客户端到服务器）
4.3.5.4、复杂度矩阵
4.3.5.5、复杂度与功能点对应
功能点分析（Function Point Analysis）学习笔记（六）
5、计算未经调整功能点数
在分别识别并计算了数据功能（Data Function）和交易功能（Transaction Function）的复杂度之后，利用下表就可以计算出未经调整功能点数：
功能点分析（Function Point Analysis）学习笔记（七）
6、计算调整系数和功能点
6.1、调整系数（Value Adjustment Factor, VAF）
VAF=（TDI×0.01）+0.65
∙
∙ 其中TDI (Total Degree of Influence) 为所有系统特征因素影响程度的和 VAF 值的范围为0.65~1.35间
6.2、已调整功能点数（Adjusted Function Point）
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 开发项目（Development ）=（UFP+CFP）×VAF 应用（Application ）=ADD×VAF 增强项目（Enhancement ）=[(ADD+CHGA+CFP)×VAFA]+(DEL×VAFB) 其中： UFP 为未调整功能点总数 CFP 为转换功能点 ADD 为增加的功能点 CHGA 为增强后改变功能的UFP VAFA 为增强后调整系数 DEL 为被删除功能点 VAFB 为增强前调整系数
6.3、系统特征因子
有14个系统特征因子：
∙
∙
∙
∙
∙
∙
∙ 1、数据通讯 2、分布式数据处理 3、性能 4、资源需求 5、事务频率 6、在线数据输入 7、终端用户效率 8、在线升级 9、复杂处理 10、可重用性 11、易安装性 12、易操作性 13、多点运行 14、易变更
每个特征因子的影响程度分为6个级别：
∙
∙
∙
∙
∙
∙ 0 毫无影响 1 偶然影响 2 小影响 3 一般影响 4 重要影响 5 强烈影响
每个特征引子的影响程度都有自己的判定规则！
功能点分析（Function Point Analysis)学习笔记（八）
6.3.1、数据通讯（Data Communication）
∙
∙
∙
∙
∙ 0 应用程序是纯粹的批处理程序或者运行在独立的PC 上 1 应用程序是批处理程序，但是有远程数据输入或远程打印 2 应用程序是批处理程序，但是有远程数据输入和远程打印 3 对于批处理程序或者查询系统来说，应用程序包含在线数据收集或者一个远程处理前端 4 应用程序不仅是一个前端，他还支持一种类型的通信协议
∙ 5 应用程序不仅是一个前端，他还支持不止一种类型的通信协议
6.3.2、分布式数据处理（distributed data processing）
∙
∙
∙
∙
∙
∙ 0 应用程序不支持系统部件之间的数据传输或者处理 1 应用程序为系统其他部件上的用户处理、准备数据 2 为传输准备数据，将数据传输到系统的另一个部分进行处理（不是最终用户）【就是在系统个部件之间传输数据】 3 分布式处理和数据传输在线进行并且是单项的 4 分布式处理和数据传输是在线进行并且是双向的 5 多数系统相应部件上都是动态执行处理功能
6.3.3、性能（Performance ）
∙
∙
∙
∙
∙
∙
求 0 用户没有提出任何要求 1 提出并评审了性能，但不必采取专门措施 2 响应时间和吞吐量在业务峰值时段是至关重要的。但不必为了CPU 的利用率而采用专门设计。业务处理的截至日期在下一个工作日 3 响应时间和吞吐量在业务峰值时段是至关重要的。但不需要为CPU 利用率而采用专门的设计。业务处理的截至日期是有限制的 4 此外，已提出的用户性能需求已经迫切到了在设计阶段安排专门的性能分析任务 5 此外，需要在设计、开发和（或）实施阶段使用性能分析工具来满足已提出的用户性能需
6.3.4、资源需求（heavily used configuration）
∙
∙
∙
∙
∙
制 0 不包括任何直接或者间接的操作限制 1 确实存在操作限制，但是比通常的应用程序的约束要少一些。 2 包括一些安全性或者时间限制的考虑 3 应用程序的某个部分需要专门的处理器 4 已提出的操作限制需要在中央处理器或者一个专门的处理器中的应用程序上加上特殊限
5 此外，在应用系统的分布式部件上存在特殊的限制 ∙
功能点分析（Function Point Analysis）学习笔记（九）
6.3.5、事务频率（Transaction Rate）
∙
∙
∙
∙
∙
了 0 没有可预见的峰值处理时段 1 可以预见一个峰值处理时断（每月，每季度） 2 可遇见每周一次的高峰 3 每天一次的高峰 4 用户在应用程序需求或者服务中提出的高处理率已经需要在设计阶段安排性能分析工作
5 需求中的处理要求必须在设计阶段安排性能分析工作，且需在设计、开发部署阶段使用性能分析工具 ∙
6.3.6、在线数据输入（Online Data Entry）
∙ 0 没有
∙
∙
∙
∙
∙ 1 1% ~ 7% 2 8%~15％ 3 16%~23％ 4 24%~30% 5 >30%
6.3.7、终端用户效率（End User Efficiency）
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 考察界面的友好性 辅助导航（功能键，跳转，动态生成树的菜单） 菜单 在线帮助和文档 光标的自动移动 滚动 远程打印（在线处理） 定制功能键 在线处理提交的批处理作业 使用光标选定屏幕的数据 大量使用的翻转录像、高度、颜色、下划线和其他指示器 在线处理的硬拷贝文档用户 鼠标界面 弹出式菜单 用尽可能少的屏幕来完成一种业务功能 支持两种语言（这个规定要算4项） 多种语言支持（这个要算6项） 记分标准 0 0项 1 1~3项 2 4~5项 3 >=6项 ，但用户没有其他关于使用效率的专门需求 4 >=6项，但已经提出了其他关于使用效率的需求强烈到需要在设计阶段进行人性化设计分析的工作 5 >=6项，需要使用特殊的工具来满足要求
6.3.8、在线升级（Online Update）
∙
∙
∙
∙
∙
∙ 0 无要求 1 更新1~3个控制文件。数据量低，容易恢复 2 更新4个或者更多的控制文件。数据量低，易恢复 3 包含对主要内部逻辑文件的更新 4 除以上之外，防止数据丢失式一项基本要求，而且经过了专门的设计并已经实现 5 除以上之外，大数据量促使恢复过程要考虑成本问题。高度自动化的恢复过程只需要少量
的人工干预
功能点分析（Function Point Analysis）学习笔记（十）
6.3.9、复杂处理（Complex Processing）
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙ 根据逻辑对程序开发的影响需要考虑下面的部分 敏感性控制(特殊的审计处理) 和特定应用程序的安全处理 大量的逻辑处理 大量的数学处理 很多的例外处理，因此必须再次处理不完整的事物 应付多种输入/输出格式 记分标准 0 没有 1 1项 2 2项 3 3项 4 4项 5 所有项
6.3.10、可重用性（Reusability ）
∙
∙
∙
∙
∙
∙ 0 没有可重用代码 1 可重用的代码重用于应用程序内部 2 应用程序中少于10％的部分会被一个以上的用户使用 3 应用程序中大于等于10％的部分会被一个以上的用户使用 4 应用程序被专门打包和文档化以简化重用 5 除4之外，用户可以通过参数维护定制应用程序
6.3.11、易安装性（Installation Ease）
∙
∙
∙
∙
∙
∙ 0 没有提出安装要求，也无需考虑安装问题 1 没有提出安装需求，但是要考虑安装问题，进行相应的工作 2 提出安装需求，提供并测试了转换和安装的指南。项目中转换工作带来的影响并不重要 3 并给项目中的工作带来显著的影响 4 除2外，提供并测试自动安装工具 5 除3外，要求提供自动安装工具
6.3.12、易操作性（Operational Ease）
∙
∙
∙
∙
∙
∙
∙ 0 除了正常的备份处理程序，用户没有提出特殊的操作方面的额外考虑 1~4 从下列项目中选择准确的特性, 每个要点记1分： 提供有效地启动、备份、恢复备份处理，但是需要操作员人工干预 无需干预 需要人工安装磁带 需要人工穿空纸和穿孔纸带 5 应用程序无人值守，所有的操作都不需要人工干预。系统能够自动进行错误恢复
6.3.13、多点运行（Multiple Sites）
∙
∙
∙
∙
∙
∙ 0 没有需求 1 有需求，但应用得软硬件环境相同 2 软硬件环境相似 3 软硬件环境不相同 4 系统中有相应的设计和文档，其他同1，2 5 系统中有相应的设计和文档，其他同3
6.3.14、易变更（Facilitate Change）
∙
∙ 考察范围 提供能够处理简单请求的灵活查询以及报表支持 ，例如对一个ILF 的处理 (算1
项).
提供能够处理简单请求的灵活查询以及报表支持 ，例如对不止一个ILF 的处理(算
2项).
提供能够处理复杂请求的灵活查询以及报表支持，例如提供一个或者一个以上得处
理功能 (算3项).
业务控制数据保存在由用户通过在线交互处理维护的表中，但是变更只在下一个工
作日才生效 (算1项).
业务控制数据保存在由用户通过在线交互处理维护的表中，需立即生效生效(算2
项).
记分标准 ∙ ∙ ∙ ∙ ∙
∙
∙
∙
∙
∙
∙ 0 一个都不满足 1 满足以上的1个 2 满意以上的2个 3 满足以上的3个 4 满足以上的4个 5 满足以上的5个