软件项目工作量评估方法

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

工作量评估

1概述

我们认真地阅读了软件的相关需求文档和设计文档后,对软件的功能进行了归纳和整理,并根据以往的经验对每个功能模块所需的编码工作量进行估算,再进一步地以此为依据,推算出整个软件生命期的工作量。工作量推算后组织主要项目干系人和相关专家进行工作量评审。

2常见的估算方法

2.1Ad-hoc方法

这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者,一直到用完了预算的经费。这种情况普遍存在于非常不成熟的组织,并且时常有100%的错误差数。

2.2开发时间的百分比法Percentage of development time。

这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先,开发工作量使用例如LOC或FP方法被估算出来,然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。

通常预留项目的总花费时间的35%给测试, 5-7%给组件和集成测试,18-20%给系统测试, 10%给接收测试(或回归测试等)

2.4类比法(经验值法或历史数据法)

根据以前或相似项目(主要在项目性质,领域,规模上有相似)所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度,因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据:在设计和实现阶段花费的时间,测试工作的规模,例如用户需求的数量,页面数,

功能点,数据样式,例如实体,字段的数量, 屏幕或字段数量,测试对象的规模,例如KLOC

2.5 WBS(work breakdown structure)估算法

将项目或产品分解为具体的工作,然后分别对各个工作进行时间估算,最终求和得出项目或产品的测试工作量/时间。

2.6 Delphi法

Delphi法是最流行的专家评估技术,在没有历史数据的情况下,这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术,要求有多种相关经验人的参与,互相说服对方。

Delphi法的步骤是:1、协调人向各专家提供项目规格和估计表格;2、协调人召集小组会各专家讨论与规模相关的因素;3、各专家匿名填写迭代表格;4、协调人整理出一个估计总结,以迭代表的形式返回专家;5、协调人召集小组会,讨论较大的估计差异;6、专家复查估计总结并在迭代表上提交另一个匿名估计;7、重复4-6,直到达到一个最低和最高估计的一致。

2.7 PERT估计法

PERT对各个项目活动的完成时间按三种不同情况估计:一个产品的期望规模,一个最低可能估计,一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E,和标准偏差SD

3.估算前准备

针对以上方法,我司综合了以上多种评估方法,总结出了适合我司的评估方法:

1)对工作进行WBS分解,尽量将任务分配到半天为工作单位的粒度,分解时需要考虑deadline、技术难点、需求变更风险等等因素。

2)尽量寻找和本项目相近项目做参考,参考历史相近项目的实际工作量和项目进度情况。

3)尽量邀请有历史经验或者对项目熟悉的专家,参与项目工作量的评估,以提高工作量评估的有效性。

4)整理工作任务的关系和客户需求的优先级,寻找项目任务的关键路径,以保证项目周期的合理性和周期最短。

5)确定项目评估工作的基线,以一名2年工作经验的开发人员为评估对象,选择了一个有10个字段的比较有代表性的业务表单,从开始到结束,精确统计了每个步骤需要的消耗的工时数。采用四舍五入法最终制作了如下的工时估算表:

6)确定技能系数,由于标准工时是按2年经验的工程师能力为基准,所以需要那工程师能力设置能力系数,工作3到6年的工程师,每增加1年工作经验则工时=标准工时*(1-0.1),6年以上一般按6年算。

3.1 WBS分解原则

3.1.1 WBS的定义

WBS(工作分解结构)是Work Breakdown Structure的英文缩写,是项目管理重要的专业术语之一。WBS的基本定义:以可交付成果为导向对项目要素进行的分组,它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中,还是在PMP,IPMP考试中,工作分解结构(WBS)都是最重要的内容之一。WBS总是处于计划过程的中心,也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的,所以WBS也是一个项目的综合工具。

WBS是由3个关键元素构成的名词:工作(work)--可以产生有形结果的工作任务;分解(breakdown)--是一种逐步细分和分类的层级结构;结构(structure)--按照一定的模式组织各部分。根据这些概念,WBS有相应的构成因子与其对应:

(1)结构化编码

编码是最显著和最关键的WBS构成因子,首先编码用于将WBS彻底的结构化。通过编码体系,我们可以很容易识别WBS元素的层级关系、分组类别和特性。并且由于近代计算机技术的发展,编码实际上使WBS信息与组织结构信息、成本数据、进度数据、合同信息、产品数据、报告信息等紧密地联系起来。

(2)工作包

工作包(work package)是WBS的最底层元素,一般的工作包是最小的“可交付成果”,这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。例如:管道安装工作包可能含有管道支架制作和安装、管道连接与安装、严密性检验等几项活动;包含运输/焊接/管道制作人工费用、管道/金属附件材料费等成本;过程中产生的报告/检验结果等等文档;以及被分配的工班组等责任包干信息等等。正是上述这些组织/成本/进度/绩效信息使工作包乃至WBS成为了项目管理的基础。基于上述观点,一个用于项目管理的WBS必须被分解到工作包层次才能够使其成为一个有效的管理工具。

(3)WBS元素

WBS元素实际上就是WBS结构上的一个个“节点”,通俗的理解就是“组织机构图”上的一个个“方框”,这些方框代表了独立的、具有隶属关系/汇总关系的“可交付成果”。经过数十年的总结大多数组织都倾向于WBS结构必须与项目目标有关,必须面向最终产品或可交付成果的,因此WBS元素更适于描述输出产品的名词组成(effictive WBS,Gregory T. Haugan)。其中的道理很明显,不同组织、文化等为完成同一工作所使用的方法、程序和资源不同,但是他们的结果必须相同,必须满足规定的要求。只有抓住最核心的可交付结果才能最有效的控制和管理项目;另一方面,只有识别出可交付结果才能识别内部/外部组织完成此工作所使用的方法、程序和资源。工作包是最底层的WBS元素。

(4)WBS字典

管理的规范化、标准化一直是众多公司追求的目标,WBS字典就是这样一种工具。它用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS元素的规范,即WBS元素必须完成的工作以及对工作的详细描述;工作成果的描述和相应规范标准;元素上下级关系以及元素成果输入输出关系等。同时WBS字典对于清晰的定义项目范围也有着巨大的规范作用,它使得WBS易于理解和被组织以外的参与

相关文档
最新文档