软考高项（九）项目范围管理 ★重点集萃★

👑 个人主页 👑 ：😜😜😜Fish_Vast😜😜😜
🐝 个人格言 🐝 ：🧐🧐🧐说到做到，言出必行🧐🧐🧐
🐸 推荐专栏 🐸 ：SpringBoot
🐸 推荐专栏 🐸 ：Java基础
🐸 推荐专栏 🐸 ：软考
🍉 博客描述 🍉 ：行好每一次程，写好每一篇文！
🍀 本篇简介 🍀 ：分享软考高项核心考点之项目范围管理内容。

输入、输出、工具与技术

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

2、项目范围管理过程包括：

3、范围管理计划描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划用于指导如下过程和相关工作：
（1）制定项目范围说明书；
（2）根据详细项目范围说明书创建WBS；
（3）确定如何审批和维护范围基准；
（4）正式验收已完成的项目可交付成果。
根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概况的。

4、需求管理计划的主要内容包括：
（1）如何规划、跟踪和报告各种 需求活动；
（2）配置管理活动；
（3）需求优先级排序过程；
（4）测量指标及使用这些指标的理由；
（5）反映哪些需求属性将被列入跟踪矩阵等。

5、让干系人积极参与需求的探索和分解工作并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。应该足够详细地挖掘、分析和记录这些需求，并将其包含在范围基准中，在项目执行开始后对其进行测量。需求将作为后续工作分解结构（WBS）的基础，也将作为成本、进度、质量和采购规划的基础。

6、访谈：是通过与干系人直接交谈来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可包括多个访谈者或多个被访者。访谈有经验的项目参与者、发起人和其他高管及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。

7、焦点小组：是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。

8、问卷调查：是指设计一些列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于受众多样化，需要快速完成调查，受访者地理位置分散并且适合开展统计分析的情况。

9：标杆对照：将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。

10、文件分析指审核和评估任何相关的文件信息。

11、决策：适用于收集需求过程的决策技术主要包括：
（1）投票：是一种为达成某种期望结果，而对未来多个行动方案进行评估的决策技术和过程。本技术用于生成、归类和排序产品需求。
（2）独裁型决策制定：采用这种方法，将由一个人负责为整个集体制定决策。
（3）多标准决策分析：该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。

12、数据表现：可用于收集需求过程的数据表现技术主要包括：
（1）亲和图：用来对大量创意进行分组的技术，以便进一步审查和分析。
（2）思维导图：把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性和差异，激发新创意。

13、人际关系与团队技能：可用于收集需求过程的人机关系与团队技能主要包括：
（1）名义小组技术：是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式。
（2）观察和交谈：是指直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，特别需要通过观察来了解他们的工作细节。观察也称为“工作跟随”，通常由旁站观察者或观察业务专家如何执行工作，但也可以由“参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
（3）引导：引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调干系人的需求差异。因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善、沟通，从而有利于干系人达成一致意见。此外，与分别召开会议相比，研讨会能够更早发现并解决问题。

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

15、原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

16、需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。

17、需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。跟踪需求的内容包括：
①业务需要、机会、目的和目标；
②项目目标；
③项目范围和WBS可交付成果；
④产品设计；
⑤产品开发；
⑥测试策略和测试场景；
⑦高层级需求到详细需求等。
应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。

18、由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程需要从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。

19、产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的用途、特征及其他方面。用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。产品分析技术主要包括：产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。

20、项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。详细的项目范围说明书包括内容有（直接列出或参引其他文件）：
（1）产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
（2）可交付成果：为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力。
（3）验收标准：可交付成果通过验收前必须满足的一系列条件。
（4）项目的除外责任：识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。

21、WBS是对项目团队为实现项目目标，创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。

22、WBS最低层的组成部分称为工作包。工作包对相关活动进行归类，以便对工作安排进度，进行估算，开展监督与控制。

23、要把整个项目工作分解为工作包，通常需要开展如下活动：
①识别和分析可交付成果及相关工作；
②确定WBS的结构和编排方法；
③自上而下逐层细化分解；
④为WBS组成部分制定和分配标识编码；
⑤核实可交付成果分解的程度是否恰当。

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

25、工作分解得越细致，对工作的规划、管理和控制就越有利。但是过细的分解会造成管理女里的无效耗费、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难。

26、在分解的过程中，应该注意以下8个方面。
（1）WBS必须是面向可交付成果的：项目的目标是提供产品或服务，WBS中的各项工作是为提供可交付的成功服务的。
（2）WBS必须符合项目的范围：WBS必须包括也仅包括为了完成项目的可交付成果的活动。100%原则（包含原则）认为，在WBS所有下一级的元素之和必须100%代表上一级的元素。
（3）WBS的底层应该支持计划和控制：WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
（4）WBS中的元素必须有人负责，而且只有一个人负责。WBS和责任人可以使用工作责任矩阵来描述。
（5）WBS应控制在4-6层，一个工作单元只能从属于某个上层单元，避免交叉从属。
（6）WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
（7）WBS的编制需要所有（主要）项目干系人的参与。
（8）WBS并非是一成不变的：在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。

27、范围基准是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。

28、WBS的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇总提供了层级结构，即账户编码。

29、每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合并与挣值相比较来测量绩效。控制账户包含两个或更多工作包，每个工作包只与一个控制账户关联。

30、规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知，一个控制账户可以包含一个或多个规划包。

31、WBS字典是针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。

32、确认范围应该贯穿项目的始终。确认范围的一般步骤包括：
①确认需要进行范围确认的时间
②识别范围确认需要哪些投入
③确定范围正式被接受的标准和要素
④确定范围确认会议的组织步骤
⑤组织范围确认会议

33、通常情况下，在确认范围前，项目团队需要先进行质量控制工作，以确保确认工作的顺利完成。

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

35、确认范围主要是项目干系人对项目的范围进行确认和接受的工作。每个人对项目范围所关注的方面是不同的：
（1）管理层主要关注项目范围：是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。
（2）客户主要关注产品范围：关心项目的可交付成果是否足够完成产品或服务。
（3）项目管理人员主要关注制约因素：关心项目可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
（4）项目团队成员主要关注项目范围中自己参与的元素和负责的元素；通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作是否有冲突的地方。

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

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

38、验收的可交付成果：符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。