在信息化升级改造项目的造价评审中有一类争议反复出现我们代码都改了测试也过了为什么这个功能点不给算提出这类异议的通常是承建方的项目管理人员。送审材料中往往包含一长串变更项审批时限调整、列表新增字段、页面布局优化……每一项从开发角度看都对应了实际工作量但按照功能点计量规则核查其中相当一部分无法计为新增功能规模。但在讨论能不能计之前有一个更容易被误解的前提必须先说清楚功能点评审查减某个计数项并不等于否定相应的开发工作量。一、先把这件事说清楚不计功能点不等于不认可工作量功能点法回答的问题是这套软件向用户交付了多少功能规模而不是开发方投入了多少人力。这是两把不同的尺子。各地标准在给出功能点法的同时基本都保留了工作量法人天人月作为并行的计价路径广东省《省级政务信息化服务预算编制标准试行》软件开发服务分册粤财行〔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 将标准功能点计数法列为尤其适用于需度量转换功能和增强功能的项目如升级改造类、结算阶段的项目。四、ILFEIF 判定流程参数与代码数据的区分流程参数调整往往涉及后台参数配置这也是功能点虚报较为集中的领域——将参数字典、程序控制表包装为内部逻辑文件 ILF。ILF 的识别需逐项排除若干类实体。四川省 T/SCSIA 0015—2025附录 C功能点识别规则与海南省《政务信息化项目投资编制标准2026年修订版》附录 C.2.1对此有同源规定。以四川省标准为例ILF 的识别规则包括识别计数范围内所有逻辑相关且用户可识别的数据或控制信息排除不被任何应用维护的实体分组实体依赖的相关实体排除代码数据实体排除不包括用户要求的属性的实体去掉包括非用户要求的附加属性的关联实体以及仅包括外键的关联实体把外键属性分组给主实体如果数据功能由被度量应用维护则为一个 ILF如果数据同时满足 ILF 和 EIF 规则则将其识别为 ILF。浙江省《政务信息化项目软件开发费用测算规范》DB3303/T 059—2023、福建省及长沙、徐州等地标准也有同源规定。这一组规则的共同指向是由用户维护、且用户可识别。上述规则在实际应用中可归纳为一条便于操作的判定路径以用户的视角审视目标数据依次确认三项条件——该数据是否具有明确的业务含义用户是否可在系统界面中定位到该数据用户是否可通过系统界面对其进行操作三项条件均满足时才具备计为 ILFEIF 的基础。以人员职级字典、审批时限参数表为例如果此类数据仅用于程序下拉取值、用户无对应的维护界面则属于代码数据一般不计为 ILF。反之如果系统提供了专门的配置管理界面业务用户可自主维护审批策略、黑名单规则等业务对象则该规则库具有用户可识别的属性具备计为 ILF 的条件对应的维护操作也可能计为 EI。这里的关键在于维护二字。代码数据与流程参数的主要区别不在于数据本身的技术形态而在于用户是否拥有对其进行维护的能力和入口。用户无法维护的数据即使业务含义明确一般也不构成 ILFEIF。因此数据是否可由用户通过系统界面进行维护是区分流程参数与代码数据时较为直观的一条界限。仅涉及后台参数修改的流程参数调整通常难以跨越这一界限。五、事务功能判定流程参数调整与界面优化的计量边界事务功能的核心计量单元是基本过程。基本过程的合并条件在各地标准中表述高度一致——《四川省信息化项目费用测算标准》T/SCSIA 0015—2025 附录 C、海南省《政务信息化项目投资编制标准2026年修订版》附录 C.7 均有同源规定。以《四川省信息化项目费用测算标准》表述为例当把一个基本过程和其它已经识别出来的基本过程比较时如果它们满足下列条件则应把这两个相似的基本过程当作同一个基本过程1包括相同的 DETs2包括相同的 FTRs3完成基本过程的处理逻辑相同。即数据元素类型DET、引用文件类型FTR与处理逻辑三者同时相同应合并为一个基本过程不宜拆分计数。这一合并规则是处理流程参数调整与界面微调争议的核心依据。其底层逻辑在于功能点计量的是用户可感知的完整业务过程。如果两个过程在数据输入、引用数据和处理逻辑上一致那么对用户而言它们更接近同一个过程不宜因技术实现上的拆分而重复计数。一流程参数调整的常见情形实际项目中的规则变更不宜一概而论通常按以下三类情形分别处理。第一类用户可维护的业务规则对象。系统提供界面允许业务用户新增、编辑、启用停用审批策略或业务黑名单。此类情形下规则库具有用户可识别的属性可能计为 ILF对应的维护操作可能计为 EI。判定要点在于用户是否可识别、可操作系统内的规则。第二类仅内部参数或算法阈值调整。例如审批时限修改、阈值调整、新增节假日顺延逻辑等仅涉及后台配置变更未向用户提供新的操作入口。此类改动一般不构成新增功能点属于代码数据层面的调整开发工作量客观存在但不产生新增功能规模。第三类原有功能入口保持不变规则变更导致输出结果发生变化。此类情形一般不宜作为全新 EIEO 报送。在升级改造项目中宜通过增强功能口径度量变更规模。以广东省粤财行〔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 端重复的事务功能EIEOEQ实务中通常按重用程度进行折算。各地标准对此多有直接规定但折算口径差异较大湖南省《长沙市财政评审中心政府投资信息化项目评审指南》长财评综〔2023〕12号规定若存在 PC 终端和移动终端共用的功能在 PC 端已计取功能点的情况下移动终端的数据功能ILFEIF不可重复计取重复的事务功能EIEOEQ可按高重用程度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天用户的操作入口与可识别业务能力均未发生变化仅后台参数有所调整列表新增字段、调整按钮位置用户的查询过程与处理逻辑基本保持不变仅展示方式有所调整。此类改动均需投入开发资源但一般不产生新增功能规模。但同时也要回到本文开头的那句话这不等于否定开发投入。功能点法不是用来否定付出而是建立一套超越技术实现细节的统一计量标尺——它不关心开发方写了多少行代码、调整了多少个参数只关心用户最终获得了什么新能力。这把尺子可能让部分调整性投入在功能点这一栏上看不见但它保证了计量结果的客观性和可比较性而这些投入仍可以在工作量法、运维服务等其他口径中被合理体现。这也提醒我们功能点法的价值恰恰在于它把功能规模与开发投入两件事分开了。分开之后该由功能点计的按功能点计该由工作量或运维口径体现的按对应口径体现双方才有对齐认知、达成共识的基础。