1、 中国软件行业 软件工程定额标准 (试行) 二九年十月编委会 组 长： 陈 勇 副组长： 孙洪林 郝宗伟 成 员： （按首字母排序） 陈化然 代寒玲 胡红升 胡日一 巨小澎 李 峰 刘惠颖 邱钦伦 孙小兰 吴 凡 王海青 王建凯 姚炳亮 闫光永 张保印 张 蠡 评审委员会 组长： 郑人杰 成员： （按首字母排序） 戴瑞敏 孔祥清 马晓东 石跃军 发布单位 中国软件行业协会系统与软件过程改进分会 支持单位（排名不分先后） 太极计算机股份有限公司 北京中软国际信息技术有限公司 中国软件与技术服务股份有限公司目 录 1概述1 1.1目的1 1.2主要内容1 1.3应用范围1 2术语1 2.1功能点，
2、功能点估算，国际功能点用户组，国际基准比对组织1 2.2功能点计数元素2 2.3下限/标准/上限估算2 3软件工程定额标准的使用流程3 4用户单位预算申请及招标估算过程3 4.1识别功能点计数元素3 4.2计算招标计数规模4 4.3计算招标规模4 4.4计算未调整的招标工作量4 4.5调整招标工作量4 4.6计算招标价格/预算费用.5 4.7计算招标工期5 4.8预算申请特殊说明5 5软件开发商投标及报价/计划过程.5 5.1识别功能点计数元素5 5.2计算投标计数规模5 5.3计算投标规模6 5.4计算未调整的投标工作量6 5.5调整投标工作量6 5.6计算投标价格6 5.7计算投标工期7
3、5.8计划投标里程碑7 5.8.1瀑布式开发7 5.8.2迭代式/敏捷开发.7 附录A.7 A.1 ILF/EIF简易识别标准.8 A.2规模变更因子.11 A.3功能点耗时率.11 A.4软件因素调整因子.11 A.5 工期-工作量回归参数12 A.6 EI/EO/EQ简易识别标准.12 A.7 需求吻合度.15 A.8 开发因素调整因子.15 A.9 软件开发商人月费率.16 A.10 利润率16 I A.11 各阶段比例系数17 附录B17 B.1 参考模型与数据来源.17 B.2 估算过程差异对比.17 II 1 概述 1.1 目的 制定本标准的目的是规范软件工程定额估算的过程，为用户
4、单位、财政审批部门、软件开发商估算软件工程项目的工作量、价格和工期等提供科学、统一、快捷的方法和实用工具。 本标准的主要用途如下： a）编制软件项目预算和审批软件工程项目时，利用有限信息得到项目工作量和造价的估算数据； b）在招评标时，对投标价格差异巨大等情况，作为采取处理方法时的依据； c）用户单位在软件项目实施中、软件开发商在自主研发或无需招投标的软件开发项目中，估算项目开发过程中的规模、工作量、工期等计划数据。 1.2 主要内容 本标准的主要内容为： a） 定义了“用户单位预算申请”、“用户单位招标”、“软件开发商投标”三个软件工程定额估算过程。 b） 根据软件工程定额过程采用的估算模型
5、和估算方法，开发了相应的估算工具表。 1.3 应用范围 本标准初始发布时提供的估算模型以政府行业用户单位的数据为基准，适用于政府行业用户单位的软件项目。今后将不断补充其它行业数据，扩大适用范围。 使用本标准提供的估算模型和估算表，可估算软件项目的预算/造价、工作量、总工期、各开发阶段工期、以及各开发阶段需投入的人员数量，其中工作量、工期、预算/造价涵盖从需求到上线的全部开发过程，但不包括系统集成所需的环境搭建工作及项目交付后维护期内的工作。 虽然具备计算机基本使用能力的人员经过简单培训，即可高效率地完成项目估算工作。但本标准建议由编制预算申请书/招标书/投标书的人员执行/参与估算，如此可提高估
6、算的速度和精度；项目需求是估算的依据。 2 术语 2.1 功能点，功能点估算，国际功能点用户组，国际基准比对组织 a） 功能点（Function Point， FP） 功能点是基于软件外部功能（输入、输出、接口、报告）对软件规模的度量。 b） 功能点估算 1 功能点估算是一种基于软件功能计数来评估软件规模的估算方法，其中也考虑到了性能/安全/质量等因素带来的规模调整，但不考虑软件开发商的企业背景/经验/所用技术等非产品因素。 功能点估算的优点是：用户单位和软件开发商都可以理解；在项目早期利用有限的功能描述即可进行估算。 c） 国际功能点用户组（ IFPUG，International Func
7、tion Point Users Group） IFPUG 为功能点的识别和计数提供了国际标准，使不同的人对同一软件的规模的认识是相同的。本标准提供的简易识别规则参考了 IFPUG 标准规则的功能点计数方法。 d） NESMA（Netherlands Software Metrics Association） NESMA 是荷兰的功能点组织，也是世界第二大功能点组织。其创造的一系列简化功能点方法在估算界占有重要地位。 e） 国际软件基准比对标准组 （ISBSG ， International Software Benchmarking Standard Group） ISBSG 长期从事基于功
8、能点的跨企业跨行业的项目数据比对，拥有大量的基于功能点的历史数据。本标准中所采用的一些数值参考了 ISBSG 公布的数据。ISBSG在中国的分支机构是 CSBSG。 2.2 功能点计数元素 功能点计数元素包括以下 5 个： a） 内部逻辑文件（Internal Logic al File，ILF，以下简称内部数据） 软件内部需要维护（如增删改查）的数据。 b） 外部接口文件（External Inter face File，EIF，以下简称外部接口） 在其它系统中维护但本软件需要调用的数据。 c） 外部输入（External Input，EI） 向软件输入数据或发送指令。 d） 外部输出（Ex
9、ternal Output，EO） 软件向使用者或其它系统输出的数据或发送的指令。 e） 外部查询（External Query，EQ） EQ 指使用软件进行的简单查询。 其中 ILF、EIF 是功能点计数时的 数据 元素，EI、EO、EQ 是功能点计数时的 业务元素。 每种计数元素都对应一定的功能点分值。累计得到整个软件的计数规模。由于利用已经识别出来的功能点计数元素计算规模，因此这种方法非常客观。 在 IFPUG 的功能点计数手册中，ILF、EIF、EI、EO、EQ 都有严格复杂的识别标准，比较难以掌握。本标准的估算方法和估算工具表提供了简易识别标准，供使用者快速估算而又不产生显著的偏差。
10、 2.3 下限/标准/上限估算 本标准的估算模型和估算工具表生成三种估算数值： a） 标准值 标准估算值是预期的中值，表示项目实际情况将有 50%低于或高于该数值。 2 b） 下限值/上限值 在本标准中，下限值/上限值并不表示项目的最优/最差可能状态，它们被定义为“50%的项目实际执行情况会介于下限值/上限值之间。” 如果招投标或立项时采用了低于下限或超出上限的估算值，项目出现延期、超支等情况的概率将显著增加。允许出现采用低于下限或超出上限估算值的情况，但此时用户单位与软件开发商双方应该就其原因进行特殊说明并达成共识。 3 软件工程定额标准的使用流程 下面的图 3.1 描绘了软件工程定额流程，
11、以及本标准定义的“用户单位预算申请”、“用户单位招标”、“软件开发商投标”三个软件工程定额估算过程的关系。 用户单位 用户单位 软件开发商 软件开发商 编写预算申请书 实际开发 实际规模 实际工作量 实际成本 实际工期 实际各阶段比例 编写招标书 编写投标书 预算申请估算 规模 工作量 预算 工期 招标估算 规模 工作量 招标价格 工期 投标估算 规模 工作量 投标价格 工期 各阶段比例 申请预算 招标 投标 图 3.1 软件工程定额流程 在 本标准的定义中，“用户单位预算申请”与“用户单位招标”过程的估算模型和计算公式，但执行本标准的单位应度量项目实际执行情况4 用户单位预算申请及招标估算过
12、程 4.1 识别功能点计数元素 招标书编写时应注明软件系统需要管理的内部数据（ILF）和外部接口（EIF），ILF和 EA计算工具。 相同，过程的具体步骤在本标准第 4 章描述。 “软件开发商投标”过程在第 5 章描述。 其中“实际开发”部分不在本标准的范围内并记录数据，供编委会工作组持续修订估算模型和估算工具表的方法及参数。 IF 的简易识别标准见附录 A.1。 将识别出的 ILF和 EIF 数量填入本标准附件3 建议招标书的格式参照本标准提供的附件 B用户单位招标书模 板。 4.2 计算招标计数规模 招标计数规模 = （35 * ILF + 15 * EIF） 预算申请和招标估算过程中，用
13、户单位只需要考虑内部数据和外部接口两种计数元素。处的 35 和15 是这种情况下 ILF 和EIF 所对应的功能点分值。 4.3 计算招标规模 招标规模 = 招标计数规模 *【招标规模变更因子】 于在预算 - 招标 - 投标（含合同签订） - 实际完成过程中对功能的了解是循序渐进的估算。 更情况4.4 计算未调整的招标工作量 未调整的招标工作量 = 招标规模 * 【功能点耗时率】 / （8 * 21.5） 能点耗时率采用ISBSG的统一定义 ，即每功能点所消耗的人时数。它是从业界功能点生产值见附录 A.3。 4.5 调整招标工作量 招标工作量 = 未调整的招标工作量 * 【软件因素调整因子】
14、于软件的应用领域不同，质量等指标要求不同，功能规模相同的产品可能造价会显著不同虑软件制造的技术。 单位：功能点 在此单位：功能点 由，因此规模整体呈现逐渐增长的趋势，为了准确预测项目的实际完成规模，防止延期和超出预算的情况，可在不同阶段的预测中使用【规模变更因子】进行修正。 招标规模是“招标阶段预测的项目完成实际规模”，并以此为依据进行后续【招标规模变更因子】由编委会工作组参考业界数据或者根据历史项目的实际需求变总结得到，各阶段的具体数值见附录 A.2。 单位：人月 功率的数据总结得到的。 【功能点耗时率】具体数单位：人月 鉴，软件因素调整因子的引入对这一偏差进行了修正。 软件因素调整因子只考
15、虑软件本身的应有价值，而不考【软件因素调整因子】的具体计算方式见附录 A.4。 4 4.6 计算招标价格/预算费用 招标预算 = 招标工作量 * 【用户单位人月费率】 单位：万元 【用户单位人月费率】 （元/人月） 为用户单位根据以往项目情况所做的政策性标准数值，用户单位一般按此价格支付软件开发商的开发费用。 因各地区以及用户单位本身的差异，此数值由用户单位自行决定。用户单位应维护一个历史数据库，在新项目预算时根据以往项目的执行情况作出判断。 用户单位若没有历史数据，可以参考附录 A.9中软件开发商的计算方法。 4.7 计算招标工期 招标工期 = b*招标工作量a单位：月 工期与工作量之间一般
16、存在上述指数关系，其中a/b 参数由编委会工作组从以往实际项目数据中进行回归得到。 尽管团队规模会导致相同工作量的项目工期有所差异，但本公式计算出来的工期反映了某个工作量的项目的最现实的工期。 a/b 参数见附录 A.5。 4.8 预算申请特殊说明 由于经过批准的预算在多数情况下难以追加，因此建议申请预算时采用“招标上限预算” ，即由“功能点上限耗时率”计算产生的预算。如此则 75%的投标项目将不会超过预算。 5 软件开发商投标及报价/计划过程 5.1 识别功能点计数元素 投标书中需着重描述软件需要管理的内部数据 （ILF） ，外部接口 （EIF） ，外部输入 （EI） ，外部输出（EO） ，
17、外部查询（EQ） ，并在附件 A 中列出上述各项的数量。 EI、EO、EQ等的简易识别标准见附录A.6。 5.2 计算投标计数规模 投标计数规模 = 【需求吻合度】*)*4*5*4*7*10( EQEOEIEIFILF +) 在投标过程中，软件开发商应既要考虑内部数据 ILF 和外部接口 EIF，也要考虑软件的业务EI、EO、EQ。 此处的 10、7、4、5、4 等数值是这种情况下各种计数元素所对应的功能点分值。 5 【需求吻合度】表明了软件开发商现有产品或已有模块在某个功能上与用户单位需求的吻合程度。若拥有较好的吻合度，则软件开发商可以因此降低工作量/成本/工期以获得更好的竞争力。 为了降低
18、分析复杂度，需求吻合度只和 ILF 内部数据或 EIF外部接口对应，而无需细化到 EI/EO/EQ 上。 在计算需求吻合度对工作量的影响时，本标准认为即使需求完全吻合，仍可能产生部分工作量。需求吻合度的计算方法见附录 A.7。 5.3 计算投标规模 投标规模 = 投标计数规模 *【投标规模变更因子】 单位：功能点 本公式的解释请参考 4.3 章。 【投标规模变更因子】数值见附录 A.2。 5.4 计算未调整的投标工作量 未调整的投标工作量= 投标规模 * 【功能点耗时率】 / （8 * 21.5） 单位：人月 本公式的解释请参考 4.4 章。 【功能点耗时率】具体数值见附录 A.3。 5.5
19、调整投标工作量 投标工作量 = 未调整的投标工作量 * 【软件因素调整因子】 * 【开发因素调整因子】 单位：人月 本公式及【软件因素调整因子】的解释请参考 4.5 章。 软件开发商计算开发工作量时，除了与用户单位一样考虑软件因素造成的工作量差异之外，还要考虑自身经验/开发方法等造成的工作量调整。开发因素调整因子的引入对这一偏差进行了修正。 开发因素调整因子只考虑软件开发商本身的情况，它是软件开发商评估自己开发这个软件产品的个别成本的主要因素。 【开发因素调整因子】的具体计算方式见附录 A.8。 5.6 计算投标价格 投标价格 = 投标工作量 * 【软件开发商人月费率】 * （1+【利润率】
20、） 单位：万元 6 【软件开发商人月费率】为软件开发商根据以往项目情况所总结的平均成本。本标准给出了计算此费率的方法以及建议的数值，具体情况见附录 A.9。 【利润率】为软件开发商向用户单位公开的本项目的软件开发部分的利润率。行业简易的利润率见附录 A.10。 5.7 计算投标工期 投标工期 = b*招标工作量a单位：月 本公式的解释请参考 4.7 章。 a/b 的数值见附录 A.5。 5.8 计划投标里程碑 5.8.1 瀑布式开发 某开发阶段工作量 = 总工作量 * 此开发阶段的【工作量比例系数】 某开发阶段工期 = 总工期 * 此开发阶段的【工期比例系数】 建议的各比例系数见附录 A.11
21、。 本节公式适用于采用纯瀑布式开发，或虽然分几次迭代或几期工程，但每次迭代时间长于 3 个月的项目。后者被理解为分期的瀑布项目。 5.8.2 迭代式/敏捷开发 迭代和敏捷开发方式在单位时间完成的功能点近似相同。 在项目最初阶段应进行总体计划/架构设计，在最终阶段应安排系统测试/稳定工作。这两个阶段不需要按比例地完成功能点，它们的工期由企业根据开发过程自行定义，但总和不应超过项目整体工期的 1/3。 如 1000 功能点、工期 12 个月的迭代/敏捷项目，安排 2 个月的总体设计期和 2 个月的系统测试期，则在剩下的 8 个月中，应近似每月完成 1000 / 8 = 125 个功能点。 本节规则
22、适用于单个迭代历时 13 个月，且每个迭代均产生可运行的软件版本（交付或不交付均可）的开发方式。 附录 A 附录 A 是上述计算过程中所需的计算工具样例/分类方法/数值等内容。 部分数据和公式是固定的不需要更新的，比如每月按照 8*21.5 小时计算等。 另外一些数据和公式，每年编委会工作组都会进行更新，比如生产率，变更率等。 7 A.1 ILF/EIF 简易识别标准 编写预算申请书或招标书的人员应学习和理解本标准，并在文字中为估算者提供足够的信息来识别 ILF 和EIF。 若无法判断是否满足下面的规则时，估算者应与编写人讨论核实。若讨论后仍无法确定，则可以标识为“未定”状态，本标准附件中的估
23、算工具会按一定比例计算此状态的 ILF 和EIF。 ILF 和EIF 的简易识别规则如下： z ILF 简易识别规则 ILF 指在待开发系统内部逻辑上的、用户可识别的一组数据 对单个 ILF一般执行 6种左右的操作 用户可以理解和识别 ILF，对 ILF 的操作是用户的业务需求 z EIF 简易识别规则 EIF 指在其它需要集成的系统中，“读”或“写”操作至少执行其中一种及以上的外部接口 无论对某个 ILF或 EIF 提到过几次、进行多少操作，均只计数 1 次。 “数据”、“接口”、“操作”、“读写”经常以较为复杂的形式存在，下面的示例演示了如何快速识别 ILF、EIF。 示例1 从“逻辑”性
24、上识别ILF a) 会议管理系统包括X局（信息中心）局、处（或公司）举行的会议，会议计划、安排、记录、查询、通知、纪要等功能均实现电子化，提高会议效率。 尽管这里提到了多个需要管理的数据（或操作）：计划、安排、记录、查询、通知、纪要，但仅从这段文字中可以看出，这些数据多数实际上都是围绕会议的一组密不可分的逻辑数据（或操作） ，应被识别为一个 ILF。 b) 发文与收文中的“公文”是否是同一个“公文”？ 尽管都被称为“公文”，但由于对用户而言这两个公文的意义截然不同，对其进行的增删改查也是有本质的差别。按照 ILF的“逻辑性”定义，这两个公文应该被判断为两个 ILF。 c) 逻辑文件与物理文件
25、对 ILF 的识别必须是基于逻辑的，即用户单位基于其业务的需求，能意识到应该存在这样一个数据，并通过对其进行操作完成特定的需求。 被识别出来的 ILF 与实际软件系统中的数据表或物理文件并非一个概念，因为由于数据唯一性/性能等考虑原因，一个 ILF 的信息常常被存储于多个数据库表中；而对于桌面文件系统（如微软 WORD），则又会将大量 ILF 存储于单一文件中。 示例2 识别操作其次数 8 本系统可以使公文管理中起草、审核、传阅、批示、签发、督办、查询 等全部过程实现全电脑自动化管理 “公文”显然是此系统内部需要管理的数据，在此处明示的操作包括起草（增） 、审核（改状态）、传阅（改权限和接收人
26、）、批示（改信息和状态）、签发（改状态） 、督办（改信息和状态）、查询（查）7种。 实际上这里还隐含了很多未提及的操作，如删除（因误操作导致的错误公文） 、编辑（修改公文名称等信息）。但由于已经发现的操作数量已经足以支持这是一个 ILF，所以在招标阶段不需要再明确是否需要这些操作；在投标阶段乙方需要分析和确认这些操作是否必要。 示例3 识别隐藏的ILF 发文管理是指以X局（信息中心）名义下发、转发或提交上级机关审批的文件 在此处的文字描述中，并未明示存在“发文单位”和“收文单位”两种内部数据，但从上下文中却可以识别它们。 对于“发文单位”，由于是固定的，因此其信息不需要进行“增删改查”等操作，
27、不是一个 ILF；而收文单位由于存在不确定性，需要录入（增） 、删除（删）、编辑（改）、以各种形式进行“增删改查”并记录结果，可以识别为一个 ILF。 若无法判断是否需要“增删改查”时，估算执行者应与预算申请书/招标书编写人讨论核实。比如若此公文管理系统允许“各级机关发送公文”，则“发文单位”也不是单一固定的，而是需要增加和删除可发文单位（增/删） 、修改发文授权（改）、编辑（改）、查看所有发文单位（查） 、查看发文历史（查）等操作，也应被识别为 ILF。 若文档编写者学习并理解了本标准，则应该在编写文档时避免出现隐藏的 ILF。 示例4 排除不合格的ILF 在预算申请/招标过程中，每个识别出
28、来的 ILF 对应 35 个功能点，合 2 人月左右的工作量。因此作为招标单位，应该谨慎对待产品功能，要避免“可以进行增删改查的数据都进行增删改查”，而是“有必要 进行增删改查的数据才进行增删改查”，以避免非实质性需求膨胀。 “是否值得为某个数据的管理投入大量工作”，也是一种直观而迅速地判断数据是否是一个 ILF 的方法。 下面的几个例子说明了这种情况的识别方法。 a) 用户可根据管理权限和指定条件查知当前公文处理情况和 领导批示，进行动态跟踪； “领导批示”尽管也需要填写、编辑、查看等操作，但它与单个公文是一一对应的（或固定地存在事先指定的多级批示），不需要动态增加、删除、列表查看多个批示，
29、因此它不是一个 ILF，而是“公文”的一个或多个字段。 9 b) 在上述发文的整个形成过程中任何人对文件的修改均记录在案，通过不同的颜色区分每个人修改的部分，并能显示修改人和修改时间，即笔迹保留。 “不同颜色”是固定使用的，无需在使用软件过程中动态调整，因此也不属于 ILF。 类似的情况如邮政编码、省地市区划名称、月份日历等。它们的特点包括： 一经指定很少改动，在软件中也没有某个界面提供这些数据的“增删改查”操作。 对这些数据的少量改动一般采用导入数据库表、配置信息和配置文件等进行。 对它们的改动不是实质性业务需求。 “笔迹”的情况则需要更进一步的信息才能确认。 “修改”操作如果只是按修改人/
30、修改时间简单追加到末尾（增） ，则不是一个需要增删改查操作的 ILF； 若还需要按修改人/修改时间过滤（查） 、以特殊字体显示被删除的内容（查）、接受/拒绝修改（改） 、回复到修改前的版本（改）等复杂操作，则应被识别为ILF。 这两种情况需要的开发工作量差别很大，也是为什么会存在“是否需要识别为 ILF”的差别。 c) 提供简便、快捷、有效地查询和统计各类收文 ，并打印出收文目录。 “各类收文”应被识别为一个 ILF，因为它们包含的信息及处理的业务流程相似，差异之处也只需要通过配置而非大量开发工作即可解决。 常见的类似情况例如： 领导/职员，多数信息相同，仅有授权不同，可被识别为一个 ILF。
31、 各类会议（公文） ，其主要数据和操作是相同的，只是参与人/处理流程会有差异，应被识别为 1个 ILF。 需要具体分析的情况例如： 日计划/周计划/月计划，若月计划中直接计划了具体的事情，并分配到周/日计划中执行，则应被识别为 1 个ILF；若月计划中只分配资源/优先级/工作方向/里程碑，在日计划中则是具体任务/日程提醒/工作量统计等工作，则两者在数据信息和操作逻辑上都是不同的，应被识别为多个 ILF。 示例5 识别EIF 领导通过手写笔输入自己的电子签名，当需要批阅公文时，系统会核对手写签名的正确性来判断用户是否合法来保证系统的安全性。 管理“手写签名”显然不是公文流转系统的功能，因为公文系
32、统不进行保存签名（增）/删除签名（删）等操作，公文流转系统只从外部调用签名系统的某个功能，因此“手写签名”被识别为 EIF。 若“签名系统”也在本次软件开发范围中，则可以同时被识别为“签名系统”的一个ILF。 10 更详细的内容请参考投标书及附件格式，以及附件（估算工具）使用说明。 A.2 规模变更因子 预算规模变更因子 = 2.0 招标规模变更因子 = 1.5 投标规模变更因子 = 1.26 A.3 功能点耗时率 功能点下限耗时率 = 9.1 小时/功能点 功能点标准耗时率 = 13.4 小时/功能点 功能点上限耗时率 = 24.8 小时/功能点 A.4 软件因素调整因子 软件因素调整因子
33、= 【规模调整因子】 * 【应用领域调整因子】 * 【质量及特性调整因子】 规模调整因子 规模调整因子 = 0.108 * Ln （功能点规模）+ 0.2229 利用规模调整因子，可以区别对待不同规模项目的生产率。 应用领域调整因子 应用类型 调整因子 范围 业务处理用 1.0 OA、公文流转，人事、会计、工资、销售等经营管理及业务处理用软件 科技用 1.2 科学计算、模拟、空白表格程序,统计, CAE（计算机辅助工程）等 多媒体用 1.3 图表,影像, 声音等多媒体应用领域,地理信息系统,教育和娱乐用等 智能信息用 1.7 自然语言处理,人工智能,专家系统等 系统用 1.7 操作系统,语言处
34、理程序,DBMS,人与机器的接口,窗口系统,CASE,实用程序等 通信控制用 1.9 通信协议,仿真,交换机软件,GPS 等 流程控制用 2.0 生产管理,CAM（计算机辅助制造）,CIM（计算机集成制造）,仪器控制,机器人控制,实时控制,内置性软件等 指挥管制用 2.2 军队,警察等需要管制军备和人力的软件 11 质量及特性调整因子 质量及特性调整因子 = （分布式处理因子 + 性能因子 + 可靠性因子 + 多重站点因子）* 0.025 + 1 调整因子 判断标准 影响度 没有明示对分散处理的需求事项 0 通过网络进行客户端/服务器及网络基础应用分布处理和数据传输 1 分布式处理 此应用能够
35、在各组成要素之间传输数据 在多个服务器及处理器上同时相互执行应用中的处理功能。 2 没有明示对性能的特别需求事项或活动，因此提供基本性能 0 应答时间或处理率对高峰时间或所有业务时间来说都很重要存在对连动系统结束处理时间的限制 1 性能 对用户对应答时间或处理率的需求水平 为满足性能需求事项，要求设计阶段开始进行性能分析，或在设计开发实现阶段使用分析工具 2 没有明示对可靠性的特别需求事项或活动，因此提供基本的可靠性 0 发生故障时可以轻易修复，带来稍微不便的损失 1 可靠性 发生障碍时引起的影响程度 发生故障时很难修复，发生经济损失或有生命危害 2 在设计阶段只需考虑一个设置站点的需求事项
36、， 为了只在相同用途的硬件或软件环境下运行而设计 0 在设计阶段需要考虑一个以上设置站点的需求事项 ，为了用途类似的硬件或软件环境下运行而设计 1 多重站点 开发能够支持不同硬件和软件环境的软件 在设计阶段需要考虑一个以上设置站点的需求事项 。为了在不同用途的硬件或软件环境下操作而设计 2 A.5 工期-工作量回归参数 工期 = = b*工作量a0.404*277.1 工作量A.6 EI/EO/EQ 简易识别标准 编写投标书的人员应学习和理解本标准，并在文字中为估算者提供足够的信息来识别 EI/EO/EQ。 若无法判断是否满足下面的规则时，估算者应与编写人讨论核实。 在投标过程中，仍然需要识别
37、 ILF和 EIF，具体方法与附录 A.1 中的描述相同。 12 EI/EO/EQ 的简易识别规则如下： z EI 的简易识别规则 是一个相对完整的“基本过程”（详细解释见后） 对内部数据的增/删/改均为EI 从外部接口中读取并存储到内部数据中 接受某个控制信号并使软件状态改变 z EO 的简易识别规则 是一个相对完整的“基本过程” 对内部数据的复杂报表（含计算内容）/统计分析等 向外部接口发送数据/控制信号 z EQ 的简易识别规则 是一个相对完整的“基本过程” 对内部数据的简单报表（不含任何计算，但可以分组或排序） 若对某些数据仅需要进行删或改而不进行任何查询，都自动隐含计算一个 EQ（即
38、只有能查询，才能删除或修改） 其它规则： z EO 和 EQ 也有可能输入信息（如输入查询条件，或触发操作如按下按键） ，但如果结果中包含向外输出数据/信号，则应优先被识别为 EO 或EQ 而非EI。 z 单个 EI/EO/EQ 无论可以被几种方式调用（比如菜单/快捷键/超链接/按钮） ，都只被计数一次，不可重复计数。 “重复计数”包括描述分开，但部分逻辑完全相同的情况。 示例1 从“基本过程”认识EI/EO/EQ 所谓“基本过程”，是指独立完整且用户可以明确感知其业务意义的一次操作，操作完成后系统进入一个稳定状态。 “独立完整”指过程本身包含了正常和异常情况的处理，下面是一个例子： a) 呈
39、送领导时，系统应查询领导活动安排子系统，若该领导出差，应及时提醒相关工作人员合理安排公文流程，从而杜绝“死文”的发生。 这里“呈送领导”操作分为两种情况，正常呈送和出差提醒；只有两种情况都加以处理，软件才能进入相对稳定的状态，因此只能被识别为一个基本过程。 此操作有可能改变数据（改变负责人，EI），也可能触发输出信息（提醒工作人员，EO），根据“其它规则”中的定义，应被识别为一个 EO。 “稳定状态”可以理解为在此状态下，软件数据完整/稳定，操作人员可以转而进行其它操作，即使掉电/重新启动系统，不会发生数据丢失的状态。 稳定状态的例子比如： 创建并保存了一个公文。 已将公文呈送给领导（但领导尚
40、未阅读）。 13 不稳定状态的例子比如： 利用多页面向导创建公文的中途（已按下多次“下一步”但未按下“完成”）。 提示：因此多页面向导只能被识别为一个 EI（或 EO/EQ） 。 领导用手写笔输入签名，但尚未按下“验证” ；或按下“验证”，但尚未从签名系统反馈出验证结果；等等。 示例2 区分EI 和EO/EQ EI 有时也会产生“输出” ，EO/EQ 有时也会需要输入，例如： 创建公文，并返回是否成功。 （EI，成功和失败信息不作为实质性输出） 重新发送指定 ID 的公文（EO，输出到系统外部） 用 ID 查询公文（EQ，查看原始信息） 对于这几种混合情况，一种快速判断方法是看 操作的主要目的
41、。EI/EO/EQ 的主要目的分别是： EI：输入并保存数据，或控制信息改变系统状态 EO：计算产生新的数据并查看信息；将数据/控制信号输出到其它系统 EQ：以原始状态查看信息 示例3 识别和区分EO 和EQ EQ 的目的是以原始面貌查看一个或多个 ILF 中的数据，可能的处理仅限于排序/筛选/分组。 EO 的目的是从一个或多个 ILF 计算新的数据，或将数据（计算结果）或控制信号输出到系统以外。 在 EQ/EO 中也会输入数据，比如查询条件/计算方法等，但不额外计算一个 EI（因为不满足基本过程中的“稳定状态”） 。 EQ 的例子包括： 查询 3 月份所有已发送公文，并按发送日期排序 注：不
42、做任何统计计算功能 搜索某个已知 ID 的公文 帮助系统（搜索帮助条目） 登录并验证密码（搜索用户名密码符合的用户） EO 的例子包括： 查询 3 月份所有已发送公文，并计算督办完成比例 打印某个（某些）公文 示例4 识别隐含的EQ 对于简单的数据的描述，常常出现漏掉“查询”的情况，比如： a) 对于收文单位，要能进行增加/删除/修改等操作。 14 实际上，为了能够删除和修改收文单位，必须首先要能列出或查询到收文单位。因此对于未明示“查询”操作但有删除/修改操作需求的情况，应该多识别并计算一个隐含的 EQ。 上例中包含四个操作：增加（EI）/删除（EI）/修改（EI）/查询（EQ） 。 但如果
43、其他操作中已经将隐含的查询计数过了，则不再重复计数。比如： b) 对于收文单位，要能进行增加/删除/修改等操作，并能生成各收文单位收文总数的汇总报表。 本例中包含四个操作：增加（EI）/删除（EI）/修改（EI）/汇总报表（EO） 。由于在汇总报表中已经包含了对收文单位的查询，不再重复计数。一种快速识别方法是：若一个数据或接口包含了一个统计/报表类型的 EO，就不再计算隐含的查询。 示例5 “数据”和“控制信息” EI和 EO 既可以是输入输出数据，也可以是“控制信息” ，这类例子包括： 开始杀毒（EI） 定时调用文件系统（另外一个系统）的文件备份功能（EO） a) 呈送领导时，系统应查询领导
44、活动安排子系统，若该领导出差，应及时提醒相关工作人员合理安排公文流程，从而杜绝“死文”的发生。 更详细的内容请参考投标书及附件格式，以及附件（估算工具）使用说明。 A.7 需求吻合度 需求吻合度是一个分数，它的具体取值如下： 数据/接口 判断标准 需求吻合度 现有产品中没有处理这类数据 1 现有产品处理过这些数据，但提供的 EI/EO/EQ 与需求有一定差异 2/3 内部数据 ILF 现有产品处理过这些数据，提供的 EI/EO/EQ 完全达到或超过需求 1/3 现有产品从未与类似接口集成过 1 现有产品曾与类似接口集成过，但发生在编码级 2/3 外部接口 EIF 现有产品有公开的可调用的方法与
45、类似接口集成 1/3 A.8 开发因素调整因子 开发因素调整因子 = 【开发语言调整因子】 * 【企业背景调整因子】 开发语言调整因子 语言分类 调整因子 15 C 及其它同级别语言/平台 1.2 COBOL 及其它同级别语言/平台 1 JAVA，C+，C#及其它同级别语言/平台 0.8 企业背景调整因子 判断标准 调整因子 为本行业开发过类似的项目 0.7 为其它行业开发过类似的项目，或为本行业开发过不同但相关的项目 0.9 没有同类项目的背景 1 A.9 软件开发商人月费率 行业建议的数值为软件开发商平均税前工资的 2.73.35 倍之间。例如，软件开发商平均税前工资 5000 元/月，则
46、此数据为 1350016750元/人月。 此计算方法已包含行政管理费用/办公费用/人员闲置费用/四险一金/企业税率， 但不含企业利润率。 由于行业的差异，本标准不设定软件开发商人月费率的绝对值。但若软件开发商来自不同的地区，多个软件开发商投标时提供的人月费率相对值应大致如表所示（以北京为 1.0） ： 城市 薪资系数 城市 薪资系数 城市 薪资系数 上海 1.13 天津 0.70 济南 0.59 北京 1.00 海口 0.69 太原 0.58 深圳 0.98 成都 0.69 沈阳 0.58 广州 0.95 青岛 0.65 合肥 0.55 珠海 0.90 重庆 0.65 长春 0.55 杭州 0
47、.85 福州 0.63 贵阳 0.52 厦门 0.85 武汉 0.60 南昌 0.50 苏州 0.83 长沙 0.60 哈尔滨 0.50 宁波 0.80 西安 0.60 石家庄 0.49 南京 0.78 昆明 0.60 呼和浩特 0.40 大连 0.75 A.10 利润率 行业建议的利润率为 15%。 实际投标中可以根据项目风险/地区差异/技术先进性/软件开发商策略等因素调整利润率。 16 A.11 各阶段比例系数 开发阶段的工作量比例系数 需求 设计 构建 测试 实施 11.44% 13.54% 45.45% 21.94% 7.63% 开发阶段的工期比例系数 需求 设计 构建 测试 实施 1
48、7.89% 13.22% 26.06% 27.56% 15.27% 附录 B B.1 参考模型与数据来源 本标准采用的规模计数模型参考并兼容 IFPUG国际功能点标准/NESMA简易计数标准。 本标准采用的工作量/成本/工期估算模型参考了韩国软件成本估算指南。 本标准采用的数据参考或回归自韩国软件成本估算指南/ISBSG 政府项目报告（ISBSG，Govt Sector Report Rel 1.3 1912031） /ISBSG数据/CSBSG数据。 对于一些定性数据如调整因子的设置和权重，在参考其它标准基础上，由本标准的编委单位经技术讨论会议产生。 B.2 估算过程差异对比 在本标准中，预
49、算过程/招标过程/投标过程的计算方法和公式非常类似，为防止混淆，对比差异如下： 工作内容 预算过程 招标过程 投标过程 输入文档 预算申请书 招标书 投标书 输入 附件 预算申请书附件 招标书附件 投标书附件 规模估算 ILF * 35 + EIF * 15 ILF * 10 + EIF * 7 + EI * 4 + EO * 5 + EQ * 4 规模 规模变更因子 预算规模变更因子 招标规模变更因子 投标规模变更因子 未调整工作量 规模 * 【功能点耗时率】 / （8 * 21.5） 工作量 工作量调整 未调整的工作量 * 【软件因素调整因子】未调整的工作量* 【软件因素调整因子】* 【开发因素调整因子】 预算 预算 工作量 * 【用户单位人月费率】 - 价格 价格 - 工作量 * 【软件开发商人月费率】 * （1+【利润率】 ） 17 工期 工期 工期 = 各阶段工作量 - - 总工作量 * 【工作量比例系数】 计划 各阶段工期 - - 总工期
