ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

信息系统项目管理师-项目范围管理考点笔记

2021-05-08 12:01:49  阅读:285  来源: 互联网

标签:需求 WBS 信息系统 项目 项目管理 确认 考点 变更 范围


历年考点分布

 

项目范围的6个过程

(1)规划范围管理:
对如何定义、确认和控制项目范围的过程进行描述。
(2)收集需求:
为实现项目目标,明确并记录项目干系人的相关需求的过程。
(3)定义范围:
详细描述产品范围和项目范围,编制项目范围说明书,作为以后项目决策的基础。
(4)创建工作分解结构:
把整个项目工作分解为较小的、易于管理的组成部分,形成
一个自上而下的分解结构。
(5)确认范围:正式验收已完成的可交付成果。
(6)范围控制:监督项目和产品的范围状态、管理范围基准变更。

注:

博客:
https://blog.csdn.net/badao_liumang_qizhi
关注公众号
霸道的程序猿
获取编程相关电子书、教程推送与免费下载。

4W1H

 

范围管理概述

1、项目范围管理需要做以下三个方面的工作

①明确项目边界

②对项目执行工作进行监控

③防止项目范围发生蔓延

★区分范围蔓延和镀金的行为
范围蔓延一客户提出新需求,超出了范围基准
范围镀金一客户没有提新需求,项目自己做了额外客户不需要工作

范围蔓延:
未对时间、成本和资源做相应调整,未经控制的产品或项目范围的扩大。
来自团队内部原因造成的范围蔓延称为“镀金”
来自团队外部原因造成的范围蔓延称为“范围潜变”。
镀金:
项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。
范围潜变:
范围潜变是指客户不断提出小的、不易察觉的范围改变,如果不加控制,累计
起来导致项目严重偏离既定的范围基准,导致项目失控和失败。
如果已经出现了范围蔓延,一样需要走变更流程。

2、产品范围与项目范围

①产品范围是指产品或者服务所应该包含的功能,项目范围是指为了能够交付产品
项目所必须做的工作。
②产品范围是项目范围的基础,产品范围的定义是产品要求的描述,而项目范围的
定义是产生项目管理计划的基拙,两种范围在应用上有区别。
③项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。判断项目范围是
否完成,要以范围基准来衡量。产品范围是否完成,则根据产品是否满足了产品描述
来判断。
④产品范围描述是项目范围说明书的重要组成部分,因此,产品范围变更后,首先
受到影响的是项目的范围

规划范围管理

1、编制范围管理计划,书面描述将如何定义、确认和控制项目范围的过程,在整个项
目中对如何管理范围提供指南和方向。范围管理计划需要项目管理团队全员参与。(掌握)
2、范围管理计划的内容:(了解)
①如何制订项目范围说明书。
②如何根据范围说明书创建WBS。
③如何维护和批准WBS。
④如何确认和正式验收已完成的项目可交付成果。
⑤如何处理项目范围说明书的变更,该工作与实施整体变更控制过程直接相联。

3、项目范围管理计划可能在项目管理计划之中,也可能作为单独的一项。根据不同的
项目,可以是详细的或者概括的,可以是正式的或者非正式的。(掌握)
4、需求管理贯穿于整个过程,它的最基本的任务就是明确需求,并使项目团队和用户
达成共识,即建立需求基线。另外,还要建立需求跟踪能力联系链,确保所有用户需
求都被正确地应用,并且在需求发生变更时,能够完全地控制其影响范围,始终保持产
品与需求的一致性。(掌握)
5、需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。
6、需求管理计划的内容:
①如何规划、跟踪和汇报各种需求活动
②需求管理需要使用的资源
③培训计划
④项目干系人参与需求管理的策略
⑤判断项目范围与需求不一致的准则和纠正规程
⑥需求跟踪结构
⑦配置管理活动
(掌握)

收集需求

1、需求包括业务需求、干系人需求、解决方案需求、过渡需求、项目需求和质量需求。

 

2、收集需求的工具与技术有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。

 

收集需求的工具和技术简单总结

 

