第3章
范 围 管 理




范围管理是有效地控制软件开发内容在合理范围内的主要方法，是IT项目管理的核心知识域之一。
3．1范围管理概述
3．1.1项目范围管理

项目范围是IT项目开发的具体内容，包括最终软件产品或者服务，以及实现该软件产品或者服务所需要执行的全部工作。在项目范围以外的工作，则不属于项目的开发范畴。
在软件项目环境中，范围有两种含义： ①产品范围，即某项软件产品、服务或成果所具有的特性和功能； ②项目范围，即为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。
范围管理是指对项目应完成内容和开发过程进行界定的过程，明确哪些方面是项目应该完成的，哪些是不应该做的。也可以说是开发项目产品或服务包含的所有内容及所用的开发过程。项目干系人必须在项目要开发的产品规格方面取得一致意见，也要在如何开发这些产品方面达成共识； 包括： 制订范围管理计划、确定项目需求、定义项目范围、创建工作分解结构(WBS)、项目范围验证、项目范围控制等。
(1) 制订范围管理计划： 确定项目范围管理和需求管理的方法和过程以及相应的管理计划，项目经理和相关干系人共同创建范围管理计划和需求管理计划。
(2) 确定项目需求： 收集用户业务需求以及对软件产品未来功能的预期。
(3) 定义项目范围： 通过项目范围管理计划、项目章程、需求规格说明书和组织过程资产创建范围说明书。
(4) 创建工作分解结构： 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。
(5) 项目范围验证： 验收已完成项目可交付成果的过程，用户或项目发起人通过审查正式接受项目的可交付成果; 如果拒绝接受，项目发起人会提出变更请求。
(6) 项目范围控制： 对范围变更进行控制，监督项目和产品的范围状态的过程。
3．1.2软件项目需求
软件需求是指用户对软件系统在功能、行为、性能等方面的期望。IEEESTD610软件工程标准词汇表(1997年)中定义需求为： 
(1) 用户解决问题或达到目标所需的条件或功能。
(2) 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或功能。
(3) 反映上面(1)或(2)所描述的条件或功能的文档说明。
软件需求就是软件为用户解决业务领域问题而提供的系统功能，软件需求分为业务需求、用户需求和功能需求，如图31所示。


图31软件需求各组成部分之间关系


(1) 业务需求反映了组织机构或客户对系统软件高层次的目标要求，属于战略层面的要求，在范围管理计划中予以说明。创建项目的目的是解决现实中存在问题或是发掘新的商业机会。通常，运行项目的人和申请项目的人是不同的。从项目发起人到项目经理关于需要什么内容的想法的转移被称作项目愿景。当得到项目发起人的认可，关于愿景的详细描述就是项目业务需求。项目发起人将想法传递给项目经理来执行。项目经理从一开始就必须能够说明项目的高层目标，必须为预期的项目结果制定一组清晰的描述特征。
(2) 用户需求描述了用户要求软件必须要完成的具体任务，一般在需求分析报告或者需求规格说明书中予以说明。用户需求要做什么事情是由项目发起人和软件的最终用户提出的，如客户信息管理需求包括保存和查找客户信息。
IT项目管理——理论、方法与实践（题库版）


第
3
章范围管理

(3) 功能需求根据组织和用户的业务需求和功能需求，定义软件必须实现的功能，满足了组织和用户的业务需求。功能需求易于确定，但不同的项目干系人可能会指定不一致的需求，每一个功能需求都会演变为一系列详细的需求，如客户信息管理包括客户的编号、单位名称、联系人、联系方式等信息的增加、修改、删除和查询等功能。
(4) 非功能性需求描述软件展现给用户的行为和执行操作效率等，包括软件执行的标准、规范、性能指标要求、外部需求等。其中，软件开发过程需求包括交付需求、实现需求、遵循的标准； 软件性能需求包括软件执行速度、同时在线的人数、可靠性等； 外部需求包括互操作性、保密性、安全性等。
3．1.3软件需求和范围的关系
清晰地定义项目范围是项目成功的基础。软件需求通过开发人员的开发工作演变成软件工程，软件功能决定了项目的主要范围，交付满足用户需求的软件是项目开发的目标之一，因此，软件需求是软件项目范围的基础。软件范围还包括项目的开发过程和软件项目过程中的中间产品; 开发过程包括软件规划、系统分析、系统设计、系统实施等; 软件过程中的产品包括软件需求规格说明书、系统设计报告、系统实施说明书等。
项目具有明确的开始时间和结束时间，存在着一个清晰的项目目标，但由于软件项目的特殊性，项目范围很难定义清晰，模糊的需求引发了项目范围不明确; 同时软件需求变更频繁，也大大增加了软件项目范围管理的工作量和复杂度。
3．1.4PMBOK6及软件分册定义的项目范围管理过程
项目范围具有渐进明晰的特征，PMBOK6及软件分册中定义的项目范围管理过程及活动见表31。


表31PMBOK6及软件分册对软件项目范围管理活动描述



活
动
启动

(Initiating)

