企业官网建设流程全解析

在信息化升级改造项目的造价评审中，有一类争议反复出现：

"我们代码都改了，测试也过了，为什么这个功能点不给算？"

提出这类异议的通常是承建方的项目管理人员。送审材料中往往包含一长串变更项：审批时限调整、列表新增字段、页面布局优化……每一项从开发角度看都对应了实际工作量，但按照功能点计量规则核查，其中相当一部分无法计为新增功能规模。

但在讨论"能不能计"之前，有一个更容易被误解的前提必须先说清楚：功能点评审查减某个计数项，并不等于否定相应的开发工作量。

一、先把这件事说清楚：不计功能点，不等于不认可工作量

功能点法回答的问题是"这套软件向用户交付了多少功能规模"，而不是"开发方投入了多少人力"。这是两把不同的尺子。各地标准在给出功能点法的同时，基本都保留了工作量法（人天／人月）作为并行的计价路径：

• 广东省《省级政务信息化服务预算编制标准（试行）》软件开发服务分册（粤财行〔2019〕82号）第 5.1 条规定，定制软件开发服务费"可按照功能点估算法或工作量估算法进行估算"，并分别给出了两套预算表；
• 海南省《政务信息化项目投资编制标准（2026 年修订版）》2.1.3 条同时列出了"功能点估算软件开发工作量法"与"专家经验估算软件开发工作量法"两条路径。采用功能点法核算的，测算的是软件功能规模；采用专家经验法核算的，则直接以人月工作量计价；
• 河南省《关于省级政务信息化建设项目支出预算标准的规定》（豫财预〔2024〕105号）在"应用系统定制开发费"整包口径下编制预算，工作量以人月为计量单位。

也就是说，一项改动即使不构成新增功能点，它真实的开发投入仍未消失，只是换了计价通道：属于建设期内的实施工作量，可以在工作量（人月）口径下体现；发生在系统交付验收之后的零星调整，则通常纳入运维服务的"优化改善"范畴。

所以，功能点评审更准确的表述是："这项改动不构成新增功能规模"，而不是"这项改动没有价值"。

二、功能点计量的核心对象：用户可识别的功能规模

多数争议的缘由，是将功能点法等同于开发工作量的计量工具。

功能点的通行定义是"衡量软件功能规模的一种单位"（四川《四川省信息化项目费用测算标准》T/SCSIA 0015—2025；北京《信息化项目软件开发费用测算规范》DB11/T 1010—2019）。它计量的是软件功能规模，即系统向用户交付的功能能力，而不是开发过程中的代码量或人天投入。

理解"功能规模"与"工作量"的区分，是理解后续所有判定规则的前提。功能点方法之所以将"用户可识别"作为贯穿五类计数项的判定主线，是因为在功能规模度量的框架下，只有用户能够识别和操作的部分，才构成软件的"功能规模"；仅存在于技术实现层面、用户感知不到的改动，通常不增加软件的功能规模。

• 内部逻辑文件（ILF）与外部接口文件（EIF）
• 须为"用户可识别的逻辑相关数据组或控制信息"。
• 程序内部常量、后台参数、代码字典等用户不可感知的数据实体，属于代码数据实体，一般在计数中被排除。
• 外部输入（EI）、外部输出（EO）、外部查询（EQ）
• 是穿越系统边界、向用户提供完整业务价值的基本处理过程。
• 后台算法、样式文件、中间临时数据表等不直接面向用户的技术实现，通常本身不构成计数对象。

事项被核减，并不意味着否定相应的开发工作。参数调整与界面调整客观上需要投入开发资源，但如果此类改动未使用户获得新的可识别业务能力，则不产生新增功能规模。对应的开发投入，宜在工作量或人天报价层面体现，或按各地规定纳入运维口径，不宜包装为新增功能点申报。

三、计数方法的适用边界

在具体分析流程参数调整与界面优化之前，有必要先明确计数方法的适用范围。方法选择不当，后续判定将失去基准。

功能点计数主要有三种方法，各自对应不同的项目阶段与适用场景。升级改造项目的一个常见误区，是直接套用新开发项目的计数口径。

编辑

关于方法适用阶段，各地标准有较为明确的建议：

