【信息系统项目管理师】第五章 项目范围管理(考点汇总篇)

【信息系统项目管理师】第五章 项目范围管理(考点汇总篇)

■考点分析与预测

项目范围管理一般上午考察3分,需求是龙头,是做项目管理的基础。没有需求就不能确定项目的范围,没有范围,项目就无从谈起,此部分在下午案例分析的几率也是比较大的。
上午历年考试的重点在范围定义的概念产品范围和项目范围以及各自的衡量标准。详细范围说明书的内容WBS的表现形式分解的方法,原则工作包的定义作用范围确认范围基准范围蔓延范围变更等知识点上。输入输出和工具与技术直接考察的并不算多。
本章在下午案例分析的命题思路主要表现为:给出某项目在范围管理方面的案例场景描述,要求指出该案例场景中存在哪些问题并说明相关原因,要求给出解决这些问题的补救措施。

■知识点回顾

高项知识点:https://blog.csdn.net/Last_Impression/article/details/81950945

PMBOK第六版:第五章 项目范围管理第六版_千月星跡-CSDN博客

PMBOK第五版(上):[读书笔记]第五章 项目范围管理(上)_千月星跡-CSDN博客

PMBOK第五版(下):[读书笔记]第五章 项目范围管理(下)_千月星跡-CSDN博客

论文攻略:https://blog.csdn.net/Last_Impression/article/details/88725932

论文模板:https://blog.csdn.net/Last_Impression/article/details/82960752

范围记忆敲出:https://blog.csdn.net/Last_Impression/article/details/89839137

范围思维导图:【信息系统项目管理师】第五章 范围管理思维导图_千月星跡-CSDN博客

■项目范围管理ITTO助记

项目范围管理
过程名定义输入,输出,工具与技术
1.编制范围管理计划编制范围管理计划,书面描述如何定义,确认和控制项目范围的过程。输入项目管理计划,项目章程,事业环境因素,组织过程资产
工具专家判断,会议
输出范围管理计划,需求管理计划
2.收集需求为实现项目目标而确定,记录并管理干系人的需要和需求的过程。输入范围管理计划,需求管理计划,项目章程,干系人管理计划,干系人登记册
工具访谈,原型法,焦点小组,观察,标杆对照,系统交互图,问卷调查
群体创新技术(※),群体决策技术,引导式研讨会,文档分析
输出需求文件,需求跟踪矩阵
3.定义范围制定项目和产品详细描述的过程。输入范围管理计划,需求文件,项目章程,组织过程资产
工具专家判断,产品分析,备选方案生成,引导式研讨会
输出项目范围说明书,项目文件更新
4.创建WBS将项目可交付成果和项目工作分解为较小的,更易于管理的组件的过程。输入范围管理计划,需求文件,需求跟踪矩阵,项目范围说明书
事业环境因素,组织过程资产
工具分解,专家判断
输出范围基准,项目文件更新
5.范围确认正式验收已完成项目可交付成果的过程。输入需求文件,需求跟踪矩阵,确认的可交付成果,工作绩效数据,项目管理计划
工具检查(审查,产品评审,审计,走查,巡检),群体决策技术
输出项目文件更新,验收的可交付成果,变更请求,工作绩效信息,项管计划更新
6.范围控制监督项目和产品的范围状态,管理范围基准变更的过程。输入需求文件,需求跟踪矩阵,组织过程资产,工作绩效数据,项目管理计划
工具偏差分析
输出变更请求,项目文件更新,项目管理计划更新,工作绩效信息,组过资产更新

■大话范围管理

制订范围管理计划

  范围管理说白了就是管理做哪些事情。范围管理计划只是一个指导性的方法论,和所有程序型指南一样,都需要专家和开会来确定如何收集,定义,创建,确认和控制范围。
  当不知道做什么无从下手时,从项目章程入手,章程中有项目的背景,高层级产品描述和特征。从章程中寻找信息,结合事业环境和组织过程资产,最后做成需求管理计划。
  一个项目可能有多个阶段,最好每一个阶段制订各自的需求管理计划和文件,便于规划,跟踪,配置和测量。

收集需求

  拿着老板的签字章程着客户收需求,定计划,记跟踪。首先要找到相关人干系人和客户,需要用到干系人登记册,找到干系人后,总要了解一下管理干系人的原则吧,于是参照了干系人管理计划。干系人太多,让相关人了解项目是什么最快也最 简单和暴力的方法就是让他们自己看项目章程。
然后得到客户的需求了,这些信息一定要写到需求文件中,其他的范围管理过程都要使用需求文件的。如果说需求文件是只是描述了客户和需求之间的对照关系的话,那么需求跟踪矩阵是描述需求与交付成果物之间的对应关系。
收集客户需求是我们系统分析师的工作,系统分析师拥有各种工具与技术来获取客户需求。
从时间上说,收集需求要面对那么多人,自然少不了方法。客户人数不多,就直接访谈,多了就得分(焦点小组),意见不统一可以开引导式研讨会引导一下,人再多就用群体创新和决策,人再再多就问卷调查,遇到不爱沟通而且说不清楚话的人,通过观察,还是说不清楚的干脆做个原型看看定义的范围,最终产品范围其实也就是这样了。所以好方法就是找个现在市面上类似的产品分析一下,简单高效。
  需求是工作分解结构的基础。收集需求其实就是在定义和管理客户希望。
