软件项目估算（二）

anscj

软件项目管理领域知识分享

这一篇集中讲功能点。

3.1.4 功能点法

功能点法重点介绍IFPUG和NESMA两个标准。

3.1.4.1 IFPUG（International Function Point Users Group）

3.1.4.1.1 功能的类型

软件由数据和程序构成的，任何一个软件所包含的功能可分为两大类型：

1）对最终用户不可见的数据功能（Data Function）

2）对最终用户可见的交互功能（Transaction Function）

数据功能

估算数据功能的复杂度就是估算ILF、EIF的复杂度，也可以简单理解为对数据库复杂度的计算。功能确定后，即可估算ILF和EIF的个数。

内部逻辑文件（ILF）：在应用程序内部的，用户可识别的、可维护的内部逻辑数据和控制信息。通常包括数据库表、临时文件、顺序文件等。
外部接口文件（EIF）：在应用程序边界内被查询，但在其他应用程序中被维护的、用户可识别的、逻辑上相关的数据。例如两个应用程序为了交换数据而使用的接口文件。

交互功能

估算交互功能的复杂度就是估算EI、EO、EQ的复杂度，也可以简单理解为对程序开发复杂度的计算。和用户之间的接口确定后，即可估算EI、EQ、EO的个数。

外部输入（EI）：对用户的输入进行处理的过程。用户通过增/删/改等典型外部输入操作来更改和维护ILF。
外部输出（EO）：向外部发送数据的过程。对数据进行处理，会更改ILF，会改变应用程序。
外部查询（EQ）：输入和输出的组合过程。根据用户提出的查询请求，从EIF或ILF取出数据输出到程序外部。不对数据进行处理，不更改ILF，不会对应用程序做出改变。

注意：EI、EO、EQ都必须是一个“基本处理(elementary process)”，即必须是对用户来说有意义的最小的功能活动单元，并且该功能不会使系统处于一个不一致的状态。

3.1.4.1.2 估算的步骤

1、Step1 识别功能点及类型
2、Step2 确定功能点的复杂度
3、Step3 确定功能点的权重
4、Step4 计算未调整的功能点
5、Step5 计算调整因子
6、Step6 计算已调整的功能点

================1、Step1 识别功能点及类型================

识别并计算应用程序中的ILF、EIF、EI、EQ、EO的个数。

ILF的判定规则

在应用程序边界内，用户进行了增删改查等操作的数据

EIF的判定规则

在应用程序边界内查询数据，在其他应用程序内保存的数据
在应用程序边界内，没有对EIF进行操作
是应用程序边界外其他应用程序的ILF

EI的判定规则

从应用程序边界之外获得数据
至少改变一个ILF
至少满足下面三个条件之一，即该基本处理过程的：

逻辑应该唯一，指其在应用程序中与其它基本处理过程的逻辑不同。例如：不能存在两个完全一模一样的存盘操作
所使用数据应该唯一，指其在应用程序中所使用的这组数据应该与其他基本处理过程所使用的数据不同。
所引用ILF或EIF文件应该唯一，指其在应用程序中所引用的ILF或EIF是与其它基本处理过程所引用的ILF或EIF不同。

EO、EQ的通用判定规则

从应用程序边界之外获得数据或控制信息
向应用程序边界外部输出数据
至少满足下面三个条件之一，即该基本处理过程的：

逻辑应该唯一，指其在应用程序中与其他EO或EQ在逻辑性上保持唯一。
所使用数据应该唯一，该唯一性是指其在应用程序中与其他EO或EQ所使用的数据不同。
所引用ILF或EIF文件应该唯一，该唯一性是指其在应用程序中与其他EO或EQ所引用的ILF或EIF文件不同。

EO的额外判定规则

还需要满足以下条件之一

包含了数学公式和计算方法
生成了派生数据
对ILF进行了维护
改变了系统的行为

EQ的额外判定规则

还需要满足以下所有条件

不能包含数学公式或计算方法
不能生成派生数据
不能维护任何一个ILF
不能改变系统的行为
从ILF或EIF中获取数据。

EI、EO、EQ对比

示例：外贸订单系统项目

EI：录入订单、修改订单、删除订单
EO：统计订单
EQ：查询订单
EIF：汇率查询转换系统
ILF：订单和客户

================2、Step2 确定功能点的复杂度================

