项目估算规范

1、密级：内部公开文档编号：VTS_PP_REGU_JHBGGC版本号：V1.0项目估算规程xx有限公司编制： xx生效日期：22008年 9月 28日审核： xx批准：xx-xx有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。文件更改摘要：日期版本号 修订说明修订人审核人批准人2008-08-11V0.1初稿2008-09-12V0.2修订变更评估与分析、计划变更申请2008-09-28V1.0正式版目 录1.简介11.1.目的11.2.适用范围11.3.术语表11.4.参考资料12.概述13.过程描述13.1

2、.角色与职责13.2.准入13.3.输入23.4.过程描述23.4.1.获取历史数据23.4.2.估计软件规模23.4.3.估计工作量33.4.4.估计成本33.4.5.估计关键资源33.4.6.估计关键路径和关键依赖关系43.4.7.制定进度表43.4.8.阶段详细估计43.4.9.形成项目数据估计表43.5.输出53.6.准出54.附录54.1.1.历史数据估计方法54.1.2.Delphi 估计方法64.1.3.Pert Sizing Technique估计方法74.1.4.工作量估计的方法74.2.1.开发工具系数94.2.2.规模系数94.2.3.生产率94.2.4.软件工程工作量阶

3、段分布10xx有限公司 项目估算规范1. 简介1.1. 目的本文档的目的是为了描述对项目软件产品的规模、工作量、成本、关键资源和进度等进行估计，描述了估计的步骤和过程。1.2. 适用范围本文档适用于公司的所有软件项目。1.3. 术语表无。1.4. 参考资料CMMI® for Development, Version 1.2CMMI Product Team2. 概述每一个项目都要进行估计，并将估计的结果作为项目计划的基础。估计是项目计划的核心。目的是为项目建立合理的预算，确定合适水平的员工，并为项目承诺提供基础。一个没有建立在合理估计基础上的计划会提供一种错误的安全感，可能比根本没有

4、计划更糟。估计的内容通常包括：规模、工作量/成本、关键资源、关键路径和关键依赖、进度表等。估计和计划贯穿了整个项目。在项目的早期阶段，使用自上而下（top_down）的方式进行粗略的估计和制定进度表。随着项目的进展，在每个详细的计划阶段，使用自下而上（bottom_up）的方法为子阶段进行更详细的计划。下一阶段的底层WBS元素必须定义，并在WBS中进行记录。先对WBS的底层元素进行估计，然后汇总到较高层，用来更新总的软件估计。软件估计的流程如下：图表 1 软件估计流程本文提供了几个估计方法及相关过程，它们主要应用于公司的软件项目规模、工作量及成本、关键计算机资源等的估计。如果这些估计方法不适用

5、于特定的项目，项目经理必须为该项目提出另外的估计方法。3. 过程描述3.1. 角色与职责l 项目经理：组织进行软件估计。l 项目组：在项目经理组织下，共同完成项目的各项估计。l 相关人员：主要是指对本项目情况较熟悉的人员。3.2. 准入l 确定了项目范围l 完成了项目工作结构分解3.3. 输入l WBS工作结构分解3.4. 过程描述3.4.1. 获取历史数据为项目估计、度量的量化目标提供支持。详细参见公司财富库中历史数据。3.4.2. 估计软件规模规模估计的目的是为了判断待开发软件产品的规模，规模是成本估计、进度估计的基础，为了估计成本和进度，所以必须进行规模估计。WBS是软件规模估计的基础。

6、我们常用的估计整个软件产品的规模的单位是：功能点（FP）。代码行（LOC）。其它：如交易数量、表数量等。有时需要估计个别软件工作产品的规模，一般采用以下单位：页：用于估计技术文档规模。字数：用于估计技术文档规模。测试用例的个数：用于估计测试规模。估计软件产品的规模主要依靠过去相关的经验，估计人员应当具有相似系统的开发经验，利用自上而下（top-down）或者自下而上（bottom-up）方式进行软件规模的估计。具体步骤如下：1) 将软件工作产品拆分成能实现精确估计的较小部分。2) 分析软件产品的WBS。3) 选择合适的度量单位。4) 选择估计方法，结合选择的技术解决方案（开发工具、语言、平台等

7、），对WBS中的产品功能进行估计。5) 估计方法可以是历史数据估计方法，或者Delphi法。6) 在项目策划过程中，评审和修正有关软件规模估计的问题，对软件产品的估计达成一致。7) 将规模估计的结果记录到项目数据估计表及项目计划中。3.4.3. 估计工作量完成项目规模估计后，应该确定完成这些工作需要的时间（以工时为单位），项目经理应该使用模型、历史数据和软件工作产品大小来确定项目工作量。工作量估计的内容应当包含以下内容：1) 软件开发工作量，包括需求分析、设计、编码、测试、其它技术文档。2) 项目管理活动的工作量。工作量的估计可以按以下步骤进行：1) 选择估计方法。2) 对WBS中的每个任务分

