软件造价|《GB/T 36964-2018 软件工程 软件开发成本度量规范》解读

· 一、引言

2019年7月1日，随着《GB/T 36964-2018 软件工程 软件开发成本度量规范》的正式实施，长期以来困扰业界的“软件价值黑”问题迎来了根本性转变。作为我国软件工程领域首部国家级成本度量标准，GB/T 36964-2018标志着中国软件产业终于拥有了与国际接轨、又符合本土实践的“价值度量衡”。它以功能点分析（FPA）为技术基石，以行业基准数据（CSBMK）为参照系，构建起从软件规模测量到成本估算的完整方法体系，使得软件造价评估从“专家经验判断”升级为“工程化科学度量”。

对于软件造价评估师而言，掌握这一标准不仅是职业能力的核心要件，更是参与政府财政评审、国企信息化投资、大型项目招投标的“通行证”。本文将从标准演进脉络、核心概念体系、功能点测量方法、成本度量模型、五大应用场景及行业实践成效六个维度，结合《中国软件行业基准数据》最新参数与典型实施案例，进行系统性深度解读。无论您是初入造价评估领域的新人，还是希望提升评估精度的资深从业者，本文都将为您提供从理论认知到实操落地的完整知识框架，助您在软件成本管控的复杂迷宫中找到科学、规范的解决路径。

· 二、标准概述与战略背景

1.标准演进脉络

《GB/T 369642018 软件工程 软件开发成本度量规范》于2018年12月28日由国家市场监督管理总局和国家标准化管理委员会联合发布，2019年7月1日正式实施，由全国信息技术标准化技术委员会（SAC/TC28）归口管理。该标准并非凭空产生，而是在电子行业标准《软件研发成本度量规范》（SJ/T 114632013）基础上进行的国家级升级，保留了原标准的核心技术逻辑，同时在应用场景、引用标准、调整因子等方面进行了全面优化。

从行业发展视角看，该标准的出台回应了长期以来软件产业面临的“价值衡量难、价格形成机制乱、成本管控弱”三大痛点。在标准发布前，我国软件项目预算编制主要依赖专家经验（俗称“拍脑袋”），估算偏差较大，严重制约了行业健康发展。通过建立基于功能点的标准化度量体系，该标准将软件规模估算与实际规模偏差控制在10%左右，工作量与成本估算偏差控制在20%以内，基本满足业界对估算准确性的要求。

2.标准定位与适用范围

本标准明确定义了软件开发成本度量的基本方法与实施流程，具体涵盖符合性声明、成本构成、度量过程以及预算编制、招投标、项目计划、合同变更、合同编制五大典型应用场景。需特别说明的是，本标准适用范围限定于“项目立项至验收交付”阶段，主要包括需求分析、概要设计、编码实现、集成测试、验收交付及相关项目管理支持活动，明确不包括数据迁移、软件运维等外部延伸成本。

本标准采用“开放式架构”设计原则，本身不提供具体的基准数据与估算模型。在估算项目直接人力成本费率时，应充分考虑不同地域人员成本的实际差异。委托方可参照同类项目的直接人力成本费率数据进行测算，开发方则宜优先采用本单位内部的直接人力成本费率数据。当前，多数使用单位在实践过程中主要参考中国软件行业协会发布的《中国软件行业基准数据》（CSBMK）或其他权威机构发布的相关数据。该架构设计既保障了本标准在方法论层面的权威性与稳定性，亦确保了数据来源的可更新性与对行业实际需求的适应能力。

· 三、核心概念体系与成本构成

1.关键术语定义

标准建立了完整的术语体系，其中几个核心概念构成了造价评估的理论基础：

（1）软件开发成本（Software Development Cost）：为达成软件项目目标，开发方所需付出的各种资源代价总和。这一定义突破了单纯的人力成本视角，强调“资源代价总和”的全面性。