收集完需求将需求规格化,形成需求规格说明书。需求规格说明书以模块化描述,但会忽略人的信息。这个时候就要对需求进行跟踪,于是就有了需求跟踪矩阵。RTM还为管理产品范围变更提供了框架。

定义范围

  收集完了用户需求,明确收集到的需求文件哪些属于项目的范围,哪些不是。找出范围的边界在哪里这样才可以让我们只做正确的事情。整理好后就得到最终的项目需求。翻翻项目章程,看看上面的高层级需求和审批要求,一下子就总结成一个文档:项目范围说明书。项目范围说明书对需求的描述比较粗略,在确认和控制范围的子过程中,还是得用需求文件才可以。
 收集需求不需要老司机,但定义范围离不开专家老司机。对产品价值分析,对需求文件中的需求好坏备选方案分析,都对抽象成范围说明书的过程还是很有帮助的。

创建WBS

用范围说明书分解成WBS。对照需求文件拿项目范围说明书开刀。你要什么我给你分什么,最后分解成WBS和WBS词典。然后把WBS,WBS词典,范围说明书装订起来,就形成一个重要的基准文档:范围基准。当然要老板批准后,才可以算作基准。WBS最底层的叫做工作包,工作包在进度管理的时候再分解成活动。WBS分树形和列表型。大型项目优先使用列表型。WBS看不懂?请参照WBS字典。

确认范围

  就是验收已完成的项目可交付成果物的过程。确认产品是否在范围内,首先要利用需求跟踪矩阵,和客户保持有效的沟通。确保产品范围没有改变,确保需求文档最新后,同时查看工作绩效数据,用他去核实已经确认过质量的产品,没有问题就验收完成生成核实的可交付成果,核实后有问题怎么办,走变更流程。于是就有了变更请求。工作绩效数据在验收完成后该整理成工作绩效信息。注意在确认范围和控制范围的时候,是没有用范围说明书的。因为范围说明书太简略和概要化了。只有拿给老板和客户看比较合适些。
  那么怎么确认项目成果物呢,主要就是检查。包括了审查,产品评审,审计,走察,巡检等方式。可交付成果是项目最重要的可交付的成果,首先它在指导与管理项目工作时生成,经过质量的控制以后,变成了核实的可交付成果,核实完成后,就在本过程中验收,变成了验收的可交付成果,最后在结束项目或阶段的时候,将验收完的可交付成果打包一下,发给客户。那么项目就完成了。

控制范围

  控制工作是否在范围内。首先要通过需求跟踪矩阵去保持客户联系,确定工作范围没有变。确保需求文档更新到最新。既然是控制工作本身,那就要用到每日收集的工作状况,就是工作绩效数据。去对照需求文档得到项目范围实施情况作出的效果如何,就有了工作绩效信息。有问题就产生一个变更请求,最后还要更新项目管理计划和项目文件。还有项目知识(组织过程资产)的更新。
项目范围计划编制的不够缜密,项目组织发生客户对产品要求发生变化等,这些都是范围发生变更的原因。控制范围的工具有偏差分析。在控制范围的时候,要特别注意两个概念:质量镀金和范围蔓延。

  • 范围论文记忆敲出

过程名通俗解释怎么写
规划范围管理详细描述如何定义,确认和控制项目或产品范围的过程可以写我组织相关人员进行了范围管理计划的编制工作,在进行编制前做了什么准备,通过什么方法进行了编制,编制后的计划包含什么内容。
收集需求为完成项目可交付成果物,记录并管理干系人需要和需求的过程可以写有哪些类型的需求,可以写输入输出工具与技术,可以写这个过程的重要性,可以写有什么问题,怎么解决,可以写需求文件,建立需求跟踪矩阵。
定义范围对项目或产品进行详细描述的过程可以举例进行描述,本项目的某个功能原来是怎么定义的,现在我们是如何进行详细的表示的。
创建WBS将项目可交付成果物分解为更加易于管理的工作包的过程我们可以写为什么要分解,是按照树型还是列表型,是将什么作为第一层,分解的五个步骤是什么,遵循的原则是什么。(举例不要罗列)
确认范围是由客户或干系人正式验收并接受项目,可交付成果的过程可以具体的写我们通过了什么方式进行了范围确认的工作,哪些进行了接受,哪些不可以接受,是什么原因,我们会怎么整改。
控制范围要管理好变更,做好范围控制工作,避免出现范围蔓延的状况可以写下范围控制的重要性,然后举例说明我们是如何进行变更控制,如何防止范围蔓延的。
  • BackToRoot:

【信息系统项目管理师】重点整理:高项知识地图_千月星跡-CSDN博客

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

进击的横打

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值