心得总结 软件开发商务谈判中，我们尝试把甲乙双方拉到同一尺度下的第一步！
上篇文章拿了一个人力资源管理系统的案例来作引，说明了甲乙双方在软件开发项目中的困境。忘记的可以再回头看一看。
先把上篇文章中提到的人力资源管理系统的例子贴过来。
组织架构管理 对公司组织架构进行维护和图形化显示，包括部门、岗位等信息。可以对部门进行新建、修改、删除、合并、改变归属关系、设定岗位人数并根据已录入的档案信息自动显示实际岗位人数。支持部门、岗位信息的 Excel 模板导入功能。可以对岗位进行新建、修改、查询、删除等，岗位信息包括岗位说明、相关联工资级别等。
招聘管理 对于空缺岗位生成招聘申请，人力资源主管和部门主管审批后自动发布到外部招聘渠道。可以查询招聘信息或删除已过期的招聘信息。对应聘人员信息进行管理，将得到的简历、面试情况录入到系统并进行维护。
档案管理 对员工的信息进行管理，包括员工基本信息（如姓名、年龄、性别、岗位、电话、邮件等）、家庭档案信息、培训记录、工作记录。还包括员工照片、社保号码登。授权用户可以对员工档案进行查询或进行修改（如调动、离职、绩效考核信息填写等）。
人力地图 将公司的全部或某部门组织架构图显示出来，并可查看员工的基本信息。本人可以维护部分个人信息，如手机号码、个人主页地址、个人说明等。
培训管理 制定公司年度培训计划进行管理，并对每次公司级培训简历培训记录并对培训效果进行分析。提供年度培训久啊的建立、修改、审核、审批等功能。对每次培训进行管理，可自动发送培训通知，培训后填写培训满意度、培训总结。可以对某时间段内的培训或选定培训进行培训效果的比较和分析。
人力资源分析 包括基于人数的分析和基于部门的分析。基于人数的分析包括统计各岗位、各部门、各学历、各年龄段的人数、各岗位/部门实际人数和空缺人数等。基于部门的分析包括分析各部门到岗率、入/离职情况、岗位构成、学历构成、年龄构成等。
报表中心 授权用户可查看或打印员工基本信息、培训信息、工作情况、考核情况、并提供人力资源常用模板（如离职申请、培训申请等）的下载和打印。
今天先来说说功能点估算的第一个方法——IFPUG 估算法。
国际功能点用户组织（International Function Point Users Group, IFPUG）
Allan J. Albrecht 1979 年在 IBM 工作时首次在《衡量应用程序开发生产力》一书中提出了功能点估算法。随后，他成立了国际功能点用户组织（International Function Point Users Group, IFPUG），他发明的这个功能点估算方法也就称为了 IFPUG 功能点估算法。
IFPUG 作为一个非营利性、会员管理的组织，其使命是成为推广和鼓励有效的应用软件开发和维护。随着时间的推移，IFPUG 方法已经成为国际上使用最广泛的功能规模度量方法之一，特别适用于信息系统。
在 IFPUG 的发展历程中，该组织不断更新和改进其功能点计数标准，以适应不断变化的软件工程实践。
- 1994 年，发布 IFPUG 计数实践手册 4.0 版
- 1999 年，发布 IFPUG 计数实践手册 4.1 版
- 2001 年，发布 IFPUG 计数逻辑文件的实践指南
- 2003 年，发布 IFPUG 功能大小的框架
- 2004 年，发布 IFPUG 计数实践手册 4.2 版
- 2005 年，发布 IFPUG 计数实践手册 4.3 版
- 2015 年，发布 IFPUG 早期功能点分析和一致的成本估算
IFPUG 估算法的原理
IFPUG 估算法在进行软件规模估算前，先建立了一个软件功能模型。将软件能够完成的功能分为了两种类型：事务功能和数据功能。
简单的理解就是，一个软件要为人服务的话，一是要能够自己保存维护一定的数据（数据功能），二是要能够提供操作这些数据的一些方法（事务功能）。
从程序员的角度来说，程序就是数据和算法的集合，也是蛮科学的。
数据功能：
IFPUG 估算针对程序的数据功能定义了 2 个模型：
- ILF: Internal Logical File，内部逻辑文件
- EIF: External Interface File，外部接口文件
IFPUG 官方定义的 ILF 和 EIF 是用户可识别的逻辑相关数据和控制信息。只是分别处于不同的系统中，ILF 处于我们评估的目标系统中，EIF 不处于我们的目标系统中。
官方的定义直译过来过于晦涩，说说我个人简单的理解就是，ILF 和 EIF 必须是对用户有实际用途的信息集。这个信息集的内容可以只是数据，同时，也可以是一些状态的表示数据。但是，一定是要对用户有实际意义！
事务功能：
- EI: External Input，外部输入
- EQ: External Inquiry，外部查询
- EO: External Output，外部输出
IFPUG 功能点方法怎么用？
IFPUG 估算法就是基于软件的功能点的这个模型，来确定软件的基本功能，进而确定功能点数。IFPUG 在实际使用时，主要分为以下几个步骤：
- 收集资料
- 划定软件边界
- 识别功能性需求
- 计算功能点
收集资料
搞懂要干啥，当然是第一步了。比如之前的人力资源系统的需求说明：
组织架构管理 对公司组织架构进行维护和图形化显示，包括部门、岗位等信息。可以对部门进行新建、修改、删除、合并、改变归属关系、设定岗位人数并根据已录入的档案信息自动显示实际岗位人数。支持部门、岗位信息的 Excel 模板导入功能。可以对岗位进行新建、修改、查询、删除等，岗位信息包括岗位说明、相关联工资级别等。
招聘管理 对于空缺岗位生成招聘申请，人力资源主管和部门主管审批后自动发布到外部招聘渠道。可以查询招聘信息或删除已过期的招聘信息。对应聘人员信息进行管理，将得到的简历、面试情况录入到系统并进行维护。
档案管理 对员工的信息进行管理，包括员工基本信息（如姓名、年龄、性别、岗位、电话、邮件等）、家庭档案信息、培训记录、工作记录。还包括员工照片、社保号码登。授权用户可以对员工档案进行查询或进行修改（如调动、离职、绩效考核信息填写等）。
人力地图 将公司的全部或某部门组织架构图显示出来，并可查看员工的基本信息。本人可以维护部分个人信息，如手机号码、个人主页地址、个人说明等。
培训管理 制定公司年度培训计划进行管理，并对每次公司级培训简历培训记录并对培训效果进行分析。提供年度培训久啊的建立、修改、审核、审批等功能。对每次培训进行管理，可自动发送培训通知，培训后填写培训满意度、培训总结。可以对某时间段内的培训或选定培训进行培训效果的比较和分析。
人力资源分析 包括基于人数的分析和基于部门的分析。基于人数的分析包括统计各岗位、各部门、各学历、各年龄段的人数、各岗位/部门实际人数和空缺人数等。基于部门的分析包括分析各部门到岗率、入/离职情况、岗位构成、学历构成、年龄构成等。
报表中心 授权用户可查看或打印员工基本信息、培训信息、工作情况、考核情况、并提供人力资源常用模板（如离职申请、培训申请等）的下载和打印。
划定软件边界
软件的边界是一个很抽象的概念，先来看一个比较实际的弱电控制的例子。
在弱电设备集成好后，集成单位 A 把设备交给施工单位 B 时，会提供一个施工图纸。
图纸上会标明每个线接到哪一个端子排上。双方约定好，上方的就是集成商 A 负责的内容，端子排下方的接线就是施工方 B 负责的内容。
这个端子排，就是区分双方工作的边界，也是责任划分的边界。
软件在开发出来前，都是很抽象的，不是很直观。那怎么把抽象的内容表现出来？——可视化。
画一个方框代替我们的系统，就好了。
这一步很重要，是可视化的第一步，也是把抽象的软件功能实例化的第一步。
识别功能性需求
定义好了软件边界，就可以根据收集到的需求信息，进行功能识别了。主要目的是判断好功能的类型，这个需求是数据功能（ILF？EIF？）还是事务功能（EI？EO？EQ？）。
例如，人力资源管理系统的组织架构管理模块：
- 组织架构管理 对公司组织架构进行维护和图形化显示，包括部门、岗位等信息。可以对部门进行新建、修改、删除、合并、改变归属关系、设定岗位人数并根据已录入的档案信息自动显示实际岗位人数。支持部门、岗位信息的 Excel 模板导入功能。可以对岗位进行新建、修改、查询、删除等，岗位信息包括岗位说明、相关联工资级别等。
首先，识别这个模块中的数据功能。上面的需求信息，整个模块主要是对部门信息和岗位信息的各种相关操作。因此，这个模块的数据功能主要就包含：部门信息和岗位信息。再确定，这些信息的维护是我们要开发的软件系统内部维护还是系统外部维护的。显然，这里没有其他的系统了，信息的维护是在我们系统的内部进行，就可以确定部门信息和岗位信息是ILF了。
然后，再针对这两个信息，把相关的事务功能识别出来。
最后，根据 5 种基本的功能类型，确定每个功能的类别就可以了，我简单做了一个功能识别：
- ILF: Internal Logical File，内部逻辑文件
- EIF: External Interface File，外部接口文件
- EI: External Input，外部输入
- EQ: External Inquiry，外部查询
- EO: External Output，外部输出
识别完各种功能类型之后，就可以进入下一步：计算功能点了。
计算功能点
IFPUG 估算法针对不同的功能，有不同的功能点技术方法。
数据功能
数据功能的功能点数的确定，要依赖数据功能的复杂程度，下面分别是 ILF 和 EIF 的计数规则。
ILF 功能点计数规则：
| 复杂度 | 功能点数 |
|---|---|
| 低 | 7 |
| 中 | 10 |
| 高 | 15 |
EIF 功能点计数规则：
| 复杂度 | 功能点数 |
|---|---|
| 低 | 5 |
| 中 | 7 |
| 高 | 10 |
也就是说，如果某个 ILF 功能的复杂度是高，那么这个功能项的功能点计数就是 15 ，如果某个 EIF 功能的复杂度是中，那么这个功能项的功能点计数就是 7 。
那么，问题就来了：怎么判断每个功能项的复杂程度？拍脑袋吗？
IFPUG 为了解决 ILF 和 EIF 的复杂度问题引入了 RET 和 DET 的概念。
- RET（Record Element Types）: 用户可以识别的数据的子集。
- DET（Data Element Types）: 用户可以识别的非重复的域。
RET 和 DET 怎么理解呢？
还是拿人力资源管理系统的组织架构管理模块来举个例子：
- 组织架构管理 对公司组织架构进行维护和图形化显示，包括部门、岗位等信息。可以对部门进行新建、修改、删除、合并、改变归属关系、设定岗位人数并根据已录入的档案信息自动显示实际岗位人数。支持部门、岗位信息的 Excel 模板导入功能。可以对岗位进行新建、修改、查询、删除等，岗位信息包括岗位说明、相关联工资级别等。
岗位信息包括了 2 个部分：
- 岗位说明
- 相关联工资级别
岗位信息就是我们系统中维护的信息总集合，也就是ILF，而岗位说明和相关工资级别就是这个数据集的子集，也就是上面提到的RET。
DET 就是岗位说明和相关工资级别这两个信息集里面的各种字段，在这里没有更多明确的信息进行说明。
每个 ILF 和 EIF 都有对应的 RET 和 DET 。
因此，在确定 ILF 或 EIF 的复杂度时，根据下面的矩阵，就可以确定:
| 1~19 个 DET | 20~50 个 DET | 51 个以上 DET | |
|---|---|---|---|
| 1 个 RET | 低 | 低 | 中 |
| 2~5 个 RET | 低 | 中 | 高 |
| 6 个以上 RET | 中 | 高 | 高 |
由于 ILF 和 EIF 的信息给得不全面，暂时将 ILF 和 EIF 的复杂度都先确定为中来进行功能点的计算，为什么进行这样选择，后面说明 NESMA 功能点估算时会进一步说明，暂时先不细说了：
- ILF: 10
- EIF: 7
事务功能
EI: External Input，外部输入
EQ: External Inquiry，外部查询
EO: External Output，外部输出
确定完数据功能，就可以开始进行事务功能的确定了。同样，确定事务功能的功能点计数，也需要判断各功能的复杂度：
EI 和 EQ 的复杂度确定：
| 复杂度 | 功能点数 |
|---|---|
| 低 | 3 |
| 中 | 4 |
| 高 | 6 |
EO 的复杂度确定：
| 复杂度 | 功能点数 |
|---|---|
| 低 | 4 |
| 中 | 5 |
| 高 | 7 |
事务功能的确定，需要依靠上面说的 DET 和引入的一个新的概念 FTR 。
- FTR（File Types Referenced）:被引用或更新的内部逻辑档案。
FTR 又怎么理解？
还是看人力资源管理系统的例子：
- 组织架构管理 对公司组织架构进行维护和图形化显示，包括部门、岗位等信息。可以对部门进行新建、修改、删除、合并、改变归属关系、设定岗位人数并根据已录入的档案信息自动显示实际岗位人数。支持部门、岗位信息的 Excel 模板导入功能。可以对岗位进行新建、修改、查询、删除等，岗位信息包括岗位说明、相关联工资级别等。
在系统中完成岗位的新增这个操作的时候，需要把岗位说明和相关工资级别两个信息都录入到系统中，才能保障整个功能的完善。这里的 FTR 就引用了 2 种不同的文件类型，因此，岗位新建这个功能的 FTR 就可以确定是 2 了。
每个 EI、EO、EQ 都有自己独立的 RET 和 FTR 需要确定，以便来判断各自的复杂程度：
EI 的复杂度确定：
| FTR\DET | 1~4 | 4~15 | 16 以上 |
|---|---|---|---|
| 0~1 | 低 | 低 | 中 |
| 2 | 低 | 中 | 高 |
| 3 个以上 | 中 | 高 | 高 |
EO 和 EQ 的复杂度确定：
| FTR\DET | 1~5 | 6~19 | 20 以上 |
|---|---|---|---|
| 0~1 | 低 | 低 | 中 |
| 2~3 | 低 | 中 | 高 |
| 4 个以上 | 中 | 高 | 高 |
同样的，由于 EI、EO、EQ 的各种信息更多的细节都还需要确定，复杂度我们都先按照中等复杂度等级来确定功能点计数：
- EI: 4
- EO: 5
- EQ: 4
计数点数总结
为了方便，我先把 5 种功能类型的计数复杂度都以中级来进行功能点计数：
| 功能类型 | ILF | EIF | EI | EO | EQ |
|---|---|---|---|---|---|
| 功能点计数值 | 10 | 7 | 4 | 5 | 4 |
按照上面的这个表格计算，就可以获得最基础的功能点数是多少了：
还有什么问题没有解决？
絮絮叨叨了这么多，我们先回过头来看看我们得到的功能点数有什么缺陷？
首先，按照 IFPUG 确定的软件模型，来简化软件系统，是不是太理想了？有很多情况都无法涵盖的，软件系统的非功能性需求都没办法衡量，是不是不太科学？比如：我微服务框架分布式部署和单体架构的软件功能能一样？
当然不一样了！但是，我们得到了一个基本衡量软件规模的基本模型，可以用数据对软件规模进行量化了，对这些非功能性的需求，那我们再在刚才的基本点数上进行修正就可以了呀。所以，IFPUG 针对 14 个通用的系统特性确定了一个基本方法来对刚刚得到的功能点数进行修正，来获得修正后的功能点数，以此来反映系统的其他功能情况。怎么调整修正？我们后面再说！
其次，IFPUG 这么复杂，在确定复杂性的时候还需要知道每个功能类型的复杂程度才能判断功能点的计数情况，我软件项目早期要是能确定这些东西，软件项目还能有这么多变更？IFPUG 也没解决这个问题呀！
对！到目前为止，我们是没有针对这个问题有很好的解决方案。但是，是不是有一种可能性：基于这个模型，我们可以积累相关的数据，然后根据数据来估算新的软件项目情况？在有新的软件项目的时候，能够判断个大概？
最后，IFPUG 功能点估算比用户故事点估算麻烦这么多，最后还有这么多问题没解决，是不是反而把自己的工作搞复杂了？我用故事点估算的方法用得很好呀。迭代计划做完，大家评估好故事点，给客户或者老板一报就完事了。
不！功能点估算和故事点估算、用例点估算、代码行估算有本质的区别。像我上一篇文章说的：我们怎样 “度量” 软件开发？，功能点的方法是根据基本模型来确定软件的规模，模型确定好之后，是不以团队的能力，开发的环境改变的。这样的好处是，能够让非软件开发的专业人员也参与进来，方便专业的软件技术人员形成统一的认识！非专业人员不会因为没有技术背景，没法参与进软件规模的讨论中。
可能还会有人问：什么是功能点？
那，什么是 “米”（m）？什么是 “千米”（km）？
“米”（metre/meter，法 mètre）是国际单位制基本长度单位，符号为 m，一米等于 10 分米。可以用来衡量长、宽、高。
1 米=光在真空中于 1/299 792 458 秒的时间内所经过的路线的长度。
同样的，功能点也是衡量软件功能规模的基本单位，可以用来衡量软件的规模大小。ISO/IEC 14143 系列的标准是对功能点有明确的定义的。所以，从使用的角度来说，不必纠结功能点到底是什么。功能点，就是一种度量单位，它度量的是软件规模的大小，就够了。
在 我们怎么 “度量” 软件开发？ 中，甲乙双方在针对人力资源管理系统的商务谈判时，都陷入到了自己的困境。
甲方的困境：
- 进行商务谈判时，无据可依，全凭专家经验。
- 无法识别合理性报价。
- 系统延续性强，商务谈判地位处于弱势。
乙方的困境：
- 公司报价缺少较为权威的依据支撑，难以帮助甲方完成预算申报。
- 面对新的业务领域，专家经验估算法偏差巨大，导致项目亏损。
- 需求模糊不清，为项目变更埋下隐患。
IFPUG 没能解决双方的困境，但至少，IFPUG 做到了第一步：把甲乙双方的商务谈判拉到了同一个尺度（功能点）下。甲乙双方讨论的功能点相对客观。不会像故事点一样，乙方团队的不同，同一个用户故事，评估出来的故事点不同。稍微，客观了一点。
后续，我们再进一步讨论，怎么解决双方的这个困境！ 源管理系统 ** 的商务谈判时，都陷入到了自己的困境。
甲方的困境：
- 进行商务谈判时，无据可依，全凭专家经验。
- 无法识别合理性报价。
- 系统延续性强，商务谈判地位处于弱势。
乙方的困境：
- 公司报价缺少较为权威的依据支撑，难以帮助甲方完成预算申报。
- 面对新的业务领域，专家经验估算法偏差巨大，导致项目亏损。
- 需求模糊不清，为项目变更埋下隐患。
IFPUG 没能解决双方的困境，但至少，IFPUG 做到了第一步：把甲乙双方的商务谈判拉到了同一个尺度（功能点）下。甲乙双方讨论的功能点相对客观。不会像故事点一样，乙方团队的不同，同一个用户故事，评估出来的故事点不同。稍微，客观了一点。
后续，我们再进一步讨论，怎么解决双方的这个困境！