规划(Planning)执行

(Executing)监控(Controlling)

规划范围管理收集需求定义范围创建WBS 确认范围控制范围
收尾
(Closing)

输
入 1.  项目管理计划

2. 项目章程

3. 事业环境因素

4. 组织过程资产

5. 为规划范围管理发布计划（软件分册）
1.  范围管理计划

2. 需求管理计划

3. 干系人管理计划

4. 项目章程

5. 干系人登记册1.  范围管理计划

2. 项目章程

3. 需求文件

4. 组织过程资产
1.  范围管理计划

2. 项目范围说明书

3. 需求文件

4. 事业环境因素

5. 组织过程资产
1.  项目管理计划

2. 需求文件

3. 需求跟踪矩阵

4. 核实的可交付成果

5. 工作绩效数据

6. 适应性软件项目的输入规划（软件分册）
1.  项目管理计划

2. 需求文件

3. 变更跟踪矩阵

4. 工作绩效数据

5. 组织过程资产

工
具
和
技
术1. 专家判断
2． 会议
1.  访谈

2. 焦点小组

3. 引导式研讨会

4. 群体创新技术

5. 群体决策技术

6. 问卷调查

7. 观察

8. 原型法

9. 标杆对照

10. 系统交互图

11.  文件分析1.  专家判断

2. 产品分析

3. 备选方案生成

4. 引导式研讨会1.  分解

2. 专家判断

3. 活动导向的WBS（软件分册）

4. WBS的滚动式规划（软件分册）

5. 适应性生命周期项目的滚动式规划（软件分册）
1.  检查

2. 群体决策技术
1.  偏差分析

2. 评审和会议输入规划（软件分册）

输
出1.  范围管理计划

2. 需求管理计划1.  需求文件

2. 需求跟踪矩阵

1.  项目范围说明书

2. 项目文件更新

3. 其他注意事项规划（软件分册）
1.  范围基准

2. 项目文件更新
1.  验收的可交付成果

2. 变更请求

3. 工作绩效信息

4. 项目文件更新
1.  工作绩效信息

2. 变更请求

3. 项目管理计划更新

4. 项目文件更新

5. 组织过程资产更新


3．2范围管理规划
规划范围管理是创建范围管理计划，定义、确认和控制项目范围的过程。通过对项目章程、项目管理技术中已批准的子计划、组织过程资产分析，借鉴组织过去已经完成的相类似项目经验，规划范围管理。项目范围管理计划应说明如何确定项目范围，编制项目范围说明书，确定工作分解结构，核实项目范围，以及控制项目范围。
项目范围管理计划是“制订范围计划”过程的主要成果，包括范围管理计划和需求管理计划。
3．2.1范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、编制、控制和确认项目范围。包括编制详细项目范围说明书，根据详细项目范围说明书创建 WBS，维护和批准 WBS，定义项目可交付成果，处理项目范围变更。
范围定义的最终结果是项目范围说明书，在很多软件项目中，可能不会有独立的范围说明文档，而是把系统分析说明书或者需求规格说明书作为项目范围说明的主要文档，配合其他文档来共同说明项目范围。在制订范围管理计划时，需要考虑清楚如何综合需求说明书等文档以清晰且详细地表述项目的工作任务。
3．2.2需求管理计划
需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理需求。生命周期模型的选择对如何管理需求有很大影响。需求管理计划的许多内容都是以生命周期模型为基础的。需求管理计划的主要内容包括： 规划、跟踪和报告各种需求活动，配置管理活动(如需求变更，追溯、跟踪需求以及需求变更审批)，需求开发优先级排序过程，软件度量指标，编制需求跟踪矩阵等。
软件需求工程包括需求开发和需求管理，如图32所示。


图32软件需求工程


软件需求开发和需求管理的关系及涵盖的活动，如图33所示。


图33软件需求工程主要活动关系