8、别进行估计。3) 对于软件开发等工作，可以根据估计的规模和经验数据值进行换算。4) 估计CM工作量近似于软件工作量的 610%。5) 估计QA工作量近似于软件工作量的 812%。6) 估计出项目管理活动的工作量，近似于软件工作量的15%20%。7) 估计评审工作量近似于软件工作量的5。8) 估计培训工作量近似于软件工作量的3。9) 将估计的结果记录到项目数据估计表中。3.4.4. 估计成本估计出工作量（工时）后，应根据公司的财务要求，进行成本的估算。估算的内容有：人力成本：人力成本（按月）*（工作量/8/22）。直接费用：直接可以报销的费用，如培训费、车费、活动费用等。3.4.5. 估计关键资

9、源项目经理应该明确完成项目所需的关键资源，并进行关键资源估计。关键资源可以是服务器环境、测试环境、目标环境等，也可以是识别出来的关键的项目组内外人力资源等。估计关键资源的步骤如下：关键资源是在软件开发和操作中受到约束的硬件资源和人力资源，前者如：计算机内存、磁盘容量、网络容量、处理器性能等；后者如项目的关键人员，包括项目组的，相关组的，以及客户。项目经理根据项目要求确定关键资源的约束。如果有关键资源，则要估计软件开发或运行中的资源状况。与估计的软件规模、计划的处理负载、预计的数据量、或其他因素相联系，来估计所需的资源的总量，作初始估计。当初始估计做好后，应对每一项资源建立一定的储备。将估计的关

10、键资源记录在项目计划“关键资源”列中。3.4.6. 估计关键路径和关键依赖关系项目经理和项目组的相关人员、QA负责人、CM负责人、相关组负责人根据各活动间的关系确定关键路径和关键依赖关系。3.4.7. 制定进度表进度表的制定可以按以下流程进行：1) 项目经理和各负责人根据估计的工作量和关键依赖关系确定每个活动的起止日期。2) 根据第1步的结果，结合资源的具体情况，项目经理和各负责人调整任务的起始日期、终止日期，甚至是调整某些任务的负责人和关键路径。（如：通过第1步的结果，发现某些项目人员在某个时间段内工作超负荷，而有些人员在某些时间段内工作量不足，这样就需要调整。若实在调整不了，就有可能会调整

11、关键路径）。3) 项目经理在项目进度表中要安排里程碑点（里程碑点一般选在有特定意义的阶段点，如重要阶段的开始或结束），并形成进度表的草稿。4) 将形成的Project草稿提交给项目组的成员或负责人，得到他们的承诺或根据他们的意见进行修改，直至达成一致。5) CM人员和QA人员根据达成一致的进度表，确定自己的日程安排。注意：返工的问题：软件项目中的返工工作量是较大的，即在发现工作产品缺陷时的修改工作。一般来说，应在每个阶段为返工的工作留出时间，做任务安排。有些项目较紧急，要求项目成员加班进行工作。对于这种情况，制定进度表一定要小心。因为若有特殊情况或某项关键任务估计得过于乐观，会导致项目进度拖延

12、，而无法再用加班的方式进行弥补。管理活动的时间占用问题：项目经理根据软件估计中的管理估计和一些技术方面的交流活动的估计，确定项目各成员在各个阶段可以真正用于完成技术任务的时间。如：在编码阶段，某项目成员每周工作40小时，但评审、项目会议以及一些技术方面的交流、培训就占去了18个小时，那么在安排该项目成员的技术任务时，只能按照他每周工作22（4018）个小时去安排。3.4.8. 阶段详细估计1) 在项目每个阶段开始前，要作阶段详细估计（工作量和时间表）。估计的步骤同上述的过程相同。2) 把详细估计累计起来，确定项目和阶段的总估计。3) 完成后更新总体的软件估计和项目计划。3.4.9. 形成项目数

13、据估计表将上述估计的结果记录到项目数据估计表中。（可参见项目数据估计表模板）软件估计要在项目的不同阶段进行，一般是在本阶段完成时进行下一阶段的详细估计。项目数据估计表作为项目计划的一部分一起评审。3.5. 输出项目数据估计表PROJECT相应估算内容3.6. 准出项目估算已完成4. 附录4.1. 估计方法4.1.1. 历史数据估计方法这种软件规模估计方法主要是利用已完成的项目数据来估计软件的代码量，通常用代码行数表示。使用此方法需注意以下几点：l 充分了解系统需求l 判断历史项目对现有软件的适用性l 基于历史项目的相似性对软件规模进行相应的调整历史数据估计方法的步骤如下：4.1.1.1. 步骤

