中国软件行业软件工程定额标准(试行)

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