做软件定制开发的人大概都经历过这样的场景：销售拿着一页纸需求来找你，“这个系统大概多少钱？下周一招标就要报价了。“于是项目经理拉几个老员工开会，大家凭着做过类似项目的记忆，拍出一个总价。委托方觉得贵，开发方觉得亏，最后各让一步成交——至于这个价格和软件实际规模有什么关系，没人说得清。
这不是能力问题，是方法缺失。国内软件行业其实早就有了一套完整的、可复核的定价标准体系，只是普及度远远不够。这套体系由两份国家标准构成：
- GB/T 36964-2018《软件工程 软件开发成本度量规范》——规定"从功能点到工作量、从工作量到钱"的成本度量全流程；
- GB/T 42588-2023《系统与软件工程 功能规模测量 NESMA 方法》（修改采用 ISO/IEC 24570:2018）——规定"功能点怎么拆"的具体计数规则。
两份标准一个管"钱怎么算”，一个管"规模怎么量”，合起来就是一套不用拍脑袋的报价方法。这篇文章用一组逻辑图把它们的完整链条讲清楚。
📩 如果你需要这两份标准的原始 PDF 文件，可以邮件联系我：i@lixx.cn，我看到后会发给你。
一、整体框架：国标是怎么把"报价"变成一道可验算的题的
链接到标题
国标报价体系的核心思路只有一句话：把"软件值多少钱"这个无法回答的问题，拆解成"软件有多少功能点 → 需要多少工作量 → 消耗多少成本 → 加上合理利润"四个可以逐级验算的问题。
flowchart LR
A["用户功能需求<br/>(系统边界内)"] -->|"GB/T 42588<br/>功能点计数"| B["功能规模 S<br/>单位: fp"]
B -->|"× 规模变更因子 CF<br/>(1.0~2.0)"| B2["调整后规模"]
B2 -->|"× 功能点耗时率 C<br/>(基准数据分位数)"| C["工作量 UE<br/>单位: 人时"]
C -->|"× 调整因子<br/>A·IL·L·T"| C2["调整后工作量 AE<br/>单位: 人时"]
C2 -->|"× 人力成本费率 F<br/>元/人月"| D["软件开发成本 SDC<br/>元"]
D -->|"+ 合理毛利润<br/>+ 数据迁移/维护费"| E["项目报价 / 预算"]
style A fill:#e8f4fd,stroke:#2196f3
style B fill:#fff3e0,stroke:#ff9800
style C2 fill:#e8f5e9,stroke:#4caf50
style E fill:#fce4ec,stroke:#e91e63
这个链条里没有任何一环依赖"某个高管的直觉"。每一环都有标准依据、有计算公式、有基准数据支撑，委托方和开发方可以坐在同一张桌子前，对着同一份需求逐条验算——这正是它成为招投标、预算审批、结算决算可参考标准的原因。
两份标准各自负责的区段如下：
flowchart TB
subgraph GB42588 ["GB/T 42588-2023（NESMA 方法）"]
direction TB
S1["① 功能识别与分类<br/>ILF / ELF / EI / EO / EQ"]
S2["② 复杂度判定<br/>DET × RET / FTR 查矩阵"]
S3["③ 加权求和<br/>得到功能规模 fp"]
S1 --> S2 --> S3
end
subgraph GB36964 ["GB/T 36964-2018（成本度量规范）"]
direction TB
T1["④ 工作量估算<br/>方程法 / 类比法 / 类推法"]
T2["⑤ 成本估算<br/>四项成本构成 SDC"]
T3["⑥ 场景化应用<br/>预算 / 招投标 / 计划 /<br/>变更 / 结算决算"]
T1 --> T2 --> T3
end
S3 -->|"功能规模 S"| T1
style GB42588 fill:#fff8e1,stroke:#ffc107
style GB36964 fill:#e8f5e9,stroke:#4caf50
二、功能点怎么拆：GB/T 42588 的 NESMA 方法
链接到标题
2.1 为什么是功能点，而不是代码行或故事点
链接到标题
功能点分析（FPA）由 Albrecht 在 1979 年提出，核心洞察是：从用户视角度量软件提供给他的"信息处理数量"，而这个数量与用什么语言、什么架构实现无关。就像租房看的"租赁点"由房间数、面积、设施决定，而与房子是砖混还是框架结构无关。
代码行数依赖技术实现、故事点依赖团队校准，都没法在甲乙双方之间作为公平衡器。功能点是唯一能写进招标文件、双方各自算出结果还能对得上账的规模单位。
2.2 五种基本功能组件：拆解的最小颗粒
链接到标题
NESMA 把任何应用从用户视角拆成五大类，先按"数据 / 事务"分组，再逐类判定：
flowchart TB
ROOT["应用程序功能<br/>(用户视角, 边界内)"] --> DATA["数据功能<br/>软件要记住什么"]
ROOT --> TRANS["事务功能<br/>软件要做什么"]
DATA -->|被本系统使用且维护| ILF["ILF 内部逻辑文件<br/>如: 客户信息"]
DATA -->|被本系统使用<br/>由其他系统维护| ELF["ELF 外部逻辑文件<br/>如: 人事系统的员工信息"]
TRANS -->|跨越边界 + 维护 ILF| EI["EI 外部输入<br/>增 / 删 / 改"]
TRANS -->|跨越边界 + 输出规模不定<br/>或含计算派生数据| EO["EO 外部输出<br/>报表 / 统计"]
TRANS -->|跨越边界 + 唯一标识查询<br/>规模固定 + 无计算| EQ["EQ 外部查询<br/>按键查详情"]
style DATA fill:#e8f4fd,stroke:#2196f3
style TRANS fill:#fff3e0,stroke:#ff9800
style ILF fill:#bbdefb,stroke:#1976d2
style ELF fill:#bbdefb,stroke:#1976d2
style EI fill:#ffe0b2,stroke:#f57c00
style EO fill:#ffe0b2,stroke:#f57c00
style EQ fill:#ffe0b2,stroke:#f57c00
数据功能的判定只要抓住一个问题——“这组数据由谁维护”：
flowchart TB
A["一组永久性逻辑数据"] --> B{"是技术性中间产物?<br/>(临时/排序/工作文件)"}
B -->|是| X1["❌ 不计数"]
B -->|否| C{"数据只被使用一次<br/>(事务文件)?"}
C -->|是| X2["❌ 不计为逻辑文件<br/>计为 EI / EO 的一部分"]
C -->|否| D{"被本系统维护?"}
D -->|"是 (使用且维护)"| ILF["✅ ILF"]
D -->|否| E{"由其他系统维护<br/>且当前数据直接可用?"}
E -->|是| ELF["✅ ELF"]
E -->|否| X3["❌ 不适用<br/>(逻辑文件必须有人维护)"]
style ILF fill:#c8e6c9,stroke:#388e3c
style ELF fill:#c8e6c9,stroke:#388e3c
style X1 fill:#ffcdd2,stroke:#d32f2f
style X2 fill:#ffcdd2,stroke:#d32f2f
style X3 fill:#ffcdd2,stroke:#d32f2f
事务功能的判定核心是看输出端有没有"算出来的东西"：
flowchart TB
A["一个基本过程<br/>(用户有意义的最小功能单元)"] --> B{"是否维护了 ILF?<br/>(增/删/改数据)"}
B -->|是| EI["✅ EI 外部输入"]
B -->|否| C{"输出规模是否固定?<br/>(行数确定, 如按编号查详情)"}
C -->|否| EO["✅ EO 外部输出"]
C -->|是| D{"输出含派生数据?<br/>(合计/平均/计算结果)"}
D -->|是| EO
D -->|否| EQ["✅ EQ 外部查询"]
style EI fill:#ffe0b2,stroke:#f57c00
style EO fill:#ffe0b2,stroke:#f57c00
style EQ fill:#ffe0b2,stroke:#f57c00
EO 和 EQ 的区分是实务中最容易出错的地方：输出里有没有"算出来的东西"。客户统计（有汇总计算、行数不定）是 EO；输入客户编号显示客户详情（规模固定、原样展示）是 EQ。另一个高频坑：修改功能里"先显示再改"的数据展示，属于 EI 的一部分，不能额外再算一个 EQ。
2.3 复杂度与权重：从功能到功能点
链接到标题
每个功能还要判复杂度（低/中/高）。数据功能看 DET（数据元素类型数）× RET（记录类型数），事务功能看 DET × FTR（引用的逻辑文件数），通过复杂度矩阵查表得到权重：
flowchart LR
F["一个已识别的功能"] --> G{"数据功能还是<br/>事务功能?"}
G -->|"数据功能 (ILF/ELF)"| H["数 DET: 用户可见字段数<br/>数 RET: 包含的实体类型数"]
G -->|"事务功能 (EI/EO/EQ)"| I["数 DET: 跨越边界的字段数<br/>数 FTR: 引用的逻辑文件数"]
H --> J["查复杂度矩阵<br/>(表4~表6)"]
I --> K["查复杂度矩阵<br/>(表7~表9)"]
J --> L["低 / 中 / 高"]
K --> L
L --> M["查功能点分配表<br/>得到权重 fp"]
M --> N["所有功能权重求和<br/>= 软件功能规模"]
style N fill:#c8e6c9,stroke:#388e3c
| 复杂度 | ILF | ELF | EI | EO | EQ |
|---|
| 低 | 7 | 5 | 3 | 4 | 3 |
| 中 | 10 | 7 | 4 | 5 | 4 |
| 高 | 15 | 10 | 6 | 7 | 6 |
以 ILF 为例，复杂度矩阵长这样（DET 越多、RET 越多，复杂度越高）：
| 记录类型 ↓ \ 数据元素类型 → | 1~19 | 20~50 | 51+ |
|---|
| 1 | 低 | 低 | 中 |
| 2~5 | 低 | 中 | 高 |
| 6+ | 中 | 高 | 高 |
全部功能的权重求和，就是软件的功能规模，标准要求结果标记为 fp(GB/T 42588—2023)，保证可追溯。
2.4 三级精度：不同阶段用不同的数法
链接到标题
NESMA 最重要的工程价值是按需求详实程度分级，这直接对应报价的不同时机：
flowchart TB
A["拿到一份需求"] --> B{"手头有什么材料?"}
B -->|"只有概念数据模型 / ER 图"| C["① 预估功能点分析<br/>FP = ILF数 × 35 + ELF数 × 15<br/>⚠️ 偏差可达 50%"]
B -->|"功能清单可识别<br/>但数不清 DET/RET"| D["② 估算功能点分析<br/>数据功能取低值 (ILF=7, ELF=5)<br/>事务功能取中值 (EI=4, EO=5, EQ=4)"]
B -->|"详细规格: 字段级 + 文件引用级"| E["③ 详细功能点分析<br/>逐功能数 DET × RET/FTR<br/>查矩阵定复杂度, 最精确"]
C --> F["适用于: 立项 / 预算阶段"]
D --> G["适用于: 招标 / 投标阶段"]
E --> H["适用于: 项目计划 / 结算阶段"]
style C fill:#ffebee,stroke:#e53935
style D fill:#fff8e1,stroke:#ffb300
style E fill:#e8f5e9,stroke:#43a047
预估法里 35 这个系数是标准给出的统计假设：每个 ILF 平均配套 3 个 EI（增/改/删）、2 个 EO、1 个 EQ 加若干通用功能（3×4 + 2×5 + 4 + 2 = 26，加上 ILF 自身低复杂度 7，约 33~35）。若拿到的是第三范式模型，则改用 维护的实体类型数 × 25 + 引用的实体类型数 × 10。
对应到 36964 的应用场景，两者刚好接上：预算阶段 → 预估法；招标/投标 → 估算法；计划及以后 → 详细法。
2.5 一个来自标准附录 D 的完整例子
链接到标题
“维护客户信息"功能：客户信息（本系统维护，ILF）、员工信息（人事系统维护，ELF）；操作有添加/导入/修改/删除客户（4 个 EI）、客户统计（1 个 EO，有汇总计算）、客户查询（1 个 EQ，按姓名或电话查）。
flowchart TB
REQ["需求: 维护客户信息"] --> D1["数据功能"]
REQ --> D2["事务功能"]
D1 --> ILF["客户信息 → ILF<br/>(本系统维护)"]
D1 --> ELF["员工信息 → ELF<br/>(人事系统维护)"]
D2 --> EI1["添加客户 → EI"]
D2 --> EI2["导入客户 → EI"]
D2 --> EI3["修改客户 → EI"]
D2 --> EI4["删除客户 → EI"]
D2 --> EO["客户统计 → EO<br/>(含分布计算, 行数不定)"]
D2 --> EQ["客户查询 → EQ<br/>(按姓名/电话, 规模固定)"]
subgraph RESULT ["三种精度结果"]
R1["预估法:<br/>1×35 + 1×15 = 50 fp"]
R2["估算法:<br/>1×7 + 1×5 + 4×4 + 1×5 + 1×4 = 37 fp"]
R3["详细法:<br/>数 DET/RET 后逐项判级 = 37 fp"]
end
ILF --> RESULT
ELF --> RESULT
EI1 --> RESULT
EI2 --> RESULT
EI3 --> RESULT
EI4 --> RESULT
EO --> RESULT
EQ --> RESULT
style R1 fill:#ffebee,stroke:#e53935
style R2 fill:#fff8e1,stroke:#ffb300
style R3 fill:#e8f5e9,stroke:#43a047
同一个需求，三种方法给出 50 和 37——这就是"估算阶段结果偏保守"的量化体现，也解释了为什么不同阶段要用不同的规模调整因子。
2.6 拆解时最容易踩的坑（标准原文都有答案）
链接到标题
- 不重复计数：“修改客户"功能在菜单里出现五次，只要逻辑处理和 DET 集合相同，只计一次（6.3）。
- 菜单结构不计功能点，每个事务的启动触发器只计 1 个 DET（6.15、6.23）。
- 帮助功能：每种类型的帮助计一个 EQ（复杂度按低），不是每个页面的帮助各算一个（6.13）。
- 消息：一个事务里的所有提示/错误消息合计只算 1 个 DET，不是一条消息一个功能（6.14）。
- 列表选择框：下拉候选列表显示是 EO（规模不定），不是 EQ；但若数据来自 FPA 表（码表）则不单独计（6.16）。
- 码表类数据（国家代码、学历字典等）：全部打包计为一个"FPA 表 ILF/ELF”，不逐个算逻辑文件（6.20）。
- 登录、权限、操作系统功能：属于平台标准能力，不计（6.9、6.10）。
- 从 3NF 模型归并逻辑文件：双向强制关系的两个实体合成 1 个 LF（2 个 RET）；有疑问时按独立处理（6.21）。
flowchart TB
A["3NF 数据模型中的两个实体 A、B"] --> B{"关系类型?"}
B -->|"(1):(N) 双向可选"| C["2 个独立 LF"]
B -->|"1:N 双向强制"| D["1 个 LF, 2 个 RET<br/>DET 取总和"]
B -->|"1:(N) 单向可选"| E{"删除 A 时<br/>允许级联删 B?"}
E -->|"允许 (B 依赖 A)"| D
E -->|"不允许 (B 独立)"| C
B -->|"(1):N 单向可选"| F{"删除最后一个 B 时<br/>允许删 A?"}
F -->|"允许 (A 依赖 B)"| D
F -->|"不允许 (A 独立)"| C
B -->|"1:1 双向强制"| G["1 个 LF, 1 个 RET"]
B -->|"1:(1) 单向可选"| E
style C fill:#c8e6c9,stroke:#388e3c
style D fill:#bbdefb,stroke:#1976d2
style G fill:#bbdefb,stroke:#1976d2
这些细则是国标和"凭经验拆"拉开差距的地方：经验派两个人拆同一份需求能差 30%，标准派拿着规则逐条对，结果应该一致——标准原话是"对同一应用程序的功能点分析宜保持相同结果”。
三、钱怎么算：GB/T 36964 的成本度量流程
链接到标题
3.1 先划清边界：什么算"软件开发成本"
链接到标题
标准把软件开发过程定义为从立项到验收之间的需求分析、设计、编码、测试、交付及项目管理活动，成本只含这期间的人力成本 + 非人力成本，各分直接/间接：
flowchart TB
SDC["软件开发成本 SDC"]
DH["直接人力成本 DHC<br/>项目组员工工资、奖金、福利"]
DN["直接非人力成本 DNC<br/>办公/差旅/培训/业务/采购费"]
IH["间接人力成本 IHC<br/>部门经理、PMO、组织级 QA 分摊"]
IN["间接非人力成本 INC<br/>场地房租、水电、设备折旧分摊"]
SDC --> DH
SDC --> DN
SDC --> IH
SDC --> IN
SDC -.->|"❌ 不含"| N1["数据迁移费"]
SDC -.->|"❌ 不含"| N2["软件维护费"]
SDC -.->|"❌ 不含"| N3["开发方毛利润<br/>(报价时另行加上)"]
style SDC fill:#e8f5e9,stroke:#4caf50
style N1 fill:#ffcdd2,stroke:#d32f2f
style N2 fill:#ffcdd2,stroke:#d32f2f
style N3 fill:#ffcdd2,stroke:#d32f2f
两条关键的边界规则，报价时经常被忽略：
- 不包含数据迁移和软件维护成本——这两项要单独列；
- 不包含利润——标准明确"编制预算、报价或结算时，除软件开发成本外，考虑开发方合理的毛利润水平是必要的"。也就是说，国标算出来的 SDC 是成本，报价还要在此基础上加利润。
3.2 五步估算流程
链接到标题
标准的估算流程是一条清晰的流水线：
flowchart TB
S0["确定系统边界<br/>(明确项目范围)"] --> S1
subgraph S1 ["第 1 步: 规模估算"]
A1["NESMA 等五种标准方法<br/>之一数功能点 → US"] --> A2["乘规模变更因子 CF<br/>S = US × CF"]
end
S1 --> S2
subgraph S2 ["第 2 步: 工作量估算"]
direction TB
B0{"需求能否支撑<br/>规模估算?"}
B0 -->|能| B1["方程法<br/>UE = C × S^a"]
B0 -->|太模糊| B2["类比法 / 类推法<br/>对照基准库或历史项目"]
B1 --> B3["× 调整因子<br/>AE = UE × A × IL × L × T"]
B2 --> B3
B3 --> B4["输出区间 + 最可能值<br/>(25 / 50 / 75 百分位)"]
end
S2 --> S3
subgraph S3 ["第 3 步: 成本估算"]
direction TB
C1{"走哪条路线?"}
C1 -->|费率路线| C2["SDC = Σ(Ei×Fi) + DNC<br/>工作量 × 人力成本费率"]
C1 -->|单价路线| C3["SDC = P × S + DNC<br/>规模综合单价 元/fp"]
end
S3 --> S4["第 4 步: 间接成本分摊<br/>按工作量比例"]
S4 --> S5["第 5 步: 多方法交叉验证<br/>分歧大时专家评审 / 加权平均"]
style S0 fill:#e8f4fd,stroke:#2196f3
style S5 fill:#e8f5e9,stroke:#4caf50
第 1 步里最关键的动作是乘规模变更因子 CF，取值范围 1.0~2.0，标准建议：预算阶段 2.0，招标阶段 1.5，投标阶段 1.26，计划阶段 1.0。这个因子的含义是：越早期数出来的功能点越"瘦"，需求细化过程中必然长出来一大块（GB/T 42588 附录 C 称之为"自主增长"，区别于用户主动加需求的"范围蔓延"）。委托方预算按 2.0 放大、开发方投标按 1.26 放大，双方各自的风险都被标准照顾到了。
第 2 步的四个调整因子：
| 因子 | 含义 | 取值范围 |
|---|
| A | 应用领域调整因子 | 0.8~1.2 |
| IL | 软件完整性级别（GB/T 18492 的 A/B/C/D 四级） | 1.0~1.8 |
| L | 开发语言调整因子 | 0.8~1.2 |
| T | 最大团队规模调整因子 | 0.8~1.2 |
标准用示例演示了完整算法，验算一遍：
flowchart LR
A["规模 S = 1000 fp"] -->|"C=8/10/14 人时/fp<br/>(基准库 25/50/75 分位)"| B["UE = C × 1000^0.9<br/>4009.5 ~ 5011.87 ~ 7016.62 人时"]
B -->|"A=1, IL=1, L=0.8, T=1.1<br/>(合计 ×0.88)"| C["AE = 3528.36 ~ 4410.45 ~ 6174.63 人时<br/>✅ 区间 + 最可能值, 不是单一数字"]
style B fill:#fff8e1,stroke:#ffb300
style C fill:#e8f5e9,stroke:#43a047
注意标准的原则：“工作量和成本的估算结果宜为一个范围值”。
3.3 标准的核心哲学：一切对着基准数据
链接到标题
读 36964 会发现一个反复出现的关键词：基准数据（benchmark）。标准自己不含任何生产率数值和估算模型——它规定的是方法和流程，数值必须来自权威部门发布的行业基准库（如工信部主导的中国软件行业基准数据报告，含功能点耗时率、人月费率的分位数）。
flowchart TB
subgraph OPEN ["基准数据闭环"]
direction LR
DB["行业基准数据库<br/>功能点耗时率 / 人月费率<br/>分位数(25/50/75)"] -->|"估算输入"| E1["委托方: 编预算"]
DB -->|"估算输入"| E2["开发方: 做报价"]
DB -->|"估算输入"| E3["第三方: 造价评估"]
E1 & E2 & E3 -->|"项目结束后<br/>末期功能点计数 + 实际成本"| FEED["规模/工作量/成本<br/>实测数据回流"]
FEED --> DB
end
style DB fill:#fff8e1,stroke:#ffb300
style FEED fill:#e8f5e9,stroke:#43a047
这保证了三点：
- 数值可更新：每年行业生产率在变，基准库年年发布，方法不用改；
- 结果可复核：第三方造价评估机构拿同一份功能清单 + 同一版基准数据，能算出和你接近的结果；
- 利益可平衡：委托方用行业 50 百分位数做预算，开发方用自己组织的生产率数据投标，两边各有合法依据。
四、五大应用场景：全生命周期都有对应玩法
链接到标题
36964 附录 A（规范性附录）按生存周期划分了五个场景，每个场景的功能点精度和价格策略都不同：
flowchart LR
A["预算"] -->|批复| B["招投标"]
B -->|中标签约| C["项目计划"]
C -->|需求变化| D["变更管理"]
C & D -->|验收| E["结算 / 决算 / 后评价"]
A -.->|"预估法<br/>CF=2.0"| M1["NESMA"]
B -.->|"估算法<br/>CF: 招标1.5 / 投标1.26"| M1
C -.->|"详细法<br/>CF=1.0"| M1
D -.->|"中期功能点计数"| M1
E -.->|"末期详细计数"| M1
style A fill:#e8f4fd,stroke:#2196f3
style B fill:#fff3e0,stroke:#ff9800
style C fill:#e8f5e9,stroke:#4caf50
style D fill:#f3e5f5,stroke:#9c27b0
style E fill:#fce4ec,stroke:#e91e63
style M1 fill:#fffde7,stroke:#fbc02d
| 场景 | 功能点方法 | 规模变更因子 | 定价要点 |
|---|
| 预算 | 预估法 | 2.0 | 需求明确取 50 百分位，不明确取 75 百分位；预算应附功能清单及功能点数 |
| 招投标 | 估算法 | 招标 1.5 / 投标 1.26 | 招标方据此设评标基准价和最低/最高合理报价；投标文件必须含功能清单及功能点数 |
| 项目计划 | 详细法 | 1.0 | 总工作量分解到各任务，与工期约束交叉调整 |
| 变更管理 | 中期计数 | — | 变更前后按标准公式算规模差，双方评审确认变更成本 |
| 结算/决算 | 末期详细计数 | — | 按最终功能清单结算；数据回流基准库，形成闭环 |
招投标场景尤其值得展开。标准要求招标方基于估算结果设定评标基准价、投标最低合理报价、投标最高合理报价：
flowchart TB
A["招标方成本估算<br/>(估算法 + 基准数据)"] --> B["+ 行业平均毛利率<br/>+ 维护要求"]
B --> C["合理招标价区间"]
C --> D1["下限 → 投标最低合理报价"]
C --> D2["上限或项目预算<br/>→ 投标最高合理报价"]
C --> D3["中值或有效报价均值<br/>→ 评标基准价"]
D3 --> E["基于评标基准价<br/>制定价格评分方法"]
F["投标人报价"] --> G{"落入<br/>[最低, 最高] 区间?"}
G -->|"低于下限"| H["❌ 不合理报价<br/>价格评分 0 分"]
G -->|"高于上限"| H
G -->|有效| I["✅ 参与价格评分"]
style H fill:#ffcdd2,stroke:#d32f2f
style I fill:#c8e6c9,stroke:#388e3c
这直接治理了两类顽疾：恶意低价抢标（低于成本竞标被标准明文禁止）和预算套高。报价的合理性不再靠评标专家的感觉，而是靠功能点数 × 基准单价区间这条硬线。
变更管理场景给出了增强项目的标准算法（删除功能也计工作量，因为删代码同样要花钱——很多合同漏掉的部分）：
flowchart TB
subgraph PROJ ["项目规模 (决定要收多少钱)"]
P["EFP = ADD + DEL + CHGA<br/>新增 + 删除 + 更改后规模"]
end
subgraph APP ["应用规模 (决定系统变成多大)"]
A["AFPA = 旧规模 + ADD − DEL + (CHGA − CHGB)"]
end
C["变更请求"] --> P
C --> A
P -->|"乘耗时率 + 费率<br/>双方评审确认"| M["变更成本"]
style P fill:#fff3e0,stroke:#ff9800
style A fill:#e8f4fd,stroke:#2196f3
style M fill:#e8f5e9,stroke:#4caf50
五、落地建议：怎么在自己的项目里用起来
链接到标题
flowchart TB
subgraph DEV ["开发方"]
direction TB
D1["投标前: 估算法自查<br/>功能点 × 1.26 × 基准耗时率<br/>算出成本底线"]
D2["合同: 争取功能点单价计价<br>写入 EFP 变更结算条款"]
D3["结项: 末期计数 + 实际工时<br/>沉淀组织级基准数据"]
D1 --> D2 --> D3
end
subgraph CUST ["委托方"]
direction TB
C1["需求书按 NESMA 输入要求写<br/>(至少功能清单 + 数据组级别)"]
C2["预算: 预估法 × 2.0<br/>+ 基准分位数取值"]
C3["评标: 写明估算方法与基准价规则<br/>用合理报价区间过滤异常"]
C1 --> C2 --> C3
end
D3 -.->|"自家生产率数据<br/>对标行业基准"| C2
style DEV fill:#fff3e0,stroke:#ff9800
style CUST fill:#e8f4fd,stroke:#2196f3
无论哪一方，都建议：功能点计数结果让用户参与确认（42588 第 4.6 条：用户是唯一能确定某项功能是否需要的角色），并记录所有假设条件和制约因素——争议的种子往往在计数阶段就埋下了。
“凭经验"的本质问题是不可复制、不可复核、不可积累。国标这套体系的价值不在于它算得更准——估算永远是估算——而在于它把定价过程变成了双方可以共同检查的透明流程：功能点数可以逐条对，生产率有基准库可查，每个调整因子有取值范围可辩，最终报价可以拆回到每一个功能上。
软件定价从手艺变成工程，靠的就是这种标准。别再拍脑袋了。
标准信息
- GB/T 36964-2018《软件工程 软件开发成本度量规范》，2018-12-28 发布，2019-07-01 实施
- GB/T 42588-2023《系统与软件工程 功能规模测量 NESMA 方法》（ISO/IEC 24570:2018, MOD），2023-05-23 发布，2023-12-01 实施
📩 需要两份标准的原始 PDF？邮件联系我：i@lixx.cn，我看到后会发给你。