功能点分析法 FPA 总结

1 要点

学习的资料就是钱岭的那本书 处理元（Elementary Process）。

参考IFPUG的《功能点计算实践手册》 方法:

Google 关键字： FPA ppt

FPA 笔记 读书笔记 FPA ILF ppt

FPA CASE FPA example

Counting Practices Manual, Release 4.2 pdf

甲學生 EI：個人資EO：個人資EQ：個人資料輸入 料輸出 料查詢 計算範圍 EI：選課 ILF：學生基本資料 EO：選課結果 EIF：選課資訊 選課系統 學籍系統

2 功能点分析法FPA

一九七九年，IBM公司的Allan Albrecht 发展出功能点分析法，来解决某些量度系统规模之方法（如代码行数）所存在之问题。它是一种量度系统规模的方法，可比较不同类型系统的规模，并且不受所采用技术的限制。量度的资料须对终端用户或系统购买者具有意义，并可以在系统发展周期的初期轻易计算出来。这个方法是透过分析与用户有关的功能，进而量度整个系统。它亦是用以估计软件发展及维修之所需成本及资源的工具。

功能点分析法从两方面，即特定的用户功能及系统特性， 来量度应用系统的规模。

顾名思义，特定的用户功能是用以量度应用系统就用户要求所提供的功能。这些功能可分为五个类型，包括资料输 入功能、资料输出功能、资料查询功能、系统内的资料档 案及外界系统之有关档案。上

述五个功能类型的每一项功 能可进一步界定为低、中、高三种，而每种复杂性并乘以一个特定数字，当每项数字加起来时，便是资讯处理规模的量化结果，称为基本功能点。

另外，系统的一般功能受以下的一般系统特征影响；而有关特征是用以对系统的一般功能作出评级的。 (a) 数 据 通 讯 ； (b) 分 布 式 处 理 ； (c) 系 统 性 能 ； (d) 使用现有器材； (e) 处 理 效 率 ； (f) 联机数据输入；

(h) 联机修订资料程度； (i) (j) (k) (l)

复杂性； 再用性； 安装便捷程度； 操 作 便 捷 程 度 ；

(m) 多个电脑场地；及

(g) 用户使用便捷程度 ； (n) 更改的便捷程度。

一般应用系统的每项属性均按影响程度评级。影响程度分为零至五级，即由没有影响至有重大影响等五级。所有影响程度的总和最终决定了整个计划的价值调整因素。

基本功能点乘以价值调整因素所得出的数目，便是以经调整的功能点显示的应用系统规模。

经调整的功能点=（基本功能点）X（价值调整因素）

3 FPA笔记一 功能点分析法概述

3.1 什么是功能点分析法（FPA）

功能点分析法，简称FPA，与代码行分析法是近年来最流行的两种基础软件规模估算和度量方法。

代码行估算法侧重技术角度，需要一定的基准数据支撑。基准数据越多，估算难度较小。代码行估算法与实现的技术，计算机语言密切相关。

功能点分析法侧重功能，在基准数据缺乏时也能进行，不过估算流程比较复杂。它完全独立于技术，且可以给用户量化的概念。

这里所说的功能点分析法，由Allan J Albrecht首先提出，又称Albrecht功能点分析法。除此之外，还有Mark II FPA和完全功能点等。但习惯上，人们说的功能点分析法就是Albrecht功能点分析法。

3.1.1 功能点分析法的定义

官方文档IFPUG CPM 4.2.1给出功能点分析法的定义是：Function point analysis is a standard method for measuring software development from the user’s point of view.

具体来说，FPA有这么几个特点： 它是一种适用于软件开发的度量方法。

它是一种标准的度量方法，由国际功能点用户组（IFPUG）维护和推动。

它从用户视角来度量产品规模。

它不注重产品的内部结构和技术复杂度。不过也并非完全无视这些因素。

FPA标准的维护组织是国际功能点用户组IFPUG

(http://www.ifpug.org)，它不定期的发布Counting Practices Manual，简称CPM来统一不同公司和产品的功能点计算模型。这套模型基于大量已完成项目的分析数据，非常全面和精确。对于同一个产品，不同的公司，不同的人，参照CPM计算出来的功能点数应当是一样的。目前最新版本是2005的CPM 4.2.1，现在三年未更新，计算模型已相当成熟。

3.1.2 功能点的定义

什么是功能点？就是客户提出的一条条的需求吗？答案是否定的。在FPA中，客户提出的需求，是功能，功能组和产品；但不是功能点。

功能点是一个的度量单位，用于度量工作产品的规模。就像公斤和千米一样，仅仅是一个抽象化的单位。

功能点不直接度量软件的内部架构和技术复杂度。

单个功能点对用户没有意义，但一个功能包含多少个功能点对用户有意义。

一个系统，一个功能包含多少个功能点，是由一系列可见的要素分析计算得来，而不是拍脑袋的经验数字。

功能点分为两种：未调整功能点和调整功能点。未调整功能点是只记用户可见功能的中间结果，调整功能点是最终结果，在未调整后功能点基础上加入了系统实现和内部架构方面的因素。一般说一个系统包含多少个功能点，是指调整功能点。

3.1.3 那些功能是用户可见的？

简而汇之，如下功能是用户可见的。

GUI，如页面和窗体。 报表。 主要文件。

参考文件，引用文件。

控制文件。 数据输入。

3.2 为什么使用功能点分析法

FPA可以应用于所有的软件项目和软件身，包括新开发项目，升级项目，应用程序，维护项目等。FPA的基本目的有两个：

度量用户要求和接收到的功能

为软件的开发和维护而度量其技术独立度。

3.2.1 功能点分析法的用途

软件度量的用途非常广泛，从客户，老板，管理人员，到程序员，都需要软件度量数据。FPA作为一种软件度量方法，主要有三方面的用途：持续的过程改进，软件资产管理，项目管理。 3.2.1.1 持续的过程改进

FPA支持用于软件质量分析与生产力分析的量化指标，比如每功能点的平均bug数，每功能点的平均人天数，等等。

分析这些量化指标，可以找到过程改进的机会；可以度量改进的效果。无论是组织还是个人，都需要持续的过程改进。具体来说，FPA可这个过程中发挥如下作用：为现状提供基线数据。 1) 为改进决策提指明方向。

2) 为具体行动提供指南。 3) 度量改进的结果。

4) 将改进的结果基线化，进入下一轮改进。

可能改进的机会，英语是Improvement Opportunities。这里的Opportunities用的很好，可惜中文的译词“机会”很难让人理解。习惯上是说“值得改进的地方”。 3.2.1.2 软件资产管理

FPA为组织的软件资产提供了量化的指标。

软件资产的总规模 软件资产的增长率 软件资产的维护成本 软件资产的代换成本

对于软件开发和服务组织，这些指标可为软件资产的维护策略提供决策依据：是重新开发，重构系统，重写代码但不改结构，还是继续维护。

对于使用软件的组织，这些指标可作为采购的参考：是自行开发，还是采购？采购的合理价格区间，目标采购包的功能符合度。 FPA为应用软件之间的功能比较提供了规范化指标。

3.2.1.3 项目管理

(1) 估算开发或维护的成本，资源，为项目计划提供依据。 (2) 估算需求变更的成本和对项目的影响。 (3) 控制需求范围。

3.2.2 功能点分析法的优点

基于定义良好的计算标准。 基于客户视角。容易理解和接受。 可应用于新项目，升级项目和维护项目。 与技术和计算机语言无关。

简单，易于计算，只需花费较少的工作量。

一致的规模度量尺度。可用来比较不同组织和技术之间的比较。

3.2.3 功能点分析法的缺点

只考虑可见部分的复杂度，对系统内部复杂性考虑太少。 功能复杂度三级划分比较武断。对一些比较复杂的功能，统计误差较大。

FPA知识简单假设全部是部分的和，没有考虑系统集成带来的额外开销。

在FPA的基础上，还有一种MARK II 功能点分析法，它能克服一些功能点法的缺陷。

3.2.4 功能点分析法的度量描述举例

(1) 今年我们的生产率提高了20%，从每月10个功能点提高到12个功能点。

(2) 通过质量检视，我们交付的软件缺陷率由每功能点2个缺陷，减少到每功能点0.5个缺陷。

(3) 我们的项目进度估算准确率显著提高，实际人天数和估算人天数的误差+45%减小到+15% 。

(4) 我们的应用软件包对相关业务的支持增加了10%，原来是50K功能点，现在是55K功能点.

(5) 由于我们调整了维护策略，工程师人均维护的功能点数从1000提高到1500.从而节省了$3M的成本

(6) 由于提高了客户需求技术，我们把需求蔓延率从35%降到10%。 (7) 根据功能点分析的结果，我们购买一个软件包，比自己开发节省了$1M.

3.3 功能点分析法与软件生命周期

功能点分析必须渗透于作为软件生命周期的全部，而不仅仅是项目开发阶段。不同阶段的功能点分析有不同的目的，参与人员和相关材料。

3.3.1 软件生命周期

FPA将软件生命周期划分为六个阶段，与通常意义的软件生命周期基本相同。只不过有些具体名称上不同。比如：方案阶段又叫概念阶段，构建阶段又叫实现阶段。

方案阶段 Proposal 需求阶段 Requirement 设计阶段 Design 构建阶段 Construction 交付阶段 Delivery 维护阶段 Maintenance

有四个阶段应当进行功能点分析：方案阶段，需求或设计阶段，交付阶段，维护阶段。每个阶段的功能点分析都有不同的目的。 FPA不是某一个人的工作，而是整个团队的工作。无论哪个阶段的FPA，都需要多种角色的参与。主要参与角色有：

