快速功能点分析法与NESMA的比较

• 一、快速功能点分析法

快速功能点分析方法是依据国际标准(ISOIEC 24570:2018《软件工程NESMA功能规模测量法功能点分析应用的定义和计算指南》)要求提出的一种软件规模测量方法，并充分考虑软件组织及需求或项目特性,目前采用预估功能点分析方法和估算功能点分析方法进行业务需求规模的估算和测量，并对方法进行了优化改进。

• 二、快速功能点估算与NESMA的不同

• 1.支持的估算方法不同

快速功能点分析法目前只采用了预估算功能点分析法和估算功能点分析法，详细估算功能点分析法并未考虑。从功能点估算的时间投入产出比上看，详细估算明显效率偏低，不能体现快速功能点分析的要义。

另外，利用快速功能点分析方法估算时，每个功能组件都采用“中级”级别复杂性程度，即ILF、 EIF、EI、EO、EQ 的取值分别为10、7、4、5、4。相较NESMA，将数据功能组件的复杂度由“低级”提升到“中级”。NESMA 估算功能点分析法，默认数据功能选择“低级”级别复杂性程度，事务功能选“中级”级别复杂性程度进行估算，即ILF、EIF、 EI、EO、EQ 的取值分别为7、5、4、5、4。这也都是标准制定们对我国大量行业数据统计分析后做出的调整。

• 2.对GSC调整因子的放弃

在NESMA模型的介绍过程中，就已经谈到了GSCs/VAF存在的问题。某些估算模型在进行功能点估算时就直接忽略掉GSC调整的步骤，恰巧，快速功能点分析法也直接采纳了这种方案。做出这样的选择有其客观原因，比如据有关数据统计，一半左右的项目VAF的调整范围在±5%内，平均值为1.01。另外，GSC的一些特征已经明显不适应当前软件行业的计数架构需求，这也一定程度上成为潜在促进因素。

当然，对于一般项目我们可以放弃使用GSC调整规模，也就相当于默认VAF=1，但对于复杂度很高的项目或大型项目，还是建议估算时要考虑GSC调整因子，同时也要选择合适的特征、特征计分规则来应对。

• 3.更细化的分阶段估算精度

NESMA及前期的估算模型中，关于需求变更调整因子CF，在预算阶段取值是2，招标阶段取值为1.5，投标阶段取值为1.26（当然，如果这些阶段的需求比较清晰明确的话，取值是可以调整的），其他进入详细需求阶段或设计阶段之后的取值均为1。其中，关于立项阶段、项目计划过程中的取值明显缺乏明确的界定。所以，在快速功能点分析法中，明确建立了针对不同阶段更细化的估算精度。

根据2023年中国行业基准数据报告，项目估算早期（如项目概算、预算阶段），规模变更调整因子CF取值为1.39；项目中期（如招投标阶段、项目立项、计划阶段、技术方案阶段），规模变更调整因子CF取值为1.21；项目晚期（如需求分析阶段，需求阶段完成后发生变更），规模变更因子取值为1.1；否则，需求阶段完成之后、项目结算、后评价，规模变更因子取值都为1。

• 4.EQ和EO计数规则的不同

快速功能点分析法继承了NESMA模型的大部分计数规则，其中也有部分计数规则差异。比较明显的就是事务功能EO和EQ的部分规则差异。

NESMA估算模型关于EO的规则中讲到，EO的输出规模是大小不等的，而EQ的输出规模是确定的。EO可能包含数据处理过的数据，而EQ不包含任何需要数据处理的结果。EO可以有输入数据，也可以不包含输入数据，但是EQ必须有一个唯一的键值被输入。

快速功能点分析法中是不包含外部输出的输出规模不确定这一条的。EO可以进行复杂的公式运算、逻辑处理、产生派生的衍生数据；EQ不可以进行运算、派生衍生数据，但可以附带简单的条件选择、排序、分组等。

通过对比可以看出，NESMA对EQ的规则限制还是比较多的。所以，NESMA中EQ类型的功能点数量多数情况下会少于EO类型，而快速功能点分析法则恰恰相反。比如，NESMA中，类似下拉列表、某个功能的查询等功能都归为EO，但是这些功能在快速功能点分析中都要归类为EQ。两种估算模型关于EO、EQ的其他规则大致雷同。

