软件成本度量-功能点估算法(度量功能软件成本方法)

从软件项目实施过程来看，可以把软件成本划分软件研制成本、软件测试成本、软件运维成本。
我们一般将软件需求分析、设计、编码、集成、测试、上线发生的成本归集为为软件研制阶段成本，软件第三方测试发生的成本归集为软件测试成本，软件维护发生的成本归集为软件运维成本，软件升级发生的成本按研制成本进行归集。
软件成本度量一直都是软件行业的一个痛点问题，涉及投资规划、采购、系统开发、系统维护、资产管理等各个环节，如果不能有效准备的评估软件实施的成本，对软件立项实施各环节都会造成一些影响，比如：

①　规划投资部门无法有效评估项目投资规模；

②　采购部门无法有效评估项目投资合理性和开发商生产效率如何评定；

③　采购部门和开发部门的商务谈判的报价如何评定；

④　业务部门软件需求描述是否足够清晰；

⑤　软件范围控制，需求变更和成本增加的平衡；

⑥　开发过程中是否存在过度设计，开发过程如何度量；

⑦　系统增强开发和维护成本度量；

⑧　软件生命周期管理；

⑨　软件资产核算和资产报废的问题。

软件项目规模评估主要依据来自于用户需求，包括功能需求和非功能需求，评估方法包括：DELPHI专家评估法、代码行法（LOC）、类比法、故事点（Story Points）、用例点（UCP-UseCasePoints）、IFPUG、NESMA、COSMIC-FFP、UK-MarkII、COCOMOⅡ等，这些评估方法从度量角度大致可以分为两类，基于开发视角和业务视角。

基于技术视角的方法是从开发人员的角度，方法包括代码行、数据库表、函数、接口、服务的数量等等。
基于开发视角的方法主要存在于技术人员之间，优势是实现起来简单容易，缺点是容易引起分歧，难以在项目初期进行度量，且难以在技术人员之外的其他人员之间得到应用，如公司之间、部门之间、用户之间等。

基于业务视角的方法从用户角度出发，如：功能点、故事点、用例点、对象点等方法。
站在使用者的角度来进行度量，并能够在项目初期得到应用，弥补技术度量方法的不足。

以下，我们针对代码行法和功能点法这两种表达形式做个比较：

1. 代码行法：SLOC， 侧重实施角度，如何做

(1) 历史数据或专家意见（Pert/Delphi）

(2) 用于度量程序开发中的智能工作量

(3) 规模同语言、设计关系密切，技术视角

(4) 多用于实施方内部核算使用

2. 功能点法：FP，侧重用户角度，做什么

(1) 基于软件功能数和独立的项目因子

(2) 基于需求，项目早期可以得到的信息

(3) 独立于软件开发语言，用于视角反应软件规模

(4) 国际主流测算方法，适合谈判沟通

功能点方法度量的是软件的规模，它是主要从逻辑设计的角度出发对提供给客户的功能进行量化的方法。
功能点分析方法的目标是提供一种与具体实施方法和技术无关的对软件开发和维护进行度量的手段，度量用户要求和能够接收到的功能。
该方法是由IBM的工程师Albrecht通过对大量项目生产率进行研究得到的成果，于1979年提出，它可以

①　用来从功能角度度量一个采购软件的规模；‹

②　帮助用户从提供的功能角度判断一个软件对他们的好处；‹

③　为一个组织判断自己的质量和生产率提供“分母”；‹

④　帮助软件开发组织从规模出发判断一个软件项目的日程、人力和成本；‹

⑤　提供对软件进行横向比较的基本判断依据。

随后多年不断完善升级，出现了多种标准和方法，目前已发展为多种有一定代表性的方法：

（1）简介

IFPUG的功能点分析（FPA）方法是一种目前被广泛接受的关于软件规模度量的有效方法，从用户的角度出发，将系统分为数据功能和交易功能两大类，分别根据具体的规则来计算功能点，最后结合系统的特征因子来调整功能点数，从而得到最终的系统规模。

