FPA方法功能点计数常见问题

前言

　　本文的目标读者是从事软件行业采用FPA功能点方法对软件研发工作量评估的人员。列举了一些FPA 方法实践过程中的常见问题，有FPA 方法评估标准定义，也有实践过程中得出的方法建议，仅供参考。

一、 帮助文档

　　应用系统中的帮助功能通常有三种形式。

　　1、应用程序的帮助 - 此种情形下的“帮助”适用于整个应用程序，通常的形式是 GUI 系统上的“帮助”菜单。

　　2、屏幕形式的帮助 -此种情形下的“帮助”适用于基于GUI或Web 的系统中的特定屏幕。

　　3、字段形式的帮助 -此种情形下的“帮助”适用于应用程序中的特定字段。

　　4、根据FPA 方法，“帮助信息”计数为一个内部逻辑文件， 每个“帮助”计数为一个事务功能（前提是“帮助信息”是本系统维护的）。 复杂度通常为“低”。

　　5、“帮助”、“关于”经常是编码数据或静态页面，通常不进行计数。

如图所示：

二、 导航菜单

　　在web 框架系统中常见有导航菜单栏，可根据页面布局需要或功能布局需要，此类菜单通常是可以在后端进行配置和调整的，前端通过实时查询展现。但此类功能是一种编码数据，通常只有菜单编号、菜单名称、菜单链接、菜单序号等字段，并无实际业务含 义。在功能点计数时，不进行计数。

如图所示：

三、 图表

　　图表展示和生成方式有多种：

　　1、实时查询报表，此类报表从数据的生成到查询展现给用户为一个基本过程，通常计数为EQ 或 EO，无数学运算或衍生数据生成识别为EQ，否则识别为 EO。

　　2、通过批处理事先生成报表数据落地到数据库中，在提供查询界面展示报表数据。从基本过程来讲这是两个基本过程。批处理生成报表数据的基本过程识别为 EI，查询展现报表数据的过程识别为EQ 或EO。此时落地存储的报表数据库表是否要计为内部逻辑文件？从FPA 方法论中我们知道所有的事物功能（EI/EO/EQ）都必须引用或维护内部逻辑文件或者外部接口文件。如果不计数内部逻辑文件，那么报表生成和查询的事物功能是否不能计数？在报表实现的过程中我们发现主要的工作量是在报表生成和报表查询的开发。标准功能当中一个逻辑文件通常对应 4~6 个基本过程，如增删改查以及提供接口等。此时的报表数据只是一种加工后的事物数据，并非新增的逻辑文件。因此根据我们的经验通过批处理生成报表只计数批处理生成报数据过程EI 和查询报表数据过程EQ/EO 即可。

　　3、同一个报表既有表格、又有饼状图、条形图来展现。同常表格展示的是明细数据，条形图展现的是汇总排序，饼状图展现的是分类百分比。因此每个图表所展示的字段属性和业务需求是不一样的。在功能点计数时，应把每个图表单独计数为 EQ/EO。

四、 打印、导出

　　打印和导出功能分两种情况：

　　1、在查询列表的基础上进行打印、导出。此时查询列表已单独计数为一个EQ 或EO。打印、导出在此基础上执行。查询数据的处理过程可以复用。因此打印和导出可分别计数为一个独立的事物功能EQ 或EO，但重用程度可识别为高。

　　2、直接输入查询数据范围或数据类别进行导出，此时没有查询列表，因此导出和打印功能可分别计数为一个独立的事物功能EQ 或EO，单重用程度可识别为低。

五、 短信码发送

　　在一些安全性要求高的系统或系统登录注册过程中经常会遇到要求输入手机号码获取验证码进行身份认证的过程。发送短信验证码的功能是否为一个独立基本过程可计数功能点？答案是不可以。我们发现发送短信验证码并不是主要的业务目的，往往是在我们进场注册登录、支付、账户查询的过程中需要对我们的身份做验证或登记操作，才要求我们获取短信码进行验证，缺少验证码验证则无法完成我们的主要业务目的。因此短信验证码不是主要业务目的， 只是其他功能中的一个处理逻辑。在功能点计数时，不对该功能进行计数。

六、 审批流程

　　目前大多数系统的流程审批功能都是通过流程引擎配置实现的。

　　1、如果流程是开发人员通过配置+开发而新建、修改的。这个情况下，用户是不能对其进行维护的。所以，这流程本身就不是ILF；用户感知的是提交、审批、审核等事务功能，可计数，并且根据审批节点进行计数，重用程度一般为高，根据去重原则去重即可。审批节点中的同意、拒绝视为一个审批功能，为审批结果的两种不同状态或分支。

　　2、如果流程引擎是开放给业务用户操作的，那么就对流程引擎自身的功能进行计数。用户新增、修改的具体流程本身就不能计数为ILF，同理提交、审批也不计数。就像是用户在 CRM 系统里新增、修改了一条具体的客户信息一样。

七、 迁移

　　迁移本身为非功能性需求，因其工作量可量化，因此除了环境准备外，本身的开发工作量可定制规则进行计数。

　　1、功能迁移，通常处理逻辑、数据字段、数据访问方式会有变化，可识别为对原有功能的修改。

　　2、数据迁移，识别需要迁移逻辑文件的数量，每个逻辑文件的迁移对应一个EI，统计 EI 数量作为数据迁移工作功能点计数结果。从实际操作过程中有时较难以识别是否为逻辑文件，可以变相识别一个物理表为一个 EI，重用程度为中或高。

　　迁移项目评估方法仅为建议，而非IFPUG 发布的FPA 标准功能点方法中的标准。

八、 微服务架构系统

　　微服务架构是一种将单应用程序作为一套小型服务开发的方 法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP 资源的 API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

　　在对微服务架构系统进行功能点计数时，我们首先要考虑的就是系统边界。度量的目的是为管理服务，因此在划分系统边界时， 因遵从组织的管理需求和组织对系统的定义。如果组织已定义好每个IT 系统，则以组织定义的系统为边界，采用标准功能点方法进行计数。在一个系统边界内，有多个微服务单元，每个微服务单元均有独立的数据库以及微服务单元之间是采用接口的方式进行数据的访问或传递，其主要工作量也集中于微服务单元之间的接口开发和逻辑处理。因此在对一个微服务系统进行功能点计数时，可将每个微服务单元划分为小的边界识别相应的事物功能，数据功能不在识别。因为在一个系统边界内相同的逻辑文件有且仅有一个。

　　微服务架构系统评估方法仅为建议，而非IFPUG 发布的FPA 标准功能点方法中的标准。（北京软件造价评估技术创新联盟）