1.  需求开发
需求开发是通过调查与分析，获取用户需求并定义产品需求，是为实现项目目标而确定、记录、管理干系人需求的过程。需求开发首先对用户进行调查，收集用户的需求信息; 其次，项目开发人员对收集的用户需求信息进行系统的分析，理清用户的真实需求和潜在需求; 最后系统地描述项目的需求。
1) 需求调查
需求调查通过与用户的交流、访谈，了解用户的组织机构、现有业务或系统的运行情况、存在的问题以及用户对未来系统的期望。调查的主要内容包括用户业务流程、人员分工与偏好、各类信息载体、业务处理流程、系统边界和系统的资源与约束条件。调查方法如下。
(1) 面谈。
在明确信息收集的目的之后，面谈是一种比较有效的方式，一般采用问与答的方式进行。在面谈之前需要进行深思熟虑，制定面谈提纲，准备提出哪些问题，以及如何取得面谈成功的方法。面谈需要获得面谈对象所处理的具体业务内容，还应了解其对当前系统状态、组织和个人目标的观点。
(2) 开调查会。
调查会由组织的管理人员、业务人员、管理专家、计算机专家和系统开发人员共同参加，系统地听取业务人员和管理人员介绍业务的内容、范围、现行系统存在的问题以及对新系统的要求和想法; 管理专家对于系统存在的问题和现行管理模式提出建设性意见; 计算机专家从技术的层面进行合理的规划; 系统开发人员可以介绍目标系统的国内发展现状，也可做一些启发性、介绍性发言，通过多轮讨论使开发人员对业务有所了解，使管理人员了解系统的预期效果。
(3) 参加业务实践。
系统分析员像业务人员一样参加业务实践，可以较深层地掌握现行系统的业务运作流程，信息的产生、传递、加工、存储和输出的具体过程和方法，充分了解现有系统的功能、效率以及存在的问题，参加业务实践需要完成一个业务周期的工作流程，才能全面地了解系统的真实概貌。这是较好的系统调查的方法，但缺点是需要系统分析人员耗费较长的时间，完成一个周期的业务实践，这种方式适合组织自主开发方式的系统开发模式。
(4) 问卷调查表。
问卷调查表往往是一种固定格式的调查方式，可以让很多业务人员回答相同的问题，系统分析员通过对问卷进行统计分析，得到问题的规律性答案或不同业务人员对待同一问题的差异性答案，引导系统分析员发现系统存在的隐含问题。
2) 需求分析
系统需求分析是系统分析员按照系统的思想结合自身的软件开发经验，根据收集的资料，对系统目标进行分析，对组织的信息需求、功能需求以及业务中存在的问题等进行系统的分析，抽取现行系统本质的、整体的需求，为编写需求文件奠定坚实的基础。
常用的需求分析方法有结构化分析法、原型法和面向对象分析法。
3) 需求定义
需求定义是根据需求调查和需求分析的结果，进一步定义准确无误的软件产品需求，编写需求文件。需求文件是描述各种单项需求将如何满足与项目相关的业务需求，只有明确的(可测量和可测试)、可跟踪的、完整的、一致的、通过主要干系人认可的需求，才能作为基准。
需求文件的主要内容包括以下内容。
(1) 业务需求: 包括业务目标和项目目标、组织的业务规则、组织的指导原则。
(2) 干系人需求： 包括项目对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求。
(3) 解决方案需求： 包括功能和非功能需求、技术和标准合规性需求。
2. 需求管理
需求管理是在开发人员和用户之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求变更的过程。需求管理过程包括： 需求确认、需求跟踪与需求变更控制等三个过程。
(1) 需求确认
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。
(2) 需求跟踪
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护需求跟踪矩阵，确保软件依据需求文档进行开发。
需求跟踪矩阵中记录每项需求关键信息的相关属性，包括标识、需求描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(如活跃中、已取消、已推迟、新增加、已批准、被分配和已完成)和状态日期，见表32。为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。


表32需求跟踪矩阵示例



项目名称项目编号项目经理

项目描述

编号关联编号需求描述业务需求、机会WBS可交付成果需求分析系统设计系统实施测试用例

001
1.0

1.1

1.2

1.2．1
续表


项目名称项目编号项目经理

项目描述

编号关联编号需求描述业务需求、机会WBS可交付成果需求分析系统设计系统实施测试用例

002
2．0

2．1

2．1.1


003
3.0

3.1.5

3.2．7


3) 需求变更控制
需求变更控制是指依据“变更申请—CCB审批—变更实施—重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。需求跟踪控制的主要内容包括： 项目目标、业务需求和机会、项目范围、可交付成果、软件分析与设计过程、软件实施、顶层需求到详细需求的演化过程。
3．3范 围 定 义
范围定义界定具体的项目范围，明确所获取的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目最终成果或服务的边界。由于在获取需求过程中识别出的所有需求不一定都包含在项目中，所以范围定义过程就要从需求文件中确定最终的项目需求，然后对软件项目及其成果或服务进行详细描述。在项目规划过程中，随着对项目了解的逐渐深入，可以更加详细地定义和描述项目范围。
3．3.1WBS的作用
项目范围说明书旨在确定项目的边界，工作分解结构旨在明确边界内有什么具体内容。
(1) 详细说明为完成项目目标必须完成各项工作，防止项目开发工作被遗漏，也防止项目无谓的镀金。
(2) 有助于项目经理及时了解项目的分工和进展情况，有益于项目团队成员沟通，开发人员能清晰地掌握自己负责开发的工作包以及与其他任务的关系。
(3) 为项目估算提供依据，如成本估算、进度安排和质量计划。
(4) 展现项目全貌，可清晰表示项目开发任务之间的层级关系。
(5) 帮助分析项目风险，防止不必要的变更。
3．3.2范围定义的主要依据
项目范围定义是以范围规划的成果为依据，把项目的主要可交付产品和服务划分为更小的、更容易管理的单元，即WBS。因此，范围定义的输入主要有以下几个方面。
(1) 范围管理计划： 项目管理计划的组成部分，是项目范围规划过程中的主要输出成果，明确了制定、监督和控制项目范围的各种活动，是范围定义过程的主要依据之一。
(2) 制约因素： 对软件开发过程中限制的因素或条件，如项目范围、进度、成本等。
(3) 前提条件： 为了制订项目计划而必须假设能够在将来获得或解决的一些条件，这些前提条件一般都是真实的、现实的、肯定的，也是可以解决的，但也有可能出现不能解决的风险。
(4) 其他计划结果： 其他领域内的结果也可以作为确定范围定义时的一个参考因素。
(5) 历史资料： 组织完成的其他软件项目或者相关项目及相关领域内项目的历史资料。
3．3.3范围定义的主要工具
在进行范围定义时，经常使用的工具和技术有以下几种。
(1) 产品分析，通过系统分析方法把高层级的软件范围描述转变为切实的可交付的成果。系统分析的方法包括结构化分析、原型法、面向对象分析等。
(2) 设计多个可选方案，根据系统的约束条件和项目干系人的需求，设计出多个项目范围可选方案。
(3) 专家判断法，根据领域专家经验和判断，定义详细的项目范围说明书。
3．3.4范围定义的主要成果
1.  项目范围说明书

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。
(1) 项目范围说明书记录了整个范围，包括项目范围和产品范围。
(2) 项目范围说明书详细描述项目可交付成果，以及为开发可交付成果而必须开展的工作。
(3) 项目范围说明书是项目干系人之间就项目范围所达成的共识。
(4) 为了更加明确地说明项目的范围，项目范围说明书可明确指出哪些工作不属于本项目范围。
(5) 项目范围说明书为项目团队能进行更详细的规划提供了依据，在执行过程中指导项目团队的工作，并为评价变更需求或增加额外工作是否超过项目边界提供基准。
项目范围说明书描述详细程度，决定着项目管理团队控制整个项目范围的有效程度，见表33。