（2）人力成本与非人力成本：标准将成本划分为人力成本（人力资源代价总和）和非人力成本（人力资源之外的其他资源代价总和）两大类。这种二分法既符合软件项目成本结构特征，也便于与财务核算体系对接。

（3）功能点耗时率

（Personhours per Functional Size Unit）：每功能点所消耗的人时数，这是连接软件规模与工作量之间的核心转换参数。

（4）基准（Benchmark）与基准比对（Benchmarking）：经过筛选并维护在数据库中的测量值，用于表征目标对象相关属性。这一概念引入了行业大数据思维，强调通过历史数据对标提高估算科学性。

2.成本构成模型

标准构建了分层级成本构成模型：

（1）直接成本：

直接人力成本：开发、测试等核心人员的薪酬福利；

直接非人力成本：专用设备、场地、差旅等专项支出。

（2）间接成本：

间接人力成本：管理人员、支持人员的分摊费用；

间接非人力成本：开发设备折旧、停工损失等联合资源代价。

这种成本分类方法体现了软件项目成本核算的特殊性——人力资源占绝对主导（通常占70%以上），同时存在显著的间接成本分摊需求。标准特别指出，间接成本是“同一种投入可以支持一个以上项目的联合资源代价总和”，如开发管理人员工资、开发设备折旧等，这为解决软件成本归集难题提供了理论依据。

· 四、功能点规模测量方法体系

1．方法家族与标准选择

《GB/T 36964-2018 软件工程 软件开发成本度量规范》最大的技术贡献在于确立了功能点法（Function Point Analysis, FPA）作为软件规模度量的首选方法。标准引用了五种国际主流功能点测量标准，形成完整的方法家族：

（1）IFPUG《信息技术 软件测量 功能规模测量 第1部分：概念定义》：是功能点度量的国际基准，定义严谨，应用最广。

（2）NESMA《系统与软件工程 功能规模测量 NESMA方法》：提供三级精度方法，高效易用，与IFPUG高度兼容，共同构成国内主流实践。

（3）COSMICFFP《系统与软件工程 功能规模测量 COSMIC方法》：专长于实时与嵌入式系统。

（4）MK II《系统与软件工程 功能规模测量 Mk II功能点分析方法》：适用于复杂业务逻辑分析。

（5）FiSMA《系统与软件工程 功能规模测量 FiSMA1.1方法》：以用户功能需求为唯一度量对象，剥离了技术实现细节，强调从最终用户视角识别和量化软件所提供的“功能服务”。

在实际应用中，IFPUG和NESMA是国内最常用的两种方法。标准使用建议：对于管理信息系统、OA系统、ERP系统等以数据处理为主的软件，优先采用IFPUG/NESMA；对于实时控制系统、嵌入式软件，可考虑COSMIC方法。

2．IFPUG方法技术要点

IFPUG方法通过量化软件系统提供的功能数量来衡量规模，关注五个关键信息域特性：

（1）数据功能类型：

内部逻辑文件（ILF）：系统内部维护的业务数据；

外部接口文件（EIF）：系统外部引用但由其他系统维护的数据。

（2）事务功能类型：

外部输入（EI）：处理来自外部的数据输入；

外部输出（EO）：向外部提供经过复杂处理的数据；

外部查询（EQ）：简单的数据检索输出。

标准计数流程包括：识别功能点类型→确定复杂度（低、中、高）→确定权重→计算未调整功能点（UFP）→计算调整因子→得出已调整功能点（FP）。复杂度判定依据数据元素类型（DET）、记录元素类型（RET）、引用文件类型（FTR）等参数，体现“功能越复杂，规模越大”的技术逻辑。

3．NESMA快速估算方法

针对国内项目早期（预算、招投标阶段）需求不完善的特点，标准特别推荐NESMA方法。NESMA提供三种精度级别的方法：

（1）指示法（Indicative）：仅关注逻辑文件（ILF和EIF），适用于预算阶段。