客户或客户代表 项目经理 系统架构师

程序员（方案阶段可能没有程序员）

文档专家：负责整理文档的苦力。

应用方案经理：可能是项目经理，也可能管理好几个项目经理。 应用方案专家：估计Reviewer, 挑刺的家伙。 度量分析员：可能和文档专家是同一个人。 功能点分析专家：一般是QA，主持分析过程。 功能点委员会：估计是Reviewer, 挑刺的家伙。

每次进行FPA时，除了需要相应的项目文档外，还建议准备好如下FPA的指导文档：

IFPUG Counting Practices Manual 所在组织的FAP指导文档。 FPA分析表。

自制一张简明指南卡：Quick Reference Card。

3.3.2 在方案阶段估算功能点

在方案阶段后期，可以采用FPA方法来估算软件的规模和项目的开发成本。具体来说有三个目的：

FPA的过程可协助双方（用户和开发人员）把高层需求条理化。 得到较为明朗的项目的范围。

粗略的估算功能点数，并折算为开发成本和进度。为制定项目计划提供依据。

在此阶段只有一些非常原始，抽象的客户需求。所以估算的精度有限。此阶段可参考的项目文档有：

高层需求文档

高层系统架构（功能，数据存储，接口）。 高层逻辑数据模型。 高层业务模型。 业务用例（可选）。

历史项目或应用软件的功能点统计数据（可选）。

3.3.3 需求或设计阶段二次估算功能点

在完成需求规格或概要设计时，如发现需求和范围较之方案阶段有较大的变化，估算的功能点不够精确，可在设计阶段的进行二次估算。其目的有三： 重新定义客户需求。 重新估算开发进度和成本。

度量项目范围的变更，如需求蔓延率。

实际上，只要项目范围发生了大的变化，就应当重新估算，最好不要超过三次。在设计完成后，项目范围已经基线化，如发生需求变更，只需估算变更部分，不要全部推到重来。

二次估算，除了需要初次估算的所有文档外，还需要如下项目文档：

需求规格。

业务用例

屏幕界面规划（Layout） 报表规划（Layout） 文件和数据库规划（Layout） 数据流：系统接收和发出的数据。 功能设计，也就是概要设计。

3.3.4 交付阶段度量最终功能点

交付阶段，所有的开发工作都已结束，需求和功能设计自然也就全部冻结。此时应进行最终的实际功能点度量。其目的有四： 在交付文件中报告实际的功能点数。 度量项目范围的变更，如需求蔓延率。 回顾项目实施情况。

发布统计数据，作为组织的基线。

度量功能点，需要参考项目的全部需求和设计文档。同二次估算相比，可能增加了如下文档：

功能设计规格。 详细设计规格。 用户手册。

3.3.5 维护阶段度量资产功能点

系统交付后，就会进入公司的IT资产库。此时需要从资产管理的角度度量一些数据。

审计资产功能点。 文档化。 确定维护策略。

4 FPA笔记二 FPA流程概述

4.1 计算功能点的总体流程

FPA的计算流程比较复杂，主要分为三大步骤：

定义分析目标；计算未调整功能点；计算调整功能点。具体图示请参见图一。

图表 1 FPA 计算流程

FPA 的主要步骤如下：

1)决定分析类型和目的：开发项目、升级项目、应用。小特性开发属于应用类型。

2)识别分析范围和应用边界。

3)计算未经调整的功能点数UPFC。

(1) 列出系统的所有功能，包括数据功能和处理功能。 (2) 计算每一个功能的功能点。

i.识别该功能的类型：ILF、EIF、EI、EO、EQ。

ii.统计该功能包含元素的数目。数据功能统计DET和RET；处理功能统计DET和FTR。

iii.根据该功能包含元素的数目，和相应功能类型的复杂度矩阵，确定其复杂度。

iv.根据相应功能类型的复杂度和功能点对照表，找到改功能的功能点数。 (3) 统计所有功能的功能点总和。

4)确定调整系数。根据14个GSC确定VAF。 5)计算调整后的功能点：AFP = UPFC * VAF

Count Data Identify Determine Type of Count Counting Scope and Application Boundary Determine Unadjusted Function Point Count Functions Count Transactional Functions Calculate Adjusted Function Point Count Determine Value Adjustment Factor 4.2 定义分析类型

FPA可应用于各类软件项目和应用系统。对于不同的项目和系统，FPA计算流程是一样的，但一些具体算法和规则上各有不同。FPA的目的也不尽相同。分析类型有三种： 新开发项目 Development Project

估算或度量系统的所有新功能点，包括新增的或系统切换的功能。度量的目的有：

定义需求

为项目计划提供估算数据：工作量，成本，人员，进度。 度量质量。 度量生产率。

升级项目 Enhancement Project

估算或度量系统中变化的功能点，包括新增，改变，减少和系统切换的功能。 应用软件Application

官方定义是度量已安装的应用软件的功能点。Appliction是指已经交付或从第三方获得的软件、软件包。小软件工具的开发也可算作应用类型。每次新开发项目完成后，都应当把交付的系统按应用软件度量一次。度量应用软件的目的有：

作为升级项目的基线。 度量软件质量 确定维护策略 确定维护的生产率

三种类型的分析关系如下图所示。

图表 2 项目FPA与应用FPA的关系

4.3 定义范围边界

FPA是从用户视角和系统见交互的角度来分解功能。只有严格的界定了分析的范围和边界，才能很好的识别和分解功能。基于用户视角定义边界，用户能够理解和描述边界。

相关应用之间的边界是由用户看到的不同功能区域划分，而不是由技术考虑来划分。

应用之间的初始边界不会因为功能点分析而改变。

定义边界的技巧

获得一个系统的流程图，在系统周围画上边框，作为边界。 察看数据的维护方式。 察看数据的应用范围。

4.4 计算未调整功能点UFPC

未调整功能点是从具体功能的复杂度计算得到，它包括三个步骤：分解功能，分析功能的复杂度，根据复杂度确定功能点数。

4.4.1 识别，分解具体功能

所有系统的具体功能都可分为两种：数据功能和处理功能。正确识别出数据功能和处理功能的数目是FPA的关键。

数据功能：指为满足用户数据需求而提供的功能。它以文件为单位计数。文件分为两类：ILF和EIF。

内部逻辑文件ILF ：系统内部维护的文件，如系统创建和更新的文件。

外部接口文件EIF ：被目标系统应用，但由外部系统维护的文件。 处理功能：指为满足用户通过系统处理数据或控制信息而提供的功能。它以处理元为单位计数。处理必然是发生在系统边界内外的一个交互过程，可分为三种：EI，EO和EQ。

外部输入EI ：指处理来自系统外的文件的处理元。它的基本目的是维护一个或多个ILF，或者改变系统的行为。

外部输出 EO ：指把文件发送到系统外的处理元。他的基本目的是给用户提供处理的结果。EO包含至少一个逻辑处理运算过程。

外部查询 EQ ：EQ也是指把文件发送到系统外的处理元。它的基本目的是为用户获取指定的信息。EQ部包含逻辑处理运算过程。 请注意，FPA是从用户角度分析系统的。这里的文件和处理元也是从用户角度来定义的，完全与实现技术无关。特被是文件，一定要时刻记住他仅仅是一组数据，与计算机文件没有关系。

文件：一组用户可识别的，有逻辑关联的数据或控制信息。它不一定计算机系统实际产生，存储或使用的文件。

处理元：对用户有意义的最小活动单元。它与实际程序中的方法，进程和API无关。

4.4.2 确定具体功能的复杂度

对于具体的文件和处理元，FPA采用三个指标度量其复杂度：RET,DET和FTR。这些指标都是直观的，可计量的。其中文件用RET和DET来度量，处理元用DET和FTR来度量。

记录元素类型RET ：在一个文件内，一个用户可识别的数据元素组。

数据元素类型DET ：用户可识别的，不重复的字段。

引用文件类型FTR ：处理涉及到的文件，包括读取，更新和修改的文件。

FPA给概念术语的名称都比较冗繁。个人感觉把这三个术语中的“类型（Type）”去掉，会更易懂。这里的“类型（Type）”都是强调对相同的东西不能重复计算的。比如同一个ILF中的两个RET都包含同一个DET，只能记为一个DET。

4.4.3 数据功能点权重矩阵

对于每一个文件（ILF或EIF），FPA是根据其复杂度来确定其功能点数。复杂度又根据文件所含的DET和RET的数量分为三级：低，中（平均）和高。

表格 1 文件功能点计算矩阵

DET个1 ~ 20 数 19 RET个数 1 2 ~ 5 >= 6

低 低 中 低 中 高 中 高 高 低 中 高 7 10 15 5 7 10 >= 复杂度 ILF 功能EIF功能~50 50 点数 点数 4.4.4 处理功能点权重矩阵

同数据功能点类似，处理功能点也是根据三级复杂度确定的。而每个处理元的复杂度根据DET和FTR计算得来。但EI 、EQ和EO三者的计算方法不尽相同。

表格 2 处理元复杂度矩阵 EI复杂度 DET个1 ~ 5 数 4 RET个数 1 2 >= 3 低 低 中 低 中 高 中 高 高 ~15 EQ、EO复杂度 >=16 DET个1 ~ 6 数 5 RET个数 1 2 ~ 3 >= 4 低 低 中 低 中 高 中 高 高 >= ~19 20 从表中可见同样文件作为输入要比输出的复杂度高。

表格 3 处理元功能点计算表 复杂度 低 中 4 高 6 EI、EQ功能3 点数 EO功能点数 4 5 7 4.4.5 汇总未调整功能点

把系统中所有ILF, EIF,EI,EO,EQ的功能点数汇总，就是系统的总的未调整功能点数UFPC。

