导图社区 范围管理思维导图
项目范围管理包括的程序，要求能确保该项目所覆盖的整体工作要求和单项工作要求，促使项目工作成功地完成。下图整理了范围管理的概述、规划范围管理、收集需求、定义范围、控制范围、确认范围、创建工作分解结构。
信息系统是由计算机硬件、网络和通信设备、计算机软件、信息资源、信息用户和规章制度组成的以处理信息流为目的的人机一体化系统。信息系统测试管理的知识点包括测试管理的内容、测试监控管理、风险管理、配置管理。
安全管理是管理科学的一个重要分支，它是为实现安全目标而进行的有关决策、计划、组织和控制等方面的活动。本图内容涵盖了安全策略、信息安全系统工程、PKI公开密钥基础设施、PMI权限管理基础设施。
一张思维导图带你了解信息文档管理与配置管理的知识内容，包括配置管理的概述、主要活动、目标和方针、过程，围挡管理的分类、质量分级，收藏下图了解吧！
社区模板帮助中心，点此进入>>
论语孔子简单思维导图
《傅雷家书》思维导图
《童年》读书笔记
《茶馆》思维导图
《朝花夕拾》篇目思维导图
《昆虫记》思维导图
《安徒生童话》思维导图
《鲁滨逊漂流记》读书笔记
《这样读书就够了》读书笔记
妈妈必读：一张0-1岁孩子认知发展的精确时间表
范围管理 Scope Management
概述
主要工作
明确项目边界
对项目执行工作进行监控
防止项目范围发生蔓延
区别
产品范围
产品所包含的功能（技术主线）
是项目范围的基础
是否完成要根据产品描述判断
产品范围描述是项目范围说明书的重要组成，产品范围变化首先影响项目范围
项目范围
为了交付产品所需做的工作（管理主线）
项目范围基准
经批准的项目范围说明书、WBS、WBS字典
以此衡量项目范围是否完成
范围管理过程
各过程
输入输出工具技术
规划范围管理
范围管理计划
可在项目管理计划之中、也可作为单独一项，可以使详细的、概括的、正式或非正式的
内容
如何制定项目范围说明书
范围定义
如何根据范围说明书创建WBS
如何维护和批准WBS
创建、维护、批准WBS
范围基线
如何确认和正式验收已完成的项目可交付成果
范围确认
如何处理项目范围变更
范围控制
需求管理计划
如何规划、跟踪、汇报各种需求活动
需求管理需要使用的资源
培训计划
项目干系人参与需求管理的策略
判断项目范围与需求不一致的准则和纠正规程
配置管理活动
收集需求
需求分类
业务需求
高层级需求
干系人需求
过度需求
质量需求
QFD质量功能部署
基本需求
期望需求
以外需求
对比课本1.41需求分析
用户需求
系统需求
工具技术
访谈
焦点小组
选定干系人和主题专家一起，由主持人引导互动式讨论
干系人一般不跨职能
引导式研讨会
邀请主要的跨职能干系人一起参会讨论，快速定义职能需求、协调关系人差异
重点强调达成一致意见
群体创新技术
头脑风暴
名义小组
投票，是头脑风暴的深化应用
德尔菲
私聊各专家，形成意见汇总后反馈给各专家，反复形成专家组意见
概念/思维导图
将头脑风暴的创意用图联系起来
亲和图（KJ法）
用图的方式把问题汇总归纳，以求找到原因，核心是头脑风暴法，根据结果找原因
多标准决策分析
借助决策矩阵，建立风险水平、不确定性、价值收益多个标准
群体决策技术
一致同意
大多数原则
相对多数原则
独裁
原型法
标杆对照
计划（实际）做法与类似组织的做法进行对比
系统交互图
显示了系统的输入和输入提供者、输出和输出提供者
文件分析
需求文件
解决方案需求
项目需求
服务水平、绩效、安全、合规性
需求相关的假设条件、依赖关系、制约因素
需求跟踪
理解
正向跟踪、逆向跟踪，追溯、回溯
箭头表示需求跟踪能力联系链
第五类联系链用于处理各类需求之间的逻辑相关性
需求跟踪矩阵
应记录每个需求的相关属性，包括需求描述、所有者、来源、优先级、当前状态(进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）
定义范围
指定项目（产品）详细描述的过程，明确产品边界
工具和技术
专家判断
产品分析
针对产品提问并回答，形成产品用途、特征描述
备选方案生成
指定尽可能多的潜在可选方案
项目范围说明书
包括项目范围和产品范围
内容（背）
产品范围描述
验收标准
可交付成果通过验收前需满足的条件，及验收过程
可交付成果
项目的除外责任
哪些是被排除在项目之外的，有助于管理干系人期望
制约条件
假设条件
控制范围
定义
监督范围状态，管理范围基准变更
原因
政府政策
项目范围计划编制不周
新技术、新手段、新方案
项目执行组织本身发生变化
客户需求发生变化
影响导致范围变化的因素，并使因素向有利方向发展
判断范围是否发生变化
管理变更应确保所有被请求变更，按照项目整体变更控制过程处理
确认范围
阶段性验收，应贯穿项目始终 正式验收已完成的可交付成果
检查
又称：审查、评审、审计、走查、巡检、测试等
群体决策
确认步骤
确定需要进行范围确认的时间
识别范围确认需要哪些投入
确认范围正式被接受的标准和要素
确定范围确认会议的组织步骤
组织范围确认会议
干系人关注点
管理层
进度、资金、资源
客户
产品的范围
项目管理人员
可交付成果是否足够和必须完成，时间、资金、资源是否足够
项目团队成员
自己参与与负责的元素
术语比较
和核实产品
核实产品
在项目或阶段末由客户来验证，强调产品的完整性
在阶段末有客户验证，主要针对可交付成果
和质量控制
质量控制
强调交付成果的正确性
一般在确认范围之前或同时
属于内部检查
强调交付成果获得客户接受
一般在阶段末尾
由外部干系人进行检查
创建工作分解结构WBS
应该全体项目团队成员、用户、 干系人共同完成和一致确认
WBS的层次
里程碑
重要的检查点是里程碑，重要的里程碑是基线
工作包
WBS 最底层的可交付成果
需要非常具体，以便承担能明白自己的任务
工作包大小需遵循8/80原则
控制账户
工作包或工作包上层的一个要素
一个控制账户可包含多个工作包，一个工作包只能属于一个控制账户
规划包
在控制账户之下、工作包之上的WBS要素
是工作内容已知，但尚缺详细进度活动WBS要素
WBS词典
用来解释WBS中的编码标识符的文档
分解
主要工作（背）
识别和分析可交付成果及相关工作
分解什么
确定WBS的结构和编排方法
怎么分解
自上而下逐层细化
为WBS组件制定和分配标识编码
编码
核实可交付成果的分解程度是恰当的
核对
原则
功能或技术原则
组织结构
系统或子系统
方式
将生命周期各阶段作为第二层
主要可交付成果作为第二层
子项目（来源于外部）作为第二层
形式
树形
层次清晰，直观性、结构性强，但不易修改。不适合大型、复杂的项目
表格型
直观性差，但可反映出所有工作要素，适合大型项目
鱼骨形
不常用
注意事项
WBS是面向可交付成果的
WBS必须符合项目范围
WBS的底层应该支持计划和控制
WBS的元素必须有且只有一个人负责
WBS的指导
WBS应控制在4~6层，超过六层的大项目可以分成若干个子项目在做WBS
一个工作单元只能属于某一个上层单元，避免交叉从属
WBS应包括项目管理工作、也包括分包出去的工作
WBS编制需要所有（主要）干系人参与，需要项目团队成员参与
WBS不是一成不变的，WBS建立后，可能要对WBS进行修改，所谓滚动分解原则
WBS作用
说明项目范围
定义项目边界
为各独立单元分配人员，规定人员职责
针对独立单元，进行时间、成本、资源需求估算，提高估算准确性
确定项目进度和控制的基准
将项目工作和财务账目联系起来
确定工作内容和工作顺序
防止需求蔓延