公式为：功能点数 = 35 \times ILF数量 + 15 \times EIF数量

（2）估算法（Estimated）：关注逻辑文件和事务功能（EI、EO、EQ），适用于执行阶段。

（3）详细法（Detailed）：关注全部功能元素及复杂度，适用于事后评估。

国内实践中常采用快速功能点赋值法，简化复杂度判定，直接使用固定权重。常见取值体系包括：

107454体系：ILF=10, EIF=7, EI=4, EO=5, EQ=4（数据功能默认“Average”复杂度）；

75454体系：ILF=7, EIF=5, EI=4, EO=5, EQ=4（数据功能默认“Low”复杂度）。

· 五、成本度量模型与计算流程

1．规模调整机制

标准充分考虑到软件项目需求的动态性，引入规模变更因子（CF, Change Factor）反映不同阶段需求的完整程度。根据标准及配套实践指南：

预算阶段：CF通常取2.0（需求极不明确）；

招投标阶段：CF降至1.26（需求基本明确）；

计划阶段：CF设为1.0（需求明确）；

交付后：CF取1.0（规模确定）。

调整后功能点数计算公式：

S=US×CF

式中：

S—调整后规模，单位为功能点（FP）；

US—未调整规模，单位为功能点（FP）；

CF—规模变更因子，取值范围 1.0～2.0。

S（调整后规模）构成后续成本测算的基准规模。

2．工作量估算模型

工作量估算是规模向成本转化的关键环节。标准采用基准生产率（PDR, Productivity Delivery Rate）作为核心参数，定义为每功能点消耗的人时数（人时/功能点）。

根据《中国软件行业基准数据》（CSBMK），全行业生产率中位值（P50）约为6.83人时/功能点，但不同地区有差异，如山西、湖北等地标定义为6.5人时/功能点。实际估算中通常选用P25（下限）、P50（最可能值）、P75（上限）三个百分位数给出工作量区间。

调整后工作量计算公式

AE=UE×A×IL×L×T

式中：

AE—调整后工作量，单位为人时（p·h）；

A—应用领域调整因子，取值范围0.8~1.2；

IL—软件完整性级别，取值范围1.0~1.8；（注：A级取1.6~1.8，B级取1.3~1.5，C级取1.1~1.2，D级取1.0）

L—开发语言调整因子，取值范围0.8~1.2；

T—最大团队规模调整因子，取值范围0.8~1.2。

3．成本计算与费用标准

对于委托方，如果已经确定了规模综合单价，则可以根据规模综合单价和估算出的规模直接计算出直接人力成本和间接成本的总和，然后计算软件开发成本，计算如式所示：

SDC=P×S+DNC

式中：

SDC—软件开发成本，单位为元；

P—规模综合单价，单位为元每功能点（元/FP）；

S—软件规模，单位为功能点（FP）；

DNC—直接非人力成本，单位为元。

标准特别强调，人月费率应参考当地信息化主管部门发布的数据或行业基准数据，避免简单采用企业财务工资数据（通常只包含直接人力成本，未含管理分摊和利润）。

· 六、应用场景与实施流程

1．五大典型应用场景

标准明确了五大核心应用场景，并针对每个场景提出差异化实施要点：

（1）预算编制（事前算）

特点：需求粗略、精度要求相对较低；

方法：采用NESMA指示法快速估算；

要点：充分考虑规模变更因子（通常取1.5或2.0），预留合理项目需求变更空间。

（2）招投标（定价参考）

特点：需求基本明确、竞争性定价；

方法：采用NESMA估算法或IFPUG方法；

要点：引入评标基准价、合理报价区间概念，防止低于成本价竞标

（3）项目计划（资源配置）

特点：需求明确、精度要求高

方法：详细功能点计数

要点：结合生产率数据制定详细进度计划，分解到人月/人天

（4）合同变更（事中调）

特点：范围变更、价格调整

方法：对变更部分进行增量功能点计数