表33项目范围说明书内容及示例



项目说明举例

项目目标项目成功的标准，包括范围、费用、进度、质量等标准项目范围： 满足公司客户信息管理需要； 项目工期： 9个月； 项目成本： 180万元； 质量目标： 3年先进，5年不落后

产品范围说明业务需求、功能需求、非功能需求及其他需求管理销售商信息，销售商信息录入、保存、查询

项目要求组织遵循的技术保准，项目交付物必须满足的条件软件安全遵循ISO/IEC 27000标准，软件通过测试、试运行和用户认可
续表


项目说明举例

项目边界对于容易模糊的内容，明确哪些属于项目范围，哪些不属于项目范围将甲方原系统数据迁移到新系统，属于项目范围； 对所有异地系统用户的系统应用培训，不属于项目范围

项目可交付成果项目中交付的各种产品经过测试和试运行的软件产品，软件使用说明书

软件验收规则定义验收项目交付物的原则系统功能满足《需求规格说明书》的定义

项目制约因素同项目范围相关的制约因素项目范围不准确，项目团队对业务领域了解不完整

项目假设一些同项目范围相关的假设因素，由于这些假设尚未实现，故这些假设都构成项目风险项目团队核心成员在项目开发期间不离职； 甲方软件运行环境在项目移交时能够准备好

项目组织项目组织情况项目经理： 张东风，项目技术开发人员： 李文军，刘丽娟，……QA： 马海波……

风险管理识别、分析、控制、规避风险风险： 人员离职风险； 控制： 监控核心人员； 策略： 做好人员或技术储备

进度里程碑项目阶段划分、里程碑等项目阶段： 软件分析、软件设计； 里程碑： 功能结构设计，代码设计等

资金限制项目在经费方面的限制差旅费成本不超过180万元； 人力成本不超过110万元

费用估算根据对项目估计的结果，预计项目的费用情况项目总成本12万元，技术人员成本90万元，项目管理成本8万元

配置管理要求在项目中使用的配置管理系统使用组织定义的配置管理系统，版本控制工具使用CVS

详细的项目范围说明书包括以下内容。
(1) 产品范围描述: 逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
(2) 验收标准: 可交付成果通过验收前必须满足的一系列条件。
(3) 可交付成果: 在项目开发阶段或项目结束时，产生的产品(中间产品)、成果或服务。可交付成果也包括各种辅助成果，如软件需求规格说明书、系统设计报告等。
(4) 项目边界: 明确说明哪些开发内容不属于项目范围，有助于管理干系人的期望。
(5) 制约因素: 对项目计划或过程执行的限制性因素。描述与项目范围有关且影响项目执行的各种内外部制约或限制条件，例如，成本、阶段工作起止时间或进度里程碑、合同条款等。
(6) 假设条件: 描述项目某些开发因素不成立时可能造成的潜在影响。在项目规划过程中，项目团队应该经常识别、记录并确认假设条件。
2. 项目文件更新
可能需要更新的项目文件如下。
(1) 更新干系人登记册: 范围确定后，保证干系人期望与项目目的的一致性，要再次识别那些将相互作用并影响项目总体结果的内外部干系人，并更新干系人名册。
(2) 更新需求文件： 调整业务需求、干系人需求和解决方案需求。
(3) 更新需求跟踪矩阵： 根据确定的详细项目范围说明书，补充和修改需求跟踪矩阵。
3．3.5项目章程和项目范围说明书关系
项目章程和项目范围说明书的内容存在一定程度的重复，但它们的详细程度不同。项目章程包括高层级的项目开发信息，而项目范围书说明则是对项目范围的详细描述。项目范围在项目开发过程中渐进明晰。
3．4建立工作分解结构
3．4.1工作分解结构

