1 章节相关

1.1 考试相关

上午一般考3分左右，20下、21下、22上考案例分析
21上考论文写作，是案例、论文需要学习准备的重点

1.2 6个过程

（1）规划范围管理：对如何定义、确认和控制项目范围的过程进行描述。
（2）收集需求：为实现项目目标，明确并记录项目干系人的相关需求的过程。
（3）定义范围：详细描述产品范围和项目范围，编制项目范围说明书，作为
以后项目决策的基础。
（4）创建工作分解结构：把整个项目工作分解为较小的、易于管理的组成部
分，形成一个自上而下的分解结构。
（5）确认范围：正式验收已完成的可交付成果。
（6）范围控制：监督项目和产品的范围状态、管理范围基准变更。

2 <5.1 范围管理概述>

1、项目范围管理需要做以下三个方面的工作：
①明确项目边界
②对项目执行工作进行监控
③防止项目范围发生蔓延

2.1 范围蔓延和范围镀金

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

范围蔓延 – 客户提出新需求，超出了范围基准【客户不断提出要求，不断去改，最终交付物不满足要求】团队客户总是希望更便宜、更多功能、更好服务
范围镀金 –客户没有提新需求，乙方自己做了额外客户不需要的工作【项目实施人员往往愿意尝试新的技术或者为信息系统项目加上更牛X的功能】团队成员希望表现自己、讨好客户、擅自承诺、送人情、尽善尽美…

2、范围蔓延

范围蔓延–未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。 来自团队内部原因造成的范围蔓延称为“镀金”
来自团队外部原因造成的范围蔓延称为“范围潜变”。

3、镀金

项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。

4、范围潜变

范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败。

5、如果范围蔓延已经产生

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

2.2 产品范围和项目范围

✓ ①产品范围是指产品或者服务所应该包含的功能，项目范围是指为了能够交付产品，项目所必须做的工作。 ✓
②产品范围是项目范围的基础，产品范围的定义是产品要求的描述，而项目范围的定义是产生项目管理计划的基础，两种范围在应用上有区别。 ✓
③项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。判断项目范围是否完成，要以范围基准来衡量。产品范围是否完成，则根据产品是否满足了产品描述来判断。
✓ ④产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。

3 <5.2 规划范围管理>

1、编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，在整个项目中对如何管理范围提供指南和方向。范围管理计划需要项目管理团队全员参与。
2、范围管理计划描述如何管理项目范围，项目范围怎样变化才能与项目要求相一致等问题，所以它也应该对怎样变化、变化频率如何，以及变化了多少等项目范围预期的稳定性进行评估。范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类等问题的清楚描述。项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。
3、范围管理计划的内容：①如何制订项目范围说明书、②如何根据范围说明书创建WBS、③如何维护和批准WBS、④如何确认和正式验收已完成的项目可交付成果、⑤如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。
例如，对于WBS的编制指南可能有（但不限于）如下内容：①确定WBS满足职能和项目的要求，包括重置和非重置成本、②检查WBS是否为所有的项目工作提供了逻辑细分、③保证每一个特定层的总成本等于下一个层次构成要素的成本和、④从全面适应和连续角度来检查WBS 、⑤所有的工作职责需分配到个人或组织单元。
4、需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
5、需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。
6、需求管理计划的内容：①如何规划、跟踪和汇报各种需求活动、②需求管理需要使用的资源、③培训计划、④项目干系人参与需求管理的策略、⑤判断项目范围与需求不一致的准则和纠正规程、⑥需求跟踪结构、⑦配置管理活动

4 <5.3 收集需求>

4.1 需求种类

1、需求包括业务需求、干系人需求、解决方案需求、过渡需求、项目需求和质量需求等。

4.2 收集需求的工具

收集需求的工具与技术有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。

