WBS分解指南-V1.0完整版.doc

  1. 1、本文档共12页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多

WBS分解指南

上海恒志软件科技有限公司

WBS分解指南 过程定义参考文件

PAGEi

NEXTIF文档标题 文档副标题

PAGEi

修改记录

版本

日期

修改人

修改内容

0.1

2009-11-1

吴伟

初稿

0.2

2009-12-1

吴伟

根据CMMI文档检查问题修改,修改内容参见CMMI文档检查问题列表(2009-12-1)

1.0

20010-1-5

李莹

正式发布修改版本号

文档标题 文档副标题

目录

TOC\o1-4\h\z\u1 概述 1

1.1 目的 1

1.2 角色职责 1

1.3 术语 1

2 WBS分解指南 2

2.1 WBS分解原则 2

2.2 WBS分解方法 3

2.3 分解阶段 3

2.4 WBS分解层次 4

3 附录:WBS分解示例 5

文档标题 文档副标题

PAGE1

概述

目的

WBS(工作任务分解结构)的目的是将整个项目分解成可管理的、相互关联的、模块化的构件或活动,即工作任务或工作包。

角色职责

项目经理负责软件项目的WBS活动。根据采用的方法和项目具体情况,由项目经理和项目经理指派的有经验的程序员、软件工程师、软件估计人员等负责实施项目的WBS活动。最终的确认必须由项目经理进行。

术语

WBS:WorkBreakdownStructure.作为有效地计划和控制项目的工具。它是由一组可交付使用的项目产品/设施组成的,表现为一种层次化的树状结构,定义了整个工程项目的工作范围。

WBS分解指南

WBS分解原则

一个单位工作任务只能在WBS中出现一次。

一个WBS项的工作内容是其对应下级各项工作之和。

WBS中的每一项都只有一个人负责,即使这项工作要多人来做,也是如此。

WBS必须与工作任务的实际执行过程一致。

WBS应服务于项目团队,项目成员必须参与WBS的制定过程,以确保一致性和全员参与。

每项WBS都必须归档,以确保准确理解项目包括和不包括的工作范围。

在根据范围说明书对项目的工作内容进行适当控制的同时,WBS必须具有一定的灵活性,以适应无法避免的变更需要。

粒度适当,即每个任务最好分解到能在1周内由1个人完成。

大小可比,即任务大小可比,不超过一个数量级,最多不超过10倍。

在进行WBS分解时,下列活动容易遗漏,需要引起注意,务必使WBS分解包含以下内容:

制定计划的活动

计划变更的活动

技术方案选择与评审的活动

所有的评审的活动(项目计划、需求、设计、测试用例、PPQA、MA、CM、等等)

需求跟踪矩阵建立的活动

需求跟踪矩阵的维护活动

周例会/阶段总结会(周期性的活动)

里程碑评审

实施PPQA的活动

度量计划的制作

度量数据的收集与分析

集成的活动

交付的活动或者分期交付的活动

回归测试的活动

过程裁剪的活动

WBS分解方法

类比法:类比法就是以一个类似项目的WBS为基础,制定本项目的工作分解结构。

自上而下法:自上而下法常常被视为构建WBS的常规方法,即从项目最大的单位开始,逐步将它们分解成下一级的多个子项。这个过程就是要不断增加级数,细化工作任务。这种方法对项目经理来说,可以说是最佳方法,因为他们具备广泛的技术知识和对项目的整体视角。

自下而上法:是要让项目团队成员从一开始就尽可能的确定项目有关的各项具体任务,然后将各项具体任务进行整合,并归总到一个整体活动或WBS的上一级内容当中去。

分解阶段

确认项目的主要要素。通常,项目的主要要素是这个项目的工作细目和项目管理。然而,在一定时期内,这个主要要素总是根据项目的实际管理而定义的。例如:项目生命周期的阶段可以当作第一层次的划分,把第一层次中的项目细目在第二阶段继续进行划分。

决定是否能对开发到这种详细层次的每个要素进行充分的成本和期限估算。这里充分的意味着能够改变项目运行过程--工作细目的分解如果在很久的将来才能完成的话,那么这种分解也就没了确定性。对于每一个要素,如果是充分、详细的论述,就有四个阶段,否则,是三个阶段--这意味着不同的要素有不同的分解层次。

确认项目的组成要素。子项目的组成要素应该用有形的、可证实结果来描述,目的是为了绩效易检测。当我们知道了主要构成要素后,这些因素就应该用项目工作怎样开度,在实际中怎样完成形式来定义。有形的、可证实的结果既包括服务,也包括产品(比如:情形报告能够用图形来描述;对于一个工业项目,组成要素可能包括几个独立单位及对它们的综合)。

核实分解的正确性

为完成具体工作分解,划分更低层次的细目是否必要和充分?如果没必要,这个组成要素就必须重新修正(增加项目、削减项目或修改项目)。

每个项目都要有明确的、完整的定义吗?如果不是,这种描述需修正或扩充。

文档评论(0)

188****8742 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档