作者：Gakki

前言
2025 年软考高项 | 信息系统项目管理师 | 第9章：项目范围管理 | 信息系统项目管理师（第四版）

考情分析

考情分析

学习建议

学习建议

思维导图

思维导图

9.1管理基础

1. 产品范围和项目范围（掌握⭐⭐⭐）
   （1）产品范围：指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
   （2）项目范围：包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。
   

   产品范围和项目范围

2. 管理新实践（了解⭐）

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

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

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

9.2 规划范围管理过程（掌握⭐⭐⭐）

1. 范围管理过程定义和作用（背诵⭐⭐⭐）

   
   
   范围管理过程定义和作用

2. 裁剪考虑因素：知识和需求管理、确认和控制、开发方法、需求的稳定性、治理。（了解⭐）

3. 敏捷与适应方法（了解⭐）

   
   
   敏捷与适应方法

9.3 规划范围管理（掌握⭐⭐⭐）

1. 规划范围管理 ITO

   
   
   规划范围管理 ITO

2. 规划范围管理：是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。

9.3.1 输入

1. 项目章程

2. 项目管理计划

3. 事业环境因素

4. 组织过程资产

9.3.2 工具与技术

1. 专家判断

2. 数据分析：适用于本过程的数据分析技术是备选方案分析。备选方案分析技术用于评估、收集需求，详述项目和产品范围，创造产品，确认范围和控制范围的各种方法。

3. 会议

9.3.3 输出

1. 范围管理计划

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

   • 范围管理计划用于指导如下过程和相关工作：
     ① 制定项目范围说明书；
     ② 根据详细项目范围说明书创建WBS；
     ③ 确定如何审批和维护范围基准；
     ④ 正式验收已完成的项目可交付成果；

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

2. 需求管理计划

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

   • 需求管理计划的主要内容包括：
     ① 如何规划、跟踪和报告各种需求活动;
     ② 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；
     ③ 需求优先级排序过程；
     ④ 测量指标及使用这些指标的理由；
     ⑤ 反映哪些需求属性将被列入跟踪矩阵等。
     【关键词：需求、配置、策略指标】

9.4 收集需求（掌握⭐⭐⭐）

1. 收集需求 ITO

   
   
   收集需求 ITO

2. 收集需求：是为实现目标而确定，记录并管理干系人的需要和需求的过程。本过程的主要作用是为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。

   • 需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
   • 让干系人积极参与需求的探索和分解工作（分解成项目和产品需求），并仔细确定、记录和管理对产品、务或成果的需求，能直接促进项目成功。
   • 需求将作为后续工作分解结构（WBS）的基础，也将作为成本、进度、质量和采购规划的基础。

9.4.1 输入

1. 立项管理文件
2. 项目章程
3. 项目管理计划
4. 项目文件
5. 协议
6. 事业环境因素
7. 组织过程资产

9.4.2 工具与技术

1. 专家判断

2. 数据收集
   

   数据收集

3. 数据分析：文件分析指审核和评估任何相关的文件信息。

4. 决策
   

   决策

5. 数据表现
   

   数据表现

6. 人际关系与团队技能
   

   人际关系与团队技能

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

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

9.4.3 输出

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

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

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

2. 需求的类别一般包括：

   （1） 业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。

   （2） 干系人需求：干系人的需要。

   （3） 解决方案需求：为满足业务需求和干系人需求，产品、服务或成果必须县备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：① 功能需求：描述产品应其备的功能，例如，产品应该执行的行动、流程、数据和交互；②非功能需求：是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。

   （4） 过渡和就绪需求：如数据转换和培训需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力。

   （5） 项且需求：项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。

   （6） 质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如，测试、认证、确认等。

3. 需求跟踪矩阵

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

  • 正向跟踪：使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。
  • 逆向跟踪：需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。

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

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

• 跟踪需求的内容包括：
  ① 业务需要、机会、目的和目标；
  ② 项目目标；
  ③ 项目范围和WBS可交付成果；
  ④ 产品设计；
  ⑤ 产品开发；
  ⑥ 测试策略和测试场景；
  ⑦ 高层级需求到详细需求等。
  

  需求跟踪矩阵

9.5 定义范围（掌握⭐⭐⭐）

1. 定义范围 ITO

   
   
   定义范围 ITO

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

9.5.1 输入

1. 项目章程

2. 项目管理计划

3. 项目文件

4. 事业环境因素

5. 组织过程资产

9.5.2 工具与技术

1. 专家判断

2. 数据分析：备选方案分析。

3. 决策：多标准决策分析。

4. 人际关系与团队技能：典型示例是引导。

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

9.5.3 输出

1. 项目范围说明书

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

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

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

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

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

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

2. 项目文件（更新）。

9.6 创建 WBS（掌握⭐⭐⭐）

1. 创建 WBS 的 ITO

   
   
   创建 WBS 的 ITO

2. 创建 WBS：

   • WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
   • WBS 最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度，进行估算，开展监督与控制。在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。

9.6.1 输入

1. 项目管理计划

2. 项目文件

3. 事业环境因素

4. 组织过程资产

9.6.2 工具与技术

1. 专家判断

2. 分解

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

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

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

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

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

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

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

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

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

3. WBS 的结构可以采用多种形式：
   （1）以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层。
   （2）以主要可交付成果作为分解的第二层。
   （3）纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。
   

   WBS 的结构
   
   
   WBS 的结构