4.5 计算调整功能点AFP

未调整功能点数是从用户角度计算得出的，完全没有考虑不同系统或不同功能的实现复杂度。FPA通过分析14个通用系统特性（GSC）对系统的影响程度（DI）得出每个系统的功能点值调整因子VAT。最后根据VAF调整功能点数，得出在系统和功能点可类比的调整功能点数。UFP、VAT和AFP三者的关系是：

AFP = UFP * VAT

请注意，一个系统只有一个VAT，它是所有14个GSC分析汇总的结果。

4.5.1 通用系统特性GSC

GSC是由IFPUG统一指定的标准。一共有14种GSC，适用于所有类型的系统和项目。

(1) 数据通讯 （Data Communications）

(2) 分布式数据处理 （Distributed Data Processing） (3) 性能 （Performance）

(4) 使用强度高的配置 （Heavily Used Configuration） (5) 事务速度 （Transaction Rate）

(6) 在线数据输入 （Online Data Entry） (7) 最终用户的效率 （End-User Efficiency） (8) 在线更新（Online Update）

(9) 复杂的处理 （Complex Processing） (10) 可重用性 （Reusability）

(11) 安装的简易性 （Installation Ease） (12) 运行的简易性 （Operational Ease） (13) 多场地 （Multiple Sites） (14) 允许变更 （Facilitate Change）

4.5.2 影响程度DI和TDI

GSC对系统的影响程度分为6级，从0到5。各级定义如下： 0 不存在或者没有影响 1 偶尔的影响 2 轻微的影响 3 中等的影响 4 显著的影响 5 强烈的影响

IFPUG针对每一中GSC,给出了详细的DI等级指南。对于一些实在没有参考等级标准，用户也可以自己定义。

把14种GSC的DI都加起来，就得到系统的总影响程度TDI，即：TDI = ∑(DI)

4.5.3 值调整因子VAF

在得出TDI后，VAF按如下公式计算。

VAF = (TDI * 0.01 ) + 0.65。

VAF只能在正负35%的范围调整功能点数。

AFP = UFP * VAT

4.6 不同项目的调整功能点AFP 4.6.1 开发项目功能点

DFP = (UFP + CFP) * VAF

DFP： 开发项目功能点。 UFP： 项目应用的UFPC。 CFP：额外的转换功能的UFPC。 VAFA：调整系数。

4.6.2 升级项目功能点

EFP = (ADD + CHGA + CFP) * VAFA + DEL * VAFB EFP：升级项目功能点。

ADD：升级项目新增UFPC。以升级后项目为基准。

CHGA：升级项目改变的UFPC。以升级后项目为基准。 CFP：额外的转换功能的UFPC。 VAFA：升级后的调整系数。 VAFB：升级前的调整系数。 DEL：升级项目中删除的UFPC。

4.6.3 应用功能点

AFP = ADD * VAF AFP：应用功能点

ADD：安装的功能UFPC。 VAF：调整系数。

4.6.4 升级应用功能点

AFP = [( UFPB + ADD + CHGA) – (CHGB +DEL)] * VAFA AFP：应用功能点

ADD：安装的功能UFPC。 VAFA：调整系数。 UFPB：升级前的UPFC。 CHGA：升级后改变的UFPC CHGB：升级前改变的UFPC ?!

4.7 附录

4.7.1 度量功能点的工作量

很多公司不能推行FPA ,并非主观上认为它没用。其主要原因有二： 1. 没有FPA的专家指导，不知从何做起，如何持续。 2. 迫于项目进度压力，担心FPA带来大量额外的工作量。

这里就推行FPA带来的额外工作量，给出一些参考数据。大多数组织是平均每小时估算出100个功能点。具体如下： 很小 功能点5 ~ 20 数 C++265 ~ 小 20 ~ 100 项目/应用系统的规模 中 100 ~ 500 大 500 ~ 10K 26K ~ 500K 很大 10K ~ 100K 500K ~ 5M 1K ~ 5K 5K ~ 26K 代码行 1K 开发工0.5人天 1人月 ~ 10人月 作量 ~ 1人月 10人月 ~ 72人月 FPA工15分钟 作量 ~ 30分钟

30分钟 72人月 ~ 200人年~ 200人年 8K人年 1小时 ~ 5小时 ~ 100小时 100小时 ~ 1K小时 ~ 1小时 5小时 4.7.2 推行FPA的建议

应当做的事情

得到老板的支持和指导。

是度量成为每一个人工作的一部分。

安排专人总管和支持度量活动，不一定是全职。 培训技术人员和用户。让用户有功能点的概念。

关注在项目团队的收益上，不要一上来就资产管理什么的。 提供自动化的支持。 与组织的过程模式整合。

度量的结果应当发布出来，并得到利用。 不应当做的事情

不要觉得度量可有可无，或不可达到。 不要苛求完美的度量系统和环境。 不要依赖不准确的数据。 不要用于衡量个人的绩效。

4.7.3 术语表

术语 英文 FPA 中文 说明 Function Point 功能点分析Analysis 法 未调整的功UFP Unadjusted Function Point 能点 AFP Adjusted Function Point Value VAF Adjustment Factor ILF Internal Logic File External Interface File External Input External Output 内部逻辑文件 外部接口文件 外部输入 外部输出 值调整因子 调整功能点 EIF EI EO EQ External Query 外部查询 General 通用系统特征 数据元素类型 记录元素类GSC System Characteristic DET Data Element Types Record RET Element Types 型 FTR File Type Referenced Degree of Influence Total Degree of Influence Elementary Process 引用文件类型 影响程度 整体影响程度 处理元 DI TDI EP

5 FPA笔记三 数据功能的识别

2008-11-26

一个系统含有多少功能点，来自其所有子功能的功能点简单汇总。要计算功能点数，必须尽可能无遗漏的把从系统分解成一个个的基本功能。然后再分别计算每一个基本功能的功能点数。FPA把系统的基本功能分为两大类五小类，不同类型的基本功能有不同的功能点计算方法。

数据功能 Data Function 内部逻辑文件 ILF 外部接口文件 EIF

处理功能 Transaction Function 外部输入 EI 外部输出 EO 外部查询 EQ

这五种功能类型关系如下图所示。

图表 1 五种基本类型

数据功能指为满足用户的内部或外部数据需求而提供的功能。其实数据功能的ILF和EIF这两个名称有点冗繁，不如直接叫内部文件和外部文件简单明了。请注意，这里的文件完全不同于传统意义上的物理的文件；它是指一组逻辑相关的数据。请注意这些概念都是基于用户视角的概念，不是计算机上的文件和处理元。在《FPA笔记一 概述》中有具体解释。

5.1 相关术语解释

处理元（Elementary Process）

对用户有意义的最小活动单元。它必须是自包含的，且能使业务保持一致的状态。处理元是处理功能的基本单位。 控制信息（Control Information）

影响某一个处理元的输入信息，它定义了处理的内容：处理什么数据，何时处理，如何处理。

用户可识别的 (User identifiable)

指用户和开发人员双方都认可，且达成一致理解的需求，处理或数据。它必须是用户关心的内容。像程序的代码，内部设计，临时文件等，都不是用户关心和认可的东西。 维护 (Maintained)

通过处理元维护改变数据的能力，如增加、修改、删除、展现、创建、转换等。

5.2 识别ILF

ILF在CPM中的定义是：An internal logical file (ILF) is a user identifiable group of logically related data or control information maintained within the boundary of the application. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being counted.

根据这个定义，可得出三条ILF的识别规则，ILF必须同时满足这些规则。

ILF是一组用户可识别的数据或控制信息。 ILF是一组逻辑关联在一起的数据。 ILF在系统范围内维护。

ILF的基本目的是持有系统要维护的数据。维护ILF必然会涉及到一个或多个处理元。在特定情况下，一个ILF可能属于多个系统。 在识别ILF时，下列文件不在FPA的考虑范围内，可以第一时间排除。

临时文件。 工作文件。

排序文件，如国家排序列表， Index文件

Static Code Table，如硬编码的下拉框列表，因为系统没有

维护它。维护它的是程序员或用户。

Code lookup table，如国家代码与名称对照表。

5.3 识别EIF

