【信息系统项目管理师】第五章复盘范围管理知识架构-CSDN博客

本文链接：https://blog.csdn.net/Last_Impression/article/details/125904195

【信息系统项目管理师】第五章复盘范围管理知识架构

范围管理目录

一.范围管理总体概要

|章节|知识领域|过程说明|输入输出|工具技术|项目文档|流程步骤|概念分类|控制审计|知识点汇总|
|:–|:–|:–|:–|:–|:–|:–|:–|:–|:–|:–|
|第五章|范围管理|5|6|4|7|1|6|4|33|

5.1 范围管理的过程说明(5项)

5.1.1 范围管理的定义和重要性

项目范围的定义：为了达到项目目标，交付具有某种特质的可交付成果，项目所要做的工作
范围管理的定义：为了达到项目目标，而对项目可交付成果或服务进行的范围规划，定义，分解，验收和控制的过程。
项目范围在项目的早期被描述出来，并且随着项目的进展变得更加的详细。
范围管理的重要性体现在以下的三点当中：

首先它可以让团队成员，项目干系人明白项目该做什么，项目的目标是什么;
其实它可以明确项目范围的边界，有效的范围管理后，可以在此基础上更好的进行成本，进度和质量的管理。
项目范围一旦发生蔓延，将直接对项目质量，成本，进度等造成严重的影响，它直接影响到项目的成功。

5.1.2 范围管理的六个过程

项目范围管理由以下六个过程所组成：规划范围管理，收集需求，定义范围，创建WBS，确认范围和控制范围。

5.1.3 范围管理的三方面工作

范围管理的三方面工作包括了明确范围边界，监控项目范围的变化，防止项目范围的蔓延。

5.1.4 质量控制与范围确认

质量控制和确认范围它们的侧重点不同，确认范围强调项目可交付成果获得客户或者发起人方的验收，质量控制强调确认可交付成果的正确性。
质量控制和确认范围它们可以有先后顺序，往往质量控制过程之后实施确认范围过程，当中这两个过程也可以同时实施。
质量控制强调的是由内部发起的对质量检验的过程，而范围确认强调的是客户干系人方对项目可交付成果的验收。

5.1.5 项目收尾与范围确认

首先项目收尾和范围确认都强调在阶段末尾对可交付成果物进行验收，但是它们的侧重点不同，确认范围侧重于对可交付成果的验收，而项目收尾更侧重于结束项目时所要做的流程性的工作。
它们的验收内容也不一样。项目收尾强调的是对产品或者服务的验收，而确认范围强调的是对可交付成果的验收。

5.2 范围管理的输入输出(6项)

5.2.1 规划范围管理

规划范围管理是依据组织的政策，规章制度等建立一个文档，该文档指导我们如何在项目中对项目范围进行管理；它的输入有四项：项目章程，项目管理计划，组织过程资产和事业环境因素；它的输出有两项：范围管理计划和需求管理计划；

5.2.2 收集需求

收集需求是收集干系人对项目的需要和期望的过程；它的输入有，项目章程，范围管理计划，需求管理计划，组织过程资产和事业环境因素等五项；它的输出就是需求文件和需求跟踪矩阵两个；

5.2.3 定义范围

定义范围是对项目或者产品的范围进行详细描述的过程；它的输入是项目章程，范围管理计划，需求管理计划，需求文件，组织过程资产和事业环境因素；它的输出是产品范围定义书；

5.2.4 创建WBS

创建WBS过程是将项目可交付成果分解成更小的更加易于管理的部分的过程；它的输入有项目章程，范围管理计划，需求文件，产品范围说明书；它的输出就是范围基准；

5.2.5 确认范围

确认范围是对项目可交付成果进行客户验收的一个过程；它的输入是项目范围管理计划，核实的可交付结果，需求文件，需求跟踪矩阵，范围基准，组过资产和事业环境因素；它的输出是验收的可交付成果，变更请求；

5.2.6 控制范围

控制范围是在项目实施过程中对范围基准的一个维护，并防止出现范围蔓延的一个过程；它的输入有：范围管理计划，工作绩效数据，范围基准，需求文件，需求跟踪矩阵，组织过程资产和事业环境因素；它的输出有工作绩效信息，变更请求；

5.3 范围管理的工具与技术(4项)

5.3.1 收集需求的工具与技术

收集需求的工具与技术一共有11中，这个知识点和系统分析师中的需求获取是有很大程度上的重叠面的，可以合在一起记忆。

范围管理中的收集需求	系统分析师领域	说明
访谈	用户访谈	通过直接与干系人交谈来获取信息的正式或非正式手段。1对1-3的进行，成本较高
问卷调查	问卷调查	受众多，地理位置分散的时候使用，调查问卷中的问题设计很重要，在无法一一访谈的时候使用该方法
观察，标杆对照	现场观摩	一些较为复杂的业务流程和操作，还是深入现场去观摩更加直接与合理
原型法	情节串联板	情节串联板是通过一系列的图片来讲故事的方式实现，它其实就是原型法的一种
引导式研讨会	联合需求计划	联合需求计划其实就是引导式研讨会的一种形式。它的特点是高度组织的群体会议，各方参与，成本较高，它的优点是更加容易在干系人之间达成一致的见解
文件分析	阅读历史文档	通过分析现有的文档，识别相关的需求，挖掘客户需求；对于数据性的信息较为有用
焦点小组	联合需求计划	被访谈者控制在6-10人，需要经验丰富主持人；它强调集中预先选定的主题专家和干系人
引导式研讨会和焦点小组的区别：两者都需要经验丰富的主持人参加，但是两者的侧重点不同。焦点小组强调邀请预先选中的干系人主题专家来参会，引导式研讨会强调的是跨职能部门人员，在会上积极充分讨论，并在会议上就需求达成一致。引导式研讨会包括了敏捷中的用户故事，联合需求计划JRP，QFD质量功能展开(质量屋)等具体实践。
抽样调查是系统分析师领域中独有的需求收集方法，它最大的特点就是在无法一一访谈的情况下，可以降低成本。

