系统集成项目管理工程师（软考中级）—— 第十二章 项目范围管理 笔记分享

• 前言

  现在分享一些笔记给大家，希望能够帮助大家并顺利通过软考。

• 幕布地址：第十二章 项目范围管理 - 幕布

• 概述

  • 考情分析
    • 1、综合知识:3-4分左右
    • 2、案例分析:很少考到，偶尔配合整体管理一起考

• 范围与范围管理的概念

  • 项目范围:为了完成具有所规定特征和功能的产品和服务必须完成的全部工作。
  • 项目的范围基准是经过批准的详细的项目范围说明书、WBS和WBS词典。
  • 项目范围管理不仅仅是让项目管理和实施人员知道为达到预期目标需要完成哪些具体的工作，还要确认清楚项目相关各方在每项工作中清晰的分工界面和责任。

• 范围管理的过程 4+2

  • 编制范围管理计划Plan Scope Management
    • 创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程
  • 收集需求Collect Requirements
    • 为实现项目目标而确定、记录并管理干系人的需要和需求的过程
  • 定义范围Define Scope
    • 制定项目和产品详细描述的过程 （详细的）
  • 创建工作分解结构Create WBS
    • 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程
  • 确认范围Validate Scope
    • 正式验收已完成的项目可交付成果的过程
  • 控制范围Control Scope
    • 监督项目和产品的范围状态，管理范围基准变更的过程

• 编制范围管理计划（详细 概括 正式 非正式）

  

  • 定义:是创建范围管理计划，书面的描述将如何定义、确认和控制项目范围的过程
  • 作用:在整个项目中对如何管理项目范围提供指南和方向。
  • ★如何基于初步项目范围说明书准备一个详细的项目范围说明书
  • 如何从详细的项目范围说明书创建WBS
  • ★如何对已完成项目的可交付物进行正式的确认和接受的（确认范围）
  • 如何对详细的项目范围说明书申请变更(该过程直接与整体变更控制过程相关联)

• 收集需求

  

  • 定义:是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。
  • 作用:为定义和管理项目范围(包括产品范围)奠定基础。

  • 工具和技术

    • 访谈
      • 通过与干系人直接交谈，来获得信息的正式或非正式方法。访谈的典型做法是向被访者提出预设和即兴的问题,并记录他们的回答。通常采取“一对一”的形式，但也可以有多个被访者和/或多个访问者共同参与
    • 焦点小组会议
      • 把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度
    • 引导式研讨会
      • 邀请主要的跨职能干系人一起参加会议，对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术:联合应用开发、质量功能展开
    • 群体创新技术
      • 组织一些群体活动来识别项目和产品需求:头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图
    • 群体决策技术
      • 为达成某种期望结果而对多个未来行动方案进行评估:一致同意100%、大多数原则51%、相对多数原则、独裁
    • 问卷调查
      • 通过设计书面问题，向为数众多的受访者快速收集信息
    • 观察
      • 直接观察个人在各自的环境中如何开展工作和实施流程
    • 原型法
      • 在实际开发之前，先造出该产品的实用模型，并据此征求对需求的反馈意见
    • 标杆对照
      • 标杆对照将实际或计划的做法(如流程和操作过程)与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的
    • 系统交互图
      • 系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统(过程、设备、计算机系统等)及其与人和其他系统(行动者)之间的交互方式系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
    • 文件系统
      • 文件分析就是通过分析现有文档，识别与需求相关的信息，来挖掘需求可供分析的文档很多，包括:商业计划、营销文献、协议、建议邀请书、现行流程、逻辑数据模型、业务规则库、应用软件文档、业务流程或接口文档、用例、其他需求文档、问题日志、政策、程序和法规文件等。

  • 需求文件描述各种单一需求将如何满足与项目相关的业务要求。内容包括:

    • 业务需求
    • 干系人需求
    • 解决方案需求
    • 项目需求
    • 过渡需求
    • 与需求相关的假设条件、依赖关系和制约因素

  • 项目跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。内容包括:

    • 业务需要、机会、目的和目标;
    • 项目目标;
    • 项目范围/WBS可交付成果;
    • 产品设计;
    • 产品开发;
    • 测试策略和测试场景;
    • 高层级需求到详细需求。依赖关系和制约因素

• 定义范围

  

  • 定义:是制定项目和产品详细描述的过程。
  • 作用:明确所收集的需求哪些将包含在项目范围内,哪些将排除在项目范围外，从而明确产品、服务或成果的边界。

  • 范围说明书的内容

    • 项目目标(量化标准)
    • 产品范围描述
    • 项目需求
    • 项目边界(除外责任)
    • 可交付成果
    • 制约因素(如:强制性日期)
    • 假设条件(不需要验证即可视为正确真实的因素)

  • 范围说明书的作用

    • 确定范围
    • 沟通基础(共识)
    • 规划和控制依据
    • 变更基础(判断是否超界)
    • 规划基础(成本，进度等计划的基础)

