WBS分解指南设计_V1.0

标准文档

上海恒志软件科技有限公司 WBS分解指南

实用文案

修改记录

版本 0.1 日期 2009-11-1 0.2 2009-12-1 1.0 20010-1-5

李莹 吴伟 根据CMMI文档检查问题修改，修改内容参见CMMI文档检查问题列表（2009-12-1） 正式发布修改版本号 修改人 吴伟 初稿 修改内容 标准文档

实用文案

目录

1

概述 ...................................................................... 1

目的 .................................................................... 1 角色职责 ................................................................ 1 术语 .................................................................... 1

1.1 1.2 1.3 2

WBS分解指南 ............................................................... 2

WBS分解原则 ............................................................. 2 WBS分解方法 ............................................................. 3 分解阶段 ................................................................ 3 WBS分解层次 ............................................................. 4

2.1 2.2 2.3 2.4 3

附录：WBS分解示例 ......................................................... 5

标准文档

实用文案

1 概述

1.1 目的

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

1.2 角色职责

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

1.3 术语

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

标准文档

实用文案

2 WBS分解指南

2.1 WBS分解原则

 一个单位工作任务只能在WBS中出现一次。  一个WBS项的工作内容是其对应下级各项工作之和。

 WBS中的每一项都只有一个人负责，即使这项工作要多人来做，也是如此。  WBS必须与工作任务的实际执行过程一致。

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

参与。

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

 在根据范围说明书对项目的工作内容进行适当控制的同时，WBS必须具有一定的灵

活性，以适应无法避免的变更需要。

 粒度适当，即每个任务最好分解到能在1周内由1个人完成。  大小可比，即任务大小可比，不超过一个数量级，最多不超过10倍。

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

内容：

 制定计划的活动  计划变更的活动

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

 所有的评审的活动（项目计划、需求、设计、测试用例、PPQA、MA、CM、等等）  需求跟踪矩阵建立的活动  需求跟踪矩阵的维护活动

 周例会/阶段总结会（周期性的活动）  里程碑评审  实施PPQA的活动  度量计划的制作  度量数据的收集与分析  集成的活动

标准文档

实用文案

 交付的活动或者分期交付的活动  回归测试的活动  过程裁剪的活动

2.2 WBS分解方法

 类比法：类比法就是以一个类似项目的WBS为基础，制定本项目的工作分解结构。  自上而下法：自上而下法常常被视为构建WBS的常规方法，即从项目最大的单位开

始，逐步将它们分解成下一级的多个子项。这个过程就是要不断增加级数，细化工作任务。这种方法对项目经理来说，可以说是最佳方法，因为他们具备广泛的技术知识和对项目的整体视角。

 自下而上法：是要让项目团队成员从一开始就尽可能的确定项目有关的各项具体任

务，然后将各项具体任务进行整合，并归总到一个整体活动或WBS的上一级内容当中去。

2.3 分解阶段

1) 确认项目的主要要素。通常，项目的主要要素是这个项目的工作细目和项目管理。

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

2) 决定是否能对开发到这种详细层次的每个要素进行充分的成本和期限估算。这里\"

充分的\"意味着能够改变项目运行过程--工作细目的分解如果在很久的将来才能完成的话，那么这种分解也就没了确定性。对于每一个要素，如果是充分、详细的论述，就有四个阶段，否则，是三个阶段--这意味着不同的要素有不同的分解层次。 3) 确认项目的组成要素。子项目的组成要素应该用有形的、可证实结果来描述，目的

是为了绩效易检测。当我们知道了主要构成要素后，这些因素就应该用项目工作怎样开度，在实际中怎样完成形式来定义。有形的、可证实的结果既包括服务，也包

标准文档

实用文案

括产品（比如：情形报告能够用图形来描述；对于一个工业项目，组成要素可能包括几个独立单位及对它们的综合）。 4) 核实分解的正确性

(1) 为完成具体工作分解，划分更低层次的细目是否必要和充分？如果没必要，这

个组成要素就必须重新修正（增加项目、削减项目或修改项目）。

(2) 每个项目都要有明确的、完整的定义吗？如果不是，这种描述需修正或扩充。 (3) 是否每个项目都要有适当的日程表、预算能分配给特殊的组织单位（如：部门、

团队或个人）？谁能担负起满意地完成这个项目的任务？如果没有，修正是必要的，为的是提供一个充分的管理控制。

2.4 WBS分解层次

将软件项目的WBS按以下5级层次进行分解： 1) 项目，即项目名称。

2) 活动，分为项目管理活动和工程活动。

3) 阶段，按照需求设计开发测试版本发布分为不同的阶段。 4) 类型，不同阶段的任务类型。 5) 任务，通常由单个人完成。

注意事项：

1) 开始阶段，分到第四级就够了。保证每个任务不超过20人日。 2) 后期，每周对类型进行细分，保证每个任务不超过5人日。 3) 关键按任务不要遗漏。

标准文档

实用文案

3 附录：WBS分解示例

三级：

上海电信移动运维业务外包管理工程_项目计划 [0]上海电信移动运维业务外包管理工程 [1]项目管理活动 [1.1]工程活动 [1.2]项目计划 [1.1.1]代码开发 [1.2.5]概要设计 [1.2.3]项目监控 [1.1.2]集成测试 [1.2.7]用户接收测试 [1.2.10]版本集成 [1.2.8]需求管理 [1.2.2]试运行 [1.2.12]系统测试 [1.2.9]归档 [1.2.14]初验 [1.2.11]需求开发 [1.2.1]单元测试 [1.2.6]详细设计 [1.2.4]终验 [1.2.13]