①访谈:
通过与干系人直接交谈来获取信息。典型做法是向被访者提出预设和即兴的问
题,并记录他们的回答。
访谈分类:
结构化一事先准备好一系列问题,有针对地进行;
非结构化一只列出一个粗略的想法,根据访谈具体情况发挥。
关键词:
直接交谈、预设和即兴问题、深入了解、一对一、一对多、获取机密和敏感的信息

②焦点小组:
由一位受过训练的主持人引导预先选定的干系人和主题专家(SME)进行互动式讨论。
焦点小组的参加者往往是同职能,同一领域、或有相似背景条件的人
是“一对多”的群体访谈,最终是为了获取整个焦点小组更有价值的集体意见。
关键词:
同职能、同一领域、有相似背景、主题专家(SME)、主持人、互动式讨论

引导式研讨会

 

群体创新技术

 

思维导图/亲和图/多标准决策分析/德尔菲技术

 

群体决策

★⑤群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术
可用来开发产品需求,以及对产品需求进行归类和优先排序。
达成群体决策的方法有:
①一致同意  所有人都同意某个行动方案。
②大多数原则  获得群体中50%以上的人的支持,就能做出决策。
③相对多数原则  根据群体中相对多数者的意见做出决定,即便未能获得一部分人的支持。
通常在候选项超过两个时使用该原则。
④独裁  由某一个人(例如,项目经理)为群体做出决策。

3、收集需求过程的主要输出有需求文件和需求跟踪矩阵。
需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件,也可以是
一份包括内容提要、细节描述和附件等的详细文件。(了解)

收集需求的方法

 

 

4、需求文件的内容包括:
①业务需求
②干系人需求
③解决方案需求
④项目需求
⑤过渡需求
⑥与需求有关的假设条件、依赖关系和制约因素。(了解)
5、需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动,包括控制需
求基线,保持项目计划与需求一致,控制单个需求和需求文档的版本情况,管理需求和
联系链之间的联系,或管理单个需求和项目其他可交付物之间的依赖关系,跟踪基线中
需求的状态。(了解)
6、可跟踪性是项目需求的一个重要特征,需求跟踪是将单个需求和其他元素之间的依
赖关系和逻辑联系建立跟踪,这些元素包括各种类型的需求、业务规则、系统组件,以
及帮助文件等。可验证性是需求的最基本特性(了解)

7、每个配置项的需求到其涉及的产品(或构件)需求都要具有双向可跟踪性。所谓
双向跟踪,包括正向跟踪和反向跟踪
正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品(成果)中找到对应点;
反向跟踪也称为逆向跟踪,是指检查设计文档、产品构件、测试文档等工作成果是否
都能在需求文件中找到出处。
具体来说,需求跟踪涉及五种类型,如图,箭头表示需求跟踪能力联系链,它能跟踪
需求使用的整个周期,即从需求建议到交付的全过程。(掌握)

需求跟踪矩阵

 

定义范围

1、定义范围是制定项目和产品详细描述的过程,是明确所收集的需求哪些将包含在项
目范围内,哪些将排除在项目范围外,从而明确产品、服务或成果的边界。(掌握)
2、定义范围工具与技术:
专家判断、产品分析、备选方案生成和引导式研讨会。(掌握)
①产品分析:
对于那些以产品为可交付成果的项目,是一种有效的工具。
②备选方案生成:
用来指定尽可能多的潜在可选方案的技术,用于识别执行项目工作的不同方法
3、项目范围说明书的内容:
①产品范围描述
②验收标准
③可交付成果
④项目的除外责任
⑤制约因素
⑥假设条件(掌握)
项目经理向干系人说明项目范围时,应以项目范围说明书为依据
项目范围说明书在“可交付物”层次上明确了要完成项目需要做的相应工作;
4、项目范围说明书的主要作用:
①确定范围
②沟通基础
③规划和控制依据
④变更基础
⑤规划基础(了解)

创建工作分解结构(WBS)

