《系统与软件工程 功能规模测量 NESMA方法》（GBT 42588-2023）标准解读

GB/T 42588-2023《系统与软件工程 功能规模测量 NESMA方法》于2023年5月23日发布、2023年12月1日正式实施，是修改采用ISO/IEC 24570:2018《软件工程 NESMA功能规模测量方法 功能点分析应用的定义和计数指南》的国家标准。该标准旨在提供一套统一、规范的功能点分析（FPA）方法，用于测量应用软件的功能规模，独立于技术实现方式，可支持软件项目预算编制、生产率评估、需求范围管控等核心场景。

一、FPA总则和总体要求

（一）FPA核心定义与目标

FPA通过分析应用程序或其规格说明，以“功能点”为单位确定功能规模，该单位独立于技术实现，仅反映用户视角的信息处理量。其核心目标分为两类：一是确定应用程序功能规模，即测量应用程序已提供或将要提供的全部功能点总数；二是确定项目功能规模，即测量新开发或增强项目中新增、更改、删除功能的功能点总数，为项目工作量评估和工期测算提供关键依据。

（二）FPA分析类型与项目阶段适配

基于功能规格说明的详细程度，FPA分为三类，适配项目不同阶段需求：

同时，按项目开发阶段，FPA可分为初期（项目启动时，用于预算编制）、中期（项目变更时，评估对成本和工期的影响）、末期（项目结束时，确定最终规模与生产率）三类。

（三）功能类型与复杂度

1、功能类型分类

FPA将应用程序功能分为两类、五种组件，是规模测量的核心单元：

2、复杂度分级与功能点赋值

功能复杂度按“低、中、高”三级划分，依据DET数量（数据详细程度）和FTR/RET数量（关联文件/记录数量）确定，最终按下表分配功能点：

二、FPA操作准则

操作准则明确了FPA的实施流程、各类分析的具体要求，以及应用程序/项目功能规模的计算方法，是实际执行的“操作手册”。

（一）FPA实施七步骤

1、收集文档：根据分析类型准备材料（预估需概念数据模型，详细需完整数据模型+屏幕/报表规格）；

2、确定用户：识别最终用户、需求确认方、关联应用程序（FPA需用户参与验证）；

3、明确分析对象：判断是“应用程序FPA”还是“项目FPA”；

4、梳理数据交互：确定应用程序与其他应用的数据流（输入/使用的数据来源）；

5、识别功能与计算规模：判定功能类型、复杂度，按表1计算功能点，记录假设与约束；

6、用户确认：与用户核对功能识别准确性，修正偏差；

7、专家校验：与FPA专家复核结果，最终确认。

（二）功能点分析

根据功能规格说明的详细程度，FPA分为三类，适用于软件生命周期不同阶段，精度与适用场景差异显著：

（三）项目中的FPA

FPA需贯穿项目开发全流程，根据项目阶段分为三类，分别服务于预算编制、变更管控与成果结算：

（四）应用程序功能规模计算

应用程序功能规模反映其向用户提供的总功能量，需区分“新应用程序”“增强型应用程序”“重建应用程序”三类场景：

1、新应用程序：

（1）若单项目实现，计数步骤与项目功能规模一致；

（2）若多子项目并行，需汇总所有子项目功能点，避免重复计数（如跨子项目的ILF仅计1次）；

（3）转换软件（如数据迁移工具）不计入应用程序规模，仅算项目规模。

2、增强型应用程序：

增强型应用指新增、更改或删除功能的应用，规模计算需采用“基准+增量”公式：

AFPA=AFPB+ADD−DEL+(CHGA−CHGB)

其中：

AFPA：增强后应用程序功能规模；

AFPB：增强前应用程序功能点数；

ADD：新增功能的功能点数；

DEL：删除功能的功能点数；

CHGA：更改后功能的功能点数；

CHGB：更改前功能的功能点数。

3、重建应用程序：

（1）若功能完全一致，新应用规模=旧应用规模；

（2）若含增强，可按“新应用程序”或“增强型应用程序”计数。

（五）项目功能规模计算

