Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25437 — 软件工程：功能点分析
标准化的软件规模度量方法，用于估算、基准测试和生产力衡量
ISO/IEC 25437标准化了功能点分析（Function Point Analysis, FPA），这是一种从用户角度衡量软件系统功能规模的方法。与衡量实现规模且依赖于编程语言的代码行数（LOC）不同，功能点量化的是所交付的功能——使其可以在项目、语言和开发范式之间进行比较。该标准与IFPUG（国际功能点用户组）计数实践手册保持一致。
功能点计数在组织内进行历史追踪时最有价值。单次计数提供信息；10-20个项目的趋势则具有预测能力。投入资源建立组织的功能点计数和相应工作量的历史数据库。
五种功能类型
ISO/IEC 25437定义了构成应用功能规模的五种功能类型。这些类型分为数据功能（内部和外部）和事务功能（输入、输出和查询）：
| 功能类型 | 缩写 | 描述 | 典型示例 |
|---|---|---|---|
| 内部逻辑文件 | ILF | 应用边界内维护的数据 | 客户数据库、产品目录、订单历史 |
| 外部接口文件 | EIF | 从其他应用引用的数据 | 参考税率表、地址验证服务 |
| 外部输入 | EI | 进入系统边界的数据 | 表单提交、传感器读数、API调用 |
| 外部输出 | EO | 离开系统边界的派生数据 | 含计算的报表、发票、仪表盘 |
| 外部查询 | EQ | 不含派生逻辑的数据检索 | 搜索结果、记录查询、状态检查 |
每种功能类型根据数据元素类型（DET）和记录元素类型（RET）的数量（对于数据功能）或引用的文件类型（FTR）和DET的数量（对于事务功能），被分配一个复杂度等级——低、平均或高。复杂度矩阵将原始计数转换为未调整功能点（UFP）。
ILF/EIF的区分对于准确度量至关重要。一个常见的计数错误是将内部参考数据（例如货币兑换表）归类为ILF，而实际上它由其他应用维护、仅被引用——这通过重复计算高估了被度量应用的功能规模。
价值调整因子与生产力基准测试
未调整功能点乘以由14个通用系统特征（GSC）计算的价值调整因子（VAF），每个特征评分为0-5。GSC包括数据通信、分布式数据处理、性能、高配置、事务率、在线数据输入、最终用户效率、在线更新、复杂处理、可复用性、安装便捷性、操作便捷性、多站点和便于变更。
VAF调整原始功能规模以反映实现环境的技术复杂度。然而，ISO/IEC 25437警告说VAF引入了主观性——不同的计数员可能对同一项目分配不同的GSC评分。许多组织现在倾向于使用未调整功能点进行基准测试，而将VAF保留用于内部估算校准。
生产力基准测试是FPA最强大的应用之一。通过将实际项目工作量（人时）除以交付的功能点，组织得出跨项目可比较的生产率（小时/FP）。行业基准差异很大：典型业务应用范围为2-10小时/FP，而实时嵌入式系统由于额外的验证和认证要求可能超过20小时/FP。
不要将功能点用于个别开发者的绩效评估。FPA在应用层面衡量功能规模，而非个人产出。使用FP/人作为绩效指标会鼓励计数膨胀并损害组织基准的可靠性。
FPA采纳的工程见解
成功采纳ISO/IEC 25437需要关注三个领域：计数员培训、计数范围纪律和工具支持。
计数员培训：认证功能点计数需要结构化的学习计划。IFPUG认证功能点专家（CFPS）认证是行业标准。团队应至少有一名CFPS认证成员，可以进行独立的计数审计和解决边界争议。计数员之间的计数一致性至关重要：计数员间差异超过10%表明培训不足或计数指南不明确。
计数范围纪律：在开始计数之前必须建立计数范围文档。该文档定义了应用边界，识别每个功能类型实例，并记录计数假设。计数范围的版本控制至关重要，因为开发期间的需求变更直接影响功能点计数。
工具支持：专业的FPA工具（如CAST、Understand或集成ALM平台）可以从需求规格或设计模型中部分自动化功能点检测。完全自动化仍然具有挑战性，因为FPA需要理解用户意图的功能，这在任何单一制品中都没有完全捕获。半自动化方法——工具识别候选功能，人工计数员验证——提供了速度和准确性的最佳平衡。
当需求发生变化时，必须调整功能点计数。如果范围蔓延在项目中期增加了三个新的外部输入和一个内部逻辑文件，则必须重新计算功能点计数。未能更新计数会破坏生产力度量，并使项目后比较变得毫无意义。
常见问题解答 (FAQ)
问1：功能点分析和用例点有什么区别？
功能点基于数据和事务功能衡量已交付软件的功能规模。相比之下，用例点衡量以用例表示的需求规模，并包含技术和环境复杂度因子。FPA具有更广泛的行业采纳和更丰富的基准数据库。
功能点基于数据和事务功能衡量已交付软件的功能规模。相比之下，用例点衡量以用例表示的需求规模，并包含技术和环境复杂度因子。FPA具有更广泛的行业采纳和更丰富的基准数据库。
问2：功能点可以用于敏捷开发吗？
可以。对于敏捷项目，可以从用户故事或特性中计数功能点。关键的调整是初始计数通常较为粗略（从史诗级描述估算ILF和EI），并在迭代规划期间随着故事分解而逐步细化。许多组织使用功能点进行发布级规模度量，使用故事点进行迭代级估算。
可以。对于敏捷项目，可以从用户故事或特性中计数功能点。关键的调整是初始计数通常较为粗略（从史诗级描述估算ILF和EI），并在迭代规划期间随着故事分解而逐步细化。许多组织使用功能点进行发布级规模度量，使用故事点进行迭代级估算。
问3：如何在我的组织中开始收集功能点数据？
从一个试点项目开始。培训2-3名团队成员进行FPA计数，完成试点的完整计数，并捕获工作量数据。试点后，使用试点数据校准组织的生产率（小时/FP）。然后扩展到5-10个项目，之后再将FPA用于新项目的估算。
从一个试点项目开始。培训2-3名团队成员进行FPA计数，完成试点的完整计数，并捕获工作量数据。试点后，使用试点数据校准组织的生产率（小时/FP）。然后扩展到5-10个项目，之后再将FPA用于新项目的估算。
问4：功能点分析的局限性是什么？
FPA不直接衡量算法复杂度、非功能性需求（性能、安全性、可用性）或技术难度。它仅衡量功能规模。对于以算法为主的系统（如科学计算、加密），FPA可能低估真实的开发工作量，应辅以其他规模度量方法。
FPA不直接衡量算法复杂度、非功能性需求（性能、安全性、可用性）或技术难度。它仅衡量功能规模。对于以算法为主的系统（如科学计算、加密），FPA可能低估真实的开发工作量，应辅以其他规模度量方法。
