以下文章来源于信息化与数字化 ，作者陈晓明

来源：信息化与数字化

导读：本文我们就来看看常用的估算方法都有哪些，业界又是怎么来做的呢。

一．工作量评估概述

长期以来，如何度量软件研发成本一直是软件业界的难题，科学、统一的软件研发成本度量标准既是有效进行软件项目管理的重要依据，也是当前软件产业发展的迫切需要。很多软件行业从业人员感叹道，这么高科技的行业，在成本预算的确定性、开发速度和组织效能上，甚至还远远不如看起来很传统的建筑制造行业。一座摩天大楼可能在半年内就可以建好，而一个大型软件开发时间可能要好几年，并且随着时间的变长项目失败率会越高。

缺乏成本度量依据及成本控制，可能在项目生命周期的各个阶段造成影响，如：在预算阶段，会造成预算浪费或预算不足；招投标阶段，可能出现恶意竞标或低价中标；在项目实施阶段，引发项目变更或成本超支。

但在实际情况中，软件工作量评估也面临着各种各样的问题，如：项目范围不确定、没有可以参考的历史项目、项目个性化多、评估结果不断被质疑等等。那么如何在现状基础之上，做好软件规模评估这件事呢？国际著名软件工程专家-Caper Jones曾说过：良好的估算方法和可靠的历史数据提供了最好的希望，现实将战胜不可能的要求。

下面，我们就来看看常用的估算方法都有哪些，业界又是怎么来做的呢。

二．常用评估方法

目前，常用的评估方法包括如下几大类：专家法、类推/类比法、方程法，其中，专家法常用的是WBS拆分法、Delphi法；类推/类比法会基于类似的历史项目或一组基准数据做估算；方程法要基于基准数据建模，并会与行业、企业数据相结合对模型不断调优，同时从功能视角、技术视角将方法划分为两大类。

1. 专家法-WBS拆分法

含义：即项目结构拆分估算法，将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的总工作量。

适用场景：适用于实施阶段，有详细的需求说明书作为依据的项目。

如：（1）项目实施阶段排期、分工；（2）存量项目二期/三期的售前评估。

2. 专家法-Delphi法

含义：由多种相关经验的人共同参与，各人进行估算，然后汇总讨论，最终得出一个综合后的结果；

适用场景：适用于输入的材料不足，需求模糊的模块或项目。

如：（1）售前阶段，一句话需求；（2）新产品类型项目。

3. 类推/类比法

含义：指将本项目的部分属性与高度类似的历史项目或一组基准数据进行比对，进而获得待估算项目工作量、工期或成本估算值的方法。

适用场景：与本项目有类似属性，如：规模、业务领域、应用场景、复杂度、开发团队经验等。

如：与资金方对接、外部系统对接等。

4. 方程法

含义：基于基准数据建模，结合行业数据、企业数据对模型不断迭代优化，最终计算出项目工作量、成本。

适用场景：输入的材料较完整，有详细的需求描述、用例描述等。

如项目实施阶段，有需求说明书、设计文档作为输入材料。

在方程法中，按照功能视角、技术视角进一步划分为两个类别，其中功能视角包括，功能点评估方法（Function Point Analysis，下文简称FPA）、对象点、用例点、故事点等；技术视角包括，代码行、数据库表、函数数量等。在上述方法中，应用最广泛的为功能点FPA。

该方法由Allan J. Albrecht于1970s在IBM提出，主要应用在金融科技领域。在1980s、1990s逐步形成国际标准，广泛应用于金融、电信、政府等领域，并在日本、韩国、荷兰等国使用该方法作为政府软件采购的依据。2000s，国内引入功能点方法，迅速在金融、能源、电信等各领域推广，尤其国内银行业，已普遍采用该方法度量软件规模，如中国银行、中国农业银行、交通银行、国开行、招商银行、平安银行、邮储银行、南京银行、天津银行等。