• 四川省 T/SCSIA 0015—2025
• 明确：预估功能点计数法"一般情况下仅适用新开发项目，对升级改造项目不适用"；标准功能点计数法"一般适用于所有项目，尤其适用于需度量转换功能和增强功能的项目，如升级改造类、结算阶段的项目"。
• 海南省《政务信息化项目投资编制标准（2026年修订版）》2.1.3 条
• 规定："在项目可行性研究报告及估算阶段宜采用预估功能点方法进行功能点规模测算"；"在项目初步设计及概算、项目预算阶段宜采用估算功能点方法进行功能点规模测算"。同时规定，原则上可研报告和初步设计阶段的应用类定制软件开发均需采用功能点估算工作量法，采用 IFPUG 方法测算。
• 河南省《关于省级政务信息化建设项目支出预算标准的规定》（豫财预〔2024〕105号）
• 则规定，其预算标准中工作量的测算采用预估功能点方法，仅需识别数据功能，功能点数合计＝35×ILF 总数＋15×EIF 总数。
• 山东省《山东省省级政务信息化建设项目支出预算编制标准（试行）》（鲁财数〔2024〕1号）
• 明确采用 NESMA 功能点度量方法。可见各地对计数方法的选择偏好并不相同——报送前先确认项目适用哪一套口径，比"套用最熟悉的算法"更稳妥。

需要提醒的是，升级改造项目不宜将改造内容按全新开发口径全量报送。功能点方法度量的是相对于既有系统的用户可感知净变化，即转换功能与增强功能，而不是对整套系统功能的重新统计。部分标准在方法选择上已有体现（如四川 T/SCSIA 0015—2025 将标准功能点计数法列为"尤其适用于需度量转换功能和增强功能的项目，如升级改造类、结算阶段的项目"）。

四、ILF／EIF 判定：流程参数与代码数据的区分

流程参数调整往往涉及后台参数配置，这也是功能点虚报较为集中的领域——将参数字典、程序控制表包装为内部逻辑文件 ILF。

ILF 的识别需逐项排除若干类实体。四川省 T/SCSIA 0015—2025（附录 C"功能点识别规则"）与海南省《政务信息化项目投资编制标准（2026年修订版）》（附录 C.2.1）对此有同源规定。以四川省标准为例，ILF 的识别规则包括：

1. 识别计数范围内所有逻辑相关且用户可识别的数据或控制信息；
2. 排除不被任何应用维护的实体；
3. 分组实体依赖的相关实体；
4. 排除代码数据实体；
5. 排除不包括用户要求的属性的实体；
6. 去掉包括非用户要求的附加属性的关联实体以及仅包括外键的关联实体，把外键属性分组给主实体；
7. 如果数据功能由被度量应用维护，则为一个 ILF；
8. 如果数据同时满足 ILF 和 EIF 规则，则将其识别为 ILF。

浙江省《政务信息化项目软件开发费用测算规范》（DB3303/T 059—2023）、福建省及长沙、徐州等地标准，也有同源规定。这一组规则的共同指向，是"由用户维护、且用户可识别"。

上述规则在实际应用中可归纳为一条便于操作的判定路径：以用户的视角审视目标数据，依次确认三项条件——该数据是否具有明确的业务含义？用户是否可在系统界面中定位到该数据？用户是否可通过系统界面对其进行操作？三项条件均满足时，才具备计为 ILF／EIF 的基础。

以人员职级字典、审批时限参数表为例，如果此类数据仅用于程序下拉取值、用户无对应的维护界面，则属于代码数据，一般不计为 ILF。反之，如果系统提供了专门的配置管理界面，业务用户可自主维护审批策略、黑名单规则等业务对象，则该规则库具有"用户可识别"的属性，具备计为 ILF 的条件，对应的维护操作也可能计为 EI。

这里的关键在于"维护"二字。代码数据与流程参数的主要区别，不在于数据本身的技术形态，而在于用户是否拥有对其进行维护的能力和入口。用户无法维护的数据，即使业务含义明确，一般也不构成 ILF／EIF。

因此，数据是否可由用户通过系统界面进行维护，是区分流程参数与代码数据时较为直观的一条界限。仅涉及后台参数修改的流程参数调整，通常难以跨越这一界限。

五、事务功能判定：流程参数调整与界面优化的计量边界