1.访谈：与干系人直接交流，通常是一对一。
2.焦点小组：有主持人，分主题、分小组讨论。
3.引导式研讨会：跨职能人员讨论。
4.群体创新技术：是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、 名义小组技术、德尔菲技术、概念／思维导图、亲和图和多标准决策分析等。
◆ 头脑风暴法：面对面，快，容易受别人影响；
◆ 德尔菲技术：背靠背，匿名，多轮次，取得一致意见100%同意；
◆ 名义小组法：头脑风暴后，对创意进行排序；
◆ 思维导图：把头脑风暴中创意整合成一张图；
◆ 亲和图：大量创意分组，然后找关系，同类的放在一起；
◆ 多准则决策技术：对众多方案进行评估和排序的技术，不确定性下的决策准则（风险管理）；
5.群体决策技术：达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生成产品需求，并对产品需求进行归类和优先级排序
◆ 大多数原则：超过50%同意；
◆ 相对多数原则：候选超过两个时使用；
◆ 独裁：一言堂；
6.问卷调查：通过设计书面问题，向为数众多的受访者快速收集信息。
7.观察：针对不愿意说出需求，可以工作跟踪（看）和/或参与观察（做）。
8.原型法：先造出该产品的实用模型，原型是有形的实物，符合渐进明细理念
9.标杆对照：将实际的项目实践与可比项目的实践进行对照，识别最佳实践，形成改进意见，为绩效考核提供依据
10.系统交互图：对产品范围的可视化描绘
11.文件分析：通过分析现有文档，识别与需求相关信息，挖掘需求

4.3 工具详细

①访谈：

通过与干系人直接交谈来获取信息。典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。
访谈分类： 结构化--事先准备好一系列问题，有针对地进行；
非结构化--只列出一个粗略的想法，根据访谈具体情况发挥。
关键词： 直接交谈、预设和即兴问题、深入了解、一对一、一对多、获取机密和敏感的信息

②焦点小组

由一位受过训练的主持人引导预先选定的干系人和主题专家（SME）进行互动式讨论。
• 焦点小组的参加者往往是同职能，同一领域、或有相似背景条件的人
• 是“一对多”的群体访谈，最终是为了获取整个焦点小组更有价值的集体意见。
关键词：同职能、同一领域、有相似背景、主题专家（SME）、主持人、互动式讨论

③引导式研讨会

把主要干系人召集在一起，集中讨论来定义产品需求（也需主持人）
• 引导式研讨会能快速定义跨职能需求和协调干系人差异，着重于形成既定目标的一致意见。
关键词：跨职能、不同部门、协调干系人差异、联合应用开发JAD、质量功能展开、用户故事（敏捷）

④群体创新技术

是指可以组织一些群体活动来识别项目和产品需求，包括头脑风暴法、名义小 组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。

头脑风暴

（BrainStorming、BS、智力激励法、自由思考法、集思广益法） —单纯地收集创意，不进行分析及投票或排序。 ◆
直接头脑风暴法（头脑风暴法） –尽可能激发创造性，产生尽可能多的设想； 开发一款新手机有哪些需求？ ◆
质疑头脑风暴法（反头脑风暴法）–对提出的设想、方案逐一质疑，分析其现实可行性；
➢ 参与人：不同专业或岗位的5~10人；时间：1小时左右； 设主持人(仅主持)、 记录员(完整记录)
➢ 头脑风暴的原则：庭外判决原则（不质疑、不分析、不批判、不反对）、追求 数量、各抒己见、自由鸣放、探索取长补短和改进办法；
关键词：畅所欲言、单纯收集、尽可能多、尽可能激发

名义小组

促进头脑风暴，通过投票排列最有用的创意，以便进一步头脑风暴或优先排序。
➢ 名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法；
➢ 名义小组技术可以使那些不善言辞的参与者也能充分发表自己的意见。
关键词： 投票、排序

德尔菲技术（Delphi Technique）

一种组织专家就某一主题达成一致意见的一种信息收集技术。
➢ 专家回答问卷，并对每一轮给出反馈意见，专家的答复只能交给主持人，以保持匿名状态。
➢ 德尔菲技术的主要缺点是：过程比较复杂，花费时间较长。
关键词： 专家、匿名、多轮、趋同、消除偏见

概念/思维导图（Mind Mapping，心智图、脑图）

–从头脑风暴中获得的创意整合成一张图，反映创意之间的共性与差异，激发新创意。
关键词： 整合、反映共性与差异、激发新创意、图文并重

亲和图（Affinity Diagram，KJ法）：

从头脑风暴中获得的创意，根据相似性进行分组，以便进一步审查和分析。
关键词：分组、有助于WBS制订

多标准决策分析（如优先矩阵）：

借助决策矩阵，用系统分析方法建立多种标准，可用于识别关键事项和合适的备选方案，并通过一系列决策对众多备选方案进行评估和排序。
关键词：多种标准、权重、评估、排序