• 创建工作分解结构(WBS)

  

  • 定义:是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
  • 作用:对所要交付的内容提供一个结构化的视图。

  • 需开展的活动

    • ★识别和分析可交付成果及相关工作
    • ★确定WBS的结构与编排方法(树型，列表型)
    • ★自上而下逐层细化分解
    • ★为WBS组成部分制定和分配标志编码
    • ★核实工作分解的程度是恰当的

  • 可采用的形式

    • 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
    • 以主要可交付成果作为分解的第二层
      • 树型-以项目生命周期的各阶段为第二层分解示例:
      • 树型-以主要可交付成果为第二层分解示例:
      • 列表型分解示例:
    • 树型:简单直观,适合于小项目
    • 列表型:可层级展开,适合于大项目

  • WBS分解原则:

    • (1)在层次上保持项目的完整性，避免遗漏必要的组成部分。
    • (2)一个工作单元只能从属于某个上层单元，避免交叉从属。
    • (3)相同层次的工作单元应用相同性质。
    • (4)工作单元应能分开不同的责任者和不同的工作内容。
    • (5)便于项目管理计划和项目控制的需要。
    • (6)最底层工作应该具有可比性，是可管理的，可定量检查的。
    • (7)应包括项目管理工作，包括分包出去的工作。

    • 注意事项:

      • WBS必须是面向可交付成果的，最底层次的工作单元为工作包;
      • WBS的编制需要所有项目干系人的参与，需要项目团队成员参与。
      • 经验法则8/80规则，8小时<工作包完成时间<80小时

  • 概念扩展:

    • 规划包:是控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分
    • 控制账户:一种管理控制点。在该控制点上将范围、预算、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效。
    • WBS词典:给WBS的每个部分赋予一个账户编码标识符，它们是成本、进度和资源使用信息汇总的层次结构。

  • WBS作用:

    • 通过工作结构分解，把项目范围分解开来，使项目相关人员对项目一目了然,能够使项目的概况和组成明确、清晰、透明和具体。
    • 保证了项目结构的系统性和完整性。
    • 通过工作结构分解，可以建立完整的项目保证体系，因为这个分解过程将项目的总目标关注的重点，如进度、成本和质量等分解到可控制的各项目单元，便于执行和实现目标要求。
    • 项目工作结构分解能够明确项目相关各方的工作界面，便于责任划分和落实。
    • 最终工作分解结构，可以直接作为进度计划和控制的工具。
    • 为建立项目沟通管理提供依据,便于把握信息重点。
    • 是项目各分计划和控制措施制定的基础和主要依据。
    • 有助于防止需求和范围蔓延。

• 项目范围确认

  

  • 定义：是正式验收已完成的项目可交付成果的过程。
  • 作用：使验收过程具有客观性;同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。

  • 工作绩效数据

    • 执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。例如:工作完成百分比、质量和技术绩效测量值、进度活动的开始和结束日期、变更请求的数量、缺陷数量、实际成本和实际持续时间等

  • 工作绩效信息

    • 从各控制过程中收集并结合相关背景和跨领域关系，进行整合分析而得到的绩效数据。如:可交付成果的状况、变更请求的执行状况、预测的完工估算

  • 工作绩效报告

    • 为制定决策、提出问题、采取行动或引起关注，而汇编工作绩效信息,所形成的实物或电子项目文件。例如:状况报告、备忘录、论证报告、信息札记、电子报表、推荐意见或情况更新

  • 检查工具

    • 项目干系人进行范围确认时，一般需要检查一下6个方面的问题:
      • 1．可交付成果是否是确认的、可确认的;
      • 2．每个可交付成果是否有明确的里程碑,里程碑是否明确的、可辨识的事件
      • 3．是否有明确的质量标准;
      • 4、审核和承诺是否清晰的表达;并获得一致同意;
      • 5．项目范围是否覆盖需要完成的产品或服务进行的所有活动，有没有遗漏或错误
      • 6．项目范围风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。

  • 确认范围的步骤

    • (1).确定需要进行确认范围的时间。
    • (2).识别确认范围需要哪些投入。
    • (3).确定范围正式被接受的标准和要素。
    • (4).确定确认范围会议的组织步骤。
    • (5).组织确认范围会议。

  • 范围确认与控制质量

    • 范围确认主要关注对可交付成果的验收，控制质量主要关注可交付成果是否正确以及是否满足质量要求。质量控制通常先于范围确认进行，但二者也可同时进行。质量控制属内部检查，由执行组织的相应质量部门实施;范围确认由外部干系人(客户或发起人）对项目可交付成果进行检查验收

  • 范围确认与项目收尾

    • 范围确认强调的是核实与接受可交付成果，项目收尾强调的是结束项目或阶段所要做的流程性工作;
    • 范围确认与项目收尾都有验收工作，范围确认强调验收项目可交付成果，项目收尾强调验收产品

• 项目范围控制

  

  • 基本概念

    • ★范围控制是监督项目和产品的范围状态，管理范围基准变更的过程。
    • ★本过程的主要作用是，在整个项目期间保持对范围基准的维护。
    • ★对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理
    • ★在变更实际发生时，也要采用范围控制过程来管理这些变更。范围控制过程需要与其他控制过程整合在一起
    • ★未得到控制的变更通常被称为项目范围蔓延
    • ★变更不可避免，因而必须以书面形式记录并强制实施某种形式的变更控制管理
    • ★每次需求变更并经过评审后都要重新确定新的基线。
    • ★范围变更过程中经常遇到的问题
      • 项目范围蔓延
      • 得不到投资人的批准
      • 项目小组未尽责任