事务功能的核心计量单元是"基本过程"。基本过程的合并条件，在各地标准中表述高度一致——《四川省信息化项目费用测算标准》T/SCSIA 0015—2025 附录 C、海南省《政务信息化项目投资编制标准（2026年修订版）》附录 C.7 均有同源规定。以《四川省信息化项目费用测算标准》表述为例：

"当把一个基本过程和其它已经识别出来的基本过程比较时，如果它们满足下列条件，则应把这两个相似的基本过程当作同一个基本过程：（1）包括相同的 DETs；（2）包括相同的 FTRs；（3）完成基本过程的处理逻辑相同。"

即：数据元素类型（DET）、引用文件类型（FTR）与处理逻辑三者同时相同，应合并为一个基本过程，不宜拆分计数。

这一合并规则是处理流程参数调整与界面微调争议的核心依据。其底层逻辑在于：功能点计量的是"用户可感知的完整业务过程"。如果两个过程在数据输入、引用数据和处理逻辑上一致，那么对用户而言它们更接近同一个过程，不宜因技术实现上的拆分而重复计数。

（一）流程参数调整的常见情形

实际项目中的规则变更不宜一概而论，通常按以下三类情形分别处理。

第一类，用户可维护的业务规则对象。系统提供界面，允许业务用户新增、编辑、启用停用审批策略或业务黑名单。此类情形下，规则库具有用户可识别的属性，可能计为 ILF，对应的维护操作可能计为 EI。判定要点在于用户是否可识别、可操作系统内的规则。

第二类，仅内部参数或算法阈值调整。例如审批时限修改、阈值调整、新增节假日顺延逻辑等，仅涉及后台配置变更，未向用户提供新的操作入口。此类改动一般不构成新增功能点，属于代码数据层面的调整；开发工作量客观存在，但不产生新增功能规模。

第三类，原有功能入口保持不变，规则变更导致输出结果发生变化。此类情形一般不宜作为全新 EI／EO 报送。在升级改造项目中，宜通过增强功能口径度量变更规模。以广东省（粤财行〔2019〕82号）软件开发服务分册 5.2 为例，定制软件升级服务费按"定制软件实际开发服务费×升级功能变化率"计算，其中升级功能变化率根据需升级的未调整功能点数量与原系统未调整功能点数量估算，取值上限不超过 30%；预算阶段无法确定具体修改需求时，可采用推荐值 15%。江苏省《徐州市市级政务信息化建设及运行维护项目支出预算标准（试行）》（徐财评〔2021〕5号）、盐城市信息化项目造价评估报告编制指南（2024）等，也采用了"升级功能变化率"这一口径。

综上，流程参数调整能否计为新增功能点，判定标准不在于规则本身是否发生变化，而在于用户是否获得了新的可操作入口或新的可识别业务能力。仅涉及后台参数修改、用户感知不明显的规则变更，一般不计新增功能点。

（二）前端界面优化的判定逻辑

界面是功能的呈现载体，页面发生改动并不等同于功能新增。

• 第一种情形
• 列表新增展示字段、调整排序、修改布局、变更按钮样式与文案。此类改动若数据源 FTR 与处理逻辑均未发生变化，通常不构成新的事务功能。
• 第二种情形
• 在原有查询基础上新增筛选条件，例如增加办结时间区间筛选。此类改动若未形成全新的完整业务过程，一般并入原有查询基本过程，不单独新增 EQ。
• 第三种情形
• 新增了此前不存在的完整业务能力，例如原系统无报表导出功能，现新增带计算逻辑的统计报表导出。此类改动产生了新的基本过程，可以计为 EO。

界面优化的判定标准与流程参数调整基本一致：用户是否获得了新的、可识别的完整业务能力。新增展示列、调整样式、增加筛选条件等改动，多属于对原有功能的局部调整；只有新增了独立、完整的业务过程时，才具备计为新事务功能的条件。

除上述按"是否形成新的基本过程"作定性判定外，实际项目中还有两条可量化的度量路径。