（2）主要功能元素

数据功能：

①　ILF – Internal Logical File – 内部逻辑文件

②　EIF – External Interface File – 外部接口文件

交易功能

①　EI – External Input – 外部输入

②　EO – External Output – 外部输出

③　EQ – External Query – 外部查询

（3）适用对象

管理信息系统（开发项目，升级项目，在用项目）

（4）普及程度

高，应用最广泛

（5）优点

从用户角度度量软件规模，使用人群多，易于交流

评估方法成熟，方法比COSMIC细致

（6）缺点

操作复杂，功能分解无方法指导，拆分结果和整体评估结果不一致

（1）简介

NESMA（Netherland Software Measurement Association，荷兰软件度量协会）功能点估算方法基于IFPUG发展而来。
它与IFPUG的概念统一，相对于IFPUG，NESMA显得更加灵活方便，并且更适合项目早期预算、招投标阶段的成本评估，针对IFPUG方法分析过程较复杂、计算工作量大的不足，NESMA方法实现了快速估算。

NESMA提供了三种类型的功能点估算方法，分别是：

①　指示法：

一般用于计划阶段，因为此阶段需求文件多不完善，故而只需关注逻辑文件即可。

②　估算法：

一般用于执行阶段，此时需求文件较为完善，故需要关注逻辑文件和相应的操作；

③　详细法：

主要用于事后评估阶段，此时功能需求非常详细，可关注逻辑文件、相应操作和复杂度。

在IFPUG的基础上，NESMA增加了指示法（Indicative）和估算法（Estimated），使得用户可以在需求不完善的情况下，快速估算软件规模。

从应用角度而言，IFPUG和NESMA标准是国际上最主要的标准，国际基准比对组织中超过90%的数据采用IFPUG/NESMA方法，国内的行业数据百分百采用IFPUG/NESMA方法，由于IFPUG方法和NESMA方法被认为是基本等效的，所以近几年，这两种方法被各行业大量采用。
但如想在早期（如预算）阶段进行度量，NESMA是更好的选择。

（2）主要功能元素

数据功能：

③　ILF – Internal Logical File – 内部逻辑文件

④　EIF – External Interface File – 外部接口文件

交易功能

④　EI – External Input – 外部输入

⑤　EO – External Output – 外部输出

⑥　EQ – External Query – 外部查询

（3）适用对象

管理信息系统

（4）普及程度

较为普及

（5）优点

从用户角度度量软件规模，使用人群多，易于交流

评估方法成熟，更适合早期测算

（6）缺点

操作复杂，功能分解无方法指导，拆分结果和整体评估结果不一致

（1）简介

通用软件度量国际协会（Common Software Measurement International Consortium ，COSMIC)提出的全功能点分析方法，COSMIC-FFP不仅适合于信息系统的规模度量，还适合于实时系统和多层系统的规模度量，已经被ISO接受为国际标准。
该方法可以在软件开发生命周期的各个阶段使用，从用户功能的视角入手，起源于客户可以理解的术语，不需要调整因子，简单易行。
COSMIC-FFP 通过入口(Entry)、出口(Exit)、读取(Read)和写入(Write)4 种数据流类型来确定软件系统功能的规模。
先将软件的功能分解为功能处理、数据组、数据属性，然后将功能处理分解为数据移动，根据数据移动来计算软件规模。

（2）主要功能元素

数据移动，入口(Entry)、出口(Exit)、读取(Read)和写入(Write)

（3）适用对象

银行、财务、保险等领域管理信息系统，非复杂计算系统

实时系统，如电话交换系统，嵌入式控制软件等，飞机定票系统等。

（4）普及程度

较普及，第二代功能点方法，部分人认为是趋势

（5）优点

计算规则简单、直接，不需要调整因子，理解后易于操作，可重复性高，支持实时系统

（6）缺点

普遍认为理解比较困难，不考虑数据计算，无法应用于分析性系统

（1）简介

