软件项目工作量评估方法

工作量评估1概述我们认真地阅读了软件的相关需求文档和设计文档后，对软件的功能进行了归纳和整理，并根据以往的经验对每个功能模块所需的编码工作量进行估算，再进一步地以此为依据，推算出整个软件生命期的工作量。工作量推算后组织主要项目干系人和相关专家进行工作量评审。2常见的估算方法2.1Ad-hoc方法这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。2.2开发时间的百分比法Percentageofdevelopmenttime。这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。通常预留项目的总花费时间的35%给测试,5-7%给组件和集成测试,18-20%给系统测试,10%给接收测试（或回归测试等）2.4类比法（经验值法或历史数据法）根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：在设计和实现阶段花费的时间，测试工作的规模，例如用户需求的数量，页面数，功能点，数据样式，例如实体，字段的数量,屏幕或字段数量,测试对象的规模，例如KLOC2.5WBS（workbreakdownstructure）估算法将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。2.6Delphi法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因素；3、各专家匿名填写迭代表格；4、协调人整理出一个估计总结，以迭代表的形式返回专家；5、协调人召集小组会，讨论较大的估计差异；6、专家复查估计总结并在迭代表上提交另一个匿名估计；7、重复4-6，直到达到一个最低和最高估计的一致。2.7PERT估计法PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert统计估计。Pert估计可得到代码行的期望值E，和标准偏差SD3.估算前准备针对以上方法，我司综合了以上多种评估方法，总结出了适合我司的评估方法：1）对工作进行WBS分解，尽量将任务分配到半天为工作单位的粒度，分解时需要考虑deadline、技术难点、需求变更风险等等因素。2）尽量寻找和本项目相近项目做参考，参考历史相近项目的实际工作量和项目进度情况。3）尽量邀请有历史经验或者对项目熟悉的专家，参与项目工作量的评估，以提高工作量评估的有效性。4）整理工作任务的关系和客户需求的优先级，寻找项目任务的关键路径，以保证项目周期的合理性和周期最短。5）确定项目评估工作的基线，以一名2年工作经验的开发人员为评估对象，选择了一个有10个字段的比较有代表性的业务表单，从开始到结束，精确统计了每个步骤需要的消耗的工时数。采用四舍五入法最终制作了如下的工时估算表：6）确定技能系数，由于标准工时是按2年经验的工程师能力为基准，所以需要那工程师能力设置能力系数，工作3到6年的工程师，每增加1年工作经验则工时=标准工时*(1-0.1),6年以上一般按6年算。终端开发标准工时（单位：小时）说明：本表针对10个字段的界面进行估算查询功能添加功能编辑功能删除功能界面（布局、美化、验证）222代码（业务逻辑、接口调试）4442用户体验（界面适配、加载）222上传（多文件）141下载2第三方登录6地图集成（特殊功能另计）2分享4消息推送2每增加10个字段增加50%工时单元测试按开发工时的30%估算3.1WBS分解原则3.1.1WBS的定义WBS（工作分解结构）是WorkBreakdownStructure的英文缩写，是项目管理重要的专业术语之一。WBS的基本定义：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构(WBS)都是最重要的内容之一。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。WBS是由3个关键元素构成的名词：工作（work)--可以产生有形结果的工作任务；分解(breakdown)--是一种逐步细分和分类的层级结构；结构(structure)--按照一定的模式组织各部分。根据这些概念，WBS有相应的构成因子与其对应：（１）结构化编码编码是最显著和最关键的WBS构成因子，首先编码用于将WBS彻底的结构化。通过编码体系，我们可以很容易识别WBS元素的层级关系、分组类别和特性。并且由于近代计算机技术的发展，编码实际上使WBS信息与组织结构信息、成本数据、进度数据、合同信息、产品数据、报告信息等紧密地联系起来。（２）工作包工作包（workpackage）是WBS的最底层元素，一般的工作包是最小的“可交付成果”，这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。例如：管道安装工作包可能含有管道支架制作和安装、管道连接与安装、严密性检验等几项活动；包含运输/焊接/管道制作人工费用、管道/金属附件材料费等成本；过程中产生的报告/检验结果等等文档；以及被分配的工班组等责任包干信息等等。正是上述这些组织/成本/进度/绩效信息使工作包乃至WBS成为了项目管理的基础。基于上述观点，一个用于项目管理的WBS必须被分解到工作包层次才能够使其成为一个有效的管理工具。（３）WBS元素WBS元素实际上就是WBS结构上的一个个“节点”，通俗的理解就是“组织机构图”上的一个个“方框”，这些方框代表了独立的、具有隶属关系/汇总关系的“可交付成果”。经过数十年的总结大多数组织都倾向于WBS结构必须与项目目标有关，必须面向最终产品或可交付成果的，因此WBS元素更适于描述输出产品的名词组成（effictiveWBS，GregoryT.Haugan）。其中的道理很明显，不同组织、文化等为完成同一工作所使用的方法、程序和资源不同，但是他们的结果必须相同，必须满足规定的要求。只有抓住最核心的可交付结果才能最有效的控制和管理项目；另一方面，只有识别出可交付结果才能识别内部/外部组织完成此工作所使用的方法、程序和资源。工作包是最底层的WBS元素。（４）WBS字典管理的规范化、标准化一直是众多公司追求的目标，WBS字典就是这样一种工具。它用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS元素的规范，即WBS元素必须完成的工作以及对工作的详细描述；工作成果的描述和相应规范标准；元素上下级关系以及元素成果输入输出关系等。同时WBS字典对于清晰的定义项目范围也有着巨大的规范作用，它使得WBS易于理解和被组织以外的参与者（如承包商）接受。在建筑业，工程量清单规范就是典型的工作包级别的WBS字典。3.1.2WBS的主要用途WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。WBS防止遗漏项目的可交付成果。WBS帮助项目经理关注项目目标和澄清职责。WBS建立可视化的项目可交付成果，以便估算工作量和分配工作。WBS帮助改进时间、成本和资源估计的准确度。WBS帮助项目团队的建立和获得项目人员的承诺。WBS为绩效测量和项目控制定义一个基准。WBS辅助沟通清晰的工作责任。WBS为其他项目计划的制定建立框架。WBS帮助分析项目的最初风险。3.1.3WBS的创建方法创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。WBS的创建方法主要有以下两种：类比方法。参考类似项目的WBS创建新项目的WBS。自上而下的方法。从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。创建WBS时需要满足以下几点基本要求：某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。WBS中某项任务的内容是其下所有WBS项的总和。一个WBS项只能由一个人负责，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。WBS必须与实际工作中的执行方式一致。应让项目团队成员积极参与创建WBS，以确保WBS的一致性。每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。WBS的工作包的定义不超过40小时，建议在4-8小时。WBS的层次不超过10层，建议在4-6层。3.1.4WBS的表示方式WBS可以由树形的层次结构图或者行首缩进的表格表示。在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中，具体的模版样式参见WBS模版样式。3.1.5WBS的分解方式WBS的分解可以采用以下三种方式进行：按产品的物理结构分解。按产品或项目的功能分解。按照实施过程分解。3.1.6项目组内创建WBS的过程项目组内创建WBS的过程非常重要，因为在项目分解过程中，项目经理、项目成员和所有参与项目的部门主任都必须考虑该项目的所有方面。项目组内创建WBS的过程是：得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。分解项目工作。如果有现成的模板，应该尽量利用。画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。验证上述分解的正确性。如果发现较低层次的项没有必要，则修改组成成分。建立一个编号系统。随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。3.1.7WBS的检验标准检验WBS是否定义完全、项目的所有任务是否都被完全分解主要依据以下标准：每个任务的状态和完成情况是可以量化的。明确定义了每个任务的开始和结束。每个任务都有一个可交付成果。工期易于估算且在可接受期限内。容易估算成本。各项任务是独立的。3.1.8WBS的使用对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工作包描述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。当WBS与OBS综合使用时，要建立账目编码(CodeofAccount)。账目编码是用于惟一确定项目工作分解结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。3.1.9WBS的实践经验最多使用20个层次，多于20层是过度的。对于一些较小的项目4－6层一般就足够了。WBS中的支路没有必要全都分解