EIF在CPM中的定义是：An external interface file (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or

more elementary processes within the boundary of the application counted. This means an EIF counted for an application must be in an ILF in another application. 根据这个定义，可得出四条EIF的识别规则，EIF必须同时满足。

EIF是一组用户可识别的数据或控制信息。 EIF是一组逻辑关联在一起的数据。

EIF不在系统范围内维护。就是说，EIF不会被改变。 EIF一定就另一个系统的ILF，并被其维护。

EIF的基本目的是持有在系统的一个或多个处理元中引用的数据。 4. ILF与EIF的区别与例子

ILF和EIF最根本的区别在于是否在系统范围内维护。在系统范围内维护的，就是ILF；否则就是EIF。

如果一个文件来自外部系统，但被目标系统修改。此时要根据这个文件包含的数据，将其拆分为两个文件：来自外部系统的数据归入EIF，被修改的数据归入ILF。即来自外部系统，又被修改的数据，在两个文件中都算。 下面举两个案例。 目标系统 逻辑文件 是否ILF或EIF 电子商务系统，提购物车 供功能有：购物订单 ILF ILF 车，订单和在线支商品种类列表，客户可通ILF 付。 过页面维护 税率表，开发人员手工维EIF 护 工资系统，负责公员工信息表，来自人事系EIF 司所有员工的工统 资计算和发放。 工资等级表，通过界面人ILF 工输入。

6 FPA笔记四 处理功能EI、EO、EQ

功能点分析法（FPA）定义的处理功能（Transactional Function）是指提供给用户，用于数据的处理的功能。（笔者注：这定义等于没说。呵呵。）处理功能分为外部输入EI、外部输出EO、外部查询EQ。显然，完全在系统内部的处理功能不在FPA的考虑范围内。

6.1 处理功能的识别过程

处理功能的识别，包括五个步骤：将功能分解为处理元；判断处理元是EI、EO还就EQ；检查是否存在重复的EI/EO/EQ；确定EI/EO/EQ的复杂度；计算EI/EO/EQ的功能点数。本文介绍前三个步骤。

图表 1 处理功能识别过程

6.2 处理元的定义

要进行FPA分析，必须把处理功能分解为处理元（Elementary Process）。自然，FPA中的处理元与计算机技术中的事务、处理等不是一回事。处理元有两个识别标准：

l 它是对用户有意义的最小活动单元。

l 它就自包含的，并使系统保持一致的行为和状态。

如果经过一段处理，系统的状态或行为不一致了，就说明这段处理不能构成处理元。同样，如果在整个处理过程中，系统在行为和状态发生多次改变，且在多个点达到新的一致性行为和状态，则这段处理很可能包含多个处理元。

笔者以为，实际情况下，正确的识别处理元非常困难。实际上也用不着在这上面钻牛角尖。FPA的目的是计算出功能点数。如果处理元粒度较大，处理元的总数就少，单个处理元的功能点数就多。反之如果处理元粒度较小，处理元的总数就多少，单个处理元的功能点数就少。对计算整个系统的功能点数并无大碍。

6.3 处理逻辑

处理元必然包含一种或多种的处理逻辑。处理逻辑（Processing Logic）是用户为完成后一个处理元而定义的特定需求。IFPUG CPM定义了13种处理逻辑。EI和EO可以包含所有13种的处理逻辑，而且有一些种类必须包含。EQ则有4种处理逻辑不能包含。具体见下表。

表格 1 系统的13种处理逻辑 处理逻辑 EI EO EQ 1) 需要执行的校验 2) 需要执行了数学公式和运算 M* N 3) 等值转换的算法，如货币转换，单位转换 4) 筛选数据的条件 5) 用于判断是否适用的条件，也就是入口条 件。 6) 一个或多个ILF的修改逻辑 7) 一个或多个被引用的ILF或EIF 8) 从系统内获取了数据或控制信息 9) 从已有数据衍生的额外数据 10) 改变了系统的行为或状态 11) 向边界外准备或展现了信息 12) 从边界外接收数据或控制信息的能力 M* M* M* N M M N N M M* M* M M 13) 数据重排。注意：重排数据不能作为处理 功能唯一性的识别依据 表中符号说明：

l 空白：处理功能（EI,EO,EQ）可以包含对应的处理逻辑。 l M：处理功能必须包含对应的处理逻辑。

l M*：所有标M*的处理逻辑，对应的处理功能必须包含至少一种。 l N：处理功能不得包含对应的处理逻辑。

6.4 识别重复的处理功能

用户提出的需求，往往是零乱的，存在很多重复的需求。在识别处理元时，要注意归并重复的处理元。当多个处理元同时满足如下三个条件时，应当把它们记为一个处理元。

l 它们的处理逻辑相同，数据排序规则除外。 l 它们包含的数据元素集合相同。

l 它们引用的逻辑文件（ILF/EIF）集合相同。

IFPUG CPM把这段规则说得非常费解。它是在EI/EO/EQ的具体识别规则中分别说明的。大意是：一个EI/EO/EQ至少应满足下列三个条件中的一个：

l 该EI/EO/EQ的处理逻辑不同于系统中任何其它EI/EO/EQ的处理逻辑。

l 该EI/EO/EQ包含的数据元素集不同于系统中任何其它EI/EO/EQ的数据元素集。

l 该EI/EO/EQ引用的逻辑文件集(ILF/EIF)不同于系统中任何其它EI/EO/EQ引用的逻辑文件集。

在判断处理逻辑是否相同时，第13种处理逻辑数据重排是个例外。比如对于员工的工作情况的查询，人事经理要求按工时排序，财务经理要求按工资排序。这两个需求应当放在同一个处理元中。 判断数据元素集合，就是判断是否包含相同的字段（又叫域），而不是数据本身的值是否相同。

6.5 EI、EO、EQ的定义

IFPUG CPM对EI、EO、EQ分别定义如下。

An external input (EI) is an elementary process that processes data or control information that comes from outside the application boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system.

An external output (EO) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external output is to present information to a user through processing logic other than, or in addition to, the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILFs or alter the behavior of the system.

An external inquiry (EQ) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information from an ILF of EIF. The processing logic contains no mathematical formulas or calculations, and creates no derived data. No ILF is maintained during the processing, nor

is the behavior of the system altered.

6.6 如何区别EI和EO/EQ

EI与EO/EQ之间的区别非常简单和直观。从它们的基本目的就可以看出。

l EI的基本目的有两个：维护ILF，或改变系统的行为和状态。 l EO/EQ的基本目的是：向系统外展现或输出数据，包括控制信息。

换而言之，只有同时符合如下两条规则的处理才是EI: l 该处理从系统外接收了数据或控制信息。

l 该处理不是更新了ILF（至少一个），就是改变了系统的行为或状态。

6.7 如何区别EO和EQ

EO和EQ的基本目地相同，它们的区别在于是否包含四种关键的处理逻辑。这四种处理逻辑，EO至少要包含一种，EQ一种也不能包含。

l 输出了衍生数据。

l 就否包含数学运算。等值转换不算。 l 是否包含对至少一个ILF的维护。 l 是否改变了系统的行为或状态。

此外，EQ还必须包含一种处理逻辑：从系统内获取了数据或控制信息，也就是说至少引用了一个ILF或EIF。

8. 典型处理功能例析 功能例子 从屏幕录入的数据 分析 EI 批处理输入 EI 从磁带等设备输入 EI 扫描输入。 EI 增，删，改等事务处理。 导航菜单 登陆界面 EI EO? EQ 从ILF读取列表的列表框或下拉EQ 框 筛选条件。 不是完整的处理元 快捷键，命令键。 导出报表 在线报表 详细报表中的统计字段 不是处理元? EO EQ EQ? 由具体报表汇总得出的总结报表 EO 查看帮助 EQ 重复的帮助 联机文档 输出文件 处理的出错或确认信息。 重复的处理元 不是EQ? EO 不是完整的处理元?

l 注意，增、删、改应当作为单独的EI。

7 软件度量的方法体系

项目度量

http://book.csdn.net/bookfiles/183/1001838364.shtml 项目度量是针对软件开发项目的特定度量，目的在于度量项目规模、项目成本、项目进度、顾客满意度等，辅助项目管理进行项目控制。 规模度量

软件开发项目规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。规模度量是软件项目失败的重要原因之一。一个好的规模度量模型可以解决这一问题。有效的软件规模度量是成功项目的核心要素：基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。规模度量的要点在于：由开发现场的项目成员进行估算；灵活运用实