群体创新技术是组织群体活动来识别项目或产品的需求。
收集需求过程中的群体创新技术有：头脑风暴，亲和图，德尔菲技术，名义小组和思维导图，多标准觉得分析这六项组成；

头脑风暴的特点是各抒己见集思广益；
德尔菲技术的特点是专家匿名背靠背；
思维导图用来串联创意，并导出新的创意；
名义小组是深度的头脑风暴，通过排序来选择出最有价值最有用的创意；
多标准决策分析就是根据多个维度对方案进行选择的技术；
亲和图是充分收集各种资料，然后通过图解的方式汇总，使问题明确起来，求得统一的认识。

最后一个是群体决策技术。它用来对产品的需求进行归类和优先排序的一种技术。为了达成群体决策的方法有：一致同意，半数以上同意，独裁和相对多数同意四项。
相对多数同意一般用在候选项有两个以上的情况，从几个候选项当中找出相对投票最多的那个。

5.3.2 定义范围的工具与技术

产品分析技术：主要用于以产品作为可交付成果的项目中。通常的做法是针对产品以问答的形式形成对将要开发的产品的功能特征和其他方面的描述。它的作用是将项目章程中的对于产品的高层级描述转化为有型的对可交付成果物的描述。
用我自己的话来概括，产品分析技术是作用问答的形式把高层级的产品描述转变为对可交付成果物的描述。
备选方案分析技术主要是用来识别完成项目可交付成果的不同的方法的技术。
除此之外在定义范围中还用到了专家判断和引导式研讨会这两项技术。

5.3.3 确认范围的工具与技术

在确认范围这个过程中用到了两个工具与技术：分别是检查和群体决策技术。检查包括了审查，检查，审计，测试等，而群体决策技术是用在需要拍板的时候，验收通过与否有时候就需要拍板决定。

5.3.4 范围控制的工具与技术

范围控制使用的方法是偏差分析。它根据范围基准测量项目绩效，以此来评估变更的程度。

5.4 范围管理的项目文档(7項)

5.4.1 范围管理计划的内容

如何制定项目范围说明书
如何根据项目范围说明书创建WBS
如何维护和批准WBS
如何确认和验收已经完成的可交付成果
如何处理项目范围说明书的变更

5.4.2 需求管理计划

需求管理的目的：明确需求内容，建立需求基线，建立需求跟踪能力链。
概念：它用来描述在整个生命周期中如何分析记录和管理需求。
需求管理计划的内容：如何规划，跟踪和汇报需求；需求管理需要使用的资源；培训计划；干系人参与需求活动的策略；项目范围和需求有不一致时达到纠偏策略；需求跟踪结构；配置管理活动。

5.4.3 项目范围说明书

项目范围说明书的六个内容：验收标准，产品范围，制约事项，可交付成果，假设条件，最后一个是项目除外责任。
项目范围说明书的五个作用：规划基础，沟通基础，变更基础，范围监控控制基础，确定范围。

5.4.4 WBS

WBS的作用：对要交付的内容提供一个结构化的视图。
WBS分解的方法：

识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上而下逐层分解
为WBS组件制定和分配标识编码
核实可交付成果分解程度是否恰当

分解的三个原则：

功能或者技术原则
组织结构
系统或者子系统

分解的八大原则
100%原则，4-6层原则，80小时原则
滚动式规划原则，独立责任原则，不可再分原则，信息透明原则，包含原则。

100%原则：下一级的元素之和必须100%代表上一级元素；
4-6层原则：WBS分解应该控制在4-6层左右
80小时原则：原则上单个工作包工期不得超过两周
信息透明原则：让管理者能够监视和控制项目进度和预算。
独立责任原则：一个工作包原则上只有一个负责人，但可以有多人参与。
滚动式规划原则：并非是一成不变的，在完成了WBS以后，仍然有可能需要对他进行修改。
包含原则：下一层的元素必须100%包含在上一级的元素中
不可再分原则

WBS的两种表现形式：树型和列表型。
列表型不算很直观，它适合大型项目的创建WBS，它能反映出项目中的所有元素；树型结构最大的优点就是结构直观清晰，易于展现，但是修改维护困难。

5.4.5 需求分类

在需求工程中，软件需求有两种分类方法，在范围管理中对软件需求也有一种分类方法。
首先说说QFD对软件需求的分类：基本需求，期待需求和兴奋需求；基本需求是有明确指示的常规的需求；期待需求是指虽然用户没有明确提出需求，但是需要实现的需求，也就是隐含的需求；兴奋需求是指可有可无的需求，如果这类需求得到实现的话，用户会为此而兴奋但却不会为此而多淘钱出来购买。
在系统分析师领域，对于需求常规的分类方法有：业务需求，用户需求和系统需求，其中系统需求又可以分为功能需求，非功能需求一级设计约束；其中功能需求对应的是UML用例图中的椭圆，而非功能需求往往我们是通过场景架构去获取；在非功能需求中，还包括了对于性能和可靠性的需求，比如压力，边界，安全等；业务需求是整体全局的高层级需求；用户需求是通过用户视角获得。
在非功能需求的分类中PIECES方法，可以通过这个分类方法对非功能需求进行再详细地分类。
在收集需求过程中将需求分为了以下六种类型：业务需求，干系人需求，质量需求，项目需求，过渡需求，解决方案需求。