1、创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程
2、里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要
的里程碑是基线(掌握)
3、工作包应便于完整地分派给不同的人或组织单元,所以要求明确各工作单元直接
的界面。工作包应该非常具体,以便承担者能明确自己的任务、努力的目标和承担的责
任。作为一种经验法则,8/80规则(80小时原则)建议工作包的大小应该至少需要8小
时来完成,而总完成时间也不应该大于80小时(掌握)

范围基准:

经过批准的项目范围说明书、WBS、WBS词典,只有通过正式的变更控制程序才能进行变更

,它被用作比较的基础。

项目范围说明书:

是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围,包括项目和产品范围。

WBS:

全部工作范围的层级分解(有助于防止范围蔓延)

WBS词典:

针对每个WBS组件,详细描述可交付成果、活动和进度信息的文件(有助于评价变更的影响)

4、控制账户是一种管理控制点。在该控制点上,将范围、预算(资源计划)、实际成本和进度加以整合,
并将它们与挣值进行比较,以侧量绩效。控制账户是WBS某个层次上的要素,既可以是工
作包,也可以是比工作包更高层次上的一个要素。如果是后一种情况,一个控制账户中就包括若干个工作包,
但一个工作包仅属于一个控制账户。项目管理团队在控制账户上考核项目的执行情况,即
在控制账户的相应要素下,将项目执行情况与计划情况进行比较,以便评价执行情况好坏,并发现与纠正偏差。(掌握)
5、规划包是指在控制账户之下,工作内容已知但尚缺详细进度活动的WBS组成部分。规划包是在控制账户之下、工作包之上的WBS
要素。规划包是暂时用来做计划的,随着情况的逐渐清晰,规划包
最终将被分解成工作包以及相应的具体活动。(掌握)

6、WBS词典也称为WBS词汇表,它是描述WBS各组成部分的文件。对于WBS的每一
组成部分,WBS词典可能包括账户编码标识、工作描述、假设条件和制约因素、负
责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、
验收标准、技术参考文献、协议信息等。(掌握)
(WBS字典实际是相当于新华字典,是对WBS中每个元素的描述)

7、分解是一种将项目可交付成果和项目工作分解成较小的、更易于管理的组件的技术。

8、要将整个项目工作分解为工作包,需要开展以下活动:(掌握)
①识别和分析可交付成果及相关工作。
②确定WBS的结构和编排方法。
③自上而下逐层细化分解。
④为WBS组件制定和分配标识编码。
⑤核实可交付成果分解的程度是恰当的
9、创建WBS时对工作的划分原则包括:
①功能或者技术原则。在创建WBS时,需要考虑将不同人员的工作分开。
②组织结构
③系统或者子系统。总的系统划分为几个主要的子系统,然后对每个子系统再进行分解。

 

11、WBS不是某个项目团队成员的责任,应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。

12、WBS表示形式有分级的树型结构(组织结构图式)和表格形式(列表式)。
树型结构图的WBS层次清晰、直观性和结构性强,但不容易修改,对大的、复杂的项
目很难表示出项目的全貌(小项目)。
表格形式的直观性比较差,但能够反映出项目所有的工作要素(大项目)。(掌握)
13、虽然有些参考文献也使用鱼骨图形式的WBS,但这种形式并不常用。

14、WBS分解注意8个方面:(掌握)
①WBS必须是面向可交付成果的。
②WBS必须符合项目的范围。
③WBS的底层应该支持计划和控制
④WBS中的元素必须有人负责,而且只由一个人负责,尽管实际上可能需要多个人参与。
⑤WBS的指导,WBS应控制在4-6层。
⑥WBS应包括项目管理工作(因为管理是项目具体工作的一部分),也要包括分包出去的工作。
⑦WBS的编制需要所有(主要)项目干系人的参与,需要项目团队成员的参与。
⑧WBS并非是一成不变的。在完成了WBS之后的工作中,仍然有可能需要对WBS进行修改。

确认范围

