软考高项第五章范围管理

范围管理概述

1. 项目范围需要做以下三方面
1. 明确项目边界，即明确哪些工作时包括在项目范围之内的，哪些工作时不包括在项目范围之内的
2. 对项目执行工作进行监督，确保所有该做的工作都做了，而且没有多做。对不包括在项目范围内的额外工作说“不”杜绝做额外工作
3. 防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围扩大
2. 产品范围和项目范围
1. 产品范围是指产品或者服务所应该包含的功能，项目范围是指为了能够交付产品，项目所必须做的工作
2. 产品范围时项目范围的基础，产品范围的定义时产品要求的描述；而项目范围的定义是产生项目管理计划的基础
3. 项目的范围基础是经过批准的项目范围说明书、WBS和WBS词典⭐
4. 判断项目范围是否完成，要以范围基准来衡量。而产品范围是否完成，则根据产品是否满足了产品描述来判断
5. 产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受影响的是项目的范围
3. 范围管理过程
1. 项目范围管理主要是通过规划范围管理i、收集需求、定义范围、创建WBS、确认范围和控制范围六个过程来实现的

 

项目管理第七个过程（范围管理第一个） 规划项目范围

1. 定义
1. 规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中对如何管理范围提供指南和方向
2. 输入
1. 项目管理计划
2. 项目章程
3. 事业环境因素
4. 组织过程资产
3. 工具与技术
1. 专家判断
2. 会议
4. 输出
1. 范围管理计划
2. 需求管理计划
5. 范围管理计划（方法论）
1. 定义 ⭐
1. 范围管理计划是制定项目管理计划过程和其他范围管理过程的主要输入
2. 内容
1. 如何制定项目范围说明书
2. 如何根据范围说明书创建WBS
3. 如何维护和批准WBS
4. 如何确认和正式验收已完成的项目可交付成果
5. 如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连
3. 特点⭐⭐
1. 项目管理范围计划可能在项目管理计划之中，也可能作为单独的一项。根据不同项目，可以是详细的或者概括的，可以是正式的或者非正式的。
6. 需求管理计划
1. 定义
1. 需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求
2. 内容
1. 如何规划、跟踪和汇报各种需求活动
2. 需求管理需要使用的资源
3. 培训计划
4. 项目干系人参与需求管理的策略
5. 判断项目范围与需求不一致的准则和纠正规程
6. 需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求
7. 配置管理活动
3. 特点⭐
1. 需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线
2. 还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品和需求的一致性

 

项目管理第八个过程（范围管理第二个） 收集需求

1. 需求的分类
1. 业务需求 整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因
2. 干系人需求 是指干系人和干系人群体的需要
3. 过渡需求 从当前状态过渡到将来状态所需的临时能力，例如，数据转化和培训需求
4. 质量需求 用于确认项目可交付成果的成果完成或其他项目需求的实现的任何条件和标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求
2. 输入
1. 范围管理计划
2. 需求管理计划
3. 干系人管理计划
4. 项目章程
5. 干系人登记册
3. 工具和技术
1. 访谈
2. 焦点小组
1. 将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动讨论。焦点小组往往比一对一的访谈更加热烈
2. 焦点小组时一种群体访谈而非一对一访谈，可以有6~10个被访谈者参加。针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的意见。
3. 引导式研讨会
1. 通过邀请主要的跨职能干系人一起参加会议。引导式研讨会对产品需求进行集中谈论与定义
2. 研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通、从而有利于参加者达成一致性意见
3. 该技术的另一个好处是，能够比单项会议更快的发现和解决问题
4. 群体创新技术
1. 定义 群体创新技术是指可以组织一些群体活动来识别项目和产品需求，群体床i虚拟技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等
2. 头脑风暴 各抒已见
3. 名义小组 通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术时头脑风暴法的深化应用，是更加结构化的头脑风暴
4. 德尔菲技术 可以防止个人的观点被不正确的方法
5. 概念/思维导图 是将头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意
6. 亲和图 亲和图又称为KJ法，是针对某一个问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法，亲和图的核心是头脑风暴法，是根据结果去找原因
7. 多标准决策分析 借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术
5. 群体决策技术
1. 定义 群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序
2. 一致同意 所有人都统一某个行动方案
3. 大多数原则 获得群体中50%以上的支持，就能做出决策，参与决策的人数定位奇数，防止因平局而无法达成决策
4. 相对多数原则
1. 根据群体中相对多数着的意见做出决定，即便未能获得一部分人的支持
2. 通常在候选项超过两个时候用该原则，例如，某个软件构件的功能有3种实现方案（标记为A,B,C）在群体决策时，同意A方案的有40%，同意B方案的人有35%，同意C方案的有25%，则最终确定采用A方案
5. 独裁 由某一个人（例如，项目经理）为群体做出决策
6. 问卷调查
7. 观察
8. 原型法 原型法是一种根据干系人初步需求，利用产品开发工具，快速地建立一个产品模型展示给干系人，再此基础上与干系人交流，最终实现干系人需求的产品快速开发的方法
9. 标杆对照 标杆对照嫁给你实际或计划的做法与其他类似组织的做法（例如，流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据，标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组织
10. 系统交互图 系统交互图是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、朵丽鱼本系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统 输出和输出接收者
11. 文件分析 文件分析就是通过分析现有文件，识别与需求相关的信息来挖掘需求。可供分析的文件很多，包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。
4. 输出
1. 需求文件
1. 定义 需求文件描述各种单一的需求将如何满足于项目相关的业务需求
2. 内容（不限于）
1. 业务需求
2. 干系人需求
3. 解决方案需求
4. 项目需求
5. 过渡需求
6. 与需求有关的假设条件、依赖关系和制约因素
2. 需求跟踪矩阵
1. 需求管理 需求管理包括在产品开发过程种维持需求一致性和准确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的 联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态
2. 需求跟踪

