中国软件行业软件工程定额标准试行资料下载.pdf
《中国软件行业软件工程定额标准试行资料下载.pdf》由会员分享，可在线阅读，更多相关《中国软件行业软件工程定额标准试行资料下载.pdf（22页珍藏版）》请在冰点文库上搜索。
虽然具备计算机基本使用能力的人员经过简单培训，即可高效率地完成项目估算工作。
但本标准建议由编制预算申请书/招标书/投标书的人员执行/参与估算，如此可提高估算的速度和精度；
项目需求是估算的依据。
2222术语2.1功能点，功能点估算，国际功能点用户组，国际基准比对组织a）功能点功能点功能点功能点（FunctionPoint，FPFPFPFP）功能点是基于软件外部功能（输入、输出、接口、报告）对软件规模的度量。
b）功能点估算功能点估算功能点估算功能点估算只供个人研究和学习，禁止商业用途，版权所有，翻版必究2功能点估算是一种基于软件功能计数来评估软件规模的估算方法，其中也考虑到了性能/安全/质量等因素带来的规模调整，但不考虑软件开发商的企业背景/经验/所用技术等非产品因素。
功能点估算的优点是：
用户单位和软件开发商都可以理解；
在项目早期利用有限的功能描述即可进行估算。
c）国际功能点国际功能点国际功能点国际功能点用户组用户组用户组用户组（IFPUGIFPUGIFPUGIFPUG，InternationalFunctionPointUsersGroup）IFPUG为功能点的识别和计数提供了国际标准，使不同的人对同一软件的规模的认识是相同的。
本标准提供的简易识别规则参考了IFPUG标准规则的功能点计数方法。
d）NESMANESMANESMANESMA（NetherlandsSoftwareMetricsAssociation）NESMA是荷兰的功能点组织，也是世界第二大功能点组织。
其创造的一系列简化功能点方法在估算界占有重要地位。
e）国际国际国际国际软件软件软件软件基准比对基准比对基准比对基准比对标准组标准组标准组标准组（ISBSGISBSGISBSGISBSG，InternationalSoftwareBenchmarkingStandardGroup）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%低于或高于该数值。
只供个人研究和学习，禁止商业用途，版权所有，翻版必究3b）下限值下限值下限值下限值/上限值上限值上限值上限值在本标准中，下限值/上限值并不表示项目的最优/最差可能状态，它们被定义为“50%的项目实际执行情况会介于下限值/上限值之间。
”如果招投标或立项时采用了低于下限或超出上限的估算值，项目出现延期、超支等情况的概率将显著增加。
允许出现采用低于下限或超出上限估算值的情况，但此时用户单位与软件开发商双方应该就其原因进行特殊说明并达成共识。
3软件工程定额标准的使用流程下面的图3.1描绘了软件工程定额流程，以及本标准定义的“用户单位预算申请”、“用户单位招标”、“软件开发商投标”三个软件工程定额估算过程的关系。
在本标准的定义中，“用户单位预算申请”与“用户单位招标”过程的估算模型和计算公式相同，过程的具体步骤在本标准第4章描述。
“软件开发商投标”过程在第5章描述。
其中“实际开发”部分不在本标准的范围内，但执行本标准的单位应度量项目实际执行情况并记录数据，供编委会工作组持续修订估算模型和估算工具表的方法及参数。
4用户单位预算申请及招标估算过程4.1识别功能点计数元素招标书编写时应注明软件系统需要管理的内部数据（ILF）和外部接口（EIF），ILF和EIF的简易识别标准见附录A.1。
将识别出的ILF和EIF数量填入本标准附件A计算工具。
用户单位用户单位软件开发商软件开发商编写预算申请书预算申请估算规模工作量预算工期申请预算编写招标书编写投标书招标估算规模工作量招标价格工期投标估算规模工作量投标价格工期各阶段比例招标投标实际开发实际规模实际工作量实际成本实际工期实际各阶段比例图3.1软件工程定额流程只供个人研究和学习，禁止商业用途，版权所有，翻版必究4建议招标书的格式参照本标准提供的附件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。
只供个人研究和学习，禁止商业用途，版权所有，翻版必究54.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计算投标计数规模投标计数规模=【需求吻合度】*）*4*5*4*7*10（EQEOEIEIFILF+）在投标过程中，软件开发商应既要考虑内部数据ILF和外部接口EIF，也要考虑软件的业务EI、EO、EQ。
此处的10、7、4、5、4等数值是这种情况下各种计数元素所对应的功能点分值。
只供个人研究和学习，禁止商业用途，版权所有，翻版必究6【需求吻合度】表明了软件开发商现有产品或已有模块在某个功能上与用户单位需求的吻合程度。
若拥有较好的吻合度，则软件开发商可以因此降低工作量/成本/工期以获得更好的竞争力。
为了降低分析复杂度，需求吻合度只和ILF内部数据或EIF外部接口对应，而无需细化到EI/EO/EQ上。
在计算需求吻合度对工作量的影响时，本标准认为即使需求完全吻合，仍可能产生部分工作量。
需求吻合度的计算方法见附录A.7。
5.3计算投标规模投标规模=投标计数规模*【投标规模变更因子】单位：
功能点本公式的解释请参考4.3章。
【投标规模变更因子】数值见附录A.2。
5.4计算未调整的投标工作量未调整的投标工作量=投标规模*【功能点耗时率】/（8*21.5）单位：
人月本公式的解释请参考4.4章。
5.5调整投标工作量投标工作量=未调整的投标工作量*【软件因素调整因子】*【开发因素调整因子】单位：
人月本公式及【软件因素调整因子】的解释请参考4.5章。
软件开发商计算开发工作量时，除了与用户单位一样考虑软件因素造成的工作量差异之外，还要考虑自身经验/开发方法等造成的工作量调整。
开发因素调整因子的引入对这一偏差进行了修正。
开发因素调整因子只考虑软件开发商本身的情况，它是软件开发商评估自己开发这个软件产品的个别成本的主要因素。
【开发因素调整因子】的具体计算方式见附录A.8。
5.6计算投标价格投标价格=投标工作量*【软件开发商人月费率】*（1+【利润率】）单位：
万元只供个人研究和学习，禁止商业用途，版权所有，翻版必究7【软件开发商人月费率】为软件开发商根据以往项目情况所总结的平均成本。
本标准给出了计算此费率的方法以及建议的数值，具体情况见附录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个功能点。
本节规则适用于单个迭代历时13个月，且每个迭代均产生可运行的软件版本（交付或不交付均可）的开发方式。
附录附录附录附录AAAA附录A是上述计算过程中所需的计算工具样例/分类方法/数值等内容。
部分数据和公式是固定的不需要更新的，比如每月按照8*21.5小时计算等。
另外一些数据和公式，每年编委会工作组都会进行更新，比如生产率，变更率等。
只供个人研究和学习，禁止商业用途，版权所有，翻版必究8AAAA.1.1.1.1ILF/EIFILF/EIFILF/EIFILF/EIF简易简易简易简易识别标准识别标准识别标准识别标准编写预算申请书或招标书的人员应学习和理解本标准，并在文字中为估算者提供足够的信息来识别ILF和EIF。
若无法判断是否满足下面的规则时，估算者应与编写人讨论核实。
若讨论后仍无法确定，则可以标识为“未定”状态，本标准附件中的估算工具会按一定比例计算此状态的ILF和EIF。
ILF和EIF的简易识别规则如下：
?
ILF简易识别规则?
ILF指在待开发系统内部逻辑上的、用户可识别的一组数据?
对单个ILF一般执行6种左右的操作?
用户可以理解和识别ILF，对ILF的操作是用户的业务需求?
EIF简易识别规则?
EIF指在其它需要集成的系统中，“读”或“写”操作至少执行其中一种及以上的外部接口无论对某个ILF或EIF提到过几次、进行多少操作，均只计数1次。
“数据”、“接口”、“操作”、“读写”经常以较为复杂的形式存在，下面的示例演示了如何快速识别ILF、EIF。
示例示例示例示例1111从从从从“逻辑逻辑逻辑逻辑”性性性性上上上上识别识别识别识别ILFILFILFILFa）会议管理系统包括X局（信息中心）局、处（或公司）举行的会议，会议计划、安排、记录、查询、通知、纪要等功能均实现电子化，提高会议效率。
尽管这里提到了多个需要管理的数据（或操作）：
计划、安排、记录、查询、通知、纪要，但仅从这段文字中可以看出，这些数据多数实际上都是围绕会议的一组密不可分的逻辑数据（或操作），应被识别为一个ILF。
b）发文与收文中的“公文”是否是同一个“公文”？
尽管都被称为“公文”，但由于对用户而言这两个公文的意义截然不同，对其进行的增删改查也是有本质的差别。
按照ILF的“逻辑性”定义，这两个公文应该被判断为两个ILF。
c）逻辑文件与物理文件对ILF的识别必须是基于逻辑的，即用户单位基于其业务的需求，能意识到应该存在这样一个数据，并通过对其进行操作完成特定的需求。
被识别出来的ILF与实际软件系统中的数据表或物理文件并非一个概念，因为由于数据唯一性/性能等考虑原因，一个ILF的信息常常被存储于多个数据库表中；
而对于桌面文件系统（如微软WORD），则又会将大量ILF存储于单一文件中。
示例示例示例示例2222识别识别识别识别操作操作操作操作其次数其次数其次数其次数只供个人研究和学习，禁止商业用途，版权所有，翻版必究9本系统可以使公文公文公文公文管理中起草起草起草起草、审核审核审核审核、传阅传阅传阅传阅、批示批示批示批示、签发签发签发签发、督办督办督办督办、查询查询查询查询等全部过程实现全电脑自动化管理“公文公文公文公文”显然是此系统内部需要管理的数据，在此处明示的操作包括起草（增）、审核（改状态）、传阅（改权限和接收人）、批示（改信息和状态）、签发（改状态）、督办（改信息和状态）、查询（查）7种。
实际上这里还隐含了很多未提及的操作，如删除（因误操作导致的错误公文）、编辑（修改公文名称等信息）。
但由于已经发现的操作数量已经足以支持这是一个ILF，所以在招标阶段不需要再明确是否需要这些操作；
在投标阶段乙方需要分析和确认这些操作是否必要。
示例示例示例示例3333识别隐藏的识别隐藏的识别隐藏的识别隐藏的ILFILFILFILF发文管理是指以X局（信息中心）名义下发、转发或提交上级机关审批的文件在此处的文字描述中，并未明示存在“发文单位”和“收文单位”两种内部数据，但从上下文中却可以识别它们。
对于“发文单位”，由于是固定的，因此其信息不需要进行“增删改查”等操作，不是一个ILF；
而收文单位由于存在不确定性，需要录入（增）、删除（删）、编辑（改）、以各种形式进行“增删改查”并记录结果，可以识别为一个ILF。
若无法判断是否需要“增删改查”时，估算执行者应与预算申请书/招标书编写人讨论核实。
比如若此公文管理系统允许“各级机关发送公文”，则“发文单位”也不是单一固定的，而是需要增加和删除可发文单位（增/删）、修改发文授权（改）、编辑（改）、查看所有发文单位（查）、查看发文历史（查）等操作，也应被识别为ILF。
若文档编写者学习并理解了本标准，则应该在编写文档时避免出现隐藏的ILF。
示例示例示例示例4444排除不合格的排除不合格的排除不合格的排除不合格的ILFILFILFILF在预算申请/招标过程中，每个识别出来的ILF对应35个功能点，合2人月左右的工作量。
因此作为招标单位，应该谨慎对待产品功能，要避免“可以进行增删改查的数据都进行增删改查”，而是“有必要有必要有必要有必要进行增删改查的数据才进行增删改查”，以避免非实质性需求膨胀。
“是否值得为某个数据的管理投入大量工作”，也是一种直观而迅速地判断数据是否是一个ILF的方法。
下面的几个例子说明了这种情况的识别方法。
a）用户可根据管理权限和指定条件查知当前公文处理情况和领导批领导批领导批领导批示示示示，进行动态跟踪；
“领导批示”尽管也需要填写、编辑、查看等操作，但它与单个公文是一一对应的（或固定地存在事先指定的多级批示），不需要动态增加、删除、列表查看多个批示，因此它不是一个ILF，而是“公文”的一个或多个字段。
只供个人研究和学习，禁止商业用途，版权所有，翻版必究10b）在上述发文的整个形成过程中任何人对文件的修改均记录在案，通过不同的颜色颜色颜色颜色区分每个人修改的部分，并能显示修改人和修改时间，即笔迹笔迹笔迹笔迹保留。
“不同颜色”是固定使用的，无需在使用软件过程中动态调整，因此也不属于ILF。
类似的情况如邮政编码、省地市区划名称、月份日历等。
它们的特点包括：
一经指定很少改动，在软件中也没有某个界面提供这些数据的“增删改查”操作。
对这些数据的少量改动一般采用导入数据库表、配置信息和配置文件等进行。
对它们的改动不是实质性业务需求。
“笔迹”的情况则需要更进一步的信息才能确认。
“修改”操作如果只是按修改人/修改时间简单追加到末尾（增），则不是一个需要增删改查操作的ILF；
若还需要按修改人/修改时间过滤（查）、以特殊字体显示被删除的内容（查）、接受/拒绝修改（改）、回复到修改前的版本（改）等复杂操作，则应被识别为ILF。
这两种情况需要的开发工作量差别很大，也是为什么会存在“是否需要识别为ILF”的差别。
c）提供简便、快捷、有效地查询和统计各类收文各类收文各类收文各类收文，并打印出收文目录。
“各类收文”应被识别为一个ILF，因为它们包含的信息及处理的业务流程相似，差异之处也只需
升级会员 