软考高项总结：第9章范围管理

一、管理基础

1、产品范围和项目范围

（1）产品范围：指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。

（2）项目范围：包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。

2、管理新实践

需求一直是项目管理的关注重点，需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现并维持收益。

（1）商业分析师，该角色的职责还应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并且在预算内按时完成，同时能够创造价值。

（2）项目经理与商业分析师之间应该是伙伴式合作关系。

3、范围管理过程定义和作用

4、裁剪考虑：知识和需求管理、确认和控制、开发方法、需求的稳定性

5、敏捷与适应方法

6、项目范围管理过程

二、规划范围管理

1、规划范围管理过程的数据流向图

2、规划范围管理ITO

3、范围管理计划

（1）范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。

（2）范围管理计划用于指导如下过程和相关工作：

①制定项目范围说明书；

②根据详细项目范围说明书创建WBS；

③确定如何审批和维护范围基准；

④正式验收已完成的项目可交付成果；

（3）根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。

4、需求管理计划

（1）需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。

（2）需求管理计划的主要内容包括：

①如何规划、跟踪和报告各种需求活动;

②配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；

③需求优先级排序过程；

④测量指标及使用这些指标的理由；

⑤反映哪些需求属性将被列入跟踪矩阵等【关键词：需求、配置、策略指标】

三、收集需求

1、收集需求过程的数据流向图

2、收集需求ITO

3、决策

4、数据收集

5、数据表现

6、人际关系与团队技能

7、系统交互图

是对产品范围的可视化描绘，可以直观显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。

8、原型法

指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。

9、需求文件

（1）需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。

（2）只有明确的（可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。

（3）需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

10、需求的类别一般包括

11、需求跟踪矩阵

（1）需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

（2）使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。

（3）需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。

（4）跟踪需求的内容包括：

①业务需要、机会、目的和目标；

②项目目标；

③项目范围和WBS可交付成果；

④产品设计；

⑤产品开发；

⑥测试策略和测试场景；

⑦高层级需求到详细需求等。

（5）需求踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。

四、定义范围

1、定义范围过程的数据流向图

2、定义范围ITO

3、定义范围基础知识

应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中，随着对项目信息了解的逐渐深入，应该更加详细、具体地定义和描述项目范围。此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。

4、产品分析

可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的用途、特征及其他方面。用以把高层级的产品或服务描述转变为有意义的可交付成果。产品分析技术主要包括：产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。

5、项目范围说明书

（1）项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括：项目和产品范围；详细描述了项目的可交付成果；代表项目干系人之间就项目范围所达成的共识。为便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。

（2）详细的项目范围说明书内容有：产品范围描述、可交付成果、验收标准、项目的除外责任【口诀：产品可验项】

①产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。

②可交付成果：为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。

③验收标准：可交付成果通过验收前必须满足的一系列条件。

④项目的除外责任：识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。

五、创建WBS

1、创建WBS过程的数据流向图

2、创建WBS的ITO

3、创建WBS基础知识

（1）WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。

（2）WBS最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度，进行估算，开展监督与控制。在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。

4、分解

（1）分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。

（2）创建WBS的常用的方法包括：自上而下的方法、使用组织特定的指南和使用WBS模板。

（3）要把整个项目工作分解为工作包，通常需要开展如下活动：

①识别和分析可交付成果及相关工作；

②确定WBS的结构和编排方法；

③自上而下逐层细化分解；

④为WBS组成部分制定和分配标识编码；

⑤核实可交付成果分解的程度是否恰当。

【口诀：释放分编核（释放粪便河）】

5、WBS的结构可以采用多种形式

（1）以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层。

（2）以主要可交付成果作为分解的第二层。

（3）纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同WBS。

6、WBS分解说明

（1）对WBS较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。如果采用敏捷或适应型方法，可以将长篇故事分解成用户故事。WBS可以采用提纲式、组织结构图或能说明层级结构的其他形式。

（2）不同的可交付成果可以分解到不同的层次。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难。

（3）要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出WBS中的相应细节。这种技术又称为滚动式规划。

7、在分解的过程中，应该注意以下8个方面

（1）WBS必须是面向可交付成果的：项目的目标是提供产品或服务，WBS中的各项工作是为提供可交付的成果服务的（多次重复循环，软件测试）。

（2）WBS必须符合项目的范围：WBS必须包括也仅包括为了完成项目的可交付成果的活动。100%原则（包含原则）认为，在WBS中，所有下一级的元素之和必须100%代表上一级的元素。

（3）WBS的底层应该支持计划和控制：WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。

（4）WBS中的元素必须有人负责，而且只有一个人负责。

（5）WBS应控制在4～6层：如果项目规模比较大，以至于WBS要超过6层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做WBS。每个级别的WBS将上一级的一个元素分为4～7个新元素，同一级元素的大小应该相似。一个工作单元只能从属于某个上层单元，避免交叉从属。

（6）WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。

（7）WBS的编制需要所有（主要）项目干系人的参与。

（8）WBS并非是一成不变的：完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。

8、范围基准：是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分。

六、确认范围

1、确认范围过程的数据流向图

2、确认范围ITO

3、确认范围基础知识

（1）确认范围应该贯穿项目的始终。

（2）确认范围的步骤包括：

①确定需要进行范围确认的时间；

②识别范围确认需要哪些投入；

③确定范围正式被接受的标准和要素；

④确定范围确认会议的组织步骤；

⑤组织范围确认会议；

【口诀：时投标步会】

（3）确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。

（4）项目干系人进行范围确认时，一般需要检查以下6个方面的问题:

①可交付成果是否是确定的、可确认的。

②每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。

③是否有明确的质量标准。

④审核和承诺是否有清晰的表达。

⑤项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。

⑥项目范围的风险是否太高：管理层是否能够降低风险发生时对项目的影响。

4、干系人关注点的不同

5、验收的可交付成果：符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。

七、控制范围

1、控制范围过程的数据流向图

2、控制范围ITO

3、控制范围：确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时，也需要采用控制范围过程来管理这些变更。控制范围过程应该与其他项目管理知识领域的控制过程协调开展。未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。

4、数据分析

5、区分范围蔓延和镀金的行为

（1）镀金 –客户没有提新需求，乙方自己做了额外客户不需要的工作，项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。【项目实施人员往往愿意尝试新的技术或者为信息系统项目加上更牛X的功能】团队成员希望表现自己、讨好客户、擅自承诺、送人情、尽善尽美。

（2）蔓延 – 客户提出新需求，超出了范围基准【客户不断提出要求，不断去改，最终交付物不满足要求】团队客户总是希望更便宜、更多功能、更好服务没有得到控制的范围扩大、没有得到控制的变更，没有走变更管理流程。比如：客户和某个团队成员关系很好，他提出要加一个功能，这个成员直接就帮他加了。客户没正式提出变更请求，没走流程。团队成员私自帮他加了内容，这是范围蔓延。属于镀金的一种形式。

（3）渐进明细是正常的，因为项目范围不可能在开始的时候就非常清晰，需要不断地细化、完善。比如计划买双鞋，没有确定颜色、款式、价位，到商场后看到了好多双鞋，慢慢的对自己要买的鞋的颜色、款式、价位都有了明确的认识。这是渐进明细。渐进明细是正常的，逐步细化。而范围蔓延和镀金都是不正常的，反对镀金、反对范围蔓延。