学信息系统项目管理师第4版系列21_范围管理

1. 产品范围

1.1. 某项产品、服务或成果所具有的特征和功能

1.2. 产品范围的完成情况是根据产品需求来衡量的

1.3. “需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力

2. 项目范围

2.1. 包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作

2.2. 项目范围的完成情况是根据项目管理计划来衡量的

2.3. 项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目

2.4. 项目范围是为了达到项目目标，交付具有某种特质的产品和服务，项目所规定要做的工作

2.4.1. 【高22下选26】

2.5. 在项目中，客户和项目团队成员往往有在当前版本中加入所有功能和特征的意愿，这对于项目来说是一种潜在的风险，会给组织和客户带来危害和损失

2.5.1. 【高22下选28】

3. 管理新实践

3.1. 需求一直是项目管理的关注重点

3.2. 需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现并维持收益

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

4. 敏捷与适应方法

4.1. 对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确

4.2. 确认范围是正式验收己完成的项目可交付成果的过程

5. 规划范围管理

5.1. 为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程

5.2. 主要作用是在整个项目期间对如何管理范围提供指南和方向

5.3. 输入

5.3.1. 项目章程

5.3.2. 项目管理计划

5.3.2.1. 项目生命周期描述

5.3.2.2. 开发方法

5.3.2.3. 质量管理计划

5.3.3. 组织过程资产

5.3.4. 事业环境因素

5.4. 工具与技术

5.4.1. 专家判断

5.4.2. 数据分析

5.4.2.1. 备选方案分析

5.4.3. 会议

5.5. 输出

5.5.1. 范围管理计划

5.5.1.1. 范围管理计划描述将如何定义、制订、监督、控制和确认项目范围

5.5.1.1.1. 【高22下选25】

5.5.1.2. 变需求属于范围，范围管理计划针对项目范围怎样变化，变化了多少

5.5.1.2.1. 【高21上选29】

5.5.1.3. 内容

5.5.1.3.1. 如何制订项目范围说明书

5.5.1.3.2. 如何根据范围说明书创建 WBS

5.5.1.3.3. 如何维护和批准 WBS

5.5.1.3.4. 如何确认和正式验收已完成的项目可交付成果

5.5.1.3.5. 如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相关联

5.5.1.3.5.1. 【高21下选29】

5.5.1.4. 【高21下案二】

5.5.2. 需求管理计划

5.5.2.1. 项目生命周期中，需求变更十分频繁，为了保证项目的顺利进行和保证产品的质量，需求的变更应该受到严格控制

5.5.2.1.1. 【高22上选27】

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

5.5.2.3. 配置管理活动

5.5.2.4. 需求优先级排序过程

5.5.2.5. 测量指标及使用这些指标的理由

5.5.2.6. 反映哪些需求属性将被列入跟踪矩阵

5.6. 数据流向图

6. 收集需求

6.1. 为实现目标而确定，记录并管理干系人的需要和需求的过程

6.2. 主要作用是为定义产品范围和项目范围奠定基础

6.3. 需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力

6.4. 需求将作为后续工作分解结构（WBS）的基础，也将作为成本、进度、质量和采购规划的基础

6.5. 软件需求分为三类，分别是常规需求、期望需求和意外需求

6.5.1. 【高21上选09】

6.5.2. 常规需求也叫基本需求

6.6. 收集需求过程中识别出的所有需求未必都包含在项目中

6.7. 输入

6.7.1. 立项管理文件

6.7.2. 项目章程

6.7.3. 项目管理计划

6.7.3.1. 范围管理计划

6.7.3.2. 需求管理计划

6.7.3.3. 干系人参与计划

6.7.4. 项目文件

6.7.4.1. 假设日志

6.7.4.2. 干系人登记册

6.7.4.3. 经验教训登记册

6.7.5. 协议

6.7.6. 事业环境因素

6.7.7. 组织过程资产

6.8. 工具与技术

6.8.1. 专家判断

6.8.2. 数据收集

6.8.2.1. 标杆对照

6.8.2.2. 问卷调查

6.8.2.3. 焦点小组

6.8.2.4. 访谈

6.8.2.5. 头脑风暴

6.8.3. 数据分析

6.8.3.1. 文件分析

6.8.3.1.1. 审核和评估任何相关的文件信息

6.8.4. 决策

6.8.4.1. 投票