14、一：分解软件系统把软件系统模块化，通过系统模块化可以及早了解整个系统。系统分解程度要以历史项目为基础。4.1.1.2. 步骤二：确定相似模块使用历史项目要与当前项目有相似的应用和相似的语言。假如相似的模块不存在，也可以用其它方法估计该模块。4.1.1.3. 步骤三：确定相似模块规模使用历史项目可以通过标准的代码统计工具实现，在开发和估计当前项目规模时，要求使用同类型统计工具。4.1.1.4. 步骤四：调整模块大小软件模块估计的调整基于历史项目模块的相似程度或修改量。软件项目中用历史数据估计法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的

15、代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行：等价代码行 = (重新设计% +重新编码% +重新测试%)/3× 已有代码行 比如：有10,000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为： (30% + 50% + 70%)/3 × 10,000 = 5,000 等价代码行。意即：重用这10000代码相当于编写5000代码行的工作量。4.1.1.5. 步骤五：记录估计数据4.1.2. Delphi

16、估计方法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种软件相关经验人的参与，互相说服对方。其步骤如下：4.1.2.1. 步骤一项目经理选择三至六名有经验的工程师（可以是项目组外的工程师，可以包括项目经理本人），他们应具备该项目的背景知识。并发给每位工程师一份估计参考资料（通常有：产品可行性报告/项目总体计划、软件需求规格说明书、WBS、风险管理计划等），和一张记录估计值的可迭代的表格。4.1.2.2. 步骤二项目经理召集各工程师讨论与规模相关的因素。4.1.2.

17、3. 步骤三每位工程师匿名填写迭代表格。里面包含了评估的理由。4.1.2.4. 步骤四项目经理整理出一个估计总结，以迭代表的形式返回每位工程师。4.1.2.5. 步骤五项目经理召集小组会，讨论较大的估计差异。4.1.2.6. 步骤六工程师复查估计总结并在迭代表上提交另一个匿名估计。4.1.2.7. 步骤七重复步骤四-六， 直到获得一个得到多数工程师共识的软件规模。4.1.3. Pert Sizing Technique估计方法这种方法共估计三个值： 软件产品预期规模的一般值、最大值和最小值。通过这三个值的计算可得到一个统计学上的期望值和一个标准偏差。公式：PERT公式估计的预期规模是E，标准偏

18、差是SD：E=（a+4b+c)÷6SD=（c-a）÷6例如：一个新的通信程序：a=规模的最小值，例如：10KSLOCb=规模的一般值，例如 12KSLOCc=规模的最大值，例如 15KSLOC即：E=（10+4*12+15）÷612.167(KSLOC)SD=(15-10)÷6=0.833这就是说，此通信程序的规模可能会在11.334KSLOC（12.167-.833）和13KSLOC（12.167 + .833）之间。本估计方法的前提是对规模的估计没有偏见，经验表明，估计偏低的倾向大于偏高的倾向，使用时应加以考虑。4.1.4. 工作量估计的方法4.1.

19、4.1. 运算法（ALGORITHMIC COST MODELS）运算法是一种简单直观的估计方法，它根据规模估计的结果和相应的系数运算得到工作量估计：工作量 = p/s*l*ep = 软件产品的规模（SLOC）s = 生产率（每人日的代码行）l = 开发工具系数e = 规模系数组织应根据自身的实际情况，定义使用不同开发语言时的调整系数，并且应当根据历史信息，经常调整开发工具系数，当没有这些信息的时候，可以由组织中有经验的人决定。开发工具系数越大，表示对工具提供的助力越低。下表是开发工具系数表的例子：开发工具系数标准C/C+1.2BO0.6.软件规模的大小也是影响规模估计的参数之一，系统的规模越

20、大，对工作量估计的影响就越小，这些数据的例子是：规模(KSLOC) 系数501.091001.08.4.1.4.2. 专家判断法（EXPERT JUDGEMENT）本估计方法需要使用者有类似系统的经验，结合规模估计的结果和WBS综合分析，形成对工作量的估计，可以按照下面的步骤进行：1) 结合WBS，根据经验和规模来估计WBS中每项功能的工作量。2) 根据每个功能点实现难度和风险的大小，适当调整工作量的估计。3) 按阶段合计需要的工作量，形成总的工作量的估计。4.2. 估计系数估计过程中需要使用很多的系数，这些系数在各个项目中是不同的，每个项目都可以根据实际情况确定自己的系数，可以参考其它项目或由项目内经验丰富的人来确定，随着软件过程数据库的丰富，不断的进行修正。当系数表中没有合适的系数时，可以使用最相近的系数或由项目内经验丰富的人来确定，增加到系数表中。所有系数的修改和增加，都应报告给EPG，经高级管理者批准后更新到系数表中才可以使用。4.2.1. 开发工具系数在进行软件工作量的估计时，由于选用的开发工具不同，开发的效率会有差异，影响工作量的估计。估