际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。 软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。软件规模的估算方法有很多种，如：功能点分析(FPA：function points analysis)、代码行(LOC：lines of code)、德尔菲法(Delphi technique)、COCOMO模型、特征点(feature point)、对象点(object point)、3-D功能点(3-D function points)、Bang度量(DeMarco's bang metric)、模糊逻辑(fuzzy logic)、标准构件法(standard component)等，这些方法不断细化为更多具体的方法。 1. 功能点分析法 (1) 功能点分析法概述

功能点分析法(FPA：function point analysis)是在需求分析阶段基于系统功能的一种规模估算方法，是基于应用软件的外部、内部特性以及软件性能的一种间接的规模测量。FPA法由IBM的工程师艾伦·艾尔布策(Allan Albrech)于20世纪70年代提出，随后被国际功能点用户协会(IFPUG：The International Function Point Users' Group)提出的IFPUG方法继承，从系统的复杂性和系统的特性这两个角度来度量系统的规模，其特征是：“在外部式样确定的情况下可以度量系统的规模”，“可以对从用户角度把握的系统规模进行度量”。功能点可以用于“需求文档”、“设计文档”、“源代码”、“测试用例”度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。经由ISO组织已经有多种功能点估算方法成为国际标准，

如：①加拿大人艾伦·艾布恩(Alain Abran)等人提出的全面功能点法(full function points)；②英国软件度量协会(UKSMA：United Kingdom Software Metrics Association)提出的IFPUG 功能点法(IFPUG function points)；③英国软件度量协会提出的Mark II FPA功能点法(Mark II function points)；④荷兰功能点用户协会(NEFPUG：Netherlands Function Point Users Group)提出的NESMA 功能点法，以及软件度量共同协会(COSMIC：the COmmon Software Metrics Consortium)提出的COSMIC-FFP方法，这些方法都属于艾尔布策功能点方法的发展和细化。 (2) 功能点分析法的基本计数

功能点分析的基本计数就是依据标准计算出的系统(或模块)中所含每一种元素的数目：①外部输入数(EI：external input)：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。②外部输出数(EO：external output)：计算每个用户输出，它们向软件提供面向应用的信息。这里，输出是指报表、屏幕、出错信息，等等。一个报表中的单个数据项不单独计算。③外部查询数(EQ：external query)：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。④内部逻辑文件(ILF：internal logical file)：计算每个逻辑的主文件，如数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件。⑤外部接口文件(EIF：external interface file)：计算所有机器可读的接口，如磁带或磁盘上的数据

文件，利用这些接口可以将信息从一个系统传送到另一个系统。 (3) 功能点分析的主要步骤

功能点分析可以按照如图5-6所示步骤进行：

图5-6 功能点分析的主要步骤

(4) 案例：CSK株式会社的功能点分析案例 【CSK株式会社的CSFPA概述】

在实施CSFPA之前，CSK以Step数方法来估算开发规模。但是在利用VB、C++、Java、SQL等语言的项目开发中，用Step数方法进行规模估算比较困难。为了以定量化手段降低甚至消除估算错误，CSK在IFPUG(International Function Point Users Group)的

FP法的基础上加以改良开发出自身的CSFPA(CSK Simplified Function Point Analysis)法，并在企业内加以实施。CSK于1995年加入IFPUG组织，并于1998年开始正式开展活动。CSFPA改良的两点是：增加了度量要件定义等上游工程的简易测量功能；避免使用人为因素太强的调整系数。CSFPA法适用体制在项目估算时的FP度量、项目完成时的FP度量、实际数据的收集、统计分析、工数模型化、质量指标化等方面具有CSK特有的方式，CSK在该方法的教育与培训、模型构筑、估算·质量计划的适用、结果评价·差异分析等方面取得了良好的绩效。 【CSFPA法的估算步骤】

CSFPA法与IFPUG法的估算步骤有所不同，二者的相似点以及不同点请参照图5-7。

图5-7 CSFPA功能点估算步骤 【CSFPA法的推广运用】

为了普及和适用CSFPA，CSK在企业内设立由多名专任人员组成的

事务局，推进方法的定义以及维护、管理、员工教育、度量支援、数据收集、统计分析、数据利用等。下面对CSFPA的适用体制加以介绍。

· 项目估算时的FP度量。在估算时度量软件规模，通过适用相应的工数模型测算预计工数，以此作为制定日程的根据。CSFPA的工数模型以开发的全过程为对象，按照项目的开发范围进行估算，将式样、品质、技术的对应要件作为变动要素对此加以调整。

· 项目完成时的FP度量。在项目完成阶段对FP数、使用环境、技术、工数以及质量信息等几十个项目加以记录，比较估算时的FP数并进行差异分析，以提升度量精度和模型有效性。

· 实际数据的收集。将度量的实际数据剃除异常点后纳入数据库，并加以分析，然后向全企业公开。这种标本数据已经超过400件。由于FP度量过程中由于度量者的不同可能导致较大的误差，事务局还面向经验甚浅的度量者提供现场支持，验证度量结果的妥当性，提高度量的精度。另外，还与其他企业所提供的数据进行比较验证，持续收集数据。

· 统计分析。对于收集起来的数据，还需要考虑到项目特性的差异并加以分析。作为分析的界限，CSK建立了包括约50种类型(可视化工具类开发、Web类开发、维护的主框架开发等)的数据库，并对各自包括工数在内的10种以上的项目和FP值实施相关分析。 · 工数模型化。CSK将FP数和工数的关系称之为“工数模型”，现在已经拥有可适用的6种工数模型。这些模型与实际数据的收集相配

合，实施差异分析，持续提升估算精度。

· 质量指标化。与工数模型一样，CSK将FP数和质量数据(缺陷、问题等)之间的相关关系作为质量模型加以提供。通过定义经由质量模型获得的指标，并与现存的指标相结合，构筑综合性的质量指标。 【CSK推进FP法的经验总结】

· 度量方法的教育与渗透—— 启蒙。要使用FP法进行度量，当然需要了解度量规则。CSK在其“项目管理研修”这一体制中，对企业员工实施教育，讲解FP法的定位、概要、使用方法，进行度量演习，让企业员工掌握FP法。

· 模型构筑—— 提升估算精度的路径。要使用各种模型提升估算的精度，需要度量项目特性以及仔细检查数据。CSK通过现场调研和支援活动，积累起专业知识和技能，并对技术、式样、质量方面的特性信息加以整理，构筑适合CSK的估算模型，提高估算精度。 · 估算·质量计划的适用—— 制定适当而正确的计划。构筑起来的模型在实际提案的时候作为估算的根据或者在产品的质量计划制定过程中适用。在模型不断适用的情况下，这些模型的适用实例也就逐渐丰富起来。

· 结果评价·差异分析—— 取得反馈信息至更高水平的运用。项目开发过程中，变更点管理以及计划与实绩的差异分析非常重要。在这个过程中，需要获得适当的反馈信息，在把握复杂的项目状况的同时需要灵活应对这些变更和反馈。CSK在这方面也在积极运作并在整个企业内展开。

【CSK功能点法今后的展开】

将FP作为商务活动中的共通尺度是CSK导入FP法的主要目的之一。为了提高CSK与顾客之间将之作为共通尺度的认知度，CSK认为需要实施如下事项：一是提高方法本身的认知度和信赖性；二是客观地验证度量数据的精度。FP是度量软件规模的手段，在软件开发的商务活动、项目管理、资产管理等诸多场合中都是切实把握规模的依据，是以适当的价格提供高质量软件的基础，也是客观性表示CSK的生产性的重要因素。CSK在通信、控制、嵌入式开发中正在试用COSMIC-FFP。

8 IFPUG 功能点估算基本方法

Function Point Estimation 功能点估算是一种用来估算项目大小的技术。

项目经理从已经界定的软件范围开始，并根据该陈述将软件分解为可以被单独估算的功能单元，然后估算每一个功能的FP值。这种分析方法是按照功能为估算单元进行分解，同样如果以其它元素作为估算单元，例如类、对象、业务过程，以下都以功能分解进行讨论。 注意：功能单元是指分解到的最小可估算单元。

FP值是按照经验，使用复杂度参数进行估算调整过的量化的数值。 估算的基本过程：

a) 界定项目范围；

b) 分解项目到可以被估算的最小功能单元； c) 识别功能单元的类型，估算复杂度； d) 计算总体系统特征值； e) 计算调整因子； f) 应用公式计算FP值。 1. 界定项目范围

界定项目范围这次不讨论。

2. 分解项目到可以被估算的最小功能单元 系统用5种信息域特征进行描述： 事务（Transaction）： 外部输入( External Input EI) 外部输出（External Output EO） 外部查询（External Inquiry EQ） 数据存储：

内部逻辑文件（Internal Logical File ILF） 外部接口文件（External Interface File EIF）。

内部文件（ILF）指每个逻辑主文件（即数据的一个逻辑组合，它可能是某大型数据库的一部分或者是一个独立的文件），例如数据库表。注意不是一个数据库表就是一个ILF，例如合同数据可以包括合同信息、合同条款、合同付款计划。

外部接口：所有机器可读的接口，是不由本系统维护的逻辑文件，

是其它系统的ILF。例如：web service取回的数据，一个人工维护的Excel表格。

3. 估算功能点的复杂度

数据元素类型(Data Element Types DET)是一个用户可识别的、唯一性的、非递归的域。

记录元素类型(Record Element Types RET)是ILF或者EIF中用户能够识别的数据元素小组。

档案类型（File Types Referenced FTR）是被引用或更新的内部逻辑档案。

交易类信息域(EI、EQ、EO)的复杂程度取决于这个交易牵涉到的数据元素类型数量，以及被引用或者更新的档案文件类型的数量。 数据存储(EIF、ILF)的复杂程度取决于这个数据的逻辑组合包含了多少类记录元素类型，以及包含了多少数据元素类型。例如合同数据包括了合同信息、合同条款、合同付款计划，就是3个RET。 记录了每个信息域的DET、RET、FTR之后，按照下表为每个信息域进行复杂度评定、打分，总分就是这个功能点的分值。 评估EI复杂度

引用的文件类型个数（FTR’s） 数据元素(Data Elements) 1-4 5-15 >15 0-1 低 低 低 2 低 中 高 >=3 中 高 高

评估EO和EQ复杂度

引用的文件类型个数（FTR’s） 数据元素(Data Elements) 1-5 6-19 >19 0-1 低 低 中 2－3 低 中 高 >3 中 高 高 事务型信息域评分值 级数(Rating) 加权值

低 4 3 3 中 5 4 4 高 7 6 6

评估 ILF EIF 的复杂度 记录元素类型（RET’s） 1-19 20-50 >50 1 低 低 中 2-5 低 中 高 >5 中 高 高 ILF EIF 的评分值 级数(Rating) 加权值 ILF EIF 低 7 5

数据元素(Data Elements)

中 10 7 高 15 10

FP = Σ 各个复杂度等级的信息域数量 × 加权值

4. 计算总体系统特征值General Sysytem Characteristics GSC 也称做复杂度调整值，是系统整体复杂程度的度量，取值 Fi 为0－5。

通用特性 描述

1. Data communications How many communication facilities are there to aid in the transfer or exchange of information with the application or system?

数据通信 多少个通信设施在应用或系统之间辅助传输和交换信息。

2. Distributed data processing How are distributed data and processing functions handled?

分布数据处理 分布的数据和过程函数如何处理？

3. Performance Was response time or throughput required by the user?

性能 用户要求相应时间或者吞吐量吗？

4. Heavily used configuration How heavily used is the current hardware platform where the application will be executed?

硬件负荷 应用运行在的硬件平台工作强度如何？

5. Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.? 事务频度 事务执行的频率(天、周、月)如何？

6. On-Line data entry What percentage of the information is entered On-Line?

在线数据输入 在线数据输入率是多少？

7. End-user efficiency Was the application designed for end-user efficiency?

终端用户效率 应用程序设计考虑到终端用户的效率吗？

8. On-Line update How many ILF’s are updated by On-Line transaction?

在线更新 多少ILF被在线事务所更新？

9. Complex processing Does the application have extensive logical or mathematical processing? 处理复杂度 应用有很多的逻辑或者数据处理吗 ？