6.8.4.1.1. 用于生成、归类和排序产品需求

6.8.4.2. 独裁型决策制定

6.8.4.3. 多标准决策分析

6.8.5. 数据表现

6.8.5.1. 思维导图

6.8.5.1.1. 把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意

6.8.5.2. 亲和图

6.8.5.2.1. 用来对大量创意进行分组的技术，以便进一步审查和分析

6.8.6. 人际关系与团队技能

6.8.6.1. 名义小组技术

6.8.6.1.1. 名义小组技术(Nominal Group Technique)通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法

6.8.6.1.1.1. 【高19下选30】

6.8.6.1.2. 向集体提出一个问题或难题，每个人在沉思后写出自己的想法

6.8.6.1.3. 主持人在活动挂图上记录所有人的想法

6.8.6.1.4. 集体讨论各个想法，直到全体成员达成一个明确的共识

6.8.6.1.5. 个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高

6.8.6.1.6. 数轮投票

6.8.6.1.7. 得分最高者被选出

6.8.6.1.8. 【高21下选30】

6.8.6.2. 观察和交谈

6.8.6.2.1. 观察也称为“工作跟随”

6.8.6.3. 引导

6.8.6.3.1. 弓I导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求

6.8.6.3.2. 研讨会可用于快速定义跨职能需求并协调干系人的需求差异

6.8.6.3.3. 与分别召开会议相比，研讨会能够更早发现并解决问题

6.8.7. 系统交互图

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

6.8.8. 原型法

6.8.8.1. 指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈

6.8.9. 群体创新技木

6.8.9.1. 【高20下选30】

6.8.9.2. 头脑风暴法、名义小组技术、德尔菲技术、概念/思维导 图、亲和图和多标准决策分析

6.8.9.3. 3版

6.9. 输出

6.9.1. 需求文件

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

6.9.1.1.1. 【高22上选28】

6.9.1.2. 需求文件描述各种单一的需求将如何满足与项目相关的业务需求

6.9.1.2.1. 【高18下选40】

6.9.1.3. 业务需求

6.9.1.3.1. 【高18下选07】

6.9.1.3.2. 整个组织的高层级需要

6.9.1.4. 干系人需求

6.9.1.5. 解决方案需求

6.9.1.5.1. 功能需求

6.9.1.5.1.1. 描述产品应具备的功能

6.9.1.5.1.2. 产品应该执行的行动、流程、数据和交互

6.9.1.5.2. 非功能需求

6.9.1.5.2.1. 对功能需求的补充

6.9.1.5.2.2. 是产品正常运行所需的环境条件或质量要求

6.9.1.5.2.3. 可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除

6.9.1.6. 过渡和就绪需求

6.9.1.6.1. 描述了从“当前状态”过渡到“将来状态”所需的临时能力

6.9.1.7. 项目需求

6.9.1.7.1. 项目需要满足的行动、过程或其他条件

6.9.1.7.2. 里程碑日期、合同责任、制约因素

6.9.1.8. 质量需求

6.9.1.8.1. 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准

6.9.1.8.2. 测试、认证、确认

6.9.1.8.3. 【高23上选27】

6.9.2. 需求跟踪矩阵

6.9.2.1. 把产品需求从其来源连接到能满足需求的可交付成果的一种表格

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

6.10. 数据流向图

6.11. 【高21下选74】

7. 定义范围

7.1. 制定项目和产品详细描述的过程

7.2. 主要作用是描述产品、服务或成果的边界和验收标准

7.3. 需要从需求文件（收集需求过程的输出）中选取最终的项目需求

7.4. 输入

7.4.1. 组织过程资产

7.4.2. 事业环境因素

7.4.3. 项目文件

7.4.3.1. 假设日志

7.4.3.2. 需求文件

7.4.3.3. 风险登记册

7.4.4. 项目管理计划

7.4.4.1. 范围管理计划

7.4.5. 项目章程

7.5. 工具与技术

7.5.1. 专家判断

7.5.2. 数据分析

7.5.2.1. 备选方案分析

7.5.3. 决策

7.5.3.1. 多标准决策分析

7.5.4. 人际关系与团队技能

7.5.4.1. 引导

7.5.5. 产品分析

7.5.5.1. 产品分解

7.5.5.2. 需求分析

7.5.5.3. 系统分析

7.5.5.4. 系统工程