由于软件项目规模较大，尤其是大型软件项目其结构、开发内容较为复杂，为了能够有效地分解项目、估算项目规模、合理分工，需要对软件项目按一定的原则分解，项目分解成任务，任务再分解成工作包。WBS是归纳、分解和定义项目范围的常用工具，其中，工作是指作为活动结果的工作产品或可交付成果，而不是活动本身。WBS把项目逐步分解成更小的部分，直至一系列的工作包，这样能更好地理解它。工作包是评估所需人力和资源的最小单元。这些工作包的集合就是WBS。
WBS也是验证项目范围的一个工具。可以检查发现项目范围的隐性任务。项目经理和技术及业务团队创建WBS，除了进行全面考虑以外，还要寻找隐性的缺陷，以求尽早地处理它们。
1.  WBS基础
工作分解结构是对完成客户需求所需的所有工作的分层描述，在WBS设计中，要考虑的关键点有以下几个。
(1) 事件： 时间点，如任务的开始或结束。
(2) 任务： 跟踪一系列活动的重要工作单元。完成处理具体功能的一个模块，就是一项任务。任务是层层分解的结果，分解就是把一个广义的活动分解成各自独立活动的过程。项目定义被“拆分”成更小的单元，直到这些更小的单元能被合理地评估它们各自所需的资金、时间、人员以及其他资源。如果任务分解得太小了，就是微观管理; 如果分解的太大了，有可能导致管理不到位。在计划的进度设计阶段，应该进行资源分配。
(3) 任务序列化： 工作包可以在制订项目进度计划时，进一步分解为活动。设计一个可实现的进度，确定活动的逻辑顺序。序列化就是在合理的序列中安排这些活动。设计活动序列的逻辑性，并说明它们能否并行。这个工作有时会漏掉WBS中的一些活动。
2. 工作包
工作包是WBS最低层次的一项足够小的任务，是项目可交付成果，具有以下特点。
(1) 工作包可以分配给另一位项目经理进行计划和执行。
(2) WBS的工作包，小到可以评估完成它所需的人力和其他资源。通常，工作包的定义应考虑80小时法则或两周法则，即任何工作包的完成时间应当不超过80小时。在80小时或少于80小时结束时，报告该工作包是否完成。
(3) 工作包由唯一的一个团队、项目小组或承包商负责。用于在组织之外分包时，称为委托包。
(4) WBS应该小于250个工作包，从这一点看，项目太大就不能进行有效管理，应该将它分解成子项目，每个子项目有自己的项目经理。
(5) WBS的工作包或任务必须文档化，以确保准确理解已包括和未包括的工作范围。
工作包必须包含可以交付给项目经理的成果，它比任务实现的百分率更容易管理。工作包的一个重要部分是描述发布产品的形态，以及它的功能如何。
3．4.2建立工作分解结构的过程
在项目工作结构分解过程中，项目经理、项目成员及其他职能经理都须考虑项目的方方面面。制定WBS的过程如下。
(1) 获取范围管理计划、项目范围说明书、需求文件。
(2) 召集有关人员，集体讨论项目主要工作，确定项目工作分解的方式以及使用的模板。
(3) 识别任务。
应该考虑创建WBS和开始活动中的各项工作之间的时间。一旦WBS识别了一项任务，相关信息必须在团队中讨论。避免重复分析每一个任务，记录团队讨论时又一次提起的任务的要点。
项目经理应该考虑工作包文档格式，工作包应该包括以下内容。
① 任务描述： 描述这项任务包含什么内容，以及完成这项任务需要什么资源。
② 进度说明： 完成每个任务所需要的时间，以及计划的开始和结束时间。
③ 任务依赖关系： 明确说明任务间的前置和后续关系。
④ 任务的可交付成果： 描述这项任务可交付成果，并进行附加说明。
⑤ 约束和假设： 这项任务的所有约束和假设都是唯一的，不要包含该项目中大的部分相同的假设。
⑥ 任务风险： 这项任务的所有风险都是唯一的，不要包含该项目中大的部分相同的风险。
⑦ 所需的资源： 评估完成这项任务所需的人员、技术和成本等。如果对于团队来说该模块所需的技术是新的，还需要进行培训。
(4) 画出WBS的层次结构图或列出WBS清单。
(5) 将主要项目可交付成果细分为更小的、易于管理的分组或工作包。工作包必须详细到可以对该工作包进行进度计划、估算成本、分配开发人员。
(6) WBS验证： 在WBS第一次设计时，需要特别关注实现项目的关键路径，而不是完成项目所需的其他所有项目。WBS完成后，项目团队应该从总体上进行审核，验证项目分解的正确性和完整性。这样做的目的是识别缺陷、不可靠的假设以及所有其他在WBS中漏掉的内容。
(7) 建立WBS标识： 为识别的每个任务或活动编制标识符号。
随着其他计划活动的进行，需要不断地对WBS更新或修正，通过这种定期检查的方法，可以控制项目的变化，直到覆盖所有工作。
3．4.3建立工作分解结构的方法
1.  类比法