10. Reusability Was the application developed to meet one or many user’s needs?

重用性 被开发的应用要满足一个或者多个用户需要吗？

11. Installation ease How difficult is conversion and installation?

易安装性 升级或者安装的难度如何？

12. Operational ease How effective and/or automated are

start-up, back-up, and recovery procedures?

易操作性 启动、备份、恢复过程的效率和自动化程度如何？ 13. Multiple sites Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?

跨平台性 应用被设计、开发和支持被安装在多个组织的多个安装点（不同的安装点的软硬件平台环境不同）吗？

14. Facilitate change Was the application specifically designed, developed, and supported to facilitate change? 可扩展性 应用被设计、开发以适应变化吗？ 调整过的FP = FP * ( 0.65 + 0.001 *Σ Fi) 参考IFPUG的《功能点计算实践手册》

9 数据文件的相关概念

（ 1 ）系统边界：它是被测量的项目（或应用）和外部用户域（或应用）之间的分界。

（ 2 ）内部逻辑文件（ ILF ）：它是用户可确认的，在应用程序内

部维护的、逻辑上相关的数据或控制信息。

（ 3 ）外部接口文件（ EIF ）：它是用户可确认的、由被测应用程序引用，但在其他应用程序内部维护的、逻辑上相关的数据或控制信息。

（ 4 ）数据元素类型（ DET ）：它是 ILF （或 EIF ）中用户可识别的、唯一的、非循环的字段或属性。

（ 5 ）记录元素类型（ RET ）：它是用户可识别的、存在于一个 ILF （或 EIF ）中的一组 DET 的子组。

（ 6 ）文件类型参考（ FTR ）：它是一个被某个事务参考的文件类型。

事务处理的相关概念

（ 1 ）外部输入（ EI ）：它表示一个数据从系统边界外进入系统内的基本事务过程。这些数据可能是控制信息或商业信息（如果是商业信息，则它会维护一个或多个 ILF ）。

（ 2 ）外部输出（ EO ）：它表示一个从系统内导出数据到系统外的基本事务过程。在这个过程中，会形成某种形式的报表或输出文件到其它应用中，并且这些导出的数据一般带有计算结果或推导的

成分。

（ 3 ）外部查询（ EQ ）：它表示一个同时带有输入和输出成分的基本事务过程。在这个过程中，数据从一个或多个 ILF （或 EIF ）中产生，并被导出至系统外部（这些导出的数据一般不会带有计算结果或推导的成分）。 IFPUG 计算未调整功能点的方法

（ 1 ）对于 ILF ，计算基于其 DET 和 RET 的数量。

（ 2 ）对于 EIF ，计算基于其 DET 和 RET 的数量。

（ 3 ）对于 EI ，计算基于其 DET 和 FTR 的数量。注意： EI 在处理过程中所维护（或参考）的任何一个 LIF （或 EIF ）都可以作为一个 FTR 计算。

（ 4 ）对于 EO ，计算基于其输入和输出两端的 DET 和 FTR 的总数量。注意： EO 在处理过程中读取（或维护）的每个 ILF （或 EIF ）都可以作为一个 FTR 计算，每个 EO 至少有一个 FTR 。

（ 5 ）对于 EQ ，计算基于其输入和输出两端的 DET 和 FTR 的总数量。注意： EQ 在处理过程中读取到的每个 ILF （或 EIF ）都可以作为一个 FTR 计算。

更

详

细

来

自

于

：

http://www.gzvtc.cn/about/chengguo/chengguo-17.htm

10 功能点估算方法

http://kingoa.blog.163.com/blog/static/39163022007438837203/ 1.详细功能点法

10.1 1.1介绍

功能点法是基于用户的角度来度量开发性或维护性商业软件规模的一种项目估算方法。它基于客观的外部应用接口和主观的内部应用复杂度以及总体的性能特征，通过软件的功能点再除以生产率可得出项目开发所需的工作量。

在需求通过评审后和项目结项时，采用详细功能点法各进行一次估算，能够最终确定软件规模和项目的实际生产率。

详细功能点法一般不适用于对网站建设、业务逻辑复杂的软件和嵌入式软件开发进行估算。

在使用详细功能点法进行项目估算时，一般需要输入《用户需求整理报告》、《概念设计说明书》、《逻辑设计说明书》、《物理设计说明书》、《数据库设计说明书》和界面原型等项目文档资料作为项目估算的参

考和依据。

10.2 1.2估算步骤

a)确定用户需求，系统范围和系统边界； b)统计未调整的功能点数（UFP）； c)对UFP通过复杂度进行调整； d)确定值调整系数（VAF）；

e)得出最终功能点数：FP= UFP *(0.65+0.01*TDI)； f)确定开发生产率；

g)最终的功能点数除以生产率获得开发工作量； i)确定项目的开发阶段占工作量的百分比；

j)确定项目中日常活动（例如项目管理，配置管理）占开发工作的百分比。

10.3 1.3信息域定义

在功能点估算中需要对5种信息域进行描述：其中事务类的有外部输入(EI)、外部输出(EO)和外部查询(EQ)；数据存储类有内部逻辑文件(ILF)和外部接口文件(EIF)。

1.3.1外部输入(EI)：通过界面等的输入，如插入、更新等操作都是典型外部输入。

1.3.2外部输出(EO)：仅仅输出，如导出、报表、打印等输出。 1.3.3外部查询(EQ)：先要输入数据，再根据输入数据计算输出，如查询。

1.3.4内部逻辑文件(ILF)：可以理解为业务对象，可能对应多个数据表。

1.3.5外部接口文件(EIF)：其它应用提供的接口数据。

10.4 1.4事务类功能点的估算：

对事务类的功能点估算需要确定数据元素类型(DET)和引用档案文件类型(FTR)两个指标：

数据元素类型(DET)：可以理解为界面的录入具体数据项。 引用档案文件类型(FTR)：事务功能需要操作的数据文件的数目。

对外部输入(EI)的复杂度的计算： 1 FTR 2 FTR 3+FTR

1 TO 4 DETs 5 TO 15 DETs 16+ DETs Low Low Average

Low Average High

Average High High

COMPLEXITY EI-UFP Low

3

Average High

4 6

对外部输出(EO)和外部查询(EQ)复杂度的计算： 1 FTR 2 FTR 3+FTR

1 TO 5 DETs 6 TO 19 DETs 19+ DETs Low Low Average

Low Average High EQ-UFP 3 4 5

Average High High

COMPLEXITY EO-UFP Low Average High

4 5 7

10.5 1.5 数据存储类功能点的估算

对数据存储类功能点的估算需要确定数据元素类型(DET)和文件引用类型(RET)两个指标：

数据元素类型(DET)：具体数据存储文件的数据项的数目。 文件引用类型(RET)：数据文件是复合文件时候关联或引用的个数。如订单数据文件由于存在订单头和明细关联引用。 对内部逻辑文件(ILF)和外部接口文件(EIF)复杂度的计算：

1 RET

1 TO 19 DETs 20 TO 50 DETs 50+ DETs Low

Low Average High EIF-UFP 5 7 10

Average High High

2 TO 5 RETs Low 6+ RETs

Average

COMPLEXITY ILF-UFP Low Average High

7 10 15

10.6 1.6 UFP计算

统计出所有的数据功能点和交易功能点后，两者相加得出未调整功能点数(UFP)，即UFP＝EI+EO+EQ+ILF+EIF。 信息域数据估算完成后可以开始考虑调整因子(VAF)。

10.7 1.7 VAF确定

调整因子(VAF)是一种补偿机制，即通过五个信息域和复杂度都还没有办法考虑到的因素就应该作为调整因子, 如同样一个软件系统一种是系统要支持分布式和自动更新，而另一种是不考虑这种需求，如果不考虑调整因子这两者的规模是一样的，但很明显第一种情况复杂度和规模都会更大些。影响调整因子(VAF)共有14个通用特性，根

据这1个通用特性对软件的影响度进行打分，每个通用特性的分值（DI）在0～5之间，分值的界定如下： 0：没有影响； 1：影响不明显； 2：略有影响； 3：中等影响； 4：明显影响； 5：强烈影响。

通用特性 Data 描述 How many communication 1. communications facilities are there to aid in the transfer or exchange of information with the application or system? 数据通信 多少个通信设施在应用或系统之间辅助传输和交换信息。 Distributed data How are distributed data and processing functions handled? 分布的数据和过程函数如何处理？ Was response time or throughput 2. processing 分布数据处理 Performance 3. 性能 Heavily required by the user? 用户要求相应时间或者吞吐量吗？ used How heavily used is the current hardware platform where the application will be executed? 4. configuration 硬件负荷 应用运行在的硬件平台工作强度如何？ Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.? 事务频度 事务执行的频率(天、周、月)如何？ data What percentage of the 5. On-Line 6. entry 在线数据输入 End-user information is entered On-Line? 在线数据输入率是多少？ Was the application designed for end-user efficiency? 应用程序设计考虑到终端用户的效率吗？ 7. efficiency 终端用户效率 Complex Does the application have 9. processing extensive logical or mathematical processing? 处理复杂度 Reusability 应用有很多的逻辑或者数据处理吗 ？ Was the application developed to meet one or many user’s needs? 被开发的应用要满足一个或者多个用户需要吗？ 10. 重用性 Installation ease How difficult is conversion and installation? 升级或者安装的难度如何？ 11. 易安装性 Operational ease How effective and/or automated are start-up, back-up, and 12. 易操作性 recovery procedures? 启动、备份、恢复过程的效率和自动化程度如何？ Multiple sites Was the application specifically designed, developed, and 13. supported to be installed at multiple sites for multiple organizations? 跨平台性 应用被设计、开发和支持被安装在多个组织的多个安装点（不同的安装点的软硬件平台环境不同）吗？ Facilitate change Was the application specifically designed, developed, and 14. 可扩展性