英国软件度量协会提出的Mark II 功能点法（主要在英国、香港等地使用），只测量逻辑和业务需求，不依赖于具体实现方式，从逻辑事务的角度出发，识别输入、处理、输出的过程，计算数据元类型的数量，计算功能规模。

（2）主要功能元素

输入Ni、输出No，处理Ne

（3）适用对象

管理信息系统或者嵌入式系统

（4）普及程度

香港、英国部分的确使用

（5）优点

比IFPUG简单，易于理解，系统整体度量和部分度量总和一致

（6）缺点

使用不广泛，获取资料难；

19项调整因子，增加主观性，调整因子主观性强，不易操作

（1）简介

COCOMO(Constructive Cost Model，构造型成本模型)。
Barry Boehm研究大量项目数据后，推导出的一个成本模型，在实际应用中取得了较好的效果，很好的匹配了采用瀑布模型的软件项目。
做了调整和改进，提出了一个新的版本-COCOMOII型中使用三个螺旋式的过程模型：应用组装模型，早期设计模型和后体系结构模型。

① 应用组装模型(Application Composition)

应用组装模型是基于对象点的度量模型，它通过计算屏幕、报表、第三代语言(3GL)模块等对象点的数量来确定基本的规模，每个对象点都有权重，由一个三级的复杂性因子表示，将各个对象点的权值累加起来得到一个总体规模，然后再针对复用进行调整。

② 早期设计模型(early design)

在项目开始后的一个阶段或者螺旋周期通常包括探索体系结构的可供选择方案或增量开放测量。
为支持这一活动，COCOMOII提出了一个早期设计模型，这一模型使用功能点和等价代码行估算规模。

③ 后体系结构模型(post architecture)

一旦项目进入开放阶段，就必然确定一个具体的生命周期体系结构，此时项目就能够为估算提供更多更准确的信息。

首先采用软件规模估算方法对项目的规模进行估算。
再应用五个比例因子，通过相关计算，将规模转化为工作量，并通过十七个成本驱动因子对工作量进行调整。
最后，采用进度计算公式，计算出开发该项目所需要的进度以及人数。

（2）主要功能元素

DSI（ 源指令条数 ） ，定义为代码行数，包括除注释行以外的全部代码；MM（ 度量单位为人月 ） 表示开发工作量；TDEV（ 度量单位为月 ） 表示开发进度，由工作量决定。

（3）适用对象

相对较小、较简单的项目和同硬件结合紧密的嵌入性的项目

（4）普及程度

（5）优点

计算精确

（6）缺点

受因子影响巨大，项目前期不容易评估代码行数；缺乏实施指导性文件

功能点方法是面向业务视角的软件规模估算方法，估算工程师只需要了解业务需求，不需要理解功能的具体开发和实现过程，不考虑编程语言、技术框架、运行平台等信息。
作为一种从用户功能角度进行软件规模评估的方式，主要适用于以功能为主的软件系统，如：各种管理信息系统、OA系统、ERP系统等。
功能点评估法作为一种软件规模的评估方法也有其局限性，以下是部分问题：

①　评估的过程较为复杂，有一定的学习曲线；

②　对需求的清晰度要求较高，项目早期信息清晰度不够；

③　功能点估算法对系统内部复杂性考虑不足；

④　功能复杂度等级划分比较武断，只有高中低；

⑤　通用系统调整因子比较陈旧，应根据最新数据做出调整；

⑥　对一些比较复杂的功能，统计误差较大；

⑦　未考虑系统集成带来的额外开销；

⑧　对复杂系统的可靠性、扩展性、稳定性以及维护性考虑不够；

⑨　对软件过程规范性管理考虑不足，如；各阶段的文档产出等；

⑩　导致不能针对计算复杂性等非技术要求较高的系统并不能准确做出评估。

以下类型的系统不太适合使用功能点估算法做规模度量：

①　互联网在线交易平台；

②　对于包含大量算法的产品：视频系统、图像处理系统、杀毒软件、网络游戏等；