1. 可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等
2. ⭐每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性，所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后续工作产品（成果）中找到对应点；反向追踪也称逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型
3. 箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程
4. 从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到响应的用户原始需求，确认每个需求的出处
5. 由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素，这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求
6. ⭐第五类联系链式需求文件之间的跟踪，这种跟踪便于更好的处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏
• 需求跟踪矩阵⭐⭐
1. 表示需求和其他产品元素之间的联系链的最普遍方式式使用需求跟踪（能力）矩阵，需求跟踪矩阵式将产品需求从其来源连接到能满足需求的可交付成果的一种表格
2. 应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识，需求文字描述，收录该需求的理由，所有者，来源，优先级别，版本，当前状态（例如：进行中，已取消，已延迟，新增加，已批准，已分配，已完成等）和状态日期

 

 

项目管理第九个过程（范围管理第三个） 范围定义

1. 定义 定义范围式制定项目和产品详细描述的过程，其主要作用式明确所收集的需求哪些将包含在项目范围内，哪些将被排除在项目范围外，从而明确产品、服务或成果的边界
2. 输入
1. 范围管理计划
2. 项目章程
3. 需求文件
4. 组织过程资产
3. 工具和技术
1. 专家判断
2. 产品分析 产品分析式一种有效的工具。通常，针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述
3. 备选方案生成 备选方案生成是一种用来指定尽可能多的潜在可选方案的技术 ，用于识别执行项目工作的不同方法
4. 引导式研讨会
4. 输出
1. 项目范围说明书⭐⭐
1. 定义
1. 作为定义范围过程的主要成果，项目范围说明书式对项目范围、主要可交付成果、假设条件和制约因素的描述
2. 项目范围说明书记录了整个范围，包括项目范围和产品范围，详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作
2. 内容 （需要背诵）
1. 产品范围描述
2. 验收标准 定义可交付成果通过验收前必须满足一系列条件，以及验收的过程
3. 可交付成果
4. 项目的除外责任 通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理干系人的期望。
5. 制约因素 列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素
6. 假设条件
3. 作用
1. 确定范围
2. 沟通基础
3. 规划和控制依据
4. 变更基础
5. 规划基础
2. 项目文件更新

 

项目管理第十个过程（范围管理第四个） 创建WBS

1. 定义 创建WBS是将项目可交付成果和项目工作分解成较小的 ，更易于管理的组件的过程
2. WBS

图为四层WBS的示例

1. 里程碑⭐ 里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线.
2. 工作包⭐ 工作包是位于WBS每条分支最底层的可交付成果或项目工作组成部分，工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。工作包的大小需要遵循8/80原则。(最小8个小时，最多80个小时)
3. 控制账户⭐ 控制账户时一种管理控制点，是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制账户中就包括若干个工作包，但是一个工作包仅属于一个控制账户。项目团推在控制账户上考核项目执行情况，即在控制账户的响应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况的好坏，并发现与纠正偏差。
4. 规划包⭐ 规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分，是在控制账户之下、工作包之上的WBS要素，是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及响应的具体活动。
5. WBS词典⭐ WBS词典，在制作WBS的过程中，要给WBS的每个部分赋予一个账户编码标志符，他们是成本、进度和资源使用信息汇总的层次结构。需要生成一些配置的文件，这些文件需要和WBS配套使用，称为WBS词典。WBS词典也成为WBS词汇表，他是描述WBS各组成部分的文件。
• 输入⭐
1. 范围管理计划
2. 项目范围说明书 （对它进行分解）
3. 需求文件
4. 事业环境因素
5. 组织过程资产
• 工具与技术⭐
1. 分解
2. 专家判断
• 输出 ⭐
1. 范围基准
2. 项目文件更新
• 分解的步骤（背诵）
1. 识别和分析可交付成果及相关工作
2. 确定WBS的结构和编排方法
3. 自上而下逐层细化分解
4. 为WBS组件制定和分配标识编码
5. 核实可交付成果分解的程序是恰当的
• 分解的原则
1. 功能或者技术原则 在创建WBS时，需要考虑将不同人员的工作分开
2. 组织结构 对于智能型项目组织而言，WBS也要适应项目的组织结构形成
3. 系统或者子系统 总的系统划分为几个主要的子系统，然后对每个子系统再进行分解
• WBS分层方式
1. 将项目生命周期的各阶段作为分解的第二层
2. 主要可交付成果作为分解的第二层
3. 子项目作为分解的第二层

9. WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认
10. 表示形式
1. 树形结构（组织结构图式）
1. 优点 树形结构的WBS层次清晰、直观性和结构性强
2. 缺点 不容易修改，对大的、复杂的项目很难表示项目的全貌
2. 表格形式（列表格）
1. 优点 能否反应出项目所有的工作要素
2. 缺点 表格形式的直观性较差
11. 值得注意的时，索然有些参考文件也使用鱼骨图形式的WBS，但这种形式并不常用
12. 分解注意事项⭐⭐
1. WBS必须是面向可交付成果的。项目的目标是提供产品和服务，仅仅是一连串特别的活动
2. WBS必须符合项目的范围。WBS必须包括，也仅包括为了完成项目的可交付成果的活动
3. WBS的底层应该支持计划和控制。WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算
4. WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与⭐
5. WBS的知道，作为知道而不是原则，WBS应该控制再4~6层。当然，大项目可以超过6层⭐
6. WBS应包括项目管理工作，也要包括分包出去的工作⭐
7. WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与⭐
8. WBS并非是一成不变的，在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改⭐
13. WBS用途与作用
1. 明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需求努力的方向。
2. 清楚地定义项目的边界
3. 为个独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源
4. 针对独立单元，进行实践、成本和资源需求量的估算，提高估算的准确性
5. 为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制基准
6. 将项目工作和项目财务账目联系起来
7. 确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。WBS可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际情况进行调节和控制。
8. 有助于防止需求蔓延

 

项目管理第十一个过程（范围管理第五个） 确认范围

1. 定义⭐
1. 确认范围是正式验收项目已完成的可交付成果的过程，确认范围包括包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收
2. 确认项目范围应该贯穿项目始终
2. 输入⭐
1. 项目管理计划
2. 需求文件
3. 需求跟踪矩阵
4. 确认的可交付成果
5. 工作绩效数据
3. 工具与技术⭐
1. 检查 检查也称为审查、评审、审计、走查、巡检、测试等
2. 群体决策
4. 输出⭐
1. 验收的可交付成果
2. 变更请求
3. 工作绩效信息
4. 项目文件变更
5. 步骤
1. 确定需要进行范围确认的时间
2. 识别范围确认需要哪些投入
3. 确定范围正式被接受的标准和要素
4. 确定范围确认会议的组织步骤
5. 组织范围确认会议
6. 项目干系人进行范围确认时，一般需要检查一下6方面的问题
1. 可交付成果是否是确定的，可确认的
2. 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辩别的事件
3. 是否有明确的质量标准
4. 审查和承诺是否有清晰的表达
5. 项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误
6. 项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击
7. 项目干系人关注点
1. 管理层所关注的项目范围，是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否再投入产出上具有合理性。
2. 客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品和服务。
3. 项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
4. 项目团队成员主要关心项目范围中自己参与的元素和负责的元素，通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作又有冲突的地方
8. 几个属于的比较
1. 确认范围和核实产品
1. 核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整；
2. 确认范围是针对项目可交付成果，由客户发起人在阶段末确认验收的过程
2. 确认范围和质量控制⭐（考过案例分析）
1. 确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）
2. 质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末进行。
3. 质量控制属于内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。
3. 确认范围和项目收尾
1. 虽然确认范围与项目收尾工作都在阶段末进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（阶段）所要作的流程性工作。
2. 确定范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。

 

项目管理第十二个过程（范围管理第六个） 控制范围

1. 定义 ⭐ 控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。
2. 输入⭐
1. 项目管理计划
2. 需求文件
3. 需求跟踪矩阵
4. 工作绩效数据
5. 组织过程资产
3. 工具与技术⭐
1. 偏差分析 （当前数据和基准进行对比）
4. 输出⭐
1. 工作绩效信息
2. 变更要求
3. 项目管理计划更新
4. 项目文件更新
5. 组织过程资产更新
5. 范围变更的原因⭐
1. 政府政策的问题
2. 项目范围的计划编制的不周密详细，有一定的错误或遗漏
3. 市场上出现了或是设计人员提出了新技术、新手段或新方案
4. 项目执行组织本身发生变化
5. 客户对项目、项目产品或服务的要求发生变化
6. 主要工作
1. 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
2. 判断范围变更是否已经发生
3. 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理