软件系统工作量估算方法论介绍——功能点分析法
背景
众所周知，软件系统的复杂性是相当高的，以下几个场景是比较常见的：
1.作为软件公司，要研发一个新的产品，功能需求大概明确了，需要确定下研发成本、资源需求等。
2.作为企业，实施软件系统，需要与软件厂商商谈具体的工期与费用等。
3.作为软件公司或企业的管理方，需要对多个软件系统进行横向对比、衡量与评价等。
以上几个问题，实际都指向一个核心问题，即如何客观估算与衡量一个软件系统的规模。只有具备了软件规模的基本数据，与之相关的工作量(人天）、工期、报价、项目成本才能计算。
概述
目前评估软件规模的方法主要分为两种：基于技术视角和基于业务视角。
基于技术视角的方法是从开发者角度出发，如：基于软件源代码行、数据库表、函数数量等。
基于业务视角的方法是从用户角度出发，与软件开发技术无关，如：功能点、故事点、用例点、对象点等。
基于技术视角的评估方法更多地局限于软件开发团队内部，由经验丰富的技术人员估算，经常也被称之为专家估算法。这种估算法标准很难量化和达成一致，不同的人，估算出来的结果可能差异很大，局限性比较大。
如果要在业务部门与开发部门、企业与软件厂商等外部组织商定软件开发的工期或费用等关键项目目标，客观上需要从业务视角出发，对软件项目规模进行衡量、一致的评价与估算。而且，在系统初始阶段，用户功能需求是唯一真正可以得到的信息。
基于业务视角来评估软件规模，国际上有一套方法论，称之为功能点分析法。该方法论内容不少，本篇对该方法论做一下大概介绍，点到即止，如感兴趣建议自行深入了解。
简介
功能点分析法度量的是软件的规模，主要从逻辑设计的角度出发对提供给客户的功能进行量化。
功能点分析方法的主要目标是度量用户要求和能够接收到的功能，并提供一种与具体实施方法和技术无关的、对软件开发和维护进行度量的手段。
此外，功能点分析方法还是一种相对来说比较简单的对规模进行度量的手段；在不同的项目和组织之间能够保持一致的度量方法；基于数据流，使用行业标准数据，是比较客观的估算，容易得到认同。
功能点分析法，实际不只一种，用的比较多的是国际功能点用户组（IFPUG）的标准功能点分析法，这种方法相对复杂一些。荷兰软件度量协会（NESMA）提供了两种简化后的方法：快速功能点分析法和初步功能点分析法。这三种方法往往结合使用，用在不同的项目阶段。需求分析阶段，使用快速功能点分析法；系统设计阶段，使用初步功能点分析法；系统实施阶段，使用标准功能点分析法。
基本概念
功能点分析法将软件的功能分为五个基本要素：
内部逻辑文件（Internal Logical Files，简称内部文件ILF）
外部接口文件(External Interface Files，简称外部文件EIF)
外部输入(External InPuts，EI)
外部输出(External Outputs，EO)
外部查询(External Inquiries，EQ)
以上描述从字面上不太好理解，用大白话来说，业务实体是内部逻辑文件（ILF），外部系统接口是外部接口文件（EIF），对业务实体的新增、删除、修改是外部输入（EI），对业务实体的查询是外部查询（EQ），对外提供接口或报表，是外部输出（EO）。
内部逻辑文件（ILF）和外部接口文件（EIF）是静态的数据；外部输入（EI）、外部输出（EO）和外部查询（EQ）是运动中的数据。
以下是具体的识别要素，供参考。
内部逻辑文件（ILF）
- ILF 指在待开发系统内部逻辑上的、用户可识别的一组数据
- 对单个ILF 一般执行6 种左右的操作，且一定包含写操作
- 数据集合必须是逻辑相关的并且是用户可以识别的
- 数据或者控制信息必须是在本应用的边界内被维护
外部接口文件（EIF）
- 这一组数据或者控制信息必须是在本应用内被引用，但并非是在本应用边界范围之内的
- 这一组数据或者控制信息的维护工作不是在本应用内进行的
- 这一组数据或者控制信息是另一个应用的ILF
外部输入（EI）
- 是获得数据的过程，对终端用户的输入进行相关的处理
- 对内部数据的增/删/改均为EI
- 从外部接口中读取并存储到内部数据中
- 接受某个控制信号并使软件状态改变
外部输出（EO）
- 输送数据到应用程序边界外部的过程
- 处理过程必须包含至少一个数学公式或计算方法，或生成派生数据
- 对内部数据的复杂报表（含计算内容）/统计分析等
- 一个EO也可以维护一个或多个ILF，并/或改变系统行为
外部查询（EQ）
- 向应用程序边界外发送数据基本处理的过程
- 从ILF或EIF中通过恢复数据信息来向用户呈现
- 该处理逻辑不包括任何数学公式或计算方法（但可以分组或排序），也不会生成任何派生数据
- EQ不会维护任何一个ILF，也不会改变应用程序的系统行为
计算方法
快速功能点法（2点法）
根据立项前期的需求分析及可研报告内容，确定计算范围、划定应用程序的边界；对项目中涉及到的内部文件（ILF）、外部文件（EIF）的数量进行评估；对ILF和EIF分别与一个权重因子相乘，计算出功能点数。
FP = ∑(35 * ILF + 15 * EIF)
即1个业务实体算35个功能点，1个外部数据接口算15个功能点，累加求和即可，非常简单，因为是粗略估算，误差也可能比较大。
初步功能点法（5点法）
设计阶段的软件开发工作量估算可采用初步功能点法，依据确定的内部文件（ILF）、外部文件（EIF）、用户输入（EI）、用户输出（EO）、用户查询（EQ）的个数来计算。
•FP = ∑(15 * ILF + 10 * EIF + 4 * EI + 5 * EO + 4 * EQ)
纳入了五要素，给予了不同的权重，比快速功能点法的进了一步，评估工作量变大，评估结果通常更准确一些。
标准功能点法
相比前面两种方法，标准功能点法引入了更多的控制因子来处理差异性，进行更细颗粒度的衡量，以求更准确的衡量和评估。
首先，不同业务实体的属性数量是有差异的，一个8个属性的实体，和一个35个属性的实体，直观上就可以判断出来开发工作量是有差异的。针对这种情况，标准功能点引入了功能复杂度来计算加权因子。功能复杂度按照高(H) 、平均(A) 或低(L)进行划分。功能复杂度高、中、低分别对应不同的功能单元加权因子取值，也就是功能点个数值。
| 功能单元类型 | 功能复杂度 | ||
|---|---|---|---|
| 低（L） | 平均（A） | 高（H） | |
| 内部逻辑文件(ILF) | 7 | 10 | 15 |
| 外部接口文件(EIF) | 5 | 7 | 10 |
| 外部输入(EI) | 3 | 4 | 6 |
| 外部输出(EO) | 4 | 5 | 7 |
| 外部查询(EQ) | 3 | 4 | 6 |
上表中的中位值，实际就对应着初步功能点估算法的权重值FP = ∑(15 * ILF + 10 * EIF + 4 * EI + 5 * EO + 4 * EQ)，所以初步功能点法就是放大了评估的粒度，降低估算的工作量。
至于如何具体评估某一个功能的功能复杂度，应该是低、中还是高，标准功能点法同样提供了一个参考标准，引入了DET（可简单理解为字段数量）和RET（可简单理解为表数量），以下是示例，不做详细展开。
其次，不同的需求，对系统要求是有差异的，例如有的系统对性能要求很高，有的系统对易用性有一定要求，这些因素同样会影响到系统实现的难度。标准功能点法，通过调整因子来处理差异性。
标准功能点法抽象出14个通用系统特性，具体如下：
- 数据通信：描述软件直接同处理器进行通信的程度；
- 分布式数据处理：描述软件的各部件间数据传输的程度；
- 性能：描述响应时间和数据吞吐量对软件研制的影响程度；
- 系统配置要求：描述计算机资源约束对软件研制的影响程度；
- 事务率：描述事务处理率对软件研制的影响程度；
- 在线数据输入：描述通过交互处理输入数据的程度；
- 最终用户效率：描述对各种人为因素和最终用户易用性的考虑程度；
- 在线更新： 描述内部逻辑文件被在线更新的程度；
- 复杂处理：描述，处理逻辑对软件研制的影响程度；
- 可重用性：描述经过专门设计、开发和支持的软件，可在其他软件中重用的程度；
- 易安装性：描述软件在不同环境下转换和安装操作的简便程度；
- 易操作性：描述软件在操作方面的满足程度，如:启动、备份和恢复过程；
- 多工作场所：描述软件用于多个用户组织、多种场所的程度；
- 易变更性：描述软件的数据结构和处理逻辑易于修改的程度；
每一个特性都有一些规则来进行评分，以判断该特性对这个应用的影响程度。评分的范围是从0到5，分别代表没有影响到影响很大。
以性能参数为例：
| 描述 | 分数 |
|---|---|
| 用户没有提出性能方面的要求 | 0 |
| 用户提出了性能和设计方面的要求，但不需要采取特定措施 | 1 |
| 响应时间和吞吐量在系统峰值时是关键的，但是不需要采取相应的CPU 使用方面的特殊设计。处理的最后期限是在下一个工作日。 | 2 |
| 在任何时候响应时间和吞吐量都是关键的，但是不需要采取相应的CPU 使用方面的特殊设计。处理的完成期限比较严格 | 3 |
| 除了上面一项的要求外，由于对需求的要求比较严格，在设计阶段就要进行性能分析 | 4 |
| 除了上面一项的要求之外，在设计和实施阶段需要使用性能分析工具来判断性能要求的完成情况 | 5 |
标准功能点法，评估每一个通用系统特性，并且为它们确定影响程度（Degree of influence - DI），然后将所有通用系统特性的DI 相加，得到整体影响程度（Total Degree of Influence - TDI），最后代入公式VAF（调整因子）=0.65+0.01×TDI。
通过公式可以得知，该系数会在正负35%的幅度上调整功能点数。
假设未经过调整因子计算前的功能点数是100，走两个极端情况，14个通用系统属性，打分都是0或者都是5，则调整后的功能点数，分别为65和135，即项目规模可能相差1倍。
延伸计算
如开篇所说，我们最终的关注点，往往不是项目规模，而是工作量、成本、工期等，而项目规模是其计算基础。现在，我们通过功能点法得到了功能点数量，怎么来进行后续计算呢？这里仅以工作量为例，其他计算类似，不再赘述。
只要稍微深入思考下，我们再拿到每个功能点需要花费的工时，则二者相乘就能算出来，该软件系统需要多少工时。每个功能点需要花费的工时，数据从哪里来呢？如果是软件公司，在长期践行功能点法这套方法论，那么通常会有公司自己的经验数据来支撑。如果是没有积累的软件公司，或者企业与软件厂商之间商谈软件系统实施工作量时，这时候就需要一个相对客观权威的数据做为计算依据。这里推荐《中国软件行业基准数据报告》，最新一版是2022年9月1日发布，下图是统计结果。
该报告同时提供了可以进行延伸计算的多项基础数据，如分行业生产率、维护型生产率、缺陷密度（缺陷数/功能点）、工作量分布（需求、设计、构建、测试、实施占比）、部分城市人员费率、功能点单价等。
优缺点
前面说了功能点分析法的不少优点，最后总结下，同时，也提一下其缺点。
优点
基于定义良好的计算标准。
基于客户视角，容易理解和接受。
可应用于新项目，升级项目和维护项目。
与技术和计算机语言无关。
简单，易于计算，只需花费较少的工作量。
一致的规模度量尺度。可用来比较不同组织和技术之间的比较。
缺点
只考虑可见部分的复杂度，对系统内部复杂性考虑太少。
功能复杂度三级划分比较粗，对一些比较复杂的功能，统计误差较大。
总结
功能点分析法是一套优秀的评估项目规模的方法论，特别是从业务视角出发，与技术，特别是开发语言无关。基于该方法论评估软件规模，如果软件厂商有自己的成熟的开发平台，能大幅提升开发效率，或有成熟产品进行二次开发定制，则能大幅降低自己的成本，在市场竞争占据优势。