• 5.编码数据计数规则的不同

逻辑文件分为内部逻辑文件和外部接口文件。NESMA中，把编码数据当做FPA数据表单独统计，而快速功能点分析法是不统计编码数据的。编码数据就是开发人员开发过程中需要硬编码的常量、文本等数据通过数据表维护起来，NESMA中称之为FPA数据表。

NESMA将所有的编码数据都统计为一个逻辑文件，来自应用内部的编码数据都统计为一个ILF，来自外部系统的统计为一个EIF。对于ILF，基本过程都计数一个EI、EO、EQ；对于EIF，没有过程计数。

快速功能点分析法估计认为编码数据是技术上的需要，非用户需求本身的需要，所以编码数据都不视为逻辑文件，与之相关的操作也都不认为是基本过程。

• 6.EI计数规则的特殊场景

以修改某个业务对象为例，譬如修改日程。修改日程，需要先点击打开日程，然后再修改、提交。

NESMA将修改日程当做一个整体的基本过程，相当于把打开日程、修改提交当做这个过程的2个步骤。站在客户的角度，目的是为了修改日程，打开日程不是目的，所以不把打开日程作为一个过程。譬如，查看日程详情，这就是客户的业务目标，可以作为一个EQ来独立计数的。

快速功能点分析法中，没有详细说明此类情况。不少估算人员就会将修改日程分解为2个过程，打开日程作为一个EQ、修改提交日程作为一个EI。站在一个功能模块的角度，除了增、删、改、查这些功能点，还应该有查看日程详情的功能点。实际上，查看日程详情跟打开日程是重复的功能点，由于不能重复计数的缘故，打开日程和查看日程详情只能统计为一个EQ。所以，站在日程模块的角度，即使是把打开日程作为一个独立EQ，快速功能点分析法和NESMA的模块估算规模仍然不会有大的偏差。

总的来说，关于这点，我个人比较倾向于NESMA模型的做法，把修改日程作为一个基本过程，而不是割裂开来。这也符合功能点规模估算的一个根本准则，站在用户立场出发。

• 三、功能点估算的注意事项

• 1.无论是逻辑文件还是基本过程的估算，必须从客户立场出发，是用户可识别的，这是根本准则。因此，凡是技术原因引进的文件，以及引用这些文件的操作，都不应该作为计数功能点进行统计。
• 2.识别逻辑文件必须建立在概念模型的基础上。概念模型可以体现数据实体之间的关系，但不需要描述实体的业务属性，更不需要对属性进行定义、设计。其实这段话也体现了概念模型-逻辑模型-物理模型的演变。数据库实体表跟逻辑文件没有必然的对应关系。
• 3.识别逻辑文件时，一定要充分考虑业务对象之间的依赖性，判定实体之间是逻辑依赖还是逻辑独立的。如，一个业务对象的属性是不能脱离业务对象本身识别为独立的逻辑文件；数据库表中的关系表是不能作为逻辑文件的；数据库的子表是不能脱离父表被识别为独立的逻辑文件的。
• 4.判定实体间的逻辑独立还是依赖，需要区分以下的场景。允许删除A，同时会删除所有连接着的B。这说明B的业务独立性和重要性不强，所以我们认为实体B是强依赖于实体A的。另外一种情况：只要有B连接着，就不允许删除A。这样的话，要删除A，必须首先删除B。这种情况下，认为B是独立于A的。
• 5.识别基本过程时切忌不要讲其中的一个步骤识别为过程。比如，上节（二.6）中说到的修改日程，不可将打开一个日程识别为一个独立的过程EQ，应该将打开日程、修改并提交视为一个整体。列举一个更恰当的事例：收集个人信息，先填写基本信息，点击下一步填写教育背景，点击下一步填写兴趣爱好，填写完成后提交。这3步的业务目标就是收集个人的完整信息，不可割裂看待为3个基本过程，实际上它们只是一个基本过程的3个步骤。
• 6.基本过程EI识别错误的可能较小，但是估算模型不同EQ和EO识别混淆的可能性还是有的。这就要求我们一定遵循前面的计数规则和主旨。