项目功能规模反映开发/增强过程中投入的功能工作量，需区分“开发项目”与“增强项目”：

1、开发项目（全新应用或重构）：

步骤：①计算子系统功能点；②计算数据转换工具的功能点（一次性工具，不计入应用程序规模）；③计算关联应用的变更功能点；④三者求和即为项目规模。

2、增强项目（现有应用功能变更）：

需按公式计算：

EFP=ADD+DEL+CHGA

其中：EFP（项目功能点），若需开发转换软件，需追加其功能点；既有ILF/ELF若未变更，不计入项目规模。

3、应用程序切换项目（替换旧应用）：

按开发项目规则计数，需包含新应用开发、数据迁移等全流程功能点。

（六）特定情况下的FPA

针对套装软件、屏幕分析、原型设计等特殊场景，标准给出专项计数规则：

1、套装软件分析：

核心是区分“用户所需功能”与“套装软件提供的功能”，需确认三点：

（1）套装软件提供的用户所需功能及功能点；

（2）套装软件缺失的用户所需功能及功能点（需后续增强）；

套装软件提供的非用户所需功能及功能点（不计入用户需求规模）；

（3）分析目标可包括：性价比（每功能点成本）、所需功能覆盖率（提供/总所需）、功能利用率（所需/提供总功能）。

2、屏幕/窗口分析（规格缺失时）：

通过应用程序物理组件（屏幕、菜单）推断功能，需注意：

（1）避免重复计数；

（2）连续不可分割的屏幕视为1个事务功能；

（3）EQ需显式引用（如菜单中存在“查询”选项）才计数，数据编辑前的预览不计为EQ；

（4）事务/数据功能复杂度默认“事务中、数据低”。

3、原型设计分析：

（1）若原型用于确定功能规格（需求不确定），仅可进行预估FPA，需编制规格后再精确计数；

（2）若原型仅用于UI设计（功能规格明确），可直接适用FPA通用准则。

（七）FPA与应用程序生存周期的结合

FPA需贯穿项目全生命周期，不同阶段采用不同分析类型，且需关注“自主增长”：

三、FPA通用准则

FPA通用准则是计数的“通用规则库”，覆盖核心原则、特殊场景处理、计数边界，确保不同人员执行FPA时结果一致。

（一）核心原则

1、逻辑视角优先：

仅从用户业务逻辑判断功能，不考虑技术实现（如编程语言、硬件、数据库类型），技术选型不影响功能点数量。例如：“客户信息存储”无论用MySQL还是Oracle，均按ILF计数，复杂度判定仅看DET/RET。

2、不重复计数：

（1）同一功能（如“修改客户信息”）无论被多少用户使用、出现在多少位置，仅计1次；

（2）同一逻辑文件（如“客户信息”）在一个应用程序中仅计为ILF或ELF，不可同时计数；

（3）跨应用程序共享数据时，按数据维护方判定类型（如A维护→A的ILF，B使用→B的ELF）。

3、用户需求为核心：

（1）仅计数用户需求的功能（初始定义+后期变更请求），非用户需求的功能（如技术优化、复用代码、后台临时文件）不计入“用户需求规模”，仅可计入“应用程序提供规模”；

（2）判断某功能是否计入，可询问“用户是否愿意为该功能付费”。

（二）FPA表的特殊计数

FPA表是含常量、解码、固定规则的实体类型（如国家代码表、税率表），需统一计数，避免分散统计：

1、FPA表判定条件：

（1）仅含1个数据项（如组织名称+地址）；

（2）数据均为常量（如化学元素表：原子序号、符号）；

（3）由键值+解释性描述组成（如国家代码：CN-中国）；

（4）含边界值/算法（如电话号码范围：编号、最小/最大号）。

2、非FPA表情形：

（1）含非常量数据（如动态税率表）；

（2）含多种不同类型数据（如买方信息：编号、姓名、地区名）。

3、计数规则：

（1）本应用维护的FPA表：合计为1个ILF，默认1个EI、1个EO、1个EQ；

（2）其他应用维护的FPA表：合计为1个ELF，无需额外计数事务功能；