③　数据处理类的平台：数据仓库，数据库、数据实时处理等；

④　后台优化类项目：数据库优化、界面优化、性能优化类项目、分布式并发项目等；

⑤　硬件产品研发等。

①　ISO14143-1：概念定义，对本系列标准中使用的术语进行解释；

②　ISO14143-2：一致性评价，给出如何检验功能点评估是否符合ISO14143系列标准的评价过程。

③　ISO14143-3：验证，在需要时对功能点评估操作进行验证。

④　ISO14143-4：参考模型，给出功能点评估的方法模型以及需要度量的内容。

⑤　ISO14143-5：应用领域确定，确定功能点评估所适用的应用领域。

⑥　ISO14143-6：使用指南，对功能点评估提出建议和指导。

①　SJ/T 11463-2013《软件研发成本度量规范》

①　DB13/T 2106-2014 《软件开发项目造价评估规范》 河北省质量技术监督局

②　DB37/T 2791-2016 《软件测试成本度量基本方法》 山东省质量技术监督局

③　DB15/T 1394-2018 《软件开发项目造价评估规范》 内蒙古自治区质量技术监督局

④　DB52/T 1653-2022 《软件开发费用测算规范》 贵州省大数据发展管理局

⑤　DB11/T 1010-2019 《信息化项目软件开发费用测算规范》 北京市经济和信息化局

⑥　DB11/T 1425-2017《信息技术 软件项目测量元》北京市质量技术监督局

⑦　DB11/T 1424-2017 《信息化项目软件运维费用测算规范》 北京市经济和信息化委员会

①　GB/T 18491.1-2001 《信息技术 软件测量 功能规模测量 第 1 部分：概念定义》

②　GB/T 18491.2-2010《信息技术 软件测量 功能规模测量 第 2 部分：软件规模测量方法与 GB/T 18491.1-2001 的符合性评价》

③　GB/T 18491.3-2010《信息技术 软件测量 功能规模测量 第 3 部分：功能规模测量方法的验证》

④　GB/T 18491.4-2010 《信息技术 软件测量 功能规模测量 第 4 部分：基准模型》

⑤　GB/T 18491.5-2010《信息技术 软件测量 功能规模测量 第 5 部分：功能规模测量的功能域确定》

⑥　GB/T 18491.6-2010《信息技术 软件测量 功能规模测量 第 6 部分：GB/T 18491 系列标准和相关标准的使用指南》

⑦　20151553-T-469 《软件度量-软件研发成本度量规范》由行业标准升级而来

⑧　GB/T 36964-2018《软件工程 软件开发成本度量规范》

⑨　GB/T 32911-2016《软件测试成本度量规范》

⑩　201941487-T-469《信息技术服务 运行维护 第7部分 成本度量规范》 完成立项

⑪　GB/T 37735-2019《信息技术 云计算 云服务计量指标》

①　20194201-T-469 《系统与软件工程 功能规模测量 COSMIC 方法》

②　20194189-T-469 《系统与软件工程 功能规模测量 IFPUG 方法》

③　20194199-T-469 《系统与软件工程 功能规模测量 Mk II 功能点分析方法》

④　20194198-T-469 《系统与软件工程 功能规模测量 NESMA 方法》

⑤　20194202-T-469 《系统与软件工程 功能规模测量 FiSMA1.1 方法》

功能点估算大致可以分为7个步骤或阶段，分别是：

(1) 确定分析类型

功能点的分析既可以应用在项目上也可以应用在应用上。
三种功能点分析的类 型：

①　开发项目

②　升级项目

③　应用。

(2) 确定分析范围和应用边界

应用边界表示所度量的软件和用户之间的边界以及应用之间的边界。

(3) 确定用户功能需求

用户功能需求是用户需求子集，表示软件应实现的用户业务活动和过程。

(4) 分解功能需求

① 数据功能，以文件文单位，识别内部逻辑文件(Internal Logical File -- ILF)和外部接口文件(External Interface File-- EIF)。
识别ILF和EIF对应的数据元素类型（DET）和记录元素类型（RET），并根据识别结果计算其复杂度，确定其功能点数。

