软考系统集成2：范围管理
2022-06-15 19:25:13 30 举报AI智能生成
登录查看完整内容
【软考：系统集成项目工程师】希望这个系列的文件可以帮到大家！
作者其他创作
大纲/内容
依据“项目管理计划”中已批准的子计划
项目管理计划
依据其中的项目背景信息来规划各个范围管理过程
高层级的项目描述
出自项目工作说明书
产品特征
提供了
项目章程
政策
程序
历史信息
经验教训知识库
组织过程资产
组织文化
基础设施
人事管理制度
市场条件
事业环境因素
输入
指定范围管理计划
目的
项目经理
项目发起人
团队成员
干系人
范围管理各过程的负责人
与会人员
会议
专家判断
工具与技术
需求说明书的编制方法、要求
描述了如何定义、制定、监督、控制、确认项目范围
是“项目管理计划”的组成部分
是制定“项目管理计划过程”、其他范围管理过程的主要依据
特点
范围管理计划
描述了如何分析、记录、管理需求，阶段与阶段之间的关系对管理需求的影响
需求管理计划
输出
外框
过程
编制范围管理计划过程
使团队知道应该如何确定所需收集的需求的类型
以便定义干系人的需要
规定了用于“收集需求”过程的工作流程
评估、试运营干系人的参与程度
了解干系人的沟通需求、参与程度
干系人管理计划
据此收集详细的需求
了解项目产品、服务、成果的高层级描述
了解哪些干系人可以提供需求信息
干系人登记册
通过与干系人直接交谈来获取信息的正式 / 非正式 的方法
访谈
召集干系人、专家，了解他们对产品、服务、成果的期望和态度
焦点小组
召集主要干系人，讨论，定义产品需求
快速定义跨职能需求和协调干系人差异的重要技术
有助于参与者之间建立信任、改善沟通，从而达成一致意见
比单项会议更早发现问题，更快解决问题
引导式研讨会
识别项目和产品需求
本身不包含投票/排序
头脑风暴法
排列最有用的创意，一边进一步开展头脑风暴/优先排序
名义小组技术
以反映创意之间的共性、差异
概念/思维导图
对大量创意进行分组，进一步审查分析
亲和图
风险水平
不确定性
价值收益
借助决策矩阵，建立多种标准。从而评估、排序方案
多标准决策分析
常用的技术
群体创新技术
为达成某种期望结果，对多个未来行动方案进行评估
生产产品需求
对产品需求进行归类、优先级排序
作用
群体决策技术
设计一系列书面问题，向众多受访者快速收集信息
受众多样化
需要快速完成调查
受访者地理位置分散
适合开展统计分析
适用场景
问卷调查
直接查看个人在各自的环境中如何执行工作、实施流程
观察（工作跟踪）
在实际制造产品前，先造出该产品的使用模型，并据此征求对需求的早起反馈
渐进明细、反复循环
原型法
将计划的做法与其他可比组织的做法比较
识别最佳实践
形成改进意见
为绩效考核提供依据
优点
标杆对照
对产品范围的可视化描绘，显示业务系统、与人和其他系统的交互方式
系统交互图
通过分析现有文档，识别与需求相关的信息，来挖掘需求
文件分析
描述单一需求将如何满足与项目相关的业务需求
按干系人、优先级分类列出全部需求
简单
包括内容提要、细节描述、附件等
详细
格式
业务需求
干系人需求
解决方案需求
项目需求
过渡需求
与需求相关的假设条件、依赖关系、制约因素
主要内容
需求文件
把产品需求从来源连接到能满足需求的可交付成果的一种表格
提供了在整个项目生命周期中跟踪需求的一种方法
需求跟踪矩阵
收集需求
明确收集的需求哪些将包含在项目范围内，哪些排除在项目范围外
制定项目、产品详细描述的过程
应该做的
不需要做的
详细定义项目的范围边界
任务
概述
需求文件 / 批准的变更申请
项目档案
旨在弄清产品范围，把对产品的要求转化成项目的要求
产品分解
系统分析
需求分析
系统工程、价值工程、价值分析
技术
产品分析
头脑风暴
横向思维
备选方案分析
来源
备选方案生成
对项目范围、主要可交付成果、假设条件、制约因素的描述
衡量项目成功的可量化标准
包括成本、进度、质量方面的具体目标
要有一定属性、计量单位、一个绝对或相对的数值
项目目标
描述了项目承诺交付的产品、服务、结果的特征
早期粗略，后期详细
产品范围描述
描述了项目承诺交付物要满足合同、标准、规范 / 其他强制性文档所必需具备的条件 / 能力
严格定义项目内包括什么，不包括什么
项目边界
在某一过程（阶段、项目）完成时，产出的任何独特的并可核实的产品、成果、服务
项目管理报告、文件
也包括辅助成果
可略可详
形式
项目的可交付成果
具体的与项目范围有关的约束条件
“项目范围说明书”的约束条件比“项目章程”中列出的多、详尽
项目的制约因素
与范围相关的假设条件，以及当这些条件不成立时对项目造成的影响
假设条件
内容
项目范围说明书
至少包括
项目文件更新
定义范围
范围说明书
项目所在行业的WBS标准
用于创建WBS的政策、程序、模板
以往项目的项目档案
以往项目的经验教训
把项目范围、可交付成果逐步划分为更小的、更便于管理的单元，直到可交付物细分到足以用来支持未来的项目活动定义的工作包
分析信息，以把可交付成果分解成更小的组成部分
分解
定义工作范围
定义项目组织
估算、控制费用
估算时间周期、安排进度
明确项目各方的工作界面
是后续管理工作的主要依据，是时间、成本、人力等管理工作的基础
形成清晰的职责使命
定义绩效考核、控制的基准
各要素应该是相对独立的，减少相互之间的交叉
逐层向下分解
100%的项目工作，不能是其他工作
相同层次的工作单元应用相同性质
最底层工作应有可比性，可管理，可定量检查
应包括项目管理工作，包括分包出去的工作
必须面向可交付成果
WBS的元素只能由一个人负责
WBS的编制需要所有干系人的参与
原则
层次清晰
直观
结构性强
不易修改
对于复杂的项目很难表示项目的全景
缺点
小的、适中的应用项目
分级的树形结构
反映出项目的所有工作要素
直观性差
大的、复杂的应用项目
表格形式
常用的表示形式
标志着某个可交付成果（阶段）的正式完成
和“可交付成果”紧密联系，但不是一个概念
报告
原型
成果
最终产品
“可交付成果”
具体时间
在这个时间应完成的事件
“里程碑”
区分
里程碑
最低层的工作单元（最底层的可交付成果）
位于工作分解结构每条分支最底层的可交付成果组成部分
1个控制账户，包括若干个工作包
1个工作包仅属于1个控制账户
在制作WBS的过程，把每个工作包分配到一个控制账户，为工作包建立唯一标识
工作包
某些概念
工作分解结构 WBS
针对每个WBS组件，详细描述可交付成果、活动、进度信息的文件
工作概述
账户编码
资源需求
管理储备
WBS词典
范围基准
创建工作分解结构WBS
正式验收已完成的项目可交付成果的过程
贯穿项目的始终
以书面文件的形式把它完成情况记录下来
使验收过程具有客观性
通过验收可交付成果，提高最终产品获得验收的可能性
有助于清楚的责任划分、任务分配
关注可交付成果的验收
“确认范围过程”
关注可交付成果的正确性、是否满足质量要求
“控制质量过程”
控制质量过程 “先于”确认范围过程，但二者也可同时进行
定义了项目已完成可交付成果的正式验收程序
WBS
工作绩效信息
工作绩效数据
合适的可交付成果
开展测量、审查、确认等活动，来判断工作、可交付成果是否符合需求、验收标准、干系人的要求期望
P287
检查（审查、产品审查、审计、巡检）
由客户/发起人 以书面形式正式签字批准
验收的可交付成果
对已完成但未通过正式验收的可交付成果、其未通过验收的原因，记录在案
变更请求
哪些可交付成果开始实施
进展如何
哪些可交付成果已经完成（验收）
包括项目进展信息
包括定义产品 / 报告产品完成情况的任何文件
确认范围
监督项目、产品的范围状态，管理范围基准变更的过程
影响导致范围变更的因素，尽量使这些因素向有力的方向发展
确认
判断范围变更是否已经发生
范围变更发生时管理实际的变更
确保所有被请求的变更按项目整体变更控制处理
工作内容
对项目中存在 / 潜在的变化采用正确的策略、方法，以降低项目的风险
未对时间、成本、资源做相应调整
未经控制的产品 / 范围的扩大
范围蔓延
客户等项目干系人只能提出范围变化的要求，但没有批准的权力，只有“项目投资人”才可以
得不到投资人的标准
他们有很多机会和客户交流，所接到的范围变化要求也最多
他们必须及时发现项目范围的变化，并报告给项目经理
如果把所有额外工作都自己承担，就很可能无法按时完成任务
项目小组未尽责任
经常遇见的问题
项目范围变更控制、管理（整体变更管理）
一定要有明确的需求变更管理控制、范围管理管制，否则很容易导致项目的失控
定义了项目的范围
每次需求变更并经过需求评审后，都要重新确定新的需求基线
随着项目进展，需求基线将会 ↑ ，容许的需求变更会 ↓
需求基线
用户需求变更
“范围控制”&&“xxxx”的联系
与“实际结果”比较，决定是否要进行变更、纠正/预防
描述了如何监督、控制项目范围
定义了管理项目变更的过程
变更管理计划
定义了哪些是配置项，哪些需要正式变更控制
配置管理计划
描述了如何分析、记录、管理项目的需求
需求应完整、明确、可跟踪、一致得到主要干系人的认可
有助于发现变更（或对范围基准的任何偏离）给项目目标造成的影响
收到的
接受的
变更请求数量
完成的可交付成果的数量
确定实际绩效、基准的差异程度、原因的技术
利用“项目绩效测量结果”评估“偏离范围基准”的程度，确定偏离范围基准的原因、程度，并决定是否需要采取纠正/预防
偏差分析
收到的变更的分类
识别的范围偏差、原因
偏差对进度、成本的影响
对将来范围绩效的预测
有关项目范围实施情况的、相互关联且与各种背景相结合的信息
是制定范围决策的基础
预防措施
纠正措施
缺陷补救
改善请求
如果批准的变更请求会对项目范围产生影响，那么范围说明书、WBS、WBS词典都要重新修订、发布
范围基准更新
如果批准的变更请求会对项目范围以外的方面产生影响
其他基准更新
造成偏差的原因
所选的纠正措施、选择理由
从项目范围控制中得到的其他经验教训
组织过程资产更新
项目管理计划更新
范围控制
主要过程
第七章项目范围管理
0 条评论
回复 删除
下一页