supported to facilitate change? 应用被设计、开发以适应变化吗？ 14个通用特性的分值（DI）合计被称作TDI。 VAF＝TDI×0.01

1.8功能点的计算

FP=UFP*(0.65+0.01*TDI)＝UFP*(0.65+VAF)

1.9确定开发生产率

生产率的确定可采取以下几种方式： a) 参考公司类似项目的生产率水平； b）参考行业的生产率标准； c) 根据公司当前生产率水平确定。

1.10开发工作量的计算

开发工作量的计算＝功能点数（FP）/开发生产率

1.11确定项目的开发阶段占工作量的百分比 项目需求阶段一般占总工作量的15％－30％；

项目设计阶段一般占总工作量的20％－40％； 项目编码阶段一般占总工作量的20％－40％； 项目测试阶段一般占总工作量的10％－30％； 各个项目可根据实际情况加以调整。

2.快速功能点法 2.1介绍

快速功能点法不考虑简单功能和复杂功能的差异，在统计功能点时不关注数据元素类型(DET)、记录元素类型(RET)和引用文件类型对规模的影响，所有的功能点的复杂度都假设为中等难度。不具备进行详细功能点法进行估算时，只为毛估项目成本或决定是否开发某个软件时可以采用此方法。

快速功能点法一般在毛估项目成本或决定是否开发某个软件时、同时不具备采用详细功能点法进行估算时使用，不适用于网站，业务逻辑复杂的软件，嵌入式软件，不适用于估算软件构建的工作量。 采用快速功能点法进行估算时，应提供《项目规划书》及《用户需求整理报告》作为估算依据。

2.2估算步骤

2.2.1确定用户需求，系统范围和系统边界。 2.2.2统计未调整的功能点数（UFP）。 2.2.3确定值调整系数（VAF）。

2.2.4得出最终功能点数：FP= UFP *(0.65+0.01*TDI)。 2.2.5确定开发生产率。

2.2.6最终的功能点数除以生产率获得开发工作量。 2.2.7确定项目的开发阶段占工作量的百分比。

2.2.8确定项目中日常活动（例如项目管理，配置管理）占开发工作的百分比。

3. 估算记录

3.1 《功能点估算表》

11 功能点分析学习笔记

最近在学习功能点分析，学习的资料就是钱岭的那本书。为了克服自己读书不认真的毛病，决定把看过的东西作一个读书笔记。所以就有了这个东西。

书的前面时写给公司领导看的。我们直接说说功能点计算的步骤，

这是第六章的内容 功能点的计算

A：功能点计算第一步是确定功能点的计算类型 功能点的计算有三种类型： 1，开发性项目功能点计算

测量一个新的应用程序，如果这个系统是要替换旧系统。那么在测量时，除了系统的功能点，还要包括从旧有系统中转换数据到新系统中功能的功能点

这个测量是逐步细化的，随着时间的延续和项目的进展。会获得越来越

多的文档资料。这些多有助于更精确的计算功能点。

根据项目采用的不同的开发方式，可以在需求，详细设计，测试，实现，

维护等阶段进行。 2，升级性项目功能点计算

用来测量对现有应用程序的修改。包括新增功能、删除功能和改变

功能。计算必须要反映出功能的变化。 3，应用程序功能点计算

就是计算一个已经完成的应用程序的功能点 B：确定计算范围和应用程序边界 用来确定边界的原则

1，边界是在用户的角度来看，用户能够用自己的语言来定义应用程序的范围和业务功能

2，判断与其他应用程序的分割主要考察是否是业务层次的分割，而不是技术层次

3，对于一个大系统中独立的不同应用程序[是不是相互独立的功能模块]，相互之间的功能点要单独计算，然后合成整个系统的功能点。不同应用程序之间进

行考察时，ILF和EIF也是相对于独立的应用程序而言。而不是整个系统。

C：确定所有数据功能【内部逻辑文件ILF和外部接口文件EIF】及其复杂性

D：确定所有失误功能【外部输入EI，外部输出EO，外部查询EQ】及其复杂性

1,一个EQ可以从多个ILF和EIF中查询数据 E：得到未调整的功能点计数

F：得到基于14项系统基本特征的值调整因子 G：计算已调整功能点计数

11.1 笔记2

功能点计算的前两步没什么可说的，我们直接从第三步开始：如何计算数据复杂度！

否现得确定那些数据文件才能行。FPA中把文件分成两种： ILF【内部逻辑文件】：是用户认可的，在应用程序内部维护的、逻辑上相关的数据快或者控制信息

。ILF的主要意图是通过应用程序的几个或者多个基本处理来保存数据。

用户认可：就是经过用户和开发人员共同认证的。不存在任何异议的数据；比如，金融系统中的支票帐户就是一个ILF

逻辑相关：就是数据块中间要有逻辑关系，时逻辑相关的。比如：学生的姓名和年龄相关。 学生信息与银行支票号信息就不想关 一个ILF不能依赖于其他的ILF。如果发生依赖关系，就需要把两个ILF合并。一个ILF可以被多个应用程序当作ILF来计算 但是在同一个应用中，一个ILF只能被计算一次

EIF【外部输入文件】：由其他的应用程序维护的。被本应用程序引用的文件。一个EIF可以被多个应用当作EIF引入，但是同一个 应用中只能应用一次。

知道了有什么文件我们现在就要知道如何计算文件的复杂度。文件拿什么来量化呢？这里又是两个概念：DET，RET

DET【数据元素类型】：简单说就是类的属性。比如：学生类的年龄，姓名等。一个RET中的每个字段都可以被看成DET。

需要注意的是：一些因为技术实现的原因而引入的字段和一些重复的字段不计在内。比如ID字段

RET【记录元素类型】：就是类了。可以把一个ILF或者EIF的子集

【比如：一个文件的必填字段】作为一个RET。如果没有子集，那么 一个ILF或者EIF可以被看作一个RET。如果一个RET还存在父子关系的RET，那么父RET就不计在内。

通俗的说就是： 人 是一个抽象对象， 教师和学生是实例对象。 在这里人的属性有：编号，姓名，年龄；教师的属性有：姓名， 年龄，教龄；学生的属性有：姓名，年龄，入学日期。

注意：上面的例子只是为了更好的项了解OOAD的人来说明问题的。事实上，由于人这个概念并不是用户识别的，也就是说用户需求中 不会出现人这个概念。所以他不能作为一个ILF。

在这里认得DET有：姓名，教龄，年龄，入学日期4个DET，因为人有教师和学生两个子对象。所以人不能计为RET。 RET有 教师，学生 两个

现在我们考虑文件的复杂性了，起始很简单，只要确定了ILF、EIF的DET 、RET然后查表就行了 下面就是表： －> DET

1～19 20～50 >=51 || 1 低 低 平均 \\/ 2～5 低 平均 高 RET >5 平均 高 高

确定了复杂性，后面再查另一个表就可以确定功能点了。注意这里功能点时未调整的

复杂级别 低 平均 高 ILF 7 10 15 EIF 5 7 10 EI 3 4 6 EO 4 5 7 EQ 3 4 6

11.2 现在开始学习如何计算事务的复杂度

事务分成三种：EI【外部输入】， EO【外部输出】， EQ【外部查询】 先看看EI：是来自应用程序之外的数据或者控制信息。他的操作对象是ILF。这里EI并不和显示世界重的输入对应。

比如：一个学生信息核能要分成多次输入，先输入用户名，年龄，等基本信息，然后输入班级等信息。但是这里

只能作为一个EI。但是对于学生信息的增加，删除，修改等维护操作确要记成多个EI。

对于输入的数据，必须是来自应用程序之外的；对于外部输入的控制信息，必须是用户需求中描述的控制信息，绝对不能是技术实现中 的控制信息。

不管是输入的数据好事输入的控制信息，他都必须是用户需求层次的院子操作。操作前后要保证数据的完整性。一些来自其他的应用 程序发送给本应用来处理的消息也是EI 程序中的参数读取、登陆页面输入等不是EI

那么如何计算EI的复杂度呢？EI的复杂度是根据EI所引用文件的DET以及EI所引用的文件总数来决定。

前面已经说过了DET的计算方法，现在看看FTR的的计算方法： 1，EI的每个基本操作【用户需求级的原子操作】所引用的ILF作为一个FTR

2，将EI在处理过程钟所引用的ILF或者EIF作为一个FTR 3，对于修改等即被读取，又被保存维护的ILF作为一个ILF 很简单吧，计算完成FTR之后，可以查表来判断复杂水平和未调整的功能点数：

DET

1～4 5～15 >=16 F <2 低 低 平均 T 2 低 平均 高 R >2 平均 高 高

上面的表格是查复杂度，然后根据前面已经提供的表格查未调整的功能点数。

EO和EQ的处理方法于EI类似，都是以DET和FTR来确定复杂度 EO是指应用程序向应用程序之外提供至少经过本应用一次处理加工

【计算，创建等维护一个或者多个ILF】的数据或控制信息。 EO操作可能会改变系统的行为。

EQ是指应用程序向应用程序之外提供对ILF和EIF数据查询结果的输出或者是控制信息的输出。比如：查询系统中符合某个条件的 结果集等。所提供的数据未经系统处理加工。EQ不会改变系统行为。 前面基本确定了系统的大致规模，现在需要考察系统的细致特征，对我们前面的测量结果进行微调。

IFPUG【国际功能点用户组】组织的测量手册是从14个方面来考察系统的细致特征。它把系统的14项考察 特征进行量化。分为5级：