根据已估算出的ILF、EIF、EI、EQ、EO的个数分别计算复杂度。

（1）ILF、EIF的复杂度取决于:

数据元素类型（DET）数量：用户可识别的、没有重复的、有业务逻辑意义的信息单元。
记录元素类型（RET）数量：在ILF或EIF中，用户可识别的DET的集合。

DET的判定

通过一个基本处理过程的执行，对ILF进行维护，或从ILF/EIF中返回一个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个DET。

例如：添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”，那么对ILF订单来说它的DET就是4个。
再如：保存订单时还会保存订单的明细。订单的明细往往作为一个子表进行保存，那么“订单号码”在主表和子表中都同时存在（主外键）。但以用户角度来识别时，存盘操作是一个最小的单位，那么订单号码只能算做一个DET

当两个应用程序维护和/或引用相同的ILF/EIF，但是每个应用程序分别维护/引用它们相应的DET时，这些DET在这两个应用程序的维护/引用中将单独计算。

例如，一个应用程序的两个基本处理过程都需要使用到“地址”的信息，地址信息又可以细分为“国家、城市、街道、邮编”。那么对于其中一个基本处理过程来说，它将整个地址信息作为一个整体进行处理，只算一个DET；另外一个基本处理过程使用地址的每个详细信息，那么DET就是4个。

RET的判定

RET在ILF /EIF中分为两种类型：可选的（Optional）和必选的（Mandatory）。计算的规则如下：

在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET。
如果一个ILF/EIF没有子集合，则ILF/EIF被计算为一个RET。

例如：在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。那么订单系统ILF中的RET为：订单信息（必选的）、客户信息（必选的）、部门信息（可选的）。因此ILF中RET的个数为3个。

确定ILF、EIF的复杂度

根据ILF或EIF中DET和RET的数量，确定ILF或EIF的复杂度。

（2）EI、EQ、EO的复杂度取决于:

数据元素类型（DET）数量：用户可识别的、没有重复的、有业务逻辑意义的信息单元
应用文件类型（FTR）数量：数据处理过程中所涉及的相关文件，包括ILF和EIF

EI中识别FTR:

通过EI读取的每个ILF或EIF都应该计算为一个FTR。
既被EI维护又被读取的ILF仅计算为一个FTR。

EI中识别DET:

在EI的过程中，用户可识别的、通过应用系统边界输入系统内部的非重复字段，应算作一个DET。
在EI的过程中，只要没有通过系统边界输入，即使它存在于系统内的一个ILF中，或者通过页面自动计算或转换的，也不能算为一个DET。

例如，外贸订单系统中，订单的金额是被单价和数量自动计算的，那么金额是没有通过系统边界输入的，因此在EI操作中就不应该算做一个DET。

在EI的过程中，系统提示的错误信息或完成操作的信息，应该被分别计算为一个DET。

例如，在网站注册用户信息时，由于输入错误系统会显示提示信息，那么这些提示信息应该被逐个计算为一个DET。
再如，当EI操作完成时系统提示并显示出来的信息，应该被计算为一个DET。

在EI操作中，如果遇到主外键的字段，应该算作一个DET。

EO和EQ中识别FTR:

通用规则

每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR

EO额外的FTR计算规则

在EO处理过程中每个被维护的ILF算一个FTR
在EO处理过程中既被读取又被维护的ILF算一个FTR

EO和EQ中识别DET:

用户可识别的非重复字段，进入应用边界并指明处理什么、何时处理或处理方式，并且由EO/EQ返回或产生，那么这样的每个字段算一个DET。

例如，报表中的每个字段都是一个DET。

在应用边界内以用户角度识别的非重复字段算一个DET。

例如，在报表中起到解释或备注作用的文字信息，不管是一个字、一个词或一段话，都当作一个DET。
再如，某种编号或日期，即使它被物理存储在不同字段中，但从用户角度看是一个整体的信息，因此被算作一个DET。

在EO或EQ操作中，如果对系统进行输入或读取操作时，相同的字段只计算一个DET。

例如，在报表查询时，输入的字段在报表上也有显示，那么将算作同一个DET。

在EO或EQ操作中，系统提示的错误信息或完成操作的信息，应该被计算为DET。

例如，用户查询一个列表时被拒绝，那么拒绝的提示信息就算为一个DET。

