在上篇文章《软件开发商务谈判中，我们尝试把甲乙双方拉到同一尺度下的第一步！》中，我们通过 IFPUG 的软件模型将甲乙双方针对软件开发这个工作拉到了同一个水平线上来讨论成本问题。

IFPUG 分析法的提出不但没有解决甲乙双方在商务谈判过程中的困境，同时，IFPUG 功能点分析法在使用过程中，还存在两个主要的问题：

1. IFPUG 在软件的非功能性需求并没有进行测算，无法准确的体现出软件开发商在实际开发中的工作量。
2. 在软件项目早期，没办法非常确定事务性功能（EI，EO，EQ）的时候，就没办法准确的核算具体的功能点，IFPUG 方法就没办法很好的应用，还在项目早期徒增工作量。

不解决这两个问题，乙方对功能点的分析结果是没有底气的，也不敢轻易的使用功能点分析的方法进行项目估算。

IFPUG 调整后的功能点

IFPUG 在最初进行功能点分析时，得到的是完全不考虑非功能性需求的功能点。为了解决没有考虑非功能性需求的问题，IFPUG 使用调整系数（value adjustment factor，VAF），对功能点进行修正，用以体现非功能性需求的工作量。

IFPUG 的 VAF 和 14 个通用系统特性（General System Characteristics，GSC）相关联：

1. 数据通讯（Data Communications）;
2. 分布式数据处理（Distributed Data Processing）；
3. 性能（Performance）；
4. 使用强度高的配置（Heavily Used Configuration）；
5. 交易速度（Transaction Rate）；
6. 在线数据输入（Online Data Entry）；
7. 最终用户的效率（End-User Effciency）；
8. 在线更新（Online Update）；
9. 复杂的处理（Comples Processing）；
10. 可重用性（Reusability）；
11. 安装的简易性（Installation Ease）；
12. 运行的简易性（Operational Ease）；
13. 多场地（Multiple Sites）；
14. 允许变更（Facilitate Change）；

在完成初步的功能点分析之后，再根据系统的特点针对这 14 个通用系统特性计算出调整系数（VAF）。

调整系数（VAF）的计算公式：

VAF = (TDI * 0.01) + 0.65

• TDI（Total Degree of Influence）： 所有的 GCS 的影响程度相加得到的整体影响程度。

确定好了 VAF 的值之后，就可以根据 VAF 对初始的功能点（UFP）进行修正，得到调整后的功能点（FP）：

FP = UFP * VAF

14 项通用系统特性（General System Characteristics，GSC）的影响程度判断暂时先不进行说明，后面再单独说明吧。

到这里，IFPUG 提出了非功能性需求度量的解决方案。但是，在项目早期时，怎么对软件开发项目进行快速估算，还是没有很好的解决方案。

NESMA 功能点分析法

NESMA 是荷兰软件度量协会（Netherland Software Measurement Association）的简称。

在项目早期时，由于无法清楚的缺点软件的具体功能，想判断清楚 ILF、EIF、EI、EO、EQ（具体定义参考软件开发商务谈判中，我们尝试把甲乙双方拉到同一尺度下的第一步！）是不可能的。

NESMA 为了解决这个矛盾，发现在项目早期，我们很难判断的是事务型的功能（EI、EO、EQ），数据型功能（ILF、EIF）在项目早期，是相对好确定的，并且趋于稳定的。

数据型功能一般都是与业务相关的数据集合。

例如之前提到的人力资源管理系统的组织架构管理模块为例：

1. 组织架构管理

对公司组织架构进行维护和图形化显示，包括部门、岗位等信息。可以对部门进行新建、修改、删除、合并、改变归属关系、设定岗位人数并根据已录入的档案信息自动显示实际岗位人数。支持部门、岗位信息的 Excel 模板导入功能。可以对岗位进行新建、修改、查询、删除等，岗位信息包括岗位说明、相关联工资级别等。

上文的需求描述中，虽然明确了新建、修改、删除、合并、改变归属关系等功能，但是，在具体的项目实施过程中，软件功能的需求变更是经常发生的事情。如果在开发过程中甲方突然发现，我需要一个岗位信息的 Excel 导出功能，方便人力部门做报表的统计。那么这时的变更做还是不做？那如果在做预算时，考虑到变更成本，成本核算的依据又是什么？这些都会给需求的变更埋下隐患，导致在项目早期进行估算困难。

回过头再来看看组织架构管理的功能需求描述可以发现，整个组织架构管理模块包含的业务信息集就部门和岗位两类信息，除此之外，不再包含其他的业务信息。

是不是可以把功能点分摊到相对稳定的数据型功能（ILF 和 EIF），进而实现在项目早期对项目进行估算呢？

当然可以！

NESMA 基于上面的这个想法，把项目的功能点分摊到了数据型功能（ILF 和 EIF）上，分别得到了 ILF 和 EIF 的功能点计数值：

功能类型	ILF	EIF
计数值	35	15

在项目早期，组织架构管理模型的功能点估算就可以只使用部门和岗位两个 ILF 进行估算：

UFP = 35 x 2 = 70

人力资源管理系统的组织架构管理模块的初始功能点（UFP）就是 70 。这样就解决了项目早期的功能点估算问题。

还有哪些待解决的问题？

至此，还有什么问题没有解决呢？先回过头看看甲乙双方的困境。

甲方的困境：

1. 进行商务谈判时，无据可依，全凭专家经验。
2. 无法识别合理性报价。
3. 系统延续性强，商务谈判地位处于弱势。

乙方的困境：

1. 公司报价缺少较为权威的依据支撑，难以帮助甲方完成预算申报。
2. 面对新的业务领域，专家经验估算法偏差巨大，导致项目亏损。
3. 需求模糊不清，为项目变更埋下隐患。

貌似好像，什么都没解决？不过，我们好像已经从把甲乙双拉到同一个谈判桌进行谈判，发展到了乙方有能力在项目早期进行谈判的时候进行快速的功能点估算了。

想要完全解决这个困境，只能再想办法了。

未完待续。

PS. 各位如果对软件造价或者软件项目管理实务感兴趣的我们可以多多交流哟！