PMP常考知识点核对单-5.项目范围管理

项目范围管理

项目范围管理包括确保项目做且只做所需的全部工作,以完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包括在项目内。
项目管理过程包括

  • 规划范围管理 - 为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程
  • 收集需求 - 为实现项目目标而确定、记录并管理相关方的需要和需求的过程
  • 定义范围 - 制定项目和产品详细描述的过程
  • 创建WBS - 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程
  • 确认范围 - 正式验收已完成的项目可交付成果的过程
  • 控制范围 - 监督项目和产品的范围状态,管理范围基准变更的过程

5.1范围管理计划(⭐️⭐️⭐️⭐️)

范围管理计划是项目管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划要对将用于下列工作的管理过程做出规定:

  • 制定项目范围说明书
  • 根据详细项目范围说明书创建WBS
  • 确定如何审批和维护范围基准
  • 正式验收已完成的项目可交付成果

根据项目需要,范围管理计划可以是正式或非正式的,非常详细或高度概括的

5.1需求管理计划(⭐️)

需求管理计划是项目管理计划的组成部分,描述将如何分析、记录和管理项目和产品的需求。根据《从业者商业分析:实践指南》【7】,有些组织称之为“商业分析计划”。需求管理的主要内容包括(但不限于)“

  • 如何规划、跟踪和报告各种需求活动
  • 配置管理活动,例如,如何启动变更,如何分析其影响,如何进行追溯、跟踪和报告,以及变更审批权限
  • 需求优先级排序过程
  • 测量指标及使用这些指标的理由
  • 反映哪些需求属性将被列入跟踪矩阵的跟踪结构

5.2需求文件(⭐️⭐️)

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级需求,然后随着有关需求信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要相关方愿意认可的需求,才能作为基准。需求文件的格式多种多样,既可以的一份按相关方和优先级分类列出的全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等等详细文件。
许多组织把需求分为不同的种类,如业务解决方案和技术解决方案。前者是相关方的需要,后者是指如何实现这些需要。把需求分成不同的类别,有利于对需求进行进一步完善和细化。需求的类别包括:

  • 业务需求。整个组织的高层级需要,例如,解决业务问题或抓住业务机会,以及实施项目的原因
  • 相关方需求。相关方或相关方群体的需要
  • 解决方案需求。为满足业务需求和相关党需求,产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和分功能需求
    • 功能需求。功能需求是描述产品应具备的功能,例如,产品应该执行的行动、流程、数据和交互
    • 非功能需求。非功能需求是对功能需求的补充,是产品正常运行所需的环境条件或质量要求,例如,可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等
  • 过渡和就绪需求。这些需求描述了从“当前状态”过度到“将来状态”所需的临时能力,如数据转换和培训需求
  • 项目需求。项目需要满足的行动、过程或其他条件,例如里程碑日期、合同责任、制约因素等
  • 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准,例如测试、认证、确认等

5.2需求跟踪矩阵(⭐️⭐️⭐️)

需求跟踪矩阵是把产品需求从其来源链接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵,把每个需求与业务目标或项目目标串联起来,有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法,有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后,需求跟踪矩阵还为管理项目范围变更提供了框架
跟踪需求包括(但不限于)

  • 业务休要、机会、目的和目标
  • 项目目标
  • 项目范围和WBS可交付成果
  • 产品设计
  • 测试策略和测试场景
  • 高层级需求到详细需求

应在需求跟踪矩阵中记录每个需求的相关属性,这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(如进行中、已取消、已推迟、新增加、已批准、被分配和已完成)和状态日期。为确保相关方满意,可能需要增加一些补充属性,如稳定性、复杂性和验收标准。下图是需求跟踪矩阵示例,其中列有相关的需求属性
需求跟踪矩阵示例

5.3项目范围说明书(⭐️⭐️⭐️⭐️)

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围,包括项目和产品范围;详细描述了项目的可交付成果;还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望,项目范围说明书可明确指出哪些工作不属于本项目范围。范围说明书使项目团队能进行更详细的规划,在执行过程中指导项目团队的工作,并为评价变更请求或额外工作是否超过项目边界提供基准
项目范围说明书描述要做和不做的工作的详细程度,决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括一下内容(可能直接列出或参引其他文件):

  • 产品范围描述。逐步细化在项目章程和需求文件中所描述的产品、服务或成果的特征
  • 可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力,可交付成果也包括各种辅助成果,如项目管理报告文件。对可交付成果的描述可略可详
  • 验收标准。可交付成果通过验收前必须满足一系列条件
  • 项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容不属于项目范围,有助于管理相关方的期望及减少范围蔓延

5.3项目章程&项目范围说明书内容对比图(⭐️⭐️⭐️⭐️)