类比法就是以组织已完成的类似项目的WBS为基础，编制新项目的工作分解结构。
2. 自上而下
自上而下法是构建WBS的常用方法，从项目的顶层开始，逐步将它们分解成下一级的多个子项，逐级分解项目活动，细化工作任务，直到识别定义的最底层任务。这种方法需要具备广泛的技术知识和对项目的整体视角。该方法可以将项目工作定义在适当的细节水平，适用于组织较为熟悉的项目，对于项目工期、成本和资源需求的估计可以比较准确。
3. 自下而上
自下而上法是要让项目团队成员从开始调研分析时，关注确定项目有关的各项具体任务细节或者工作包，然后将各项具体任务细节进行分类整合，按照活动的相近程度，并归总成一个整体活动，逐级汇总到WBS的上一层级，直至完成项目的全部内容。
自下而上不需要考虑WBS制定的指导方针或参考其他类似项目的WBS，应尽可能列出项目经理或项目组成员认为完成项目需要做的各项任务或工作包。在列出详细的任务清单后，对所有任务按照功能相关度进行分组，将这些详细任务归并到上一级更加综合的活动中。如软件需求分析人员需要确定用户对项目的要求以及该项目的开发具体内容，开发人员确定对软件开发需求和对软件功能的需求。项目团队将这多项任务都归入到软件项目的总体功能构架中去。自下而上法创建的WBS效果好，缺点是耗时长。该方法适用于组织从未开发过的新软件项目。
4. 使用模板
如果存在WBS的指导方针，那就必须遵循这些方针。有些项目要求按照甲方提供的WBS模板提交项目建议书。建议书包括针对WBS中每一项任务或工作包的成本估算、进度安排、人员安排等，既有明细估算项，也有汇总估算项。项目整体的成本估算必须是通过汇总WBS底层各项任务成本而得到的。
WBS分解类型按照可交付成果分解和按照项目活动(生命周期阶段)分解为两种类型; 表现形式为清单式(见表34和表35)和图表式(见图34和图35)。


表34按生命周期划分进销存系统WBS（清单式）



1. 项目投招标

1.1项目开发请求

1.1.1管理和信息需求

1.1.2原系统存在的问题

1.2项目立项

1.2．1可行性分析

1.2．2招投标与签订合同


1.3项目规划

1.3.1战略目标集转化分析

1.3.2关键成功因素分析

1.3.3企业系统计划分析
续表


2． 系统分析与设计

2．1系统分析

2．1.1系统详细调查与需求分析

2．1.2组织机构与功能分析

2．1.3业务流程分析

2．1.4数据流程分析

2．1.5数据字典

2．1.6处理过程分析

2．1.7数据综合查询分析

2．1.8系统开发方案确定

2．1.9编写系统分析报告


2．2系统设计

2．2．1系统总体功能结构设计

2．2．2模块结构设计

2．2．3系统流程设计

2．2．4代码设计

2．2．5数据库设计

2．2．6输出设计

2．2．7界面与输入设计

2．2．8系统物理配置方案设计

2．2．9编写设计说明书


3. 系统实施

3.1开发与测试

3.1.1软件编程

3.1.2系统测试


3.2试运行与移交

3.2．1初始运行数据准备

3.2．2系统试运行

3.2．3系统验收移交




表35按可交付成果划分进销存系统WBS（清单式）



0.项目前期

0.1合同签订

0.2系统调研分析

1. 系统维护

1.1系统基础维护

1.2系统权限管理

1.3基础数据管理

2． 库存管理

2．1入库管理

2．2出库管理

2．3盘点管理

3. 客户关系管理

3.1销售管理

3.2客服管理续表


4. 财务管理

4.1采购付款

4.2应收账款

5.统计分析

5.1库存统计分析

5.2销售统计分析

5.3财务统计分析

6.客户关系管理

6.1软硬件选型及采购

6.2硬件环境安装调试

6.3软件环境安装调试

7.软件测试

7.1模块测试

7.2系统测试

7.3集成测试

8.系统移交验收

8.1初始运行数据准备

8.2系统试运行

8.3系统验收移交