② 交易功能，识别交易功能外部输入（EI）、 外部输出（EO）和外部查询（EQ），分别根据其引用文件类型（FTR）和数据元素类型（DET）计算交易功能复杂度，确定其功能点数。

(5) 计算未调整功能点数

加权求和计算未调整功能点数（UFPC）。

(6) 确定调整因子

调整系数(VAF)是建立在 14 个用来评价被分析的应用的功能的通用系统特性的基础之上的。
每一个特性都有一些规则来进行评分，对这 14 个通用系统特性进行总结，计算出调整因子 VAF。

(7) 计算交付功能点数

将未调整功能点数（UFP）和调整因子（VAF）相乘得到功能点数。

计算公式：PF=UFPVAF

根据软件项目周期，我们通常将项目分成规划、需求、设计、开发、测试、上线、线上运维等7个阶段，以下简要说明各阶段可能产生的可作为度量依据的产出。

①　项目策划：项目实施范围、目标可以为规模度量提供总体依据

②　可行性分析： 项目范围、目标、实施路径进一步量化明确

③　成本收益报告：

④　项目启动报告：项目范围，组织结构清晰化，可用作规模前期度量依据

⑤　工时记录：用于验证前期各类度量指标，作为历史数据为后续类似项目评估提供依据

①　系统分析

②　需求规格说明书

1) 系统用例、功能说明、业务流程、业务场景等都可以用作功能点分析的依据

2) 系统非功能需求，也可用作技术实现评估的依据。

③　需求规格的评审&返工

④　业务、应用架构设计/规格说明

1) 系统的结构划分、边界、子系统之间的交互

2) 技术实施方案等都可作为度量的依据。

⑤　架构设计说明评审&返工

⑥　工时记录：用于验证前期各类度量指标，作为历史数据为后续类似项目评估提供依据

①　功能设计/界面交互设计

1) 详细设计、交互的设计，直接用于工作量评估

②　创建物理/内部设计

1) 系统内部逻辑，实现方式直接用于度量修正、校准

③　总体技术路线选择、架构设计、集成设计 进一步为开发工作度量提供明确依据

④　部署方案设计、网络、服务器、容器、安全、监控等方案明确， 为技术实现和后期运维提供度量依据。

⑤　设计评审&返工

⑥　工时记录：用于验证前期各类度量指标，作为历史数据为后续类似项目评估提供依据

①　技术详细设计、细化设计等等

②　软件包选择

③　开发代码

④　代码评审&返工

⑤　软件定制/接口

⑥　单元测试

⑦　软件集成

软件实现过程中的细化设计、方案调整、实施用时，细化、验证前期评估的结果。

工时记录：用于验证前期各类度量指标，作为历史数据为后续类似项目评估提供依据

①　测试计划， 用作测试工作量的评估

②　测试用例， 测试工作量的细化、评估、验证、进一步的校准

③　系统测试， 测试工作量的细化、评估、验证、进一步的校准

④　性能测试， 测试工作量的细化、评估、验证、进一步的校准

⑤　集成测试， 测试工作量的细化、评估、验证、进一步的校准

⑥　验收测试， 测试工作量的细化、评估、验证、进一步的校准

⑦　工时记录：用于验证前期各类度量指标，作为历史数据为后续类似项目评估提供依据

①　交付上线准备，计划准备，上线工作量度量

②　用户文档

③　用户培训

④　实施上线

⑤　用户支持

⑥　工时记录：用于验证前期各类度量指标，作为历史数据为后续类似项目评估提供依据

①　运维计划， 日常工作量的度量

②　软件运维， 日常工作量的度量

③　网络服务器运维， 日常工作量的度量

④　重大活动保障， 重大活动、突发事情工作量的度量

⑤　安全运维， 日常工作量的度量

⑥　工时记录：用于验证前期各类度量指标，作为历史数据为后续类似项目评估提供依据