虽然项目章程和项目范围管理说明书的内容存在一定程度的重叠,但他们的详细程度完全不同。项目章程包含高层级的信息,而项目范围说明书则是对范围组成部分的详细描述,这些组成部分需要在项目过程中渐进明细。下图显示了这两个文件的一些关键内容
项目章程与项目范围说明书的内容

5.4分解(⭐️⭐️⭐️)

创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是,为所要交付的内容提供架构,它仅开展一次或仅在项目的预定一点开展
WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS组织并定义了项目的总范围,代表着经批准的当前项目范围说明书中所规定的工作
WBS最低层的组成部分称为工作包,其中包括计划的工作。工作包对相关活动进行归类,以便对工作安排进度、进行估算、开展监督与控制。在“工作分解结构”这个词语中,“工作”是指作为活动结果的工作产品或可交付成果,而不是活动本身

5.4范围基准(⭐️⭐️⭐️⭐️)

范围基准是经过批准的范围说明书、WBS和相应的WBS词典,只有通过正式的变更控制程序才能进行变更,它被用做比较的基础。范围基准是项目管理计划的组成部分,包括:

  • 项目范围说明书。项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素对描述
  • WBS。WBS是项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层,代表对项目工作更详细的定义
  • 工作包。WBS的最低层级是带有独特标识号的工作包。这些标识号为进行成本、进度和资源信息的逐层汇总提供了层级结构,构成账户编码。每个工作包都是控制账户的一部分,而控制账户则是一个管理控制点。在该控制点上,把范围、预算和进度加以整合,并与挣值相比较,以测量绩效。控制账户拥有两个或更多工作包,但每个工作包只与一个控制账户关联
  • 规划包。一个控制账户可以包含一个或多个规划包,其是一种低于控制账户而高于工作包的工作分解结构组件,工作内容已知,但详细的进度活动未知
  • WBS词典。WBS词典是针对WBS中的每个组件,详细描述可交付成果、活动和进度信息的文件。WBS词典对WBS提供支持,其中大部分信息由其他过程创建,然后在后期添加到词典中。WBS词典中的内容可能包括(但不限于):
  • 账户编码标识
  • 工作描述
  • 建设条件和制约因素
  • 负责的组织
  • 进度里程碑
  • 相关的进度活动
  • 所需资源
  • 成本估算
  • 质量要求
  • 验收标准
  • 技术参考文献
  • 协议信息

5.5理解P164页中与控制质量的对比说明(⭐️⭐️⭐️)

确认范围过程与控制质量过程不同之处在于,前者关注可交付成果的验收,而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认质量过程,但二者也可同时进行

5.5检查(⭐️⭐️)

检查是指开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准。检查又是也被称为审查、产品审查和巡检等。在某些应用领域,这些属于具有独特和具体的含义

5.5验收可交付成果(⭐️⭐️⭐️⭐️)

符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件,证明相关方对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程

完整章节

查看完整章节内容请点击: PMP常考知识点核对单进行查看。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
软件测试需求是开发测试用例的依据,测试需求分解的越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,对测试用例的设计质量的帮助越大。详细的测试需求还是衡量测试覆盖率的重要指标,测试需求是计算测试覆盖的分母,没有详细的测试需求就无法有效的进行测试覆盖计算。 软件测试执行阶段是由一系列不同的测试类型的执行过程组成的,每种测试类型都有其具体的测试目标和支持技术,每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试,准确的测试类型可以给软件测试带事半功倍的效果。 现有的软件测试分析技术不太成熟,对测试需求和测试类型的分析,所采用的方法主要是根据经验进行收集、整理,该方法依赖于测试设计人员的测试经验,由此方法得出的测试需求、测试类型往往导致测试用例设计不充分,测试覆盖度低,测试目的性不强,容易遗漏等缺陷。 可见,如何对测试需求进行细致的整理分析,明确测试执行时的测试类型,是一个亟待解决的问题。 有鉴于此,本方法的主要目的在于提供一种软件测试需求的分析方法,可以方便、详尽的获取测试需求,明确测试执行时需要实施的测试类型。 为实现上述目的,本方法提供了一种软件测试需求分析的方法,包括以下步骤: a)列出软件开发需求中具有可测试性的开发需求; b)对步骤a)列出的每一条开发需求,形成可测试的分层描述的测试需求; c)对步骤b)形成的每一条测试需求,从GB/T 16260.1-2006《软件工程 产品质量 第1部分:质量模型》中定义的软件内部/外部质量模型来确定软件产品的质量需求; d)对步骤c)所确定的质量需求,分析测试执行时需要实施的测试类型; e)建立测试需求跟踪矩阵,对测试需求进行管理

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值