导图社区 第5章 项目范围管理
软考高级--信息系统项目管理师第五章知识点，项目范围管理，实质上是指一种功能管理，它是对项目所要完成的工作范围进行管理和控制的过程和活动。
软考高级--信息系统项目管理师第六章知识点，活动排序( activity sequencing)根据项目活动清单中各项活动相互关联与依赖关系，确定项目活动的先后顺序的活动。
软考高级--信息系统项目管理师第四章知识点。项目管理,全生命周期管理软件,可定制,本地化服务,全流程管理,降低企业成本,提高利润和利润,实现客户管理全过程,轻松实现利润全网覆盖,
社区模板帮助中心，点此进入>>
项目时间管理6大步骤
互联网9大思维
项目管理的五个步骤
电商部人员工作结构
组织架构-单商户商城webAPP 思维导图。
暮尚正常运转导图
域控上线
产品经理如何做好项目管理
车队管理
python思维导图
第五章 项目范围管理
范围管理的概述
范围管理就是做范围内的事，且只做范围内的事，既不多做也不少做
范围
包括
产品范围
关注功能、强调结果
项目范围
关注工作，强调过程
产品范围是项目范围的基础，项目范围是项目管理计划的基础
项目范围基准包括
项目范围说明书
WBS
WBS词典
项目范围管理需要做的工作
明确项目边界
对项目执行工作进行监控
防止项目范围发生蔓延
区分范围蔓延和镀金行为
范围蔓延：客户提出新的要求，超出了范围基准
范围镀金：客户没有新的要求，卖方自己做的超出范围基准的工作
范围管理的重要性
让项目团队成员知道为达到预期目标需要完成哪些具体工作，清楚项目相关各方在每项工作中清晰的分工界面和责任
范围管理能够提高对项目成本、进度和资源估算的准确性
规划范围管理
概念：编制范围管理计划，书面描述如何定义、确认、控制项目范围的过程
作用：在整个项目中对如何管理范围提供指南和方向
ITTO过程
输入
项目章程
项目管理计划
事业环境因素
组织过程资产
工具与技术
专家判断
会议
输出
范围管理计划
内容
如何制订项目范围说明书
如何根据项目范围说明书创建WBS
如何维护和批准WBS
如何确认和正式验收已完成的项目可交付成果
如何处理项目范围说明书的变更
需求管理计划
概念：需求管理计划是描述在整个项目生命周期内如何分析、记录和管理需求
如何规划、跟踪、汇报各种需求活动
需求管理需要使用的资源
培训计划
项目干系人参与需求管理的策略
判断项目范围与需求不一致的准则和纠正程序
需求跟踪结构
配置管理活动
需求管理的基本任务
1.明确需求，建立基线
2.建立需求跟踪能力联系链，始终保持产品与需求的一致性
收集需求
概念：为实现项目目标而确定、记录并管理干系人需要和需求的过程
作用：为定义和管理项目范围（包括产品范围）奠定基础
需求分类
业务需求
整个组织的高层级需要
干系人需求
干系人或干系人群体的需要
解决方案需求
过度需求
从当前状态过渡到将来状态所需的临时能力
项目需求
项目需要的行动、过程和其它条件
质量需求
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准（QFD）
干系人管理计划
干系人登记册
访谈
通过与干系人直接交谈获得信息的正式或非正式方法，是一种最基本的收集需求的手段
焦点小组
焦点小组是一种群体访谈
引导式研讨会
引导式研讨会对产品需求进行集中讨论和定义，比单项会议更快的解决问题
群体创新技术
概念：组织一些群体活动来识别项目和产品需求
头脑风暴法
各抒己见，集思广益
名义小组法
通过投票来排列最有用的创意，以便进行进一步头脑风暴或优先排序
德尔菲法
采用匿名或背靠背方式，能使每一位专家独立自主的做出自己的判断
预测过程几轮反馈，是专家意见逐渐趋同
有助于减轻数据偏倚，防止任何个人对数据产生不恰当的影响
概念/思维导图
又称心智图，将从头脑风暴中获得的创意用一张简单的图联系起来，以反映这些创意之间的共性或差异，从而引导出新的创意
亲和图
又称KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等资料，通过图解方法进行汇总，并按其相互亲和性归纳整理这些资料，是问题明确，求得统一认识
多标准决策分析
借助决策矩阵，用系统分析方法建立多种标准，从而对多种方案进行评估和排序
群体决策技术
指未达到某种期望结果，而对多个未来行动方案进行评估
可用来开发产品需求，以及对产品需求进行归类和优先排序
方法
一致同意
大多数原则
相对多数原则
独裁
问卷调查
观察法
原型法
标杆对照
将实际或计划的做法与其他类似组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据
系统交互图
是范围模型的一个例子，是对产品范围的可视化描述，显示系统与参与者之间的交互方式
文件分析
通过分析现有文档，识别与需求相关的信息来挖掘需求
需求文件
概念：描述各种单一的需求将如何满足与项目相关的业务需求
与需求有关的假设条件、依赖关系和制约因素
需求跟踪矩阵
概念：是将产品需求从其来源连接到能满足需求的可交付成果的一种表格
作用：表示需求和其他产品元素之间的联系链的最普遍方式。
需要跟踪的内容
业务需求、机会、目的和目标
项目目标
项目范围（WBS可交付成果）
产品设计
产品开发
测试策略和测试场景
高层级需求到详细需求
需求跟踪矩阵中记录的典型属性包括：唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期
其中当前状态有：进行中、已取消、已推迟、新增加、已批准、已分配、已完成
需求管理
在CMMI中，需求管理是已管理级的一个关键过程域
需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动
控制需求基线
保持项目计划与需求一致
控制单个需求和需求文档的版本情况
管理需求和联系链之间的联系或管理单个需求和项目其他可交付物之间的依赖关系
跟踪基线中需求的状态
需求跟踪
需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等
可跟踪性是项目需求的一个重要特征
需求跟踪的内容
每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性，所谓双向跟踪，包括正向跟踪和反向跟踪。
正向跟踪：检查需求文件中的每个需求是否都能在后续工作产品（或成果）中找到对应点
反向跟踪：也称为逆向跟踪，指检查设计文档、产品构件、测试文档等工作成果是否能在需求文件中找到出处。
需求跟踪涉及五种类型
箭头表示需求跟踪能力联系链，他能跟踪需求使用的整个周期，即从需求建议到交付的全过程
左半部分表示从用户原始需求可向前追溯到需求文件，这样能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求需求文件中包括所有的用户原始需求，确认每个需求的出处
右半部分表明，由于在项目实施过程中，产品需求转化为设计和测试等实现元素，所以通过定义单个需求和特定产品元素之间的联系链，可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，是项目团队成员指代每个产品元素存在的原因。如果不能将设计元素和测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。
第五类联系链是需求文件之间的跟踪，这种跟踪便于更好的处理各种需求之间的逻辑相关性，检查需求分解过程中可能出现的错误或遗漏。
定义范围
概念：制定项目和产品详细描述的过程
作用：明确所收集到的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界
产品分析
对于以产品为可交付成果的项目，产品分析是一种有效的工具
备选方案生成
是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法
专家判断法
项目范围说明书（详细）
概念：项目范围说明书是对项目范围、主要可交付成果、假定条件和制约因素的描述
产品范围描述
验收标准
可交付成果
项目除外责任
假定条件
制约因素
作用
确定范围
沟通基础
变更基础
规划基础
规划和控制依据
项目文件更新
创建工作分解结构
概念：创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。
作用：对所要交付的内容提供一个结构化的试图
相关概念
里程碑
里程碑标志着某个可交付成果或阶段的正式完成
重要的检查点是里程碑，重要的里程碑是基线
工作包
工作包是位于WBS每条分支最底层的可交付成果或项目工作组成部分
划分原则
工作包应便于完整地分派给不同的人或组织单元
工作包应该非常具体
遵循8/80规则，工作包大小至少需要8小时完成，总完成时间不大于80小时
规划包
规划包是指在控制账户之下，工作包之上，工作内容已知但尚缺详细进度活动的WBS组成部分，随着情况逐渐清晰，规划包最终将分解成工作包以及相应的具体活动
控制账户
控制账户是一种管理就控制点
一个控制账户中包括若干个工作包，但一个工作包仅属于一个控制账户
随着也称WBS词汇表，是描述WBS各组成部分的文件
WBS分解需要开展的活动
识别和分析可交付成果及相关工作
确定WB的结构和编排方法
分解自上而下逐层细化分解
为WBS组件制定和分配标识编码
核实可交付成果的分解成都是恰当的
WBS划分原则
功能或者技术原则
组织结构原则
系统和子系统原则
WBS分解方法
项目生命周期各阶段作为分解的第二层
主要可交付成果作为分解的第二层
整合可能由项目团队以外组织来实施的各种组件，然后作为外包工作的一部分，卖方需编制相应的合同WBS
WBS的表现形式
树形
优点：层次清晰、直观性和结构性强
缺点：不易修改，对大的、复杂的项目很难表示出项目的全貌
表格形
优点：能够反应所有工作要素
缺点：直观性较差
鱼骨形
不常用
WBS需要注意的8个方面
WBS必须是面向可交付成果的
WBS必须符合项目范围
WBS的底层应支持计划和控制
WBS中的元素必须有人负责
WBS的指导，WBS应控制在4~6层
WBS应包括项目管理工作，也包括分包出去的工作
WBS的编制需要所有项目干系人参与，需要项目团队成员的参与
WBS并非一成不变的，在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改
创建WBS的过程
WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认
详细的项目范围说明书
分解
范围基准
WBS的目的和用途
明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向
清楚定义项目的边界
为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需的技术和人力资源
针对独立单元，进行时间、成本、资源需求量的估算，提高估算准确性
为计划、预算、进度安排和费用控制奠定共同的基础，确定项目进度和控制的基准
将项目工作和项目财务账目联系起来
确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目
有助于防止需求蔓延
确认范围
概念：正式验收项目已完成的可交付成果的过程
作用：使验收过程具有客观性
包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收
确认范围的步骤
确认范围应贯穿项目始终
一般步骤
确定需要进行范围确认的时间
识别范围确认需要哪些投入
确定范围正式被接受的标准和要素
确定范围确认会议的组织步骤
组织范围确认会议
需要检查的6个方面
可交付成果是否是确定的、可确认的
每个可交付成果是否有明确的里程碑、里程碑是否有明确的、可辩别的事件
是否有明确的质量标准
审核和承诺是否有清晰地表达
项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或错误
项目范围的风险是否太高，管理层是否能够降低可预见风险发生时对项目的冲击
干系人关注点
管理层所关注的项目范围，是指范围对进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性
客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务
项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要潜在风险和预备解决的方法
项目团队成员主要关心项目范围中自己参与的元素和负责的元素
核实的可交付成果
工作绩效数据
检查
验收的可交付成果
变更请求
工作绩效信息
几个术语的比较
确认范围与核实产品
核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整
确认范围是针对项目的可交付成果，由客户或发起人在阶段末确认验收的过程
确认范围与质量控制
确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体的质量要求（质量标准）
质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末进行。
质量控制属于内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收
确认范围与项目收尾
虽然确认范围和项目收尾工作都在阶段末进行，但确认范围强调的是核实与接收可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作
确认范围和项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品
控制范围
概念：监督项目和产品的范围状态，管理范围基准变更的过程
作用：在整个项目期间保持对范围基准的维护
范围变更
范围变更的原因
政府政策问题
项目范围的计划编制步不周密详细，
出现了新技术、新手段或新方案
项目执行组织本身发生变化
客户的新要求
变更是不可避免的，未经控制的产品或项目范围扩大，称为范围蔓延
范围变更包括包括书面文件、跟踪系统和授权变更所必须的批准层级
范围变更控制主要工作
影响导致范围变更的因素，并尽量使这些因素朝着有利的方向发展
判断范围变更是否已经发生
范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。
偏差分析
组织过程资产更新
项目管理计划更新