要点：明确变更功能点与基准功能点的对应关系

（5）项目决算（事后评）

特点：实际成本核算、绩效评价

方法：详细法精确计数实际功能规模

要点：对比估算值与实际值，分析偏差原因

2．第三方评估实施流程

在财政投资、政府采购等场景中，第三方造价评估已成为标准配置。专业评估流程包括：

第一步：文档审查

审查需求规格说明书、设计文档、招标文件等，判断项目所处阶段，确定适用的功能点计数方法（预估功能点法或估算功能点法）。

第二步：功能点识别与计数

识别逻辑文件（ILF/EIF）和事务功能（EI/EO/EQ），根据复杂度赋值计算未调整功能点数（UFP）。

第三步：规模调整

根据项目特征识别软件规模调整系数、软件质量特性调整系数（如性能、安全性、可靠性要求），计算调整后功能点数（FPs）。

第四步：工作量计算

引用权威基准数据（如CSBMK）中的生产率数据（P50中位值），结合调整因子计算开发工作量。

第五步：成本确定

根据当地人月费率标准，计算直接人力成本，加计直接非人力成本和间接成本，形成最终造价评估报告。

· 七、行业应用价值与实践成效

1．解决行业痛点

《GB/T 369642018 软件工程 软件开发成本度量规范》的实施解决了软件行业长期存在的三大难题：

一是价值量化难题，通过功能点将抽象的软件功能转化为可度量的规模单位，使“软件价值”从主观判断转向客观计量。功能点方法从用户业务视角出发，不需要理解技术实现细节，业务人员与技术人员终于拥有了共同的度量语言。

二是价格形成机制难题，在政府采购和国企信息化投资中，标准提供了“评标基准价”、“合理报价区间”等概念，遏制了恶意低价中标和漫天要价两种极端情况。某省级政务系统应用案例显示，全过程造价评估使预算超支率显著降低。

三是成本管控难题，标准支持按阶段（预算、计划、决算）进行成本对标，通过偏差分析识别项目管理薄弱环节。在银行业等成熟应用行业，已形成基于功能点的项目绩效评价体系。

2．行业应用现状

目前，该标准已在政府机构、金融、电信、能源、制造等多个行业全面铺开。其中，银行业作为最早应用的行业，已形成成熟的内部评估体系；政务信息化领域也得到普遍采用，例如长沙市财政评审中心已建立基于功能点的标准化评审流程；同时，该标准在高校信息化中也有效破解了软件建设成本估算难题，提供了从规模到成本的三步估算路径。实践数据显示，经过专业认证的软件造价评估师，其整体评估误差率可控制在±10%以内（其中基础功能点测算误差约±8%，非功能性需求调整误差约±2%）。

3．配套体系建设

标准的有效实施依赖于完善的配套体系，在数据支撑方面，依托每年更新的《中国软件行业基准数据》（CSBMK）提供生产率、人月费率及调整因子等关键参数；在人才培养方面，北京软件造价评估技术创新联盟等机构持续开展软件工程造价师、造价评估专家等专业认证培训；在工具支持方面，已出现如“软件造价喵”等智能化工具，通过AI算法实现功能点自动识别，有效提升了评估效率；同时，地方标准体系也在不断完善，北京、湖南、湖北、山西等地已相继出台配套地方标准，进一步细化了实施规则。

· 八、实践挑战与发展建议

1．当前实施难点

尽管国家标准GB/T 36964-2018具有高度的科学性与规范性，但在实际推广应用过程中仍面临若干现实挑战，主要表现在以下几个方面：

一是在方法适用性方面，功能点估算方法对需求文档的完整性与准确性有较高要求。项目前期特别是预算编制阶段，常因需求不够明确，即便采用NESMA快速功能点估算方法，评估结果仍存在较大不确定性，影响预算编制的精确性。