⑤群体决策

就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
达成群体决策的方法有：①—致同意；②大多数原则；③相对多数原则；④独裁
①一致同意:所有人都同意某个行动方案。
②大多数原则:获得群体中50%以上的人的支持，就能做出决策。
③相对多数原则:根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。通常在候选项超过两个时使用该原则，有3种实现方案（标记为A、B、C)，在群体决策时，同意A方案的人有40%，同意B方案的人有35%，同意C方案的人有25%，则最终确定采用A方案。
④独裁:由某一个人（例如，项目经理）为群体做出决策。
3、收集需求过程的主要输出有需求文件和需求跟踪矩阵。
◆ 需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
◆ 需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

6 问卷调查

设计一系列书面问题，向众多受访者快速收集信息。
• 关键词：受众多样化、快速完成、成本低、地理位置分散、适合开展统计分析
• 缺点：缺乏灵活性、无法了解细节及更隐性的信息、干系人不重视、真实性差

7 观察（Observation、工作跟踪）

直接察看个人在各自的环境中如何执行工作和实施流程。
• 关键词： 直接察看、难以或不愿清晰说明、挖掘隐藏的需求

8 原型法（Prototype）

在实际制造产品之前，先造出实用模型，据此征求对需求的早期反馈。
• 步骤：1.模型创建；2.用户体验；3.反馈收集；4.原型修改；
• 关键词：减轻风险、渐进明细、敏捷、故事板

9 标杆对照（Benchmarking）

将实际或计划做法与行业内或行业外的可比组织的做法进行比较，以便识别最佳实践， 形成改进意见，并为绩效考核提供依据。
• 关键词：可比组织、内部、外部、识别最佳实践、形成改进意见、为绩效考核
提供依据

10 系统交互图（Context Diagram）

范围模型的例子。是对产品范围的可视化描绘，显示业务系统以及与人和其他系统之间的交互方式（如：DFD、用例图等）
• 关键词：拓扑图、可视化

11 文件分析（Document Analysis）.

–通过分析现有文档，识别与需求相关的信息，来挖掘需求
• 关键词：分析现有文档

4.4 其他概念

4、需求文件的内容包括：①业务需求②干系人需求③解决方案需求④项目需求⑤过渡需求⑥与需求有关的假设条件、依赖关系和制约因素。
5、软件需求规格说明书就是一种典型的需求文件。因为项目具有渐进明细的特点，一开始，可能只有概括性的需求，然后随着信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
6、需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
7、可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。可验证性是需求的最基本特性

4.5 收集需求

1.从用户原始需求可向前追溯到需求文件,可区分受变更影响的需求，确保需求文件包括所有用户需求
2.从需求文件回溯到相应的用户原始需求，确认每个需求的出处
3.从需求文件追溯到产品元素，可知每个需求对应的产品元素，从而确保产品元素满足需求
4.产品元素回溯到需求文件，使项目团队成员知道产品元素存在的原因(如果设计元素或测试案例无法回溯到需求文件，则可能是镀金;如果孤立的产品元素是一个正当功，则可能是需求遗漏)
5.需求文件之间的跟踪,便于更好地处理各种需求之间的逻辑相关性,检查需求分解中可能出现的错误或遗漏。
★7、每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。双向跟踪，包括正向和反向跟踪：
正向跟踪：检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点； (以免需求被做漏、做偏)
反向跟踪：逆向跟踪，检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。(是查需求源头，了解为什么要做这个需求,来源背景和原因是什么)
★8、需求跟踪矩阵表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。

9、需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、己完成等）和状态日期。

5 <5.4 定义范围>