4. WBS 分解说明
   （1）对 WBS 较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。如果采用敏捷或适应型方法，可以将长篇故事分解成用户故事。WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。
   （2）不同的可交付成果可以分解到不同的层次。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。
   （3）要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出 WBS 中的相应细节。这种技术又称为滚动式规划。

5. 在分解的过程中，应该注意以下 8 个方面：
   ① WBS 必须是面向可交付成果的：项目的目标是提供产品或服务，WBS 中的各项工作是为提供可交付的成果服务的（多次重复循环，软件测试）。
   ② WBS 必须符合项目的范围：WBS必须包括也仅包括为了完成项目的可交付成果的活动。100% 原则（包含原则）认为，在 WBS 中，所有下一级的元素之和必须 100% 代表上一级的元素。
   ③ WBS 的底层应该支持计划和控制：WBS是项目管理计划和项目范围之间的桥梁，WBS 的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
   ④ WBS 中的元素必须有人负责，而且只有一个人负责。
   ⑤ WBS 应控制在 4～6 层：如果项目规模比较大，以至于 WBS 要超过 6 层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做 WBS。每个级别的 WBS 将上一级的一个元素分为 4～7 个新元素，同一级元素的大小应该相似。一个工作单元只能从属于某个上层单元，避免交叉从属。
   ⑥ WBS 应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
   ⑦ WBS 的编制需要所有（主要）项目干系人的参与。
   ⑧ WBS 并非是一成不变的：完成了 WBS 之后的工作中，仍然有可能需要对 WBS 进行修改。
   【口诀：面果、一个人负责、4~6层、盒饭、全员（所有）、分包、吃鸡、可变。面果一个人负责 4~6 层得盒饭，全包分包出去吃鸡，这个计划可变】

9.6.3 输出

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

   • 项目范围说明书：包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
   • WBS：全部工作范围的层级分解。工作分解结构每向下分解一层，代表对项目工作更详细的定义。
     • 工作包：WBS 的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇总提供了层级结构，即账户编码。
     • 控制账户则是一个管理控制点，控制账户包含两个或更多工作包，每个工作包只与一个控制账户关联。
     • 规划包：规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知但详细的进度活动未知，一个控制账户可以包含一个或多个规划包。
   • WBS 字典：WBS 字典是针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS 字典中的内容一般包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。

2. 项目文件（更新）。

9.7 确认范围（掌握⭐⭐⭐）

1. 确认范围 ITO

   
   
   确认范围 ITO

2. 确认范围

   • 确认范围应该贯穿项目的始终。

   • 确认范围的步骤包括：
     ① 确定需要进行范围确认的时间；
     ② 识别范围确认需要哪些投入；
     ③ 确定范围正式被接受的标准和要素；
     ④ 确定范围确认会议的组织步骤；
     ⑤ 组织范围确认会议；
     【口诀：时投标步会】

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

   • 项目干系人进行范围确认时，一般需要检查以下 6 个方面的问题:
     ① 可交付成果是否是确定的、可确认的。
     ② 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。
     ③ 是否有明确的质量标准。
     ④ 审核和承诺是否有清晰的表达。
     ⑤ 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
     ⑥ 项目范围的风险是否太高：管理层是否能够降低风险发生时对项目的影响。

3. 干系人关注点的不同：

   • 管理层主要关注项目范围：是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。

   • 客户主要关注产品范围：关心项目的可交付成果是否足够完成产品或服务。

   • 项目管理人员主要关注项目制约因素：关心项目可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。

   • 项目团队成员主要关心项目范围中自己参与的元素和负责的元素。

确认范围

9.7.1 输入

1. 项目管理计划。

2. 项目文件。

3. 工作绩效数据。

4. 核实的可交付成果：是指已经完成，并被控制质量过程检查为正确的可交付成果。

9.7.2 工具与技术

1. 检查：是指开展测量、車查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。

2. 决策：投票，当由项目团队和其他干系人进行验收时，使用投票来形成结论。

9.7.3 输出

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

2. 变更请求。

3. 工作绩效信息。

4. 项目文件（更新）。

9.8 控制范围（掌握⭐⭐⭐）

1. 控制范围 ITO

   
   
   控制范围 ITO

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

9.8.1 输入

1. 项目管理计划

2. 项目文件

3. 工作绩效数据

4. 组织过程资产

9.8.2 工具与技术

1. 数据分析
   • 偏差分析：用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
   • 趋势分析：旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

9.8.3 输出

1. 工作绩效信息。

2. 变更请求。

3. 项目管理计划（更新）。

4. 项目文件（更新）。

补充知识：

1. 区分范围蔓延和镀金的行为：

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

   • 蔓延：客户提出新需求，超出了范围基准【客户不断提出要求，不断去改，最终交付物不满足要求】团队客户总是希望更便宜、更多功能、更好服务没有得到控制的范围扩大、没有得到控制的变更，没有走变更管理流程。

     • 比如：客户和某个团队成员关系很好，他提出要加一个功能，这个成员直接就帮他加了。客户没正式提出变更请求，没走流程。团队成员私自帮他加了内容，这是范围蔓延。属于镀金的一种形式。

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

   • 渐进明细是正常的，逐步细化。而范围蔓延和镀金都是不正常的，反对镀金、反对范围蔓延。

   • 来自团队内部原因造成的范围蔓延称为“镀金”。

   • 来自团队外部原因造成的范围蔓延称为“蔓延”。

   • 如果已经出现了范围蔓延，一样需要走变更流程。