0，不存在或者无关【无需考虑这方面的特性】 1，偶尔相关 2，中等相关 3，平均相关 4，较强相关 5，完全相关

对应14项特征，评分标准参考如下【在书上摘抄】 A：数据通信 [data communication]

B：分布式数据处理 [distributed data processing] C：性能 [performance]

D：资源需求 [heavily used configuartion] E：处理速度 [transcation rate]

F：在线数据输入 [online data entry]

G：最终用户使用效率 [end user effcoency] H：再线升级 [online update] I：复杂处理 [conplex processing] J：可重用性 [reusability] K：易安装性 [installation ease] L：易操作性 [operational ease] M：多场所 [multiple sites] N：支持变更 [facilitate change] 下面是参照的评分标准 A：数据通信

0，应用程序是纯粹的批处理程序或者运行在独立的PC上 1，应用程序是批处理程序，但是有远程数据输入或远程打印 2，应用程序是批处理程序，但是有远程数据输入和远程打印【注意两者是\"与\"关系，两者都有】

3，对于批处理程序或者查询系统来说，应用程序包含在线数据收集或者一个远程处理前端

4，应用程序不仅是一个前端，他还支持一种类型的TP【teleprocessing, TP 远程处理】通信协议

5，应用程序不仅是一个前端，他还支持不止一种类型的TP【teleprocessing, TP 远程处理】通信协议【多种协议】 只有没有任何交互的批处理程序才能取0，屏幕输入数据也是远程输

入

具备屏幕输入，但以批处理方式来处理内部逻辑文件的程序应该是3分

通常来说，批处理程序0～3分，在线应用程序3～4分，实时、电信、过程控制系统 4～5分 B：分布式数据处理

0，应用程序不支持系统部件之间的数据传输或者处理 1，应用程序为系统其他部件上的用户处理、准备数据

2，为传输准备数据，讲述据传输到系统的另一个部分进行处理（不是最终用户）【就是在系统个部件之间传输数据了】 3，分布式处理和数据传输在线进行并且是单项的 4，分布式处理和数据传输是在线进行并且是双向的 5，多数系统相应部件上都是动态执行处理功能

说明：只有分布式程序或者实时系统才会考虑本项，其他程序可以取0

web程序 取2～4， 实时，电信或者控制系统取0～5。取5分时，系统重h

C：性能：主要描述系统的响应时间，数据吞吐量等 0，用户没有提出任何要求

1，提出并评审了性能和设计序需求，但不必采取专门措施 2，响应时间和吞吐量在业务峰值时段是至关重要的。但不必为了CPU的利用率而采用专门设计。业务处理的截至日期在下一个工作

日

3,响应时间和吞吐量在业务峰值时段是至关重要的。但不需要为CPU利用率而采用专门的设计。业务处理的截至日期是有限制的 4，此外，已提出的用户性能需求已经迫切到了在设计阶段安排专门的性能分析任务

5，此外，需要在设计、开发和（或）实施阶段使用性能分析工具来满足已提出的用户性能需求

说明：通常来说，批处理程序得0～4分；在线应用程序得0～4分；实时、电信处理程序得0～5分

D：资源需求，就是描述系统对特殊资源（比如：硬件资源，带宽资源等）的特殊需求以及确定的资源环境对应用程序的限制等 0，不包括任何直接或者间接的操作限制

1，确实存在操作限制，但是比通常的应用程序的约束要少一些。不需要多费功夫

2，包括一些安全性或者时间限制的考虑 3，应用程序的某个部分需要专门的处理器

4，已提出的操作限制需要在中央处理器或者一个专门的处理器中的应用程序上加上特殊限制

5，此外，在应用系统的分布式部件上存在特殊的限制 说明：一般的程序2分；CS结构、实时系统的3～5分

E：事务频率：描述应用程序处理事物的频率（是每天，每小时还是每年）

0，没有可预见的峰值处理时段

1，可以预见一个峰值处理时断（每月，每季度） 2，可遇见每周一次的高峰 3，每天一次的高峰

4，用户在应用程序需求或者服务中提出的高处理率已经需要在设计阶段安排性能分析工作了

5，需求重的处理要求必须在要在设计阶段安排性能分析工作，并且需要在设计、开发部署阶段使用性能分析工具 说明：在线应用程序0～4分

F：在线数据输入：应用程序的数据要求在线输入的比重多大 0，没有 1，1％～7％ 2，8～15％ 3，16～23％ 4，24~30% 5,>30%

G:用户使用效率：考察应用程序的界面友好性 友好界面中的考察因素项包括：

辅助导航（功能键，跳转，动态生成树的菜单） 菜单

在线帮助和文档 光标的自动移动

滚动

远程打印（在线处理） 定制功能键

在线处理提交的批处理作业 使用光标选定品目的数据

大量使用的翻转录像、高度、颜色、下划线和其他指示器 在线处理的硬拷贝文档用户 鼠标界面 弹出式菜单

用尽可能烧得品目来完成一种业务功能 支持两种语言（这个规定要算4项） 多种语言支持（这个要算6项） 记分标准： 0，0项

1，1～3个上面列出的因素项 2，4～5项

3，>=6项，但用户没有其他关于使用效率的专门需求

4，>=6项，但已经提出了其他关于使用效率的需求强烈到需要在设计阶段进行人性华设计分析的工作

5，>=6项，需要使用特殊的工具来满足要求 说明：无交互的程序 才能取0分。一般3分 H：在线升级

0，无要求

1，更新1～3个控制文件。数据量底，容易恢复 2，更新4个或者更多的控制文件。数据量底，易恢复 3，包含对主要内部逻辑文件的更新

4，除以上之外，防止数据丢失式一项基本要求，而且经过了专门的设计并已经实现

5，除以上之外，大数据量促使恢复过程要考虑成本问题。高度自动化的恢复过程只需要少量的人工干预 说明：普通的应用程序 3分。

I：复杂处理，应用程序中是否包含复杂的逻辑处理业务 根据逻辑对程序开发的影响需要考虑下面的部分

1，敏感性控制（特殊的审计处理）和特定应用程序的安全处理 2，大量的逻辑处理 3，大量的数学处理

4，很多的例外处理，因此比促再次处理不完整的事物（比如一个ATM业务的无效验证等） 5，应付多种输入/输出格式 记分标准： 0，0项 1，1项 2，2项 3，3项

4，4项 5，所有项

考察的方式：首先，应用程序是否提供了一种安全机制，使某些人可以看见或者输入别人无法看见的或者输入的数据；第二，是否存在大量显祖的逻辑处理（if/then/else等）；第三，是否存在大量数学处理（不仅仅是加减乘除的操作）；第四，是否存在复杂编辑或者验证；第五，应用程序中是否包含多种媒介（例如：语音和屏幕输入） J：可重用性 0，没有可重用代码

1，可重用的代码重用于应用程序内部

2，应用程序中少于10％的部分会被一个以上的用户使用 3，应用程序中大于等于10％的部分会被一个以上的用户使用 4，应用程序被专门打包和文档化以简化重用（这个应用程序本身就是为了复用而生，公用模块）

5，除4之外，用户可以通过参数维护定制应用程序 K：易安装性

0，没有提出安装要求，也无需考虑安装问题

1，没有提出安装需求，但是要考虑安装问题，进行相应的工作 2，提出安装需求，提供并测试了转换和安装的指南。项目中转换工作带来的影响并不重要

3，并给项目中的工作带来显著的影响 4，除2外，提供并测试自动安装工具

5，除3外，要求提供自动安装工具 L：易操作性：系统是否容易使用

0，除了正常的备份处理程序，用户没有提出特殊的操作方面的额考虑

1～4从下列项目中选择准确的特性，没有特别说明，分值为1 提供有效地启动、备份、恢复备份处理，但是需要操作员人工干预 无需干预（2分） 需要人工安装磁带 需要人工穿空纸和穿孔纸带

5，应用程序无人值守，所有的操作都不需要人工干预。系统能够自动进行错误恢复【火星车上的系统应该属于这类】

说明：对于无需磁带、打空纸安装的系统得1分；如果系统启动、备份和恢复需要干预 得3分不需要干预得4分自动恢复得5分 M：多场所：系统是否需要被安装在不同的地点供不同的组织使用 0，没有需求

1，有需求，但应用得软硬件环境相同 2，软硬件环境相似 3，软硬件环境不相同

4，系统中有相应的设计和文档，其他同1，2 5，系统中有相应的设计和文档，其他同3 N：易变更：系统是否能够根据特殊的需求而改变 考察范围：

提供灵活的查询和报表支持

业务控制数据被分组保存在用户维护得表中 记分标准 0，没有设计

1～5选择相应的条目：

提供能够处理简单请求得灵活查询以及报表支持－－例如，对一个内部逻辑文件的加减（比如支持用户选择自己关心得财务字段内容输出）【1项】

对多个内部逻辑文件得加减【2项】 提供一个或者一个以上得处理功能【3项】

业务控制数据保存在由用户通过在线交互处理维护得表中，但是变更只在下一个工作日才生效【1项】 立即生效【2项】

综合上面的系统特性，一般情况下得分：批处理系统总分小于15分；有前端批处理程序得总分在15～30分之间；交互式应用程序在30～45分之间，实时、电信或者过程控制系统得30～60分。 调整因子 VAF＝（总分 × 0.01） + 0.65

前面讲述了 如何计算未调整的功能点 以及根据起项系统特性获取的调整参数。 最终的计算结果如下：

最终的功能点＝未调整功能点数 × 调整参数

根据不同的计算类型【在第一步骤时就要确定的内容】，这个公式可以做一些调整。具体内容很简单。不说了 完