Albrecht 功能点方法

功能点分析 (Albrecht/IFPUG)

功能点分析 (Function Point Analysis, FPA) 是一种标准化的方法，用于根据交付给用户的功能来度量软件规模。该方法由 IBM 的 Allan Albrecht 在 20 世纪 70 年代开发，后来由国际功能点用户组 (International Function Point Users Group, IFPUG) 标准化。它从用户的角度，根据逻辑功能来量化软件，与实现所使用的技术无关。其目标是度量软件“做什么”，而不是“如何做”。

IFPUG 功能点已被 ISO/IEC 标准认可（例如 ISO/IEC 20926）。

功能点的核心概念

FPA 基于应用的边界识别并分类了五种基本的功能组件类型：

数据功能 (Data Functions)：

• 内部逻辑文件 (Internal Logical File, ILF)：应用程序边界内部维护的、用户可识别的逻辑相关数据组。示例：由应用程序管理的客户记录文件/表。
• 外部接口文件 (External Interface File, EIF)：由应用程序引用但维护在其边界外部（由另一个应用程序维护）的用户可识别的逻辑相关数据组。示例：引用由单独的金融系统维护的货币汇率表。

事务功能 (Transactional Functions)：

• 外部输入 (External Input, EI)：数据从外部跨越边界进入内部，处理数据以维护一个或多个 ILF 的基本过程。示例：添加新客户的屏幕功能。
• 外部输出 (External Output, EO)：派生数据从内部跨越边界到外部的基本过程。必须涉及超出简单数据检索的业务逻辑。示例：需要基于 ILF 数据进行计算的月度销售汇总报告。
• 外部查询 (External Inquiry, EQ)：具有输入和输出组件的基本过程，从 ILF 或 EIF 检索数据并发送到边界外部。主要目的是数据检索，涉及最少的业务逻辑。示例：查找并显示特定客户详细信息的屏幕功能。

功能点计数步骤 (IFPUG 方法)

1. 确定计数类型：是用于开发（初始构建）、增强（修改）还是应用程序（现有应用程序的总规模）？
2. 识别应用程序边界：清晰定义要度量的应用程序的内部和外部。
3. 计数功能组件：根据用户的视角和 IFPUG 规则，识别并分类所有 ILF、EIF、EI、EO 和 EQ。
4. 确定复杂性级别：根据涉及数据元素类型 (Data Element Types, DETs - 用户可识别的唯一字段) 和记录元素类型 (Record Element Types, RETs - ILF/EIF 内数据的逻辑子组) 或引用文件类型 (File Types Referenced, FTRs - 由事务读或维护的 ILF/EIF) 的特定规则，为每个已识别的组件分配复杂性等级（低、中、高）。IFPUG 为此提供了特定的矩阵。
5. 复杂性矩阵示例（概念性 - 具体规则请参考 IFPUG 手册）：
7. 计算未调整功能点 (Unadjusted Function Points, UFP)：将每种组件类型在每个复杂性级别的计数乘以标准权重因子，然后求和。
9. 确定价值调整因子 (Value Adjustment Factor, VAF)：评估 14 个通用系统特征 (General System Characteristics, GSCs) 对应用程序的影响。每个 GSC（例如，数据通信、性能、可重用性、安全性）按 0（无影响）到 5（强影响）的等级评分。这些评分的总和（影响总度量 Total Degree of Influence, TDI）用于 VAF 公式。
10. 14 个 GSCs 是：数据通信、分布式数据处理、性能、配置利用度、事务率、在线数据录入、终端用户效率、在线更新、复杂处理、可重用性、安装易用性、操作易用性、多站点、便于修改。
11. 计算最终调整功能点 (Adjusted Function Points, FP)：将 VAF 应用于 UFP。公式为：FP = UFP * VAF，其中 VAF = 0.65 + (0.01 * TDI)。

应用和背景

功能点用于：

• 软件规模度量：提供一种独立于技术的大小度量。
• 估算：作为工作量和成本估算模型的输入（尽管通常需要历史数据校准）。
• 生产力度量：计算生产力（例如，每人月的功能点数）。
• 项目跟踪：通过跟踪新增、修改或删除的功能点来监控范围变更。
• 基准测试：比较不同项目或组织的应用规模或项目生产力。

局限性和现代相关性

尽管已标准化，但 FPA 存在局限性：

• 主观性：识别组件和评估复杂性仍然可能涉及判断，需要经过培训的计数师以保持一致性。
• 工作量大：详细计数可能非常耗时，特别是对于大型应用。
• 早期生命周期困难：需要相当详细的功能需求，使其在非常早期的阶段难以准确应用。
• 适用性：可能不太适合非事务性系统（例如，科学计算、实时嵌入式系统）或边界复杂的分布式微服务架构。
• 敏捷背景：在敏捷团队中较少用于短期规划，敏捷团队通常倾向于使用用户故事点 (Story Points) 进行相对规模估算和基于速率 (Velocity) 的预测。然而，FPs 仍可用于高级别的组合估算或需要标准化规模度量的固定价格合同。

尽管存在局限性，但在某些情况下，特别是在大型项目估算、基准测试以及管理需要标准化规模度量的固定价格合同时，FPA 仍然是一种相关的技术。