7.5.5.5. 价值分析

7.5.5.6. 价值工程

7.6. 输出

7.6.1. 项目范围说明书

7.6.1.1. 产品范围描述

7.6.1.2. 可交付成果

7.6.1.3. 验收标准

7.6.1.4. 项目的除外责任

7.6.2. 项目文件（更新）

7.6.2.1. 假设日志

7.6.2.2. 需求文件

7.6.2.3. 需求跟踪矩阵

7.6.2.4. 干系人登记册

7.7. 数据流向图

8. 创建WBS

8.1. 把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程

8.2. 主要作用是为所要交付的内容提供架构

8.3. 仅开展一次或仅在项目的预定义点开展

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

8.5. WBS最低层的组成部分称为工作包，其中包括计划的工作

8.6. 输入

8.6.1. 项目管理计划

8.6.2. 组织过程资产

8.6.3. 事业环境因素

8.6.4. 项目文件

8.6.4.1. 项目范围说明书

8.6.4.2. 需求文件

8.7. 工具与技术

8.7.1. 专家判断

8.7.2. 分解

8.7.2.1. 分解活动

8.7.2.1.1. 识别和分析可交付成果及相关工作

8.7.2.1.2. 确定WBS的结构和编排方法

8.7.2.1.3. 自上而下逐层细化分解

8.7.2.1.4. 为WBS组成部分制定和分配标识编码

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

8.7.2.2. WBS结构

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

8.7.2.2.2. 以主要可交付成果作为分解的第二层

8.7.2.2.3. 滚动式规划

8.7.2.3. 注意事项

8.7.2.3.1. WBS必须是面向可交付成果的

8.7.2.3.2. WBS必须符合项目的范围

8.7.2.3.3. WBS的底层应该支持计划和控制

8.7.2.3.4. WBS中的元素必须有人负责，而且只有一个人负责

8.7.2.3.4.1. 独立责任原则

8.7.2.3.5. WBS应控制在4〜6层

8.7.2.3.5.1. 一个工作单元只能从属于某个上层单元，避免交叉从属

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

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

8.7.2.3.8. WBS并非是一成不变的

8.8. 输出

8.8.1. 范围基准

8.8.1.1. 经过批准的范围说明书、WBS和相应的WBS词典

8.8.1.2. 只有通过正式的变更控制程序才能进行变更，它被用作比较的基础

8.8.1.3. 项目范围说明书

8.8.1.4. WBS

8.8.1.4.1. 【高21下案一】

8.8.1.4.1.1. 【高19下选74】

8.8.1.4.1.2. 【高18下选41】

8.8.1.4.1.3. 【高18上选39】

8.8.1.4.1.4. 【高23上选29】

8.8.1.4.2. 每层中的所有要素之和是下一层的工作之和

8.8.1.4.2.1. 【高22下选27】

8.8.1.4.3. 每个工作要素应该具体指派一个层次，而不应该指派给多个层次

8.8.1.4.4. WBS 需要有投入工作的范围描述，这样才能使所有人对要完成的工作有全面的了解

8.8.1.4.4.1. 【高19上选39】

8.8.1.5. 工作包

8.8.1.5.1. 每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点

8.8.1.5.2. 控制账户包含两个或更多工作包，每个工作包只与一个控制账户关联

8.8.1.6. 规划包

8.8.1.6.1. 一种低于控制账户而高于工作包的工作分解结构组件

8.8.1.6.2. 工作内容己知，但详细的进度活动未知

8.8.1.6.3. 一个控制账户可以包含一个或多个规划包

8.8.1.7. WBS字典

8.8.2. 项目文件（更新）

8.8.2.1. 假设日志

8.8.2.2. 需求文件

8.9. 数据流向图

9. 确认范围

9.1. 正式验收己完成的项目可交付成果的过程

9.2. 主要作用

9.2.1. 使验收过程具有客观性

9.2.2. 通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性

9.3. 需要在整个项目期间定期开展

9.3.1. 应该贯穿项目的始终

9.3.1.1. 【高21上选31】

9.4. 步骤

9.4.1. 确定需要进行范围确认的时间

9.4.2. 识别范围确认需要哪些投入

9.4.3. 确定范围正式被接受的标准和要素

9.4.4. 确定范围确认会议的组织步骤

9.4.5. 组织范围确认会议