路径一：判断复杂度增量。标准功能点计数法并不直接看"页面改了多少"，而是通过识别 DET（数据元素类型）、RET（记录元素类型）、FTR（引用文件类型）判定事务功能的复杂度等级，再按复杂度加权取值（依据 GB/T 36964—2018《软件工程 软件开发成本度量规范》及 IFPUG 功能规模度量方法）。据此，界面调整的规模增量可以这样核查：若改动未引入新的 FTR，处理逻辑也未发生变化，仅 DET 有局部增减，复杂度等级通常维持在原有档位，不产生规模增量；只有当 DET 或 FTR 的增减使复杂度跨越等级边界时，才对应产生可计量的规模增量。这一路径的意义在于，把"界面改了、所以该加钱"的笼统主张，转换为可逐项核对的复杂度比对。

路径二：引入修改类型。部分地方标准在功能点明细表中专门设置了"修改类型"字段，要求逐项标注该计数项的性质——是全新新增，还是在既有功能上的修改，以避免"在既有功能上做改动、却按新增功能计列"。例如湖南省《长沙市财政评审中心政府投资信息化项目评审指南》（长财评综〔2023〕12号）附录 A.6"开发规模估算表"、湖南省《益阳市市本级政府投资信息化项目预算编制与财政评审工作指南（试行）》（益财评〔2024〕346号）附录 A.1.1.1.1"定制软件开发费（功能点法）明细表"，均在"类别—UFP—重用程度"之外单列"修改类型"列，由修改类型与重用程度共同决定该项的未调整规模（US）。对评审方而言，这一列是识别"改动包装成新增"的抓手；对报送方而言，也是报送前的自查清单。

（三）移动端重复功能的处理

对于移动终端（包括 iOS、安卓、小程序等）与 PC 端重复的事务功能（EI／EO／EQ），实务中通常按重用程度进行折算。各地标准对此多有直接规定，但折算口径差异较大：

• 湖南省《长沙市财政评审中心政府投资信息化项目评审指南》（长财评综〔2023〕12号）
• 规定：若存在 PC 终端和移动终端共用的功能，在 PC 端已计取功能点的情况下，移动终端的数据功能（ILF／EIF）不可重复计取，重复的事务功能（EI／EO／EQ）可按高重用程度（1/6）计取；移动终端包括 iOS、安卓和小程序（移动端 Web 应用、微信小程序、支付宝小程序、钉钉小程序等）三类，其中小程序类不论终端种类原则上只计一次。湖南省《益阳市市本级政府投资信息化项目预算编制与财政评审工作指南（试行）》（益财评〔2024〕346号）采用同一口径，将此类重用程度称为"超高级"，RE 取值 1/6。
• 四川 T/SCSIA 0015—2025 在复用度识别规则中明确，移动端与 PC 端重复的事务功能，重用程度为高，按 1/3 计。
• 海南 2026 年修订版则规定，重用程度原则上默认取中（2/3）。

可见，"多端分别全量报送"在各地标准下都难以成立；至于按 1/6、1/3 还是 2/3 折算，则取决于项目所在地适用的标准。

在实际项目中，部分项目将多端复刻的查询、填报功能全量报送，这是评审中较为常见的核减项。移动端界面虽为重新开发，但功能与 PC 端重复，用户未获得新的业务能力，宜按重用程度折算。

上述三类判定规则覆盖了流程参数调整与前端界面优化的主要场景，但实际项目中的情况往往更为复杂——一项改动可能同时涉及参数调整与界面新增，一个查询可能既增加字段又修改处理逻辑，此类边界情形需要结合需求文档与实际操作路径逐项研判。

六、各地标准的口径差异：几个容易踩坑的取值

功能点方法的原理全国同源，但具体参数取值各地差异明显，跨地区直接套用存在风险。以下是几项评审中容易被忽视、又最容易引发争议的差异（均引自各地已发布标准，实际项目应以当地现行有效版本为准）。

其一，复用度（重用程度）的默认取值不同

这是决定"调整改造类改动按几折算"的关键参数。

• 四川省 T/SCSIA 0015—2025 以"中（2/3）"为默认值，并对通用模块（用户、角色、权限、系统管理、系统日志等）及移动端与 PC 端重复的事务功能，规定了更高的重用程度。
• 海南省（2026年修订版）2.1.3 条规定："重用程度有高（1/3）、中（2/3）、低（1）三个级别。通常情况下，重用程度默认为中。"
• 广东省（粤财行〔2019〕82号）软件开发服务分册表 3 备注明确："在预算阶段，新建项目的复用度调整系数默认取值为1（复用度低），根据实际情况进行调整；在已有软件系统或功能模块基础上进行优化完善或调整改造的，复用度调整系数默认取值为2/3（复用度中）。"