（3）复杂度按“记录类型（FPA表数量）+DET（总数据元素）”判定。

（三）数据共享场景的功能判定

当应用程序间共享数据时，需按以下规则判定逻辑文件类型（以A、B为两个应用为例）：

（四）常见组件的计数规则

1、帮助功能：

（1）每种帮助类型（如应用帮助、屏幕帮助、字段帮助）计1个EQ；

（2）同一帮助功能（如全局帮助）跨多屏幕仅计1个EQ；

（3）帮助文本可维护→存储文件视为FPA表ILF；

（4）复杂度：详细FPA“低”、估算FPA“中”。

2、消息：

（1）系统消息（如操作系统提示）不计；

（2）功能消息（如错误提示）：关联EI/EO/EQ时计1个DET，通用消息（如日志报告）计1个EO。

3、菜单结构：

（1）菜单本身不计，但事务功能的启动触发（如菜单选择）计1个DET；

（2）用户可维护菜单结构→按ILF（存储菜单数据）+EI（维护）计数。

4、列表功能：

（1）显示用户可选列表（数据来自ILF/ELF，非FPA表）→计为EO（列表规模未知）；

（2）列表数据来自FPA表→不计为独立功能。

5、信息安全与授权：

（1）标准功能（如通用登录、角色权限）不计；

（2）定制化安全功能（如专属数据权限控制）→按EI/ILF计数。

6、工具与组件：

（1）开发环境标准工具（如通用报表生成器）不计；

（2）用户要求的定制工具（如专属查询工具）→按EI/EO/EQ/ILF计数；

（3）操作系统更改（如适配硬件）不计，不增加用户功能。

（五）DET计数通用规则

DET（数据元素类型）是功能复杂度判定的核心依据，需明确“计与不计”的边界：

1、需计数的DET：

（1）跨越应用程序边界的可编辑字段（如客户姓名输入框）；

（2）逻辑文件/FPA表中显示的字段（如客户身份证号）；

（3）启动触发（如菜单选择、功能键，计1个DET，与步骤无关）；

（4）功能消息（如错误提示，所有消息计1个DET）；

（5）输入选择数据（如下拉列表选项）、衍生数据（如计算出的合计金额）；

（6）其他控制数据（如选择打印机、文件名）。

2、不计数的DET：

（1）导航元素（如翻页键、滚动条）；

（2）格式元素（如标题栏、表头、字段标签、页码）；

（3）系统自动生成数据（如系统日期、时间戳、内部更新字段）。

（六）功能点分析的完整性检查

为避免功能漏计，需按以下规则校验：

1、ILF完整性：每个ILF至少对应1个EI（维护）+1个EO/EQ（使用）；若缺失，需与用户确认是否遗漏功能（如仅维护不使用的ILF可能为技术文件，不计入）。

2、ELF完整性：每个ELF至少对应1个EO/EQ（使用）；若仅用于EI的数据验证（无EO/EQ），需确认其必要性（如仅验证客户ID的ELF仍需计数）。

3、事务功能完整性：每个EI需维护至少1个ILF，每个EO/EQ需引用至少1个ILF/ELF；若不满足，需检查功能定义是否准确（如无引用文件的EI可能为技术功能，不计入）。

四、五大组件

内部逻辑文件（ILF）、外部逻辑文件（ELF）、外部输入（EI）、外部输出（EO）、外部查询（EQ）是构成功能规模测量的五大核心基本功能组件，其中ILF与ELF归为“数据功能类型”，EI、EO、EQ归为“事务功能类型”，二者共同构成应用程序功能规模的测量基础。

需特别说明的是，“外部接口文件”这一概念在不同FPA方法中的术语表述与定义细节存在差异：在IFPUG方法中，此类“被待分析应用使用但不维护的外部数据组”被称为“外部接口文件（EIF）”；而在本标准采用的NESMA方法中，统一称为“外部逻辑文件（ELF）”。具体对比分析详见：软件造价之外部接口文件是EIF还是ELF？此处仅聚焦NESMA方法下ELF的核心规则。