二是在人员专业性方面，国际功能点用户组（IFPUG）等方法体系相对复杂，功能点识别与计数工作需经过系统化专业培训方可掌握。即便如此，不同评估人员对同一软件系统的规模判定仍可能出现±10%左右的偏差，评估结果的一致性有待进一步提升。

三是在数据支撑方面，现有基准数据库对人工智能、区块链等新兴技术领域的覆盖尚不充分，相关历史项目数据积累不足，导致传统软件生产率参数在新兴领域适用性受限，影响估算结果的合理性。

四是在度量完整性方面，现行标准虽能较好覆盖功能性需求的规模度量，但对大数据处理、高并发访问、高可用性等非功能性需求的成本影响，尚未建立科学、精细的调整模型，相关评估方法仍较为原则化，难以准确反映非功能特性带来的成本投入。

以上问题在一定程度上制约了标准在更广泛场景下的深入应用，需在后续修订与实践推广中予以重点关注和系统完善。

2．专业实施建议

作为软件造价评估师，建议从以下方面提升评估质量：

（1）采用分级评估策略

根据项目阶段选择适当精度方法：预算阶段用NESMA指示法快速估算（误差±30%可接受），招标阶段用估算法（误差±20%），结算阶段用详细法（误差±10%）。

（2）建立本地化基准库

在参考CSBMK等全国性数据基础上，积累组织自身历史项目数据，建立本地化生产率基准。特别是要区分不同技术栈（如传统Java开发vs云原生开发）的生产率差异。

（3）强化非功能性调整

针对性能、安全性、可靠性等非功能性需求，建立详细的调整因子检查表。例如，对于金融级安全要求的系统，SWF调整因子可能需要取1.3~1.5。

（4）注重风险储备

软件估算 inherently 存在不确定性，建议在计算结果基础上增加10%~15%的管理储备（Management Reserve），应对需求变更和技术风险。

（5）持续校准改进

通过“估算实际”对比分析，持续校准组织级的PDR（生产率）和调整因子，形成组织过程资产。

3．未来发展趋势

随着软件工程实践的深入发展，国家标准GB/T 36964-2018亦需与时俱进，持续优化完善。其未来演进将重点聚焦以下方面：

一是推进评估智能化，积极引入自然语言处理等先进技术，实现需求文档中功能点的自动识别与测算，有效提升评估效率，降低人工成本。

二是增强模式适应性，在现有瀑布模型基础上，加强对敏捷开发、DevOps等新型研发模式的支持，研究建立故事点与功能点之间的科学映射机制。

三是拓展生命周期覆盖，推动标准由当前以验收交付为主，逐步向运维阶段延伸，构建覆盖软件开发、部署、运维全过程的成本度量体系。

四是强化新技术响应，针对人工智能大模型、低代码平台等新兴技术形态，加快研制配套的规模度量补充方法，确保标准的广泛适用性与行业前瞻性。

· 九、结语

《GB/T 369642018 软件工程 软件开发成本度量规范》的发布实施，标志着我国软件产业进入了“可度量、可对比、可管控”的科学管理新阶段。作为软件造价评估师，深入理解和熟练运用该标准，不仅能够提升项目成本管控的专业水平，更能推动组织从经验驱动向数据驱动转型。

在实际工作中，我们应当把握标准“基于功能点、依托基准数据、分层级调整”的核心思想，灵活运用IFPUG、NESMA等方法，结合CSBMK等行业基准数据，建立符合组织特点的造价评估体系。同时，也要清醒认识到软件估算既是科学也是艺术，在遵循标准的基础上，仍需保持专业判断，综合考虑技术复杂度、团队能力、风险因素等多重变量，才能提供真正有价值的造价评估服务。

随着数字化转型的深入，软件成本度量将从“可选项”变为“必选项”。《GB/T 369642018 软件工程 软件开发成本度量规范》作为这一领域的基础性国家标准，必将发挥越来越重要的行业基准作用，助力我国软件产业高质量发展。

END