同一项"在原有系统上做优化调整"的改动，按新建项目的"低复用（1）"计算，与按调整改造的"中复用（2/3）"计算，规模相差三分之一。这是评审双方最容易产生分歧、也最需要先把口径对齐的地方。

其二，升级改造的规模阈值不同

广东（粤财行〔2019〕82号）5.2 以"功能点变化率不超过 30%（推荐值 15%）"界定定制软件升级服务；江苏省《徐州市市级政务信息化建设及运行维护项目支出预算标准（试行）》（徐财评〔2021〕5号）等也采用"升级功能变化率"口径。

其三，建设期与运维期的边界不同

海南省（2026年修订版）4.3 条第二项规定："定制开发软件优化功能的业务范围≤15%，优化功能的开发费用不高于项目投资的 15% 且不大于 100 万元的优化升级费用，可按运维项目申报。"同时，该标准第四章注 7 明确，成品软件、定制开发软件的运行维护费，自项目竣工验收之日起至少 2 年后（硬件设备至少 3 年）再开始计算。换言之，交付后的零星参数调整、界面微调，是否走运维通道、何时可以启动运维计费，各地规定并不相同。

其四，关键测算参数不同

表中"人月折算系数"的差异看似微小（174 与 176），但在大额项目上会放大；PDR、人月费率的地区差异更为直接。这也正是"严禁跨地区直接套用计量口径"的原因所在。

七、实际项目中的注意事项

其一，功能点计量应遵循项目适用的计量标准。不同标准在计数规则、调整因子、参数取值等方面可能存在差异，正式项目判定应以对应标准的正式发布文本为准，并注意标准是否已有修订版本（如海南已发布 2026 年修订版）。

其二，不宜跨地区直接套用计量口径。各地标准对复用系数、生产率 PDR、人月费率、人月折算系数的取值存在差异，部分地区预算阶段的重用程度默认取值为低（1），部分地区默认取值为中（2/3）。直接套用某一地区的规则至其他地区项目，计量结果可能出现偏差。

其三，明确建设期改造与运维服务的边界。系统交付后的零星参数调整、界面微调，通常属于运维服务范畴；部分地区还给出了"优化功能业务范围≤15% 且费用不超过一定金额可按运维项目申报"的具体阈值（如海南 2026 年修订版）。应注意避免建设期与运维期的重复计费。

其四，功能点计数不宜脱离合同约束。合同计价约定与适用计量标准存在冲突时，宜结合合同约定综合研判，二者均难以单独作为唯一判定依据。

在功能点识别与造价评估工作中，可借助软件造价喵提升效率与准确性。软件造价喵是基于 AI 大模型的软件造价评估工具，可自动解析需求文档、智能识别功能点，每项功能点的识别均附有详细合规解释，并支持原文本与识别结果一一对应的在线修订复核，一键生成满足财政评审与审计要求的合规测算报告。平台内置各省市、各行业软件造价标准70余项及国内10年全量软件行业基准数据。

结语：两把尺子，各自归位

回到文章开篇提出的问题：流程参数调整、前端界面优化，为什么不能算功能点？

其根本原因在于，功能点计量的对象是用户可识别的新增功能能力，而非开发过程中的技术实现工作量。审批时限由5天调整为3天，用户的操作入口与可识别业务能力均未发生变化，仅后台参数有所调整；列表新增字段、调整按钮位置，用户的查询过程与处理逻辑基本保持不变，仅展示方式有所调整。此类改动均需投入开发资源，但一般不产生新增功能规模。

但同时也要回到本文开头的那句话：这不等于否定开发投入。功能点法不是用来否定付出，而是建立一套超越技术实现细节的统一计量标尺——它不关心开发方写了多少行代码、调整了多少个参数，只关心用户最终获得了什么新能力。这把尺子可能让部分调整性投入在"功能点"这一栏上看不见，但它保证了计量结果的客观性和可比较性；而这些投入，仍可以在工作量法、运维服务等其他口径中被合理体现。

这也提醒我们：功能点法的价值，恰恰在于它把"功能规模"与"开发投入"两件事分开了。分开之后，该由功能点计的按功能点计，该由工作量或运维口径体现的按对应口径体现，双方才有对齐认知、达成共识的基础。