以项目生命周期的各个阶段作为分解的第二层，把产品和项目可交付成果放在第三层，如表34和图34所示; 以项目可交付成果作为分解的第二层，如表35和图35所示。
3．4.4WBS字典
WBS字典是工作分解结构的辅助说明性工具，用来对WBS中的控制单元或工作包做进一步详细说明。说明选项或详细程度可以根据项目具体需要确定。控制单元是WBS中的要素，是项目团队对项目的管理控制点，即针对控制单元的要素对项目执行情况进行控制与考核。可以把工作包作为控制单元，也可以把多个工作包或更高层的要素作为控制单元。
1.  WBS字典内容
WBS字典主要由项目工作的技术性陈述组成。WBS字典可以用来将定义好的工作任务与负责这部分工作的组织联系起来，形成所谓的“责任分配矩阵”(Responsibility Assignment Matrix，RAM)。WBS字典还可以作为编制合同工作说明书(Statement Of Work，SOW)的基础，帮助用户与项目经理进行沟通。
2. WBS字典属性
WBS字典主要属性包括： 负责人、项目名称、版本号、工作包编号、工作包描述(内容)、质量要求、成本预算、时间要求、部门或外部单位(委托项目)、资源配置情况和其他属性等。
3. 实例
WBS字典实例见表36。







图34按生命周期划分进销存系统WBS(图表式)












图35按可交付成果划分进销存系统WBS(图表式)


表36WBS字典实例



项目名称 项目编号

版本号 工作包编号

工作包 上层任务

负责人赵建伟团队成员李宝力、赵强、张悦

工作内容

质量要求

时间要求

成本要求0.6万元

项目经理（签字） 负责人（签字）

3．5范 围 确 认
范围确认(Scope Verification)是由项目团队在将项目最终交付成果交给用户之前，用户对已经完成的开发任务进行验收，审查项目计划规定范围内的各项工作或活动是否已经完成，应交付成果是否达到要求。
如果项目提前终止，则应审查有哪些工作已经完成，也要验证项目完成所达到的程度，并将核查结果记录在案，形成确认文件。
范围确认过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
3．5．1范围确认的依据
在项目实施过程中，收集有关项目阶段已经完成的工作信息，并将这些信息编入项目进度报告中，进度报告明确哪些可交付成果已经完成，哪些未完成，达到质量标准的程度等。范围确认的依据如下。
1.  项目管理计划
项目管理计划包含范围管理计划和范围基准。范围管理计划定义了项目已完成可交付成果的正式验收程序。范围基准包含批准的范围说明书、WBS 和 WBS 字典，明确可验收成果。如果范围发生变更，以变更后的范围基准作为验收依据。
2. 需求文件
需求文件给出了项目业务需求、产品需求、其他需求以及验收标准。
3. 需求跟踪矩阵
需求跟踪矩阵描述了项目功能需求、变更记录以及需求的实现状态，可以作为范围确认的依据。×××项目需求跟踪矩阵案例，见表37。
4. 核实可交付成果
核实的可交付成果是指已经完成，并被控制质量过程检查为正确、符合质量标准的可交付成果。


表37×××项目需求跟踪矩阵



用户需求
项标号用户需
求标题用户需求
变更标识软件需求
功能编号软件需求
功能标题软件需求
变更标识需求
状态变更
序号优先级优先级
说明当前
状态概要
设计

1管理员

1.1.1添加用户原始1.1添加用户，包括批量添加和单个添加，并且设置用户使用期限原始已批准高是老师和学生用户功能执行必须实现的

1.1.3删除用户原始1.2删除用户，删除选中的一个或多个用户原始已批准高关键功能,必须实现

1.1.4修改用户使用期限原始1.4修改用户使用期限原始已批准中可用默认值，但最终必须实现

（以下略）

1.2修改自己密码原始1.7修改自己密码原始已批准高关键功能，必须实现

1.3登录系统原始1.8登录
系统原始已批准高关键功能，必须实现

1.4退出系统原始1.9退出
系统原始已批准高关键功能，必须实现

2匿名用户

2． 1查看课程
建设资源原始2． 1查看课程建设资源原始已批准高关键功能，必须实现

2． 2查看课内
学习资源原始2． 1查看课内学习资源原始已批准高关键功能，必须实现

（以下略）

3教师用户

3. 1修改首页内容原始3. 1修改首
页内容原始已批准高关键功能，必须实现

（以下略）


