信息化项目软件开发费用测算指南

软件及信息化工程造价行业规范 信息化项目软件开发费用测算指南信息化项目软件开发费用测算指南 V4.0V4.0 重庆市首席信息官（CIO）协会 2017 年 10 月 1 日发布实施 软件及信息化工程造价行业规范 本办法由重庆市首席信息官（CIO）协会 软件及信息化工程造价评估专委会 编制 重庆市首席信息官（CIO）协会 联系电话软件及信息化工程造价行业规范 I 目目 次次 前言.II 信息化项目软件开发费用测算指南.- 1 - 1范围.- 1 - 2术语和定义.- 1 - 3软件开发成本构成. - 3 - 4软件开发成本测算步骤.- 4 - 附 录 A.- 8 - A.1功能点计数项分类.- 8 - A.2ILF 的识别. - 8 - A.3EIF 的识别. - 8 - A.4EI 的识别. - 8 - A.5E0 的识别. - 8 - A.6EQ 的识别. - 9 - 附 录 B.- 10 - B.1功能点分值计算方法.- 10 - B.2技术复杂度因子 TCF.- 11 - B.3功能点耗时率.- 11 - B.4软件因素调整因子（SWF）.- 11 - B.5开发因素调整因子（RDF）.- 13 - B.6各阶段开发工作量比例系数.- 13 - B.7人月费用. - 14 - 附 录 C.- 15 - C.1预估功能点计数表样例.- 15 - C.2估算功能点计数表样例.- 16 - C.3详细功能点清单列表.- 17 - C.4软件项目开发费用测算表样例.- 18 - C.5开发软件需求书写规范样例.- 19 - 附 录 D.- 23 - D.1需求示意. - 23 - D.2测算规模. - 23 - D.3确定预算. - 24 - 软件及信息化工程造价行业规范 II 前前言言 本指南系根据国家工信部颁布的 电子建设工程概 （预） 算编制办法及计价依据 （HYD 41-2015） （工信厅规201577号）、工信部行业标准软件研发成本度量规范 （SJ/T11463-2013）、ISO/IEC 14143功能点度量国际标准、软件及信息化工程造价管理办法(V4.0)和信息化项目软件开发费 用测算指南(V3.0)等国内外行业标准与规范，并结合软件及信息化工程咨询评估机构开展的700 余例软件及信息化工程造价评估咨询服务案例实践，研制的一套基于行业成本测算模型和方法。 本指南能科学有效地对软件项目的功能规模、工作量、工期、开发成本进行合理测算，并能指 导用户采用软件功能点法对用户需求、项目招标书、项目合同、项目概预算、项目验收与结算、项 目运维费用计算、项目质量等软件项目全生命周期进行有效管理，能规范信息化项目软件开发涉及 的各方在信息化项目软件开发费用测算方法上达成一致，以满足软件产业发展的迫切需求。 本指南不包含信息化项目软件开发费用测算过程中所需使用的各种基准数据或测算模型，相关 各方在使用本标准时，应参考权威部门或行业协会发布的最新基准数据、测算模型开展信息化项目 软件开发费用测算相关活动。对于一些定性数据如调整因子的设置和权重，在参考其它标准基础上， 由本指南的编委会经技术讨论会议产生。 本指南2017年10月1日发布实施，原信息化项目软件开发费用测算指南(V3.0)同时废止。 软件及信息化工程造价行业规范 - 1 - 信息化项目软件开发费用测算指南信息化项目软件开发费用测算指南 1 1 范围范围 本指南规定了信息化项目软件开发费用测算的方法及过程，包括软件开发费用的构成、 软件开发费用测算过程、 软件开发费用测算的应用。 其目的是帮助信息化项目软件开发涉及 各方科学、一致地进行费用测算。 本指南适用于政府部门、 事业单位、 国有企业 （包含但不限于： 软件工程项目设计单位、 业主单位、概预算编制与审核单位、监理机构、测评机构、审计单位）等用户的信息化项目 软件开发费用测算，且费用测算与功能规模密切相关。 本指南不适用于测算以非功能性需求为主， 或包含大量复杂算法， 或以创意为主的信息 化项目软件开发费用。 本指南不涉及软件定价， 但相关各方可依据本指南明确开发成本， 从而为软件定价提供 重要依据。 涉及软件功能需求分析员、软件概预算编制与审核人员、软件投标报价专员、软件测评 专员、软件工程结算审核人员、软件工程审计专员等人员经培训，取得软件工程造价师、软 件工程造价评估师的资质，可开展信息化项目软件开发费用测算工作。 2 2 术语和定义术语和定义 下列术语和定义适用于本指南。 2.12.1 软件开发成本软件开发成本 为达成软件开发项目目标开发方所需付出的各种资源代价总和。 注：注：资源包括人、财、物、信息等。 2.22.2 软件开发收入软件开发收入 向客户交付软件开发工作成果所获得的收益。 2.32.3 毛利润毛利润 软件开发项目的收入与软件开发项目的成本之差。 注：注：一般包含经营管理费用分摊、市场销售费用分摊、各种税费及税后净利。 2.42.4 直接成本直接成本 为达成软件开发项目目标而直接付出的各种资源代价总和。 注：注：如可直接计入软件开发项目成本的直接材料、直接人工等。 2.52.5 间接成本间接成本 与达成软件开发项目目标相关，但同一种投入可以支持一个以上项目的联合成本。 注：注：如开发管理人员工资、开发设备折旧、停工损失等。 2.62.6 人力成本人力成本 为达成软件开发项目目标所需付出的各种人力资源代价总和。 2.72.7 非人力成本非人力成本 为达成软件开发项目目标所需付出的人力成本之外的其他成本。 2.82.8 软件软件成本测算成本测算 在本指南中， 特指对软件开发成本的预计值进行测算或对实际值进行测算、 分析的过程。 2.92.9 方程法方程法 基于基准数据建立参数模型，并通过输入各项参数，确定待测算项目工作量、工期、开 发成本估算值的方法。 2.102.10 类比法类比法 将本项目的部分属性与类似的一组基准数据进行比对， 进而获得待测算项目工作量、 工 期或成本测算值的方法。 2.112.11 类推法类推法 将本项目的部分属性与高度类似的一个或几个已经完成项目的数据进行比较， 适当调整 后获得待测算项目工作量、工期或成本测算值的方法。 2.122.12 系统边界系统边界 被度量软件与用户或其他系统之间的界限。 软件及信息化工程造价行业规范 - 2 - 2.132.13 功能点（功能点（FPFP） 衡量软件功能规模的一种单位。 2.142.14 功能点测算功能点测算 功能点测算是一种基于软件功能计数来评估软件规模的测算方法，其中也考虑到了性 能、安全、质量等因素带来的规模调整，但不考虑软件开发商的非产品因素。 2.152.15 国际功能点标准及国际功能点标准及5 5个子标准个子标准 国际标准化组织ISO/IEC已发布了以下五种规模度量标准，即： a)ISO/IEC 19761（COSMIC方法）加拿大通用软件度量国际联盟； b)ISO/IEC 20926（IFPUG方法）美国国际功能点用户组-标准功能点度量法； c)ISO/IEC 20968（Mk方法）英国软件行业协会； d)ISO/IEC 24570（NESMA方法）荷兰软件度量协会-快速功能点度量法； e)ISO/IEC 29881（FiSMA方法）芬兰软件度量行业协会。 在度量软件规模测算时， 应考虑可能的需求变更程度， 并对规模测算结果进行适当调整。 注注：根据相关国际标准中的方法适用范围声明，COSMIC方法适用于商业应用软件和实 时系统；IFPUG方法适用于所有类型软件的功能规模度量；Mk方法适用于逻辑事务 能被确定的任何软件类型；NESMA方法与IFPUG方法非常类似，但对功能点计数进行 了分级，以便在测算的不同时期选择不同精度的方法进行测算；FiSMA方法适用于所 有类型软件的功能规模度量。目前在全球采用功能点度量方法的组织中，采用IFPUG 功能点标准的组织所占的比例不低于75%，而采用其他4种功能点标准的组织加起来的 比例不超过20%。NESMA也是世界第二大功能点组织。其创造的一系列快速功能点方 法在测算界占有重要地位。 2.162.16 国际软件基准比对标准组（国际软件基准比对标准组（ISBSGISBSG） ISBSG长期从事基于功能点的跨企业跨行业的项目数据比对，拥有大量的基于功能点的 历史数据。本指南中所采用的一些数值参考了ISBSG 公布的数据。 2.172.17 功能点计数元素功能点计数元素 功能点计数元素包括以下5 个： a） 内部逻辑文件（Internal Logical File，ILF，以下简称内部数据） 软件内部需要维护（如增删改查）的数据。 b） 外部接口文件（External Interface File，EIF，以下简称外部接口） 在其它系统中维护但本软件需要调用的数据。 c） 外部输入（External Input，EI） 向软件输入数据或发送指令。 d） 外部输出（External Output，EO） 软件向使用者或其它系统输出的数据或发送的指令。 e） 外部查询（External Query，EQ） EQ 指使用软件进行的简单查询。 注：注：其中ILF、EIF是功能点计数时的数据元素，EI、EO、EQ是功能点计数时的业务元 素。每种计数元素都对应一定的功能点分值。累计得到整个软件的计数规模。在IFPUG 的功能点计数手册中，ILF、EIF、EI、EO、EQ 都有严格复杂的识别标准。 2.182.18 下限、标准、上限估算下限、标准、上限估算 本指南的测算模型和测算工具表生成三种测算数值： a） 标准值 标准测算值是预期的中值，表示项目实际情况将有50%低于或高于该数值。 b） 下限值、上限值 下限值是预期的25%值，表示项目实际情况将有25%低于或75%高于该数值。 上限值是预期的75%值，表示项目实际情况将有75%低于或25%高于该数值。 注注：在本指南中，下限值、上限值并不表示项目的最优、最差可能状态，它们被定义为 “50%的项目实际执行情况会介于下限值、上限值之间”。 2.192.19 百分位数百分位数 在某实数集合中，对于集合内某元素X，如果该集合中有且仅有P%的数据不大于X，则 称X为该集合的P百分位数。 软件及信息化工程造价行业规范 - 3 - 2.202.20 功能点耗时率功能点耗时率 每个功能点所消耗的人时数。 2.212.21 净值分析净值分析 通过将项目已完成工作的计划工作量与实际工作量进行比较， 确定项目进度、 成本偏离 情况的方法。 2.222.22 预算预算 根据项目成本测算的确定预计项目费用的过程。 2.232.23 预算价预算价 项目立项时批复的预算额度。 2.242.24 投标价投标价 在招投标过程中，各投标人递交的承包价格。 2.252.25 评标基准价评标基准价 在评标中设定为价格评分最高分的价格。 2.262.26 投标最低合理报价投标最低合理报价 在评标中设定为有效投标报价的下限价格。 2.272.27 投标最高合理报价投标最高合理报价 在评标中设定为有效投标报价的上限价格。 2.282.28 规模综合单价（功能点单价）规模综合单价（功能点单价） 单位规模的直接成本与间接成本之和。单位通常为“元/功能点”。 2.292.29 变更成本变更成本 为实现变更所需付出的软件开发成本。 2.302.30 结算结算 开发方在项目验收后对项目的成本进行计算的过程。 2.312.31 决算决算 委托方在项目验收后对项目的成本进行计算的过程。 2.322.32 后评价后评价 在项目已经完成并运行一段时间后，对项目的目的、执行过程、效益、作用和影响进行 系统的、客观的、可量化的分析和总结的一种技术经济活动。 2.332.33 委托方委托方 软件项目的出资方。 2.342.34 开发方开发方 受委托方委托，负责软件开发的组织或团队。 2.352.35 第三方第三方 委托方和开发方之外设计、造价、监理、测评、审计、咨询机构等主要为项目服务的相 关方。 3 3 软件开发成本构成软件开发成本构成 3.1 软件开发成本由直接成本和间接成本构成。 直接成本包括直接人力成本和直接非人 力成本。间接成本包括间接人力成本和间接非人力成本。 注注： 本指南中软件开发过程包括从项目立项开始到项目完成验收之间的需求分析、 设计、 编码、集成、测试、验收交付活动相关的项目管理、支持活动。软件开发成本仅包括软件开 发过程中的直接成本和间接成本，不包括数据迁移、软件维护等成本。所涉及工作量、工期 也仅为软件开发过程所用的工作量、工期。 3.2 直接人力成本包括开发方项目组成员的工资、奖金、福利等人力资源费用。其中， 项目成员包括参与该项目开发过程的所有开发或支持人员，如项目经理、需求分析人员、设 计人员、开发人员、测试人员、部署人员、用户文档编写人员、质量保证人员、配置管理人 员等。 对于非全职投入该项目开发工作的人员， 按照项目工作量所占其总工作量比例折算其 人力资源费用。 软件及信息化工程造价行业规范 - 4 - 3.3 直接非人力成本包括： 办公费，即开发方为开发此项目而产生的行政办公费用，如办公用品、通讯、邮寄、印 刷、会议等； 差旅费，即开发方为开发此项目而产生的差旅费用，如交通、住宿、差旅补贴等； 培训费，即开发方为开发此项目而安排的特别培训产生的费用； 业务费， 即开发方为完成此项目开发工作所需辅助活动产生的费用， 如招待费、 评审费、 验收费等； 采购费，即开发方为开发此项目而需特殊采购专用资产或服务的费用，如专用设备费、 专用软件费、技术协作费、专利费等； 其他，即未在以上项目列出但确系开发方为开发此项目所需花费的费用。 3.4 间接成本包括间接人力成本和间接非人力成本。 间接人力成本指开发方服务于开发管理整体需求的非项目组人员的人力资源费用分摊。 包括开发部门经理、PMO或EPG人员、产品规划人员、组织级质量保证人员、组织级配置管理 人员等的工资、奖金、福利等的分摊。 间接非人力成本指开发方不为开发某个特定项目而产生， 但服务于整体开发活动的非人 力成本分摊。包括开发方开发场地房租、水电、物业，开发人员日常办公费用分摊及各种开 发办公设备的租赁、维修、折旧分摊。 注注： 不同的组织在软件开发费用测算过程中应考虑已有财务或其他管理制度对软件开发 费用构成的影响。除软件开发成本外，应考虑开发方合理的毛利润。对于需要提供其他支持 服务的项目或产品，还需要考虑支持活动所需的各种成本，如数据迁移费、维护费等。当软 硬件购置费、 测评费等费用单独列支时， 不应再将上述费用作为软件开发费用的直接非人力 成本重复计算。 3.5 通常采用三种方法确定软件开发成本 a) 软件开发成本=直接人力成本+直接非人力成本+间接人力成本+间接非人力成本； b) 软件开发成本=工作量 人月费用； C) 软件开发成本=功能规模 功能点单价。 注注： 实际运用中多采用第二种和第三种方法来确定软件开发成本。 规模综合单价方法更 能适应项目范围存在较大变更概率的项目， 可以支撑委托方的费用预算审批， 也可保护开发 方的利益，此时，规模测算结果必须作为附件提交，如采用功能点方法进行软件规模测算的 项目，上报预算和招标时还应附上功能清单及对应的功能点数。 项目预算时应依据规模、工作量、工期、成本、预算金额的估算结果，并考虑此项目的 特殊因素。例如，对于质量、进度要求较高的项目，为确保项目成功可按照预算金额的上限 值进行预算。 如无特殊情况， 不应以低于预算金额下限或高于预算金额上限的金额进行预算。 4 4 软件开发成本测算步骤软件开发成本测算步骤 本指南中所涉及规模、工作量、工期仅为软件开发过程所用规模、工作量、工期。 4.14.1 软件开发成本测算基本流程与原则软件开发成本测算基本流程与原则 图1 软件开发成本测算基本流程 软件及信息化工程造价行业规范 - 5 - 图 1 展示了成本测算的基本流程。 在依据此流程进行软件开发成本测算时应考虑以下情 况： -在需求极其模糊或不确定时，宜采用类比法或类推法，直接粗略测算工作量和工 期，也可直接粗略测算成本； -对于有明确工期要求的项目，在采用方程法测算工作量时，工期要求有可能是方 程的参数之一； -间接成本是否与工作量测算结果相关取决于间接成本分摊计算方式； -工期测算结果与直接人力成本测算结果及其他成本测算结果相互关联并可能互相 影响。 如工期测算的结果有可能导致重新测算工作量和直接非人力成本， 并最终改变软件开 发成本测算结果。 在成本测算过程中，应遵循以下原则： a) 充分利用基准数据，采用方程法、类比法或类推法，对工作量、工期、成本进行测 算。对于进行规模测算的项目，宜采用方程法测算工作量、工期和成本； b) 在规模测算时，应根据项目特点、阶段和需求的详细程度选择合适的测算方法； c) 工作量、工期、成本的测算结果宜为一个范围而不是单一值； d) 成本测算过程中宜采用不同的方法分别测算并进行交叉验证。 如果不同方法的测算结果产生较大差异，可采用专家评审方法确定测算结果，也可 使用较简单的加权平均方法。 4.2 规模测算 在规模测算前，应根据项目范围明确系统边界。对于尚未确定的需求，应该在规模 测算前确定估算原则。 通常情况下，规模测算是软件测算过程的起点。测算规模是后续计算软件项目的工 作量、工期、成本和进度的主要依据，是项目范围管理的关键，因此，在条件允许的情 况下，应进行规模测算。在规模测算过程中，需要注意以下情况： a) 在规模测算开始前，应根据可行性研究报告或类似文档明确项目需求及系统边 界。项目需求除包含最基本的业务需求外，还应进行初步的子系统/模块划分，并对每一 子系统或模块的基本用户需求进行说明，以保证可以根据项目需求进行规模预估。 b) 依据项目特点、 阶段和需求详细程度不同， 通常测算人员在选择估算方法时应采 用纳入国际标准的功能点方法进行功能规模测算，如 IFPUG 方法（标准功能点方法）、 NESMA 方法（快速功能点方法）。 c) 若当前的项目需求极其模糊或不确定， 可不进行规模测算， 而直接采用类比法或 类推法估算工程量、工期和成本。 4.2.1 功能规模度量（IFPUG 方法，即标准功能点方法） 4.2.1.1IFPUG 的功能规模度量（FSM）方法称为功能点分析，其功能规模的单位为功能 点。 4.2.1.2 功能点分析通过量化提供给用户的逻辑设计的任务和服务来度量软件。功能点 分析的目的是：度量用户要求的和得到的软件实现的功能；独立于技术实现来度量软件的开 发、升级和维护。 4.2.1.3 功能点分析的过程： 应该足够简单减少度量过程管理费用； 应该是一种在不同项目和组织中一致的度量过程。 4.2.1.4 功能规模度量框架 IFPUG 功能点分析在不同功能领域中创建应用有不同的交付率 （交付一个功能点所用的小 时数），这和不同的项目规模及软件复杂性有关。 软件及信息化工程造价行业规范 - 6 - 4.2.1.5 功能规模度量过程 为了执行功能点计数，需要执行以下活动来识别和分类基础功能组件（ILF、EIF、EI、 EO、EQ)：功能点计数过程的图像化 图 2 功能点计数过程 4.2.1.6 标准功能点方法度量的识别规则 详见附录A 功能点计数基本规则。 4.2.24.2.2 快速功能规模度量（快速功能规模度量（NESMANESMA方法，即快速功能点方法方法，即快速功能点方法） 详见附录A 功能点计数基本规则。 4.34.3 工作量测算工作量测算 4.3.1 基本原则在测算工作量时，应： a) 对项目风险进行充分分析并根据分析结果对测算方法或模型合理调整。例如，根据 风险情况调整测算模型中影响因子的权重或取值。风险分析时应考虑技术、管理、资源、商 业多方面因素。 例如：需求变更、外部协作、时间或成本约束、人力资源、系统架构、用户接口、外购 或复用、采用新技术等。 b) 根据经验或相关性分析结果，确定影响工作量的主要属性。 4.3.2测算公式 采用方程法测算工作量应使用以下公式： AE=(SAE=(SPDR)PDR) SWFSWFRDFRDF 式中：AE-测算工作量，单位为人时； S-调整后的软件规模，单位为功能点； PDR-功能点耗时率，单位为人时每功能点。PDR的取值见附录B.3或本组织历史 数据； SWF-软件因素调整因子，取值见附录B.4或本组织历史数据； RDF-开发因素调整因子，在预算时如无特殊要求，取值为1。如果需要调整，见 附录B.5或本组织历史数据。 可根据上述公式及PDR基准数据的P25、 P50、 P75值， 分别计算出工作量测算结果的下限、 最有可能值和上限。 4.44.4 工期测算工期测算 采用的工作量工期模型为：工期=1.277（AE/176） 0.404。合理工期范围采用工作 量测算合理范围的上下限值分别计算； 根据经验， 当期望工期多于测算工期下限但少于最有 可能工期时，每压缩10%的工期，将导致10%的工作量增加。 在测算工期时，应： a) 根据工作量测算结果和资源情况，对工作任务进行分解并制订工作时间表。制订工 作时间表时应充分考虑关键路径任务约束对工期的影响； b) 利用基准数据测算合理的工期范围。利用基准数据，建立“工作量工期”模型， 使用方程法测算合理的工期范围； c) 将委托方的期望工期或开发方初步制订的工作时间表中的工期与工期测算结果进行 比较； d) 委托方期望工期或工作时间表中的工期短于测算出的工期下限时，应分析原因，必 要时对人力资源安排或项目范围进行调整，再重新测算工作量、工期，并制订新的工作时间 表。压缩工期会增加项目工作量，导致生产效率降低。 阶段工作量 某开发阶段工作量 = 总工作量 此开发阶段的【工作量比例系数】各比例系数见附 软件及信息化工程造价行业规范 - 7 - 录B.4。本公式适用于采用瀑布式开发，迭代视为分期的瀑布项目。 4.54.5 信息化项目软件开发费用测算信息化项目软件开发费用测算 4.5.1 依据工作量、人月折算系数、人月费用测算软件开发费用 在获得了工作量测算结果后，采用以下公式测算费用： P=AE/HMP=AE/HMF F 式中：P-软件开发费用，单位为元； AE-测算工作量，单位为人时； HM-人月折算系数，单位为人时每人月，取值为176（每天按工作8小时计算，每 月按工作22天计算）； F-人月费用，单位为元每人月； 4.5.2 功能点单价测算软件开发费用 基于已确定的功能点单价测算软件开发费用，采用以下公式： P=SPPSWFRDF 式中：P-软件开发费用，单位为元； S-调整后的软件规模，单位为功能点； PP-功能点单价，单位为元每功能点； SWF-软件因素调整因子，取值见附录B.4或本组织历史数据； RDF-开发因素调整因子，在预算时如无特殊要求，取值为1。如果需要调整，见 附录B.5或本组织历史数据。 软件及信息化工程造价行业规范 - 8 - 附附 录录 A A （规范性附录）功能点计数基本规则 A.1A.1 功能点计数项分类功能点计数项分类 功能点计数项分为数据功能和事务功能两类，其中数据功能包括ILF、EIF；事务功能包 括外部输入（EI）、外部输出（EO）、外部查询（EQ）。 数据功能是系统提供给用户的满足产品内部和外部数据需求的功能， 体现系统管理或使 用哪些业务数据（业务对象）。ILF或EIF所指的“文件”不是传统数据处理意义上的文件， 而是指一组用户可识别的、 逻辑上相互关联的数据或者控制信息。 这些文件和物理上的数据 集合（如数据库表）没有必然的对应关系。 事务功能是系统提供给用户的处理数据的功能， 体现系统如何处理和使用那些业务数据 （业务对象）。事务功能又称为基本过程，是用户可识别的，业务上的一组原子操作。 预估功能点方法:只需要识别数据功能， 包括ILF和EIF； 估算功能点方法:需要识别数据 功能和事务功能，包括ILF、EIF、EI、EO和EQ；详细功能点方法: :需要识别数据功能和事 务功能，包括ILF、EIF、EI、EO和EQ，以及它们所应对的复杂度。 A.2A.2 ILFILF的识别的识别 识别ILF的步骤如下： a) 识别业务对象。业务对象应是用户可理解和识别的，包括业务数据或业务规则。 注：为程序处理而维护的数据属于编码数据。所有的编码数据均不应识别为逻辑文件， 与之相关的操作也不应识别为基本过程。 b) 确定逻辑文件数量。根据业务上的逻辑差异及从属关系确定逻辑文件的数量。 c) 是否是ILF。确定该逻辑文件是否在本系统内进行维护。如果是，记为ILF；否则为 EIF。 A.3A.3 EIFEIF的识别的识别 EIF是被应用边界内一个或几个基本处理过程所引用的业务数据。 一个应用中的EIF应是 其他应用中的ILF。识别EIF的步骤如下： a) 识别业务对象。业务对象应该应是用户可理解和识别的。业务对象包括业务数据或 业务规则。 而一些为了程序处理而维护的数据则属于编码数据。 所有的编码数据均不识别为逻辑文 件，与之相关的操作也不识别为基本过程。 b) 确定逻辑文件数量。需要根据业务上的逻辑差异及从属关系确定逻辑文件的数量。 c) 是否是EIF。确定该逻辑文件是否在本系统内进行维护。如果是，记为ILF；否则为 EIF。 A.4A.4 EIEI的识别的识别 EI是处理来自系统边界之外的数据或控制信息的过程。目的是维护一个或多个ILF或者 改变系统的行为。 EI的基本识别规则如下： a) 应是来自系统边界之外的输入数据或控制信息； b) 穿过边界的数据应是改变系统行为的控制信息或者应至少维护一个ILF； c) 该EI不应被重复计数。任何被分别计数的两个EI至少满足下面三个条件之一（否则 应视为同一EI）： 1) 涉及的ILF或EIF 不同； 2) 涉及的数据元素不同； 3) 处理逻辑不同。 A.5A.5 E0E0的识别的识别 EO是处理向系统边界之外发送数据或控制信息的过程。 目的是向用户呈现经过处理的信 息。 EO的基本识别规则如下： a) 将数据或控制信息发送出系统边界。 b) 处理逻辑应至少符合以下一种情况： 1) 包含至少一个数学公式或计算过程； 2) 产生衍生数据； 软件及信息化工程造价行业规范 - 9 - 3) 维护至少一个ILF； 4) 改变系统行为。 c) 该 EO 不应被重复计数。 任何被分别计数的两个EO 至少满足下面一个条件 （否则被 视为同一EO）： 1) 涉及的ILF或EIF 不同； 2) 涉及的数据元素不同； 3) 处理逻辑不同。 A.6A.6 EQEQ的识别的识别 EQ是向系统边界之外发送数据或控制信息的基本处理过程。 目的是向用户呈现未经加工 的已有信息。 EQ的基本识别规则如下： a) 将数据或控制信息发送出系统边界； b) 处理逻辑可包含筛选、分组或排序； c) 处理逻辑不应包含： 1) 数学公式或计算过程； 2) 产生衍生数据； 3) 维护 ILF； 4) 改变系统行为。 d) 该 EQ 不应被重复计数。 任何被分别计数的两个EQ 至少满足下面一个条件 （否则被 视为同一EQ）： 1) 涉及的ILF或EIF 不同； 2) 涉及的数据元素不同； 3) 处理逻辑不同。 软件及信息化工程造价行业规范 - 10 - 附附 录录 B B （规范性附录）参数表 B.1B.1 功能点分值计算方法功能点分值计算方法 B.1.1B.1.1 预估功能点预估功能点 功能规模统计只能识别ILF和EIF文件，可用于预算和招投标阶段，采用如下公式计算： 功能点数35ILF+15EIF 这一公式基于如下假设：平均情况下，每个ILF对应3个EI、2个EO和1个EQ，每个EIF对 应1个EO和1个EQ，35和15是将上述ILF、EIF、EI、EO、EQ的复杂度默认为中，再考虑系统整 体的功能性得出的。 B.1.2B.1.2 估算功能点估算功能点 功能规模统计能识别ILF和EIF文件，并能识别出事务功能EI、EO、EQ，可用于预算和招 投标阶段，采用如下公式计算： 功能点数=10ILF+7EIF+4EI+5EO+4EQ 这一公式基于如下假设：将ILF、EIF、EI、EO、EQ的复杂度默认为中。 B.1.3B.1.3 详细功能点详细功能点 功能规模统计能识别ILF和EIF文件和事务功能EI、 EO、 EQ并能识别出每个功能要素的数 量。可用于预算、招投标阶段、结算、决算阶段。 一旦估算出应用程序中每个功能要素的数量后， 就可以将每个计数与一个复杂度值 （加 权因子）相乘，最后进行合计，算出一个初步的总的功能点数UFC。 复杂度加权因子表如下： 功能要素复杂度加权因子表（Complexity weights Factor） 复杂度 功能要素 低平均高 用户输入数 EI346 用户输出数 EO457 用户查询表 EQ346 内部逻辑文件数 ILF71015 外部接口文件数 EIF5710 每个功能要素的复杂度可通过下表进行分析判断。 功能要素复杂度判别表（Determine the complexity-level） ILF（内部逻辑文件）和 EIF（外部接口文件） EO（用户输出）和 EQ（用户查询） EI（用户输入） 记录 单元 数据单元文件 类型 数据单元文件 类型 数据单元 1-1920-5051+1- 5 6-1920 + 1- 4 5-1516+ 1低低平均0或1低低平均0或1低低平均 2- 5 低平 均 高2- 3 低平均高2- 3 低平均高 6+平均高高4+平均高高4+平均高高 从表中可以看出，EI（用户输入）、EO（用户输出）和EQ（用户查询）是由文件类型和数据 单元的数理来决定的。而ILF（内部逻辑文件）和EIF（外部接口文件）则是由记录单元和数 据单元来决定的。通过上面的两维表即可确定各个功能要素的复杂度是低、平均，还是高。 注：注：表中三种数据项定义如下： 1) 记录单元类型Record Element Type （RET）：指在ILF或EIF中，用户可识别的数据 域的子集，可以通过检查数据中的各种逻辑分组来识别它们。 （例如一个客户文件，包括客 户姓名、地址等个人信息，以及客户的信用卡和卡号。一个客户有多张信用卡。该文件含有 两个记录单元：客户信息和信用卡信息）。 2) 文件引用类型File Type Referenced（FTR）：指在一个事务过程中，所引用到的各 软件及信息化工程造价行业规范 - 11 - 种文件，可以是内部逻辑文件，也可以是外部接口文件。 3) 数据单元类型Data Element Type（DET）：是用户可识别的无递归，不重复的信息 单元。DFT是动态的，而非静态的，可以读自于文件，或由FTR的数据单元创建。另外，一个 DET也可是对一个事务处理过程的唤醒，或是事务的有关信息。 B.2B.2 技术复杂度因子技术复杂度因子TCFTCF 算出功能点总数UFC后，还需要根据项目具体情况，对各个技术复杂度参数进行调整， 技术复杂度一共考虑了14通用系统特征，他们分别是： 技术复杂度因子表 各个复杂度参数的取值范围从0到5， 表示该项对功能点总数的影响从没有到极高。 各个 参数默认值为0，也就是该项不影响功能点调整。 每个参数都是对功能点数的线性调整， 设Ei为依据14个方面的调节参数对软件系统的影 响程度，则功能点技术复杂度因子为： TCF=0.65+0.01* Ei , Ei），（ 50 , TCE ）（35. 1 ,65. 0 B.3B.3功能点耗时率功能点耗时率 1.参考中国软件行业基准数据（2016年）P25、P50、P75取值。 功能点下限耗时率P25 = 3.94 小时/功能点 功能点最有可能耗时率P50 = 7.16 小时/功能点 功能点上限耗时率P75 = 12.28 小时/功能点 2.参考工信部颁布的电子建设工程概（预）算编制办法及计价依据（HYD 41-2015） （工信厅规201577号）标准的P25%、P50%、P75%的取值。 功能点下限耗时率 = 9.1 小时/功能点 功能点最有可能耗时率 = 13.4 小时/功能点 功能点上限耗时率 = 24.8 小时/功能点 说明： 1.在预算时如无特殊要求，建议参考采用中国软件行业基准数据（2016年）取值。 2.若各行业或地区建立行业或地区功能点耗时率基准库， 可以根据实际情况， 对功能点 耗时率进行调整。 B.4B.4软件因素调整因子（软件因素调整因子（SWFSWF） 软件因素调整因子 =【软件规模调整因子】【应用领域调整因子】【质量及特性调 整因子】 软件规模调整因子（SF），计算公式：SF= 0.108 Ln（S）+ 0.2229 （式中S为调整 后软件功能规模） 应用领域调整因子（应用领域调整因子（ATAT） 应用类型应用类型调整因子调整因子范围范围 业务处理用1.0OA、公文，人事、会计、工资、销售等经营管理及业务处 EM1Data communications数据通讯 EM2Performance软件性能 EM3Heavily used configuration可配置性 EM4Transaction rate事务效率 EM5Online data entry实时数据输入 EM6End user efficiency用户界面复杂度 EM7Online update在线升级 EM8Complex processing复杂运算 EM9Reusability ease代码复用性 EM10Installation ease安装简易性 EM11Operations ease操作方便性 EM12Multiple ease跨平台要求 EM13Facilitate change可拓展性 EM14Distributed functions分布式数据处理 软件及信息化工程造价行业规范 - 12 - 理用软件 科技用 应用集成 1.2 科学计算、模拟、空白表格程序，统计，CAE（计算机辅 助工程）等企业服务总线、应用集成等 多媒体用1.3 图表，影像，声音等多媒体应用领域，地理信息系统，教 育和媒体用等 智能信息用1.7自然语言处理，人工智能，专家系统等 系统用1.7 操作系统，语言处理程序，DBMS，人与机器的接口，窗口 系统，CASE，实用程序等 通信控制用1.9通信协议，仿真，交换机软件，GPS等 流程控制用2.0 生产管理，CAM（计算机辅助制造），CIM（计算机集成制 造），仪器控制，机器人控制，实时控制，内置性软件等 指挥管制用（QRQR） 2.2军队，警察等需要管制军备和人力的软件 质量及特性调整因子质量及特性调整因子 调整因子调整因子判断标准判断标准影响度影响度 分布式处 理 此应用能够在各组成 要素之间传输数据 没有明示对分散处理的需求事 项 -1 通过网络进行客户端/服务器 及网络基础应用分布处理和数 据传输 0 在多个服务器及处理器上同时 相互执行应用中的处理功能 1 性能 对用户对应答时间或 处理率的需求水平 没有明确对性能的特别需求事 项或活动，因此提供基本性能 -1 应答时间或处理率对高峰时间 或所有业务时间来说都很重要 存在对连动系统结束处理时间 的限制 0 为满足性能需求事项，要求设 计阶段开始进行性能分析，或 在设计开发实现阶段使用 分析1具 1 可靠性 发生