1、定义范围是制定项目和产品详细描述的过程，是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。
★2、定义范围工具与技术：专家判断、产品分析、备选方案生成和引导式研讨会。
①产品分析：对于那些以产品为可交付成果的项目，是一种有效的工具。
②备选方案生成：用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法
产品分析与范围定义紧密相关,如软件产品,分为几个子系统?是不是有基础平台?等等。
★3、项目范围说明书的内容：①产品范围描述、②验收标准、③可交付成果、④项目的除外责任、⑤制约因素、⑥假设条件
(1）产品范围描述。逐步细化在项目章程和需求文件中所描述的产品、服务或成果的特征。
(2）验收标准。定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。
(3）可交付成果。可交付成果既包括组成项目产品或服务的各种结果，也包括各种辅助成果
(4）项目的除外责任。通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围， 有助于管理干系人的期望。
(5）制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素
(6）假设条件。
4、项目范围说明书的作用：①确定范围、②沟通基础、③规划和控制依据、④变更基础、⑤规划基础

6 <5.5创建工作分解结构（WBS）>

1、创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要作用是对 所要交付的内容提供一个结构化的视图。
2、里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线
★3、工作包应便于完整地分派给不同的人或组织单元，所以要求明确各工作单元直接的界面。工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。作为一种经验法则，8/80规则（80小时原则）建议工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时

◆范围基准–经过批准的项目范围说明书、WBS、WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。
◆项目范围说明书–是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围， 包括项目和产品范围。
◆WBS–全部工作范围的层级分解（有助于防止范围蔓延）
◆WBS词典–针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件（有助于评价变更的影响）

★4、控制账户是一种管理控制点。在该控制点上，将范围、预算（资源计划）、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效。控制账户是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户。项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相 应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。
★5、规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。规划包是在控制账户之下、工作包之上的WBS要素。规划包是暂时用来做计划的，随着情况的逐渐清晰，规划包最终将 被分解成工作包以及相应的具体活动。
★6、WBS词典也称为WBS词汇表，它是描述WBS各组成部分的文件。对于WBS的每一组成部分，WBS词典可能包括账户编码标识、工作描述、假设条件和制约因、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。（WBS字典实际是相当于新华字典，是对WBS中每个元素的描述）
7、分解是一种将项目可交付成果和项目工作分解成较小的、更易于管理的组件的技术。
★8、要将整个项目工作分解为工作包，需要开展以下活动：
①识别和分析可交付成果及相关工作。
②确定WBS的结构和编排方法。
③自上而下逐层细化分解。
④为WBS组件制定和分配标识编码。
⑤核实可交付成果分解的程度是恰当的
★9、创建WBS时对工作的划分原则包括：
①功能或者技术原则：在创建WBS时，需要考虑将不同人员的工作分开。
②组织结构：对于职能型的项目组织而言，WBS 也要适应项目的组织结构形式
③系统或者子系统：总的系统划分为几个主要的子系统，然后对每个子系统再进行分解。

6.1 10、WBS分解的方法：

①项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层
②主要可交付成果作为分解的第二层
③整合可能由项目团队以外的组织来实施的各种组件（例如，外包工作），然后作为外包工作的一部分，卖方需编制相应的合同WBS。

★11、WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。

★12、WBS表示形式有分级的树型结构（组织结构图式）和表格形式（列表式）。
树型结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌（小项目）。
表格形式的直观性比较差，但能够反映出项目所有的工作要素（大项目）。
13、虽然有些参考文献也使用鱼骨图形式的WBS,但这种形式并不常用。

6.2 ★14、WBS分解注意8个方面：

①WBS必须是面向可交付成果的：所有下一级的元素之和必须100%的代表上一级元素。
②WBS必须符合项目的范围。WBS必须包括，也仅包括为了完成项目的可交付成果的活动
③WBS的底层应该支持计划和控制。 WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
④WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。
⑤WBS的指导，WBS应控制在4〜6层。当然，大项目可以超过6层。
⑥WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
⑦WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
⑧WBS并非是一成不变的。在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。

6.3 补充了解：

（1）在层次上保持项目的完整性，避免遗漏必要的组成部分。
（2）—个工作单元只能从属于某个上层单元，避免交叉从属。
（3）相同层次的工作单元应用相同性质。
（4）工作单元应能分开不同的责任者和不同的工作内容。
（5）便于项目管理计划和项目控制的需要。
（6）最底层工作应该具有可比性，是可管理的，可定量检查的。
（7）应包括项目管理工作，包括分包出去的工作。

15、当一个项目的WBS分解完成后，项目干系人对完成的WBS应该给予确认，并对此达成共识，然后才能据此进行时间估算和成本估算。WBS的目的和用途主要体现在以下8个方面：
(1）明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。
(2）清楚地定义项目的边界
(3）为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源。
(4）针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
(5）为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。 (6）将项目工作和项目的财务账目联系起来。
(7）确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。WBS可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元， 并根据实际情况进行调节和控制。
(8）有助于防止需求蔓延。

7 <5.6 确认范围>

1、确认范围是正式验收项目已完成的可交付成果的过程，其主要作用是使验收过程具有客观性， 同时，通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的 正式验收。
★2、确认范围的主要工具与技术是检查和群体决策技术。检查也称为审查、评审、审计、走查、 巡检、测试等，是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和 产品验收标准。
★3、确认范围应该贯穿项目的始终。
★4、确认范围的步骤：①确定需要进行范围确认的时间、②识别范围确认需要哪些投入、③确定范围正式被接受的标准和要素、④确定范围确认会议的组织步骤、⑤组织范围确认会议。
5、范围确认时，一般需要检查以下问题：
①可交付成果是否是确定的、可确认的。
②每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件
③是否有明确的质量标准
④审核和承诺是否有清晰的表达。
⑤项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。
⑥项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。
★6、项目中各人员关注点：【各司其职】
◆ 管理层所关注的项目范围，是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。【企业管理层不会关心太细节的东西。只需要关心投入产出的合理性就好了】
◆ 客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务。
◆ 项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
◆ 项目团队成员主要关心项目范围中自己参与的元素和负责的元素
7、核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整；确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。
8、确认范围与项目收尾的不同之处在于：
①虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
②确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。

7.1 ★9、确认范围与质量控制的不同之处在于：

①确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
②质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行,而质量控制并不一定在阶段未进行。
③质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。

8 <5.7 控制范围>

★1、控制范围是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时，也要采用范围控制过程来管理这些变更。
2、造成项目范围变更的原因是项目外部环境发生了变化，例如： ①政府政策的问题。 ②项目范围的计划编制不周密详细，有一定的错误或遗漏。
③市场上出现了或是设计人员提出了新技术、新手段或新方案。 ④项目执行组织本身发生变化。 ⑤客户对项目、项目产品或服务的要求发生变化。
★3、未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）称为范围蔓延。【客户不断提出要求，不断去改，最终交付物不满足要求！镀金：项目实施人员往往愿意尝试新的技术或者为信息系统项目加上】变更是不可避免的，控制范围过程依赖于范围变更控制系统，范围变更控制是指对有关项目范围的变更实施控制，审批项目范围变更的一系列过程，包括书面文件、跟踪系统和授权变更所必须的批准级别。
★4、范围变更控制的工作：
①影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。
②判断范围变更是否已经发生。
③范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理

9 案例分析

案例分析部分，除了找错改错，以下知识点比较重要：

比如范围管理6个过程、范围基准、范围说明书的内容、作用，WBS2个表现形式、创建的3个方法、8个原则、分解步骤5个、范围确认和质量控制的区别联系、需求跟踪矩阵、双向跟踪等，希望大家平时带着记忆！

10 论文

11 习题

【例1-17下】 （）不属于范围变更控制的工作。
A.确定影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
B.判断范围变更是否已经发生
C.管理范围变更，确保所有被请求变更按照项目整体变更控制过程处理
D.确定范围正式被接受的标准和要素
【例2-18上】关于WBS的描述，不正确的是（）。
A.WBS必须且只能包括100%的工作 B.WBS的元素必须指定一个或多个负责人
C.WBS应该由全体项目成员、用户和项目干系人一致确认 D.分包出去的工作也应纳入WBS中 【例3-18上】（）属于控制范围的活动。
A.与客户仔细讨论项目范围说明书，并请客户签字
B.当客户提出新的需求时，说服用户放弃新的需求
C.确认项目范围是否覆盖了需要完成的产品或服务进行的所有活动
D.确认每项工作是否有明确的质量标准 练一练
【例4-18下】关于需求管理的描述，正确的是（）。
A.需求管理包括在产品生存周期中维持需求一致性和精确性的所有活动
B.从测试用例和测试报告的描述中追踪到用户原始需求的过程是正向追踪
C.需求文件之间的跟踪用于检查需求分解中可能岀现的错误或遗漏
D.需求跟踪矩阵中可以不体现测试策略和测试场景的跟踪结果
【例5-18下】某公司决定在现有公文处理系统的基础上，新开发一个移动端APP便于大家远程办公。项目经理召开工作会议，就工作分解结构提出了如下的建议，其中（）是不妥当的；
A.项目组所有人员都要参与，任务分解的层次控制在4至6层之间
B.对目前尚不清楚具体活动的模块可以使用规划包进行分解
C.项目干系人对完成的WBS给予确认，并达成共识
D.项目经理负责项目分解，外包商负责外包合同WBS分解
【例6-18下】 （）是控制范围常用的工具和技术。
A.引导式研讨会 B.产品分析
C.偏差分析 D.标杆对照 练一练
【例7-19上】关于工作分解结构（WBS）的描述，正确的是（）。
A.WBS必须符合项目范围
B.WBS元素必须由多个人负责
C.WBS必需控制在5-8层
D.WBS的编制只需要项目团队成员参与
【例8-19上】关于范围控制的描述，正确的是（）。
A.控制进度是控制范围的一种有效的方式 B.项目执行组织本身发生变化不会引起范围变更
C.范围变更控制必须和其他控制过程综合在一起 D.政府政策的变化不可以成为范围变更的理由
【例9-19下】在项目管理的过程中，确认范围的输入不包括（）。
A.项目管理计划 B.工作绩效数据 C.验收可交付成果 D.需求跟踪矩阵
【例10-19下】 （）执行的步骤为：分成多个小组，每个小组开展讨论：小组过论结束后。主持人依次询问每位参与者，请每人提出一个创意：这种询问可以进行很多轮，直至得到足够数量的创意；再由全 体参与者对所有创意进行评审和排序。
A.焦点小组 B.名义小组 C.引导式研讨会 D.头脑风暴
【例11-19下】关于确认范围和质量控制的描述，不正确的是（）。
A.确认范围强调可交付成果的接受程 B.质量控制强调可交付成果的正确性
C.确认范围和质量控制均由组织内部质量部门实施
D.确认范围和质量控制都可以通过检查的方法来进行
【例12-20下】验收的可交付成果,属于项目范围管理中（）过程的输出。
A.定义范围B.控制范围 C.收集需求 D.确认范围
【例13-20下】在收集需求时,可以采用的群体创新技术包括（）。
①头脑风暴法②观察③原型法④德尔菲技术⑤文件分析⑥名义小组技术
A.①②③ B.①④⑥ C.②③⑤ D.④⑤⑥
【例14-20下】在项目范围管理中,企业管理层主要关注（）。
A.产品的范围 B.项目范围投入产出的合理性 C.交付成果是否满足质量要求 D.项目过程的合理性
【例15-21上】关于确定范围的描述，正确的是（）
A.确认范围是在正式验收阶段才执行的过程
B.分解技术是确认范围的主要工具与技术
C.客户主要关心产品范围和可交付成果
D.确认范围强调的是结束项目所要做的流程性工作
【例16-21上】项目进入设计阶段时，GB/T22239《信息安全技术网络安全等级保护基本要求》己经升 级版本，而项目需求是按旧版本策划的。（）直接影响项目进度。
A.提高需求评审频率 B.执行项目范围变更 C.与项目干系人沟通 D.重新进行成本估算
【例17-21下】范围管理计划中不包含（）。
A.确定WBS满足项目和职能要求
B.确定所有的工作职责需分配到个人或组织单元
C.确定如何处理项目范围说明书的变更
D.确定并正式验收可交付成果的正确性
【例18-21下】关于收集需求的描述，不正确的是（）。
A.德尔菲技术通过组织专家讨论、并投票来排列最有用创意
B. QFD对质量需求分为基本需求、期望需求和意外需求
C.概括性的需求说明文件不能作为基准
D.如果不能将设计元素或测试案例回溯到需求文件，就可能出现镀金行为
【例19-21下】在确认范围过程中，（）主要关注项目范围对项目进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。
A.客户 B.管理层 C.项目经理 D.项目团队成员
【例20-22上】某公司承担了一个新项目，为一家小型制造企业开发协同工作系统，该制造企业之前没有使用过协同工作系统，业务比较复杂，需求会持续变更，作为项目经理应通过（）来确保项目顺利完成。
A.项目前期多花时间，尽可能的明确和细化需求
B.更改项目完成时间，提前进行验收，以便处理验收时发现的问题
C.在开发中采用迭代开发的方式，及时调整功能
D.制定需求管理计划，规划如何分析、记录和管理需求
【例21-22上】在需求文件中，（）的需求可作为基准使用。
①可测量和可测试②项目经理认可③完整且可跟踪④相对独立无依赖
A.①② B.①③ C.③④ D.②③

参考答案