5． 工作绩效数据
工作绩效数据包括项目功能、项目符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。
3．5．2范围确认的方法
范围确认的方法是对所完成可交付成果的数量和质量进行检查。检查的方法主要包括： 
(1) 检查是指对项目需求实现开展审查和确认等活动，来判断工作过程和项目可交付成果是否符合范围说明书中约定的需求和产品验收标准。IT项目检查包括过程检查和产品检查。
(2) 试运行是指采用测试用例或到用户单位进行试运行的方式，对完成的可交付成果进行试运行，给出试运行报告。
(3) 专家评定是用户按合同约定的项目范围、标准、程序和方法，组织用户和相关领域的专家对可交付成果进行评定。
(4) 第三方评定，按合同约定委托双方一致认可的、具有相应资质的、独立的第三方，运用专业方法，对可交付成果进行评定。
范围确认通常包括三个步骤： ①测试，应用测试用例对已完成的工作进行测试和实验; ②评估，就是把测试的结果与双方在合同中约定的预期结果或测试标准进行对比分析，判断是否符合合同要求; ③处理，即决定被检查的工作结果是否可以接受，如果不予接受，采取何种补救措施。
3．5．3范围确认的结果
范围确认的结果就是对可交付成果的正式接受。用户根据合同中可交付成果接受的有关规定，一次或分几次接受完成。确认文件需要客户或发起人以签字或会签的形式进行批准。
对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案; 并对这些可交付成果提出变更请求以进行缺陷补救。
3．6范 围 控 制
范围控制是在项目生命周期内监控项目和产品的范围状态，管理范围基线变更的过程。
范围控制确保所有变更请求、纠正策略或预防措施都通过实施整体变更控制过程进行处理。在变更实施过程中，要采用范围控制过程来管理和跟踪变更。范围控制应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大(未对进度、成本和资源做相应调整)被称为范围蔓延。软件项目变更频繁，因此，必须强制实施某种形式的变更控制。
3．6．1范围控制主要内容
(1) 按照项目范围计划和WBS实施项目范围控制。
(2) 在范围控制过程中，及时跟踪检查，记录检查结果，建立范围控制报告。
(3) 判断工作范围有无变化，分析范围变更的影响，并实施相应策略。
3．6．2项目范围变更管理要求
(1) 项目范围变更要有严格的审批程序和手续。
(2) 范围变更后应调整相关的计划。
(3) 组织应对重大的项目范围变更提出影响报告。
(4) 在项目的结束阶段，应验证项目范围，检查项目范围规定的工作是否完成和交付成果是否完备。
(5) 项目结束后，组织应对项目范围管理的经验教训进行总结。
3．6．3项目范围控制的主要步骤
(1) 在收集到已完成活动的实际范围和项目变更带来影响的有关数据，并据此更新项目范围后，对范围进行分析并与原范围计划进行比较，找出要采取纠正的地方。
(2) 确定需要采取的措施。
(3) 估计所采取的纠正措施的效果，如果所采取的纠正措施仍无法获得满意的范围调整，则重复以上步骤。
3．6．4控制偏差分析
偏差分析是一种确定实际绩效与基准的差异程度及原因的技术。可利用项目绩效测量结果评估偏离范围基准的程度。确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。

案 例 分 析
A集团是正克信息技术有限公司多年的客户，正克已为其开发了多个信息系统。最近，A集团又和正克签订了新的开发合同，以扩充整个企业的信息化应用范围，陈工担任该项目的项目经理。陈工组织相关人员对该项目的工作进行了分解，并参考了公司同A集团曾经的合作项目。经过评估，得到该项目总工作量60人月，计划工期6个月。项目刚刚开始不久，陈工的高级经理J找到陈工。
J表示，由于公司运作的问题，需要在4个月内完成项目，考虑到压缩工期的现实，可为该项目增派4名开发人员。陈工认为，整个工作量是经过仔细分解后评估得到的，评估过程也参考了历史类似项目，该项目工作量是客观真实的。
目前项目已经开始，增派的人手还需要一定时间熟悉项目情况，因此即使增派4人也很难在4个月内完成。如果强行要求项目组成员经过加班等方式追逐4个月完成的目标，肯定会降低项目的质量，造成用户不满意。因此，陈工提出将整个项目分为两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准，这样不增派开发人员也可完成。高层经理认为该方案可以满足公司的运作要求，用户也同意按照这种方案实施。
6个月后，项目在没有增加人员的前提下顺利完成，虽然比最初计划延长了半个月的工期，但既达到了公司的要求，又使客户对最终交付的系统满意，项目组成员也没有感受到很大的压力。
问题1： 请用不超过500字，指出陈工是如何保证项目成功完成的？
问题2： 请用不超过500字，试结合案例指出项目范围管理的工作要点。
习题
一、 单选题
1. 用来衡量产品范围完成情况的文件是()。


A． 项目管理计划B． 项目范围说明书

C． 项目工作分解结构D． 产品需求文件
2． 过程()会直接影响到创建工作分解结构。

A． 定义范围，控制范围B． 定义范围,收集需求

C． 控制范围，确认范围D． 收集需求,确认范围
3. 下列文件()详细描述了项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。

A． 项目管理计划B． 项目章程

C． 工作分解结构D． 项目范围说明书
4. 项目范围说明书不包括()。

A． 产品范围描述B． 项目制约因素和假设条件

C． 项目的除外责D． 项目总体预算
5． 项目范围说明书的意义在于()。

A． 开展更详细规划的基础B． 提供了项目简要的说明

C． 为干系人审批项目D． 为成本核算提供了标准
二、 判断题
1. 工作包是带有特定标识符的任务。()
2． 工作分解结构应该细化到能进行可靠估算的层面。()
3. 工作分解结构不是必需的。()
4. 确认范围应该在项目开始时进行。()
5． 范围蔓延的一种表现形式是镀金。()
三、 简答题
1. 需求管理有哪几个过程？
2． 范围定义的主要依据是什么？
3. 请简要说明建立工作分解结构自上而下法和自下而上法分别适用于什么情况？
4. 控制范围与确认范围的区别是什么？