9.5. 确认范围过程与控制质量过程的不同之处

9.5.1. 前者关注可交付成果的验收

9.5.2. 后者关注可交付成果的正确性及是否满足质量要求

9.5.3. 控制质量过程通常先于确认范围过程，但二者也可同时进行

9.6. 干系人关注点

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

9.6.1.1. 【高21下选31】

9.6.1.1.1. 【高20下选31】

9.6.2. 客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务

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

9.6.4. 项目团队成员主要关心项目范围中自己参与的元素和负责的元素，通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作又有冲突的地方

9.7. 确认范围由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收

9.7.1. 【高19下选31】

9.7.1.1. 【高23上选28】

9.8. 输入

9.8.1. 核实的可交付成果

9.8.2. 工作绩效数据

9.8.3. 项目文件

9.8.3.1. 需求文件

9.8.3.2. 需求跟踪矩阵

9.8.3.3. 质量报告

9.8.3.4. 经验教训登记册

9.8.4. 项目管理计划

9.8.4.1. 范围基准

9.8.4.2. 需求管理计划

9.8.4.3. 范围管理计划

9.8.5. 【高19下选29】

9.9. 工具与技术

9.9.1. 检查

9.9.1.1. 审查、产品审查和巡检

9.9.2. 决策

9.9.2.1. 投票

9.10. 输出

9.10.1. 验收的可交付成果

9.10.2. 变更请求

9.10.3. 工作缋效信息

9.10.3.1. 包括项目进展信息

9.10.4. 项目文件（更新）

9.10.4.1. 需求文件

9.10.4.2. 需求跟踪矩阵

9.10.4.3. 经验教训登记册

9.10.5. 【高20下选29】

9.11. 数据流向图

9.12. 【高22上案一】

9.12.1. 【高20下选75】

9.12.2. 【高18下选73】

10. 控制范围

10.1. 监督项目和产品的范围状态，管理范围基准变更的过程

10.2. 主要作用是在整个项目期间保持对范围基准的维护

10.2.1. 超出基准的变更会影响进度

10.2.1.1. 【高21上选32】

10.3. 需要在整个项目期间开展

10.4. 确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理

10.5. 必须和其他控制过程综合在一起考虑

10.5.1. 【高19上选40】

10.6. 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延

10.7. 确认项目范围是否覆盖了需要完成的产品或服务进行的所有活动

10.7.1. 【高18上选40】

10.8. 输入

10.8.1. 项目管理计划

10.8.1.1. 范围管理计划

10.8.1.2. 需求管理计划

10.8.1.3. 变更管理计划

10.8.1.4. 配置管理计划

10.8.1.5. 范围基准

10.8.1.6. 绩效测量基准

10.8.2. 项目文件

10.8.2.1. 经验教训登记册

10.8.2.2. 需求跟踪矩阵

10.8.2.3. 需求文件

10.8.3. 工作绩效数据

10.8.3.1. 工作绩效数据是在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值

10.8.3.1.1. 【高23上选25】

10.8.3.2. 数据通常是最低层次的细节，将交由其他过程从中提炼并形成信息

10.8.3.3. 在工作执行过程中收集数据，再交由 10 大知识领域的相应的控制过程做进一步分析

10.8.3.3.1. 已完成的工作

10.8.3.3.2. 关键绩效指标（KPD、技术绩效测量结果、进度活动的实际开始日期和完成日期、己完成的故事点、可交付成果状态、进度进展情况、变更请求的数量、缺陷的数量、实际发生的成本、实际持续时间等）

10.8.4. 组织过程资产

10.9. 工具与技术

10.9.1. 数据分析

10.9.1.1. 偏差分析

10.9.1.2. 趋势分析

10.9.2. 【高18下选42】

10.10. 输出

10.10.1. 工作绩效信息

10.10.2. 变更请求

10.10.3. 项目管理计划（更新）

10.10.3.1. 范围管理计划

10.10.3.2. 范围基准

10.10.3.3. 进度基准

10.10.3.4. 成本基准

10.10.3.5. 绩效测量基准

10.10.4. 项目文件(更新)

10.10.4.1. 经验教训登记册

10.10.4.2. 需求跟踪矩阵

10.10.4.3. 需求文件

10.11. 数据流向图

11. 【高20下案一】

11.1. 【高19上案三】

11.2. 【高18下案一】

11.3. 【高18上选73】