中国电子技术标准化研究院、北京软件造价评估技术创新联盟和北京软件和信息服务交易所联合发布的《中国软件行业基准数据》文档里也有关于不同行业和地区的软件行业的一些基准数据，有兴趣的同学可以参考下。

中国软件行业基准数据

5. 小结

我们再回顾一下软件评估的常用方法：WBS拆分法、Delphi专家法、类推/类比法、功能点FPA，在这么多方法中，前几个都属于通用类方法，可以应用在各行各业，如：建筑业的造价评估、石油勘探钻井预测等。但只有FPA是专门针对软件造价评估的方法，且考虑其在金融科技领域已经得到广泛应用，所以下面我们具体看一看什么是FPA方法。

三．功能点评估方法FPA

含义：从用户视角出发，对软件的规模从逻辑设计的角度进行度量的标准方法。该方法将系统分为数据功能和事物功能两大类，分别根据具体的规则来计算功能点，最后结合系统的特征因子来调整功能点数，从而得到最终的系统规模。

适用场景：输入的材料较完整，有详细的需求描述。

可能有点抽象，下面我们一点点展开：

1. 什么是功能点

（1）度量单位

功能点是度量软件规模的一种单位，例如生活中我们采用平方米度量房子的面积，用斤或千克来度量体重一样。

（2）用户视角

在评估过程中，它是从用户视角出发，强调用户能感知的业务价值。比如我们在信贷系统、供应链系统中常见的“客户管理”模块，系统操作用户是能切切实实感知到客户信息存在的，用户点击【新增】【查询】按钮，是能感知到信息流变化的。

（3）核心思想

核心思想：一是系统维护的信息；二是系统处理的复杂度。

（4）国际标准

目前已形成5个国际标准，其中在国内应用最广泛的是IFPUG和NESMA：

l IFPUG 国际功能点用户组

lCOSMIC 通用软件度量国际联盟

l Mk II 英国软件度量协会

l NESMA 荷兰软件度量协会

lFiSMA 芬兰软件度量协会

2. FPA概述

下图很好的诠释了FPA的核心思想，中间蓝色框表示我们待评估的系统，其自身维护了很多的业务数据，称之为内部逻辑文件（ILF）。与外部的交互包括两种场景，一是用户，二是外围系统。在与外部交互过程中，进一步细分为两个层面，一是外部去触发、输入信息，本系统做出相应的响应，即对应评估结果的基本过程（EI、EO、EQ）；二是本系统与其他系统对接时，需要调用外围系统信息，这些信息本身是外部系统的内部逻辑文件，对应本系统称之为外部接口文件（EIF）。以上就构成了FPA评估的所有基础组件，从中我们也可以看出，FPA是从用户视角出发去评估，即系统能向外提供（或输出）的功能价值。这也间接的说明了，该方法论不适用于非功能性需求、AI等新兴技术开发为主的规模度量。

3. FPA计数过程

在FPA评估过程中，其实就是对输入文档（需求、设计文档等）进行如下5种基础功能组件的分解计数，确定复杂度，再确定权重值。

第一步：计数

（1）逻辑文件

①　ILF（内部逻辑文件）：在本系统维护的业务数据、业务规则。

可以通俗的理解为，系统后台维护的数据表，但并不是全部数据表。因为本方法的设计理念是从用户视角出发，因此维护的这些数据是要能被用户感知到的实体表，如客户信息表、账户信息表、借据表等，而处理过程中所设计的中间表、配置表等不纳入ILF计数范围。

②　EIF（外部接口文件）：本系统引用，在其他系统维护的数据。

我们与外部系统对接，会引用外部的信息，这些文件本身是外部系统的ILF，对于本系统而言，计入EIF。

（2）基本过程

由一个触发事件引起，系统进入稳定状态作为一个标志。因此，在识别基本过程时，一定要找到触发事件，比如用户点击的一个按钮或日终的定时任务等，但最终系统都要进入一个稳定的状态，这样才算一个完整的基本过程。分为如下3类：