1、确认范围是正式验收项目己完成的可交付成果的过程。确认范围包括与客户或发起
人一起审查可交付成果,确保可交付成果已圆满完成,并获得客户或发起人的正式验收。
(了解)
2、确认范围的主要工具与技术是检查和群体决策技术。检查也称为审查、评审、审
计、走查、巡检、测试等,是指开展测量、审查与确认等活动,来判断工作和可交付成
果是否符合需求和产品验收标准。(掌握)
3、确认范围应该贯穿项目的始终。

4、确认范围的步骤:(掌握)
①确定需要进行范围确认的时间。
②识别范围确认需要哪些投入。
③确定范围正式被接受的标准和要素。
④确定范围确认会议的组织步骤。
⑤组织范围确认会议。

5、范围确认时,一般需要检查以下问题:(了解)
①可交付成果是否是确定的、可确认的。
②每个可交付成果是否有明确的里程碑,里程碑是否有明确的、可辫别的事件
③是否有明确的质量标准
④审核和承诺是否有清晰的表达。
⑤项目范围是否覆盖了需要完成的产品或服务进行的所有活动,有没有遗漏或者错误。
⑥项目范围的风险是否太高,管理层是否能够降低可预见的风险发生时对项目的冲击。

7、核实产品是针对产品是否完成,在项目(或阶段)结束时由发起人或客户来验证,
强调产品是否完整;确认范围是针对项目可交付成果,由客户或发起人在阶段末确认验
收的过程。


9、确认范围与项目收尾的不同之处在于:(掌握)
①虽然确认范围与项目收尾工作都在阶段末进行,但确认范围强调的是核实与接受可交
付成果,而项目收尾强调的是结束项目(或阶段)所要做的流程性工作。
②确认范围与项目收尾都有验收工作,确认范围强调验收项目可交付成果,项目收尾强
调验收产品。
10、范围确认完成时,同时应当对确认中调整的WBS及WBS字典进行更新。
11、范围确认和需求确认一定要分开。需求确认是在项目前期3方通过召开需求评审会
的方式讨论从而形成一个需求说明书,确认需求;范围确认是阶段性的验收。(了解)

控制范围

1、控制范围是监督项目和产品的范围状态、管理范围基准变更的过程,其主要作用
是在整个项目期间保持对范围基准的维护。对项目范围进行控制,就必须确保所有请求
的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际
发生时,也要采用范围控制过程来管理这些变更。(掌握)
2、造成项目范围变更的原因是项目外部环境发生了变化,例如:(了解)
①政府政策的问题。
②项目范围的计划编制不周密详细,有一定的错误或遗漏。
③市场上出现了或是设计人员提出了新技术、新手段或新方案。
④项目执行组织本身发生变化。
⑤客户对项目、项目产品或服务的要求发生变化。

3、未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)称为范
围蔓延。【客户不断提出要求,不断去改,最终交付物不满足要求!镀金项目实施人
员往往愿意尝试新的技术或者为信息系统项目加上】变更是不可避免的,控制范围过程
依赖于范围变更控制系统,范围变更控制是指对有关项目范围的变更实施控制,审批项
目范围变更的一系列过程,包括书面文件、跟踪系统和授权变更所必须的批准级别
(了解)

4、范围变更控制的工作:(掌握)
①影响导致范围变更的因素,并尽量使这些因素向有利的方面发展。
②判断范围变更是否已经发生。
③范围变更发生时管理实际的变更,确保所有被请求的变更按照项目整体变更控制过程处理

5、项目管理中变更是极其普遍的现象,对变更要进行管理。项目范围的核心是产品围,
因此,产品的需求发生变化其实就是一种范围变更。需求的核心是客户的需求,无论需
求识别还是需求变更都要让客户参与。范围管理是整体管理的一部分,变更流程可统一
设计,统一管理,因此没必要必须把范围变更与整体变更区分开来。(了解)

6、项目范围变更控制,包括审批项目范围变更的一系列过程,包括书面文件、跟踪系统和授权变更所必须的批准级别;

项目范围管理案例分析

 


 

标签:需求,WBS,信息系统,项目,项目管理,确认,考点,变更,范围
来源: https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/116522120

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有