在EO或EQ操作中如果遇到主外键的字段，应该算作一个DET。
在EO或EQ过程中，只要没有通过系统边界输入，即使它存在于系统内的一个ILF中，或者通过页面自动计算或转换的，也不能算为一个DET。

例如，在公司发工资的时候，员工对应的状态信息被更新，但这个状态信息的更新是没有通过系统边界输入的，因此也不能算做一个DET。

在饼图中百分比和分类算作不同的DET。
报表/页面的标题、系统字段生成的记号、页码等类似信息不计算DET。

例如，页码、位置信息、时间、上一页和下一页等信息，都不能算作一个DET。

确定EI的复杂度:

根据EI或EO或EQ中DET和FTR的数量，确定EI或EO或EQ的复杂度。

确定EO、EQ的复杂度:

根据EI或EO或EQ中DET和FTR的数量，确定EI或EO或EQ的复杂度。

================3、Step3 确定功能点的权重================

根据已估算出的功能点复杂度，确定功能点的权重。

（终于有个简单的步骤了~~~~）

================4、Step4 计算未调整的功能点================

统计各类功能点中各复杂度的功能点数量，分别与对应的权重相乘，得出该类该复杂度的未调整功能点数。

所有未调整功能点数相加，得出总的未调整功能点数。

（这个步骤也简单~~~~，坚持，快结束了）

================5、Step5 计算调整因子================

调整因子是通过系统基本特征及其影响程度来计算的。

针对14项系统基本特征对系统的重要程度进行评估，得出每项特征的影响程度值（DI）：

将14项基本特征的影响程度值DI相加就是总影响程度（TDI）

根据TDI计算调整因子（VAF）：VAF=0.65 +TDI*0.01

14项系统基本特征

数据通讯
分布式数据处理
性能
大业务量配置
事务处理率
在线数据输入
最终用户效率（用户界面友好程度）
在线更新
复杂处理（算法）
可复用性
易安装性
易操作性
多场地（多点运行）
支持变更（客户化程度）

（1）数据通讯

数据通讯指的是应用程序直接与其他系统或设备通讯的程度。

（2）分布式数据处理

分布式数据处理是应用在内部组件之间传递信息的程度。这个特性是在应用边界内体现的。

（3）~（14）:不讲了，能查到。基本思路就是通过分析应用程序对某个特性的支持程度，反过来来判断特性对应用程序的影响程度，查表得到每一个对应的值，再综合算出一个值来，就是调整因子VAF了。

================6、Step6 计算已调整的功能点================

根据未调整功能点（Step4的结果）和调整因子（Step5的结果）计算已调整功能点：

FPC = UFP * VAF

（终于结束了~~~）

3.1.4.1.3 估算的示例（员工管理系统）

在员工管理系统中添加一个员工资料，会使用到员工的一般信息、教育情况、工作经历和家属信息。员工隶属于某个部门，在本系统中会有一个对部门进行维护的功能。员工的工资则由另外一个财务系统提供。

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

员工ID（标签控件）
员工名称
性别
生日
婚否
所属部门ID（标签控件）
所属部门名称
—受教育的时间
—学校名称
—所学专业
—工作时间
—工作单位
—工作部门
—工作职务
—亲属的姓名
—之间关系
—亲属年龄
—工作单位

假设部门信息如下所示：

部门ID（标签控件）
部门名称

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

员工ID（标签控件）
员工姓名
金额
单位

ILF和EIF的功能点数：合计19个

EI的功能点数：合计25个

EQ的功能点数：合计9个

EO的功能点数：合计4个

计算调整因子

最终调整后的功能点数量为：（19 + 25 + 9 +4）* 0.84 = 48.88个

3.1.4.1.4 估算步骤总结

Step1 识别功能点及类型：计算ILF、EIF、EI、EO、EQ的个数
Step2 确定功能点的复杂度：计算各ILF、EIF的DET和RET个数，计算各EI、EO、EQ的DET和FTR个数，确定复杂度
Step3 确定功能点的权重：根据复杂度查表得出权重
Step4 计算未调整的功能点：加权统计所有功能点
Step5 计算调整因子：分析14项系统特性，打分并计算调整因子
Step6 计算已调整的功能点：未调整*调整因子=已调整

3.1.4.2 NESMA

这一篇东西太多了，功能点NESMA标准以及剩下的其他东西都放在第三篇吧。

NESMA标准绝对会让你眼前一亮的，相信我！