简化功能点系列之一：什么是功能点

这是简化功能点系列的第一篇。

目标

功能点的目标，是估算工作量，进而估算成本和造价。

俗话说：“店大欺客，客大欺店”，银行这么大的客遇上IBM这么大的店，会发生什么呢？那就是功能点。

大约在1979年左右，IBM发布了对功能点的基本定义，后来随着业界的发展，逐渐成为当前唯一被广泛认可的软件规模度量标准。

功能点最大的特点，就是它和工作量的比例关系很好（应该是，功能点就是为了这个目标而设置的，因此这个不是偶然）。

什么是功能点

和我们平时说的“功能点”不同的是，标准功能点（Function Point）是一个被严格定义的概念，不会因为估算人员差异产生显著差别。

下面的图展示了功能点中的“计数单元”，就是可以被数为功能点的东西。

内部逻辑文件ILF，就是用户的业务数据，类似于UML中的Entity，或者业务类Business　Class，或者数据库中的某些“主表”。

外部接口文件EIF，就是要访问的外部数据（注意不是外部系统，而是外部系统中的一个ILF）。

外部输入EI，主要目的是使ILF数据变化的一种操作，简单说增删改都是EI；还有一种“使行为发生变化”的EI，如“开始杀毒”。

外部查询EQ，主要目的是查看原始数据，比如查看流水帐，查看余额。

外部输出输出，主要目的是查看计算和派生的数据，比如查看年度报表；还有一种是“穿越系统界面”的，比如打印。

这些功能点的定义，核心是“客户可以理解并识别”，比如图中灰色的那些“数据”和“操作”，是客户看不到的，因此不能计算为功能点。

在计数过程中，各种功能点标准都做了一些细节定义，防止出现错误估算的情况。比如：

1. “查询”有很多条件，算几个？

2. 输出之前要先输入（输入查询日期范围），算几个？

3. 有的复杂有的简单，怎么数？

……等等，总之各种一望而知的和想都想不到的问题，都能找到依据（但有的依据很难掌握）。

IFPUG曾有报告指出，若两个人经过了标准功能点的培训，那么这两个独立计数相差不到10%。

功能点标准

现在世界上有５个功能点的ISO标准（值得注意的是，除了功能点，没有任何其他比如代码行、故事点、用例点……形成标准），分别是 （下面是俗称）：

IFPUG（澳大利亚，最大的功能点组织），NESMA（荷兰，世界第二大功能点组织，代表欧洲），MarkII，COSMIC（能用到嵌入式），FiSMA（芬兰）。

功能点有各种简化方法，但基本上都“与功能点兼容”，就是说借用了功能点的定义和数值。

各种组织、咨询公司收集的功能点项目数据在5万左右（其中一家就达到2万多），粗略估计企业内部的功能点数据可能超过50万。

每年还能看到各种功能点的对比数据报告，这个也是其他估算方法所不能比拟的。

标准功能点的局限性

尽管功能点是一种“与技术无关”的“只需要需求就能数的”东西，但却很难在某些场景中应用，比如：

1. 功能点的复杂度依赖于某些细节，无法早期获得。

具体包括字段数DETs、影响到的表的数量FTRs、字段的排列组合情况RETs等信息，而这些信息只有在很详细的界面设计和数据库设计出现后，才能计算清楚。

比如那个RETs，我本人现在还搞不懂。我可是不但听过功能点课程，还翻译过国外的课程（PPT加口译，还仔细查阅了英文原文中的定义），还和外国讲师额外请教了很多，搭上了去颐和园划船的时间，还是不能给出严格区分的方法。

2. 功能点的很多概念与日常需求分析和描述差别很大

一个资深产品经理，本来需求写的好好的，也足以给测试人员写用例，给设计人员写设计，做出来的产品客户也很满意，就差一个估算和度量不太懂，于是他就参加标准功能点培训……突然，他就像小学生误入微积分课堂一样，听到一大堆完全陌生的词汇、定义和判断准则，感觉自己完全像一个基础为零的菜鸟一样。

实际上，需求分析资深人士和外行学功能点的速度一样快……或者说，一样慢，因为前面的积累几乎用不上。

之后的几篇博客，将会介绍如何以一种无为而治的方法，对已有的需求描述方法略作改进，就能从中自动计数功能点。

一篇看似平淡无奇的Word文档（甚至里边全是标题不需要文字），可以在几秒钟后算出功能点数值；而多数项目（2人年以下的），几个小时就能做完。