四级：

项目计划 [1.1.1]项目估算 [1.1.1.1]项目计划编制 [1.1.1.2]项目计划评审 [1.1.1.3]项目计划维护 [1.1.1.4]

标准文档

实用文案

项目监控 [1.1.2]项目阶段总结(月) [1.1.2.2]项目例会(周) [1.1.2.1]里程碑评审会 [1.1.2.3]项目阶段总结(月) 2 [1.1.2.2.2]项目阶段总结(月) 3 [1.1.2.2.3]项目阶段总结(月) 1 [1.1.2.2.1]项目阶段总结(月) 4 [1.1.2.2.4]项目阶段总结(月) 6 [1.1.2.2.6]项目阶段总结(月) 5 [1.1.2.2.5]项目例会(周) 4 [1.1.2.1.4]项目例会(周) 18 [1.1.2.1.18]项目例会(周) 12 [1.1.2.1.12]项目例会(周) 5 [1.1.2.1.5]项目例会(周) 6 [1.1.2.1.6]项目例会(周) 8 [1.1.2.1.8]项目例会(周) 1 [1.1.2.1.1]项目例会(周) 9 [1.1.2.1.9]项目例会(周) 2 [1.1.2.1.2]项目例会(周) 25 [1.1.2.1.25]项目例会(周) 3 [1.1.2.1.3]项目例会(周) 26 [1.1.2.1.26]项目例会(周) 14 [1.1.2.1.14]项目例会(周) 19 [1.1.2.1.19]项目例会(周) 10 [1.1.2.1.10]项目例会(周) 20 [1.1.2.1.20]项目例会(周) 23 [1.1.2.1.23]项目例会(周) 13 [1.1.2.1.13]项目例会(周) 15 [1.1.2.1.15]项目例会(周) 11 [1.1.2.1.11]项目例会(周) 21 [1.1.2.1.21]项目例会(周) 17 [1.1.2.1.17]项目例会(周) 22 [1.1.2.1.22]项目例会(周) 7 [1.1.2.1.7]项目例会(周) 24 [1.1.2.1.24]项目例会(周) 16 [1.1.2.1.16]系统测试里程碑评审 [1.1.2.3.3]需求里程碑评审 [1.1.2.3.1]概要设计里程碑评审 [1.1.2.3.2]

需求开发 [1.2.1]编写需求规格说明书 [1.2.1.3]需求评审 [1.2.1.4]需求分析 [1.2.1.2]需求调研 [1.2.1.1]

标准文档

实用文案

需求管理 [1.2.2]管理需求变更 [1.2.2.2]需求跟踪矩阵 [1.2.2.1]

概要设计 [1.2.3]作业计划概要设计评审 [1.2.3.4]网元信息模块与作业计划模块接口概要设计 [1.2.3.9]备品备件系统与任务管理模块接口概要设计评审 [1.2.3.8]作业计划概要设计 [1.2.3.3]任务管理概要设计评审 [1.2.3.2]网元信息模块与作业计划模块接口概要设计评审 [1.2.3.10]备品备件系统与任务管理模块接口概要设计 [1.2.3.7]任务管理概要设计 [1.2.3.1]WX系统与任务管理模块接口概要设计 [1.2.3.5]WX系统与任务管理模块接口概要设计评审 [1.2.3.6]运维管理与外包系统接口概要设计 [1.2.3.11]运维管理与外包系统接口概要设计评审 [1.2.3.12]

详细设计 [1.2.4]作业计划详细设计评审 [1.2.4.4]任务管理详细设计评审 [1.2.4.2]作业计划详细设计 [1.2.4.3]任务管理详细设计 [1.2.4.1]

标准文档

实用文案

代码开发 [1.2.5]WX系统代码开发 [1.2.5.3]任务管理模块代码开发 [1.2.5.1]备品备件代码开发 [1.2.5.4]网元信息管理代码开发 [1.2.5.5]作业计划模块代码开发 [1.2.5.2]

单元测试 [1.2.6]单元测试用例 [1.2.6.1]单元测试 [1.2.6.2]单元测试报告 [1.2.6.3]

版本集成 [1.2.8]Beta版本集成 [1.2.8.3]正式版本集成 [1.2.8.4]Alpha版本集成 [1.2.8.2]版本集成计划 [1.2.8.1]

系统测试 [1.2.9]编写系统测试用例 [1.2.9.2]系统测试用例评审 [1.2.9.3]Beta版本系统测试 [1.2.9.5]Alpha版本系统测试 [1.2.9.4]系统测试计划 [1.2.9.1]

用户接收测试 [1.2.10]用户接收测试 [1.2.10.2]用户接收测试问题记录及修改 [1.2.10.3]用户接收测试方案 [1.2.10.1]用户接收测试签字 [1.2.10.4]

初验 [1.2.11]初验会议 [1.2.11.3]初验文档整理及编写 [1.2.11.1]初验申请 [1.2.11.2]

标准文档

实用文案

试运行 [1.2.12]试运行文档编制 [1.2.12.2]试运行问题记录 [1.2.12.1]

终验 [1.2.13]终验会议 [1.2.13.3]终验文档整理及编写 [1.2.13.1]终验申请 [1.2.13.2]

标准文档