①　EI（外部输入）：由外部输入，并对内部逻辑文件进行维护或改变系统行为的事务。

举例：点击【新增】【修改】按钮，新增或修改一个客户信息，均算作EI。

②　EO（外部输出）：对数据加工后呈现或输出的事务。

举例：按月计提台账查询或导出，该台账在生成过程中，并不是简单的将后台数据表直接输出（select *from...），而是需要进行逻辑计算、数据加工，这种情况算作EO。

③　EQ（外部查询）：对已有数据直接呈现或输出的事务。

举例：客户信息查询功能，直接把数据库中存的数据原封不动的展示出来，没有做任何的加工处理，算作EQ。

说明：在实际规模估算过程中，某一个事务算作EO/EQ/EI并不是特别关键，因为他们的权重区别并不是很大。重要的是要数全了，不要漏~~~

第二步：确定重用程度、修改类型

识别出逻辑文件或基本过程后，需要确定每一项的重用程度、修改类型：判断本事务与原有系统功能的重用程度（高、中、低）；然后再确定其修改类型（新增、修改、删除）。

下图为评估示例：

4. 工作量计算过程

FPA计数完成后，我们最终是要获得待评估系统/项目的工作量，整体计算过程如下：

功能组件权重映射表：

计算过程如下表所示：

5. 方法特点与推广

我们总结一下FPA方法的特点：

（1）客观性：对比专家法、类推法，相对能减少主观偏差。

（2）输入文件：输入的材料较完整，有详细的需求描述、用例描述等。

（3）适用场景：有清晰、明确输入的功能性需求，如实施阶段或存量项目二期，不太适合新项目售前阶段的一句话需求；不适用于非功能性需求及新兴技术开发为主的成本评估;也不太适合那种交互单一但是难度高的场景，例如复杂的算法，风控模型，安全防控，高标准的基础架构层等。

（4）学习成本：虽已对功能点分析法进行精简，但仍有较大的学习、培训成本。

（5）沟通成本：原始需求功能与工作量没有直观对应，对未接触过该方法论的同学理解难度大，沟通成本高。

（6）评估投入成本：拆解过程需要考虑细致的设计实现方式，需要花费的时间、精力较多。

四．总结

最后，我们对常用的评估方法进行对比，大家会发现没有万能的评估方法，每一种方法都有其适用的场景，并均有所限。在条件允许的情况下，我们可以进行交叉验证。

随着软件工程领域的数字化不断深入，工作量评估的精度也在稳步提升。举例来说，设计工程师现在可以利用Figma等工具，与客户紧密合作，共同塑造交互性极强的设计。而在编码环节，团队成员通过使用Vscode等在线代码编辑器共享工作空间，彼此协同以提升编码效率。此外，通过自动化测试以及众多的RPA（Robotic Process Automation）工具，我们能够及时发现产品的Bug，而且还能记录下每个功能点的完成时间和效率，从而积累大量宝贵的数据，为工作量评估提供强有力的参考。

进入GPT大模型的时代，AI的作用更是不可或缺。开发团队现在可以借助AI生成代码，甚至是完整的软件和产品。AI模型的崛起无疑将重塑行业标准。想象一下，当用户能够清晰地描述他们的奇思妙想和设计构想时，AI成本估算模型能够在短时间内提供一个大致的成本评估。而后，这些信息可以交由高度专业化的AI交付模型来执行开发工作，或者，根据成本评估，在市场上寻找最符合要求的开发团队来实现这些构想。数字化工具和AI的结合正在为软件工程注入新的活力，使工作量评估更加精准，开发过程更加流畅，而产品的创新和质量也得以提升。

参考资料

[1]张旸旸,王海青,蔡立志,等.软件成本度量标准实施指南[M].北京:清华大学出版社,2017.

[2]王海青等,软件研发成本度量规范释义[M].北京：机械工业出版社，2014.