01 行业应用现状功能点分析Function Point Analysis, FPA自20世纪70年代末由Allan J. Albrecht提出以来已发展成为国际上主流的软件规模度量方法。如今IFPUG 方法纳入 ISO/IEC 20926 国际标准国内在2023 年也发布了多项软件功能规模测量系列国家标准GB/T 42449-2023《系统与软件工程 功能规模测量 IFPUG方法》、GB/T 42452-2023《系统与软件工程 功能规模测量 COSMIC方法》、GB/T 42448-2023《系统与软件工程 功能规模测量 FiSMA1.1方法》、GB/T 42566-2023《系统与软件工程 功能规模测量 MkⅡ功能点分析方法》以及GB/T 42588-2023《系统与软件工程 功能规模测量 NESMA方法》。相关标准解读《系统与软件工程功能规模测量IFPUG方法》GB/T42449-2023标准解读《系统与软件工程 功能规模测量 NESMA方法》GBT 42588-2023标准解读然而在实际应用中功能点计数“漏数、多数、错数”的问题频发。其中一个不可忽视的原因是习惯于从“系统设计的技术开发视角”出发考虑功能点而忽略了功能点方法最根本的起点——用户视角。以下是几类典型的错误错误一把“技术实现”当成“用户功能”业务场景某系统的文件管理模块中用户可通过“上传文件”功能上传各类文档。后台根据文件类型图片、文档、视频分别设计了独立的上传接口和存储路径每种类型对应不同的处理逻辑技术视角错误计数从技术实现出发认为系统有3种文件类型每种类型都有独立的上传接口、存储路径和处理逻辑因此识别为3个EI。基于用户视角合规判定从用户视角来看“上传文件”是一个完整的业务操作用户并不感知后台按图片、文档还是视频做了接口拆分。用户的操作只有选择文件、点击上传不同文件类型在用户视角下属于同一基本过程而非3个独立的基本过程。错误二把“页面跳转”当成“业务功能”业务场景某系统的客服模块中为了提升用户体验将办理的各项入口集成到客服界面中。用户在咨询相关服务时可以通过客服界面直接点击“办理入口”按钮跳转到对应的服务办理页面无需在平台上反复查找。技术视角错误计数看到系统中新增了一个“接入办理入口”功能认为这是一个用户可操作的功能点且需要开发接口、配置跳转链接于是将其计为1个EI。基于用户视角合规判定用户点击“接入办理入口”后系统执行的操作是页面跳转/导航——将用户从客服界面切换到服务办理页面。用户在此过程中没有向系统输入业务数据、没有触发数据状态变更、没有收到系统输出的业务信息。此类导航/跳转类功能不应作为独立的功能点计入。错误三把“物理表”直接等同于“逻辑文件”业务场景某系统的用户管理模块中数据库设计包含多张与用户相关的表用户基本信息表、用户权限表、用户偏好设置表、用户登录日志表。计数人员在识别ILF时逐一核对了这些物理表。技术视角错误计数打开数据库设计文档看到4张与用户相关的物理表认为每张表都存储了系统需要维护的数据于是识别为4个ILF。基于用户视角合规判定用户知道“我的个人信息”包含姓名、联系方式、权限等但用户不需要知道这些数据在数据库中分几张表存储——那是物理设计层面的考量用户不关心也不应影响功能点计数。错误四混淆EO与EQ业务场景某系统的统计分析模块中提供一份“月度销售统计报表”该报表需要从订单表中汇总当月销售总额、订单数量、各类商品销售占比、环比增长率等数据并以图表和表格形式展示给用户。技术视角错误计数看到这是一个“查询并展示”的功能页面有一个“查看报表”按钮认为系统只是从数据库中读取数据并展示因此计为1个EQ。基于用户视角合规判定用户需要的是“一份经过汇总计算的月度销售统计报表”而不是“查看订单列表”。系统在生成此报表时需要执行加工处理凡是包含加工处理或计算逻辑的数据输出应计为EO。02 不同规模度量方法的视角差异各类度量方法从不同视角出发均有自身适配场景而功能点方法是以“用户视角”为核心判定逻辑拥有统一、可对外评审、跨项目可比的标准化计数体系。功能点方法的创立其初衷之一是让项目组和客户可以使用同一方法定义功能需求实践证明理解客户需求最好的办法是站在客户的角度分析软件系统产生的结果。落地用户视角开展功能点测算时可借助AI 智能造价工具——软件造价喵支持用户上传可研方案或设计文档系统智能识别项目功能点生成报告一站式完成软件规模自动测算。03 用户视角的核心原则原则一逻辑视图而非物理视图计数应优先参考业务需求、产品原型所呈现的逻辑业务结构而非数据库物理表结构、API接口拆分或分布式部署等技术实现方案。原则二边界由用户定义而非由技术划分界定计数边界时以用户完整业务领域用户管理、客服管理、养老服务等划分范围不以前端、后端、微服务模块切割边界若外部系统与本系统存在用户可感知的数据交互需单独识别EIF不能单纯按技术服务隔离边界。原则三“用户可识别”作为功能的过滤条件无论数据功能还是事务功能第一步判断普通业务使用者能否理解、访问、维护该组数据或操作后台缓存、日志、临时中转数据用户无访问权限一般不计ILF/EIF若日志支持用户查询导出可单独统计。了解更多数据功能识别要点功能点识别控制要点—数据功能原则四事务功能判定标尺是用户完整交互行为区分EI/EQ/EO仅围绕三类用户行为判断用户向系统新增/变更数据为EI用户主动读取原始数据浏览为EQ系统自动运算、主动输出业务成果为EO同一页面内多类操作若具备独立业务闭环可分别计数不强制合并。了解更多事务功能识别要点功能点识别控制要点—事务功能04 识别过程中分步贯彻用户视角原则在完整的功能点识别工作中整体流程分为边界划定、数据功能识别、事务功能识别、复核校验四大阶段每个阶段针对性落地对应用户视角判定原则各阶段环环相扣。按用户业务域划定系统边界功能点识别应以功能用户需求为识别依据而非直接从数据库设计文档、系统架构图、接口清单等技术产物出发。需求规格说明书、产品原型、用户故事、业务流程图才是有效输入。技术文档用于理解实现方式而非计数。判断标准这个功能是用户提出来的还是开发人员为方便实现而增加的用“用户可识别”过滤数据功能识别数据功能时可以逐一用三问验证用户能识别这组数据吗逻辑上是一个整体吗数据由本系统维护还是外部引用不符合任一条件则不应该作为ILF/EIF计入。以用户操作行为判定事务功能识别事务功能时可以遍历用户操作路径图每个操作节点用三问判断归属用户往系统里“放”了什么输入数据/指令用户从系统里“拿”到了什么系统输出加工计算后的信息用户从系统里“看”到了什么系统检索展示已有数据用“业务语言测试”验证结果对每个功能点逐条核对排查按表、接口过度拆分问题清理边界内技术模块剔除日志、缓存误计项修正EI/EQ/EO 错判不合规项重新调整。用业务语言描述功能点能否说清“用户做什么”。05 结语功能点方法发展至今已超过四十年IFPUG 计数实践手册持续迭代更新ISO/IEC 2092 国际标准历经版本演进国家标准也已正式落地实施。各版本仅细化细分场景计数细则核心底层逻辑保持统一——功能点方法是从用户视角出发对软件规模从功能需求的角度进行度量的标准方法。用户视角是功能点方法的根本立足点也是其区别于其他度量方法的核心特征。