思维导图，【中级职称】项目集成管理工程师（新版教材） 第15章、组织保障
2024-10-16 01:37:39 0 举报AI智能生成
第15章、组织保障，介绍了项目组织结构和职责分配对于项目管理的重要性。主要内容包括：项目组织结构、组织结构模式、项目管理组织结构、组织结构的调整和组织结构的考核与评价。该章节还强调了组织结构的设计原则，包括目标明确、职责清晰、分工协作、流程通畅和有效沟通。此外，还介绍了组织结构的考核与评价标准，包括质量、成本、工期、安全、环境、满意度和综合绩效等。同时，也强调了组织结构在项目不同阶段的调整，以及针对项目组织结构问题所应采取的措施。最后，强调了项目经理在组织结构中的核心地位和职责。
作者其他创作
大纲/内容
1、信息和文档管理
1.1、信息系统相关信息（文档）是指某种数据媒体和其中所记录的数据
1.2、信息和文档
1.2.1、信息系统信息
1、用户信息
2、业务信息
3、经营管理信息
4、系统运行信息
1.2.2、信息系统文档
1、开发文档
1.1、可行性研究报告和项目任务书
1.2、需求规格说明书
1.3、功能规格说明书
1.4、设计规格说明书，包括程序和数据规格说明
1.5、开发计划
1.6、软件集成和测试计划
1.7、质量保证计划
1.8、安全和测试信息
2、产品文档
2.1、培训手册
2.2、参考手册和用户指南
2.3、软件支持手册
2.4、产品手册和广告
3、管理文档
3.1、开发过程的每个阶段的进度和进度变更的记录
3.2、软件变更情况的记录
3.3、开发团队的职责定义
3.4、项目计划、项目阶段报告
3.5、配置管理计划
1.3、信息（文档）管理规则和方法
1.3.1、信息（文档）编制规范
图表编号规则
1.3.2、信息（文档）定级保护
1、影响对象
1.1、个人、法人和其他组织的合法权益和经济利益
1.2、社会秩序、公共利益
1.3、国家安全
2、侵害影响程度
2.1、无影响
2.2、造成一般损害
2.3、造成严重损害
2.4、造成特别严重损害
1.3.3、信息（文档）配置管理
1、配置管理
1.1、配置库的建立
1.2、配置管理数据库（CMDB）准确性的维护
2、变更类型
2.1、主动变更
常用于提高项目收益、包括降低成本、改进过程以及提高项目的便捷性和有效性等
2.2、被动变更
常用于范围变化、异常、错误和适应不断变化的环境等
2、配置管理
2.1、基本概念
2.1.1、配置项（Configuration Item，CI）
1、定义：为配置管理设计的硬件、软件或两者的集合，它在配置管理过程中作为一个单一的实体来对待
2、典型的配置项
2.1、项目计划书
2.2、技术解决方案
2.3、需求文档
2.4、设计文档
2.5、源代码
2.6、可执行代码
2.7、测试用例
2.8、运行软件所需的各种数据
2.9、设备型号及其关键部件
3、管理基本原则
3.1、基线配置项向开发人员开放读取的权限
3.2、非基线配置项向项目经理、CCB及相关人员开放
2.1.2、配置项状态
1、草稿
配置项刚建立时
2、正式
配置项通过评审后
3、修改
更改配置项时
2.1.3、配置项版本号
1、草稿
为0.YZ，YZ的数字取值范围为01-99
2、正式
2.1、为XY，X为主版本号，取值范围为1-9；Y为次版本号，取值范围为0-9
2.2、配置项的Y值可适量增加，Y值增加到一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值
3、修改
3.1、为X.YZ,配置项在修改时，一般只增大Z值，X、Y保持不变
3.2、当配置项修改完毕，状态成为“正式”时，将Z值设为0，并且增大X.Y值
2.1.4、配置项版本管理
1、对配置项的任何修改都将产生新的版本
2、由于我饿们不能保证新版本一定比旧版本好，所以不能抛弃旧版本
2.1.5、配置基线
1、指一个产品或系统在某一特定时刻的配置状况
2、基线通常对一个与项目过程中的里程碑，一个项目可以有多个基线，也可以只有一条基线
3、交付给用户使用的基线一般称为发行基线，内部过程使用的基线一般称为构造基线
4、建立基线的价值
4.1、基线为项目工作提供一个顶点和快照
4.2、新项目可以在基线提供的定点上建立
4.3、当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法
4.4、可以利用基线重新建立基于某个特定发布版本的配置，以重现一报告的错误
2.1.6、配置管理数据库
1、发布内容，包括每个配置项以及版本号
2、经批准的变更可能影响到配置项
3、与某个配置项有关的所有变更请求
4、配置项的变更轨迹
5、特定的设备和软件
6、计划升级、替换或弃用的配置项
7、与配置项有关的变更和问题
8、来自于特定时期特定供应商的配置项
9、受问题影响的所有配置项
2.1.7、配置库
1、类型
1.1、开发库
1.1.1、也成为动态库、程序员库或工作库
1.1.2、用于保存开发人员当前正在开发的配置实体
1.1.3、开发人员的个人工作区
1.2、受控库
1.2.1、也成为主库
1.2.2、包含当前的基线加上对基线的变更，配置项被置于完全的配置管理下
1.2.3、工作结束时，将当前的工作产品存入受控库
1.3、产品库
1.3.1、也成为静态库、发行库、软件仓库
1.3.2、包含已发布使用的各种基线存档，被置于完全的配置管理之下
1.3.3、作为最终产品存入产品库内，等待交付用户或现场安装
2、建库模式
2.1、按配置项类型建库
适用于通用软件的开发组织
产品的继承性较强，工具比较统一，对并行开发有一定的需求
2.2、按开发任务建库
适用于专业软件的开发组织
使用的开发工具种类繁多，开发模式以线性发展为主
2.2、角色与职责
2.2.1、配置控制委员会CCB
1、制定和修改项目配置管理策略
2、审批和发布配置管理计划
3、审批基线的设置、产品的版本号等
4、审查、评价、批准、推迟或否决变更申请
5、监督已批准变更的实施
6、接收变更与验证结果，确认变更是否按要求完成
7、根据配置管理报告决定相应的对策
2.2.2、配置管理负责人
1、管理所有活动，包括计划、识别、控制、审计和回顾
2、负责配置管理过程
3、通过审计过程确保配置管理数据库的准确和真实
4、审批配置库或配置管理数据库的结构性变更
5、定义配置项责任人
6、指派配置审计员
7、定义配置管理数据库的范围、配置项属性、配置项之间的关系和配置项状态
8、评估配置管理过程并持续改进
9、参与变更管理过程评估
10、对项目成员进行配置管理培训
2.2.3、配置管理员
1、建立和维护配置管理系统
2、建立和维护配置库或配置管理数据库
3、配置项识别
4、建立和管理基线
5、版本管理和配置控制
6、配置状态报告
7、配置审计
8、发布管理和交付
2.2.4、配置项负责人
1、记录所负责配置项的所有变更
2、维护配置项之间的关系
3、调查审计中发现的配置项差异，完成差异报告
4、遵从配置管理过程
5、参与配置管理过程评估
2.3、目标与方针
2.3.1、管理目标
1、管理的配置信息
1.1、所有配置项能够被识别和记录
1.2、维护配置项记录的完整性
1.3、威奇塔管理过程提供有关配置项的准确信息
1.4、核实有关信息系统的配置记录的正确性并纠正发现的错误
1.5、配置项当前和历史状态得到汇报
1.6、确保信息系统的配置项的有效控制和管理
2、目标
1、确保软件配置管理计划得以制定，并经过相关人员的评审和确认
2、应该识别出要控制的项目产品有哪些，并且制定相关控制测罗，以确保这些项目产品被合适的人员获得
3、应制定控制策略，以确保项目产品在受控制范围内更改
4、应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件的基线状态和内容
2.3.2、管理方针
关键成功因素
1、所有配置项应该记录
2、配置项应该分类
3、所有配置项要进行编码
4、应该定期对配置库或配置管理数据库中的配置项进行审计
5、每个配置项在建立后，应该有配置负责人负责
6、要关注配置项的变化情况
7、应该定期对配置管理进行回顾
8、能够与项目的其他管理活动进行关联
2.4、管理活动
2.4.1、制定配置管理计划
配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态
2.4.2、配置项识别
基本步骤
1、识别需要受控的配置项
2、为每个配置项指定唯一的标识号
3、定义每个配置项的重要特征
4、确定每个配置项的所有者及其责任
5、确定配置项进入配置管理的时间和条件
6、建立和控制基线
7、维护文档和组件的修订与产品版本之间的关系
2.4.3、配置项控制
1、变更申请
2、变更评估
2.1、变更对项目的影响
2.2、变更内容是否必要
2.3、变更的范围是否考虑周全
2.4、变更的实施方案是否可行
2.5、变更工作量估计是否合理
3、通告评估结果
CCB吧关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人
4、实施变更
项目经理组织修改并记录
5、变更验证与确认
项目经理指定人员对变更后的配置项进行测试或验证
6、变更的发布
配置管理员将变更后的配置项纳入基线
7、基于配置库的变更控制
7.1、基于配置库的变更控制
7.2、操作步骤
1、将待升级的基线从产品库取出，放入受控库（假设版本号为V2.1）
2、程序员将预修改的代码片段从受控库中检出（Check out）放入自己的开发库中进行修改
3、程序员将开发库中修改的代码检入受控库（Check in）
4、软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库
2.4.4、配置状态报告
有效的记录和报告管理配置所需要的信息，目的是及时、准确的给出配置项的当前状况，供相关人员了解，以加强配置管理工作
2.4.5、配置审计
1、功能配置审计
1.1、配置项的开发已圆满完成
1.2、配置项已达到配置标识中规定的性能和功能特征
1.3、配置项的操作和支持文档已完成并且符合要求等
2、物理配置审计
2.1、要交付的配置项是否存在
2.2、配置项中是否包含了所有必须的项目等
2.4.6、配置管理回顾与改进
1、对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议
2、召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行汇报，听取各方意见，回顾上次过程改进计划执行情况
3、根据会议结论，制定并提交服务改进计划
4、根据过程改进计划，协调落实改进等
3、变更管理
3.1、基本概念
3.1.1、项目变更的含义
在信息系统项目的实施过程中，由于项目环境或其他的原因而对项目的功能、性能、架构、技术指标、集成方法和项目进度等方面作出的改变
3.1.2、变更产生的原因
1、产品范围（成果）定义的过失或者疏忽
2、项目范围（工作）定义的过失或疏忽
3、增值变更
4、应对风险的紧急计划或回避计划
5、项目执行过程与基准要求不一致带来的被动调整
6、外部事件等
3.1.3、变更分类
1、根据变更性质
1.1、重大变更
1.2、重要变更
1.3、一般变更
2、根据变更的迫切性
2.1、紧急变更
2.2、非紧急变更
3、根据行业特征
3.1、产品（工作）范围变更
3.2、环境变更
3.3、设计变更
3.4、实施变更
3.5、技术标准变更
3.1.4、变更管理原则
1、基准管理
2、变更控制流程化
3、明确组织分工
4、与干系人充分沟通
5、变更的及时性
6、评估变更的可能影响
7、妥善保存变更产生的相关文档
3.1.5、变更管理与相关活动的关系
1、与项目整合管理的关系
1.1、变更管理是项目整合管理的一部分，实施项目整体变更控制过程贯穿项目始终
1.2、一旦确定了项目基准，就必须通过变更管理来处理变更请求
2、与配置管理的关系
2.1、对配置项的任何变更都应该提出变更请求，并经过变更控制
2.2、变更管理过程中包含的部分配置管理活动
2.2.1、配置项识别
2.2.2、配置状态记录
2.2.3、配置确认与审计
3.2、角色与职责
3.2.1、变更控制委员会（CCB）
1、负责审查、评价、批准、推迟或否决项目变更
2、将变更的申请、否决或推迟的决定通知受此处置意见影响的相关干系人
3、接收变更与验证结果，确认变更是否按要求完成
3.2.2、变更管理负责人
1、负责整个变更过程方案的结果
2、负责变更管理过程的监控
3、负责协调相关资源，保证所有变更按照预定过程顺利运作
4、确定变更类型，组织变更计划和日程安排
5、管理变更的日程安排
6、变更实施完成后的回顾和关闭
7、承担变更相关责任，并且具有相应权限
8、可能以逐级审批的形式或团队会议的形式参与变更的风险评估和审批等
3.2.3、变更请求者
1、提出变更需求，记录并提交变更请求单
2、初步评价变更的风险和影响，给变更请求设定适当的变更类型
3.2.4、变更实施者
1、负责按照变更计划实施具体的变更任务
2、负责记录并保存变更过程中的产物，将变更后的基准纳入项目基准中
3、参与变更正确性的验证与确认工作
3.2.5、变更顾问委员会
1、在紧急变更时，可以对被授权者行使审批权限
2、定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进意见
3.3、工作程序
3.3.1、变更申请
1、项目的干系人都可以提出变更申请
2、一般项目经理或项目配置管理员负责相关信息的收集，以及对变更申请的初审
3.3.2、对变更的初审
初审的目的
1、对变更提出方施加影响，确认变更的必要性，确保变更时更有价值的
2、格式校验，完整性校验，确保评估所需信息准备充分
3、在干系人间提出供评估的变更信息达成共识等
3.3.3、变更方案论证
3.3.4、变更审查
3.3.5、发出通知并实施
3.3.6、实施监控
3.3.7、效果评估
评估关注的内容
1、评估依据是项目的基准
2、结合变更的初衷来看，变更所有达到的目的是否已经达成
3、评估变更方案中的技术论证、经济论证内容与实施过程的差距并触发解决
3.3.8、变更收尾
判断发生变更后的项目是否已纳入正常轨道
3.4、变更控制
3.4.1、变更申请的控制
3.4.2、变更内容的控制
1、对进度变更的控制
1.1、判断当前项目进度状态
1.2、对造成进度变化的因素施加影响
1.3、查明进度是否已经改变
1.4、在实际变化出现时对其进行管理
2、对成本变更的控制
2.1、对造成费用基准变更的因素施加影响
2.2、确保变更请求获得同意
2.3、当变更发生时，管理这些实际的变更
2.4、保证潜在的费用超支不超过授权的项目阶段资金和总体资金
2.5、监督项目费用绩效，找出与费用基准的偏差
2.6、准确记录所有的与费用基准的偏差
2.7、防止错误的、不恰当的或未批准的变更被纳入费用或资源的使用报告中
2.8、就审定的变更，通知利害关系人
2.9、采取措施，将预期的费用超支控制在可接受的范围内
2.10、控制项目费用，查找造成正、负偏差的原因
3、对合同变更的控制
1、规定合同修改的过程
2、应道与整体变更控制结合起来
3.4.3、变更类型的控制
1、标准变更的控制
1.1、通常是低风险、预先授权的变更
1.2、不需要额外授权的情况下实现
2、正常变更的控制
2.1、通常是常规的、较低风险的变更
2.2、通过已确定的变更授权角色和变更管理流程进行管理
3、紧急变更的控制
3.1、通常不包括在变更计划里
3.2、在需要时可以精简
3.4.4、变更输入输出的控制
1、变更的输入控制
1.1、项目控制变更的基准、项目计划、配置管理计划、项目文件和组织过程资产等
1.2、变更前的项目工作绩效报告
1.3、提出的变更请求和变更方案等
2、变更的输出控制
2.1、批准的变更请求
2.2、更新的项目基准、更新的项目计划、配置管理计划、项目文件和变更日志
2.3、变更后的项目工作绩效报告，对比变更执行效果
2.4、共享经验教训，时期成为本项目和实施组织内其他项目历史数据的组成部分
3.5、版本发布和回退计划
3.5.1、版本发布前的准备工作
1、进行相关回退分析
2、备份版本发布所涉及的存储过程、函数等其他数据存储及回退管理
3、备份配置数据，包括数据备份方式
4、备份在线生产平台接口、应用和工作流等版本
5、启动回退机制的触发条件
6、对变更回退的机制责任的说明，如通知相关部门，确定需要回退的关联系统和回退时间点登
3.5.2、回退步骤
1、通知相关用户系统开始回退
2、通知各关联系统进行版本回退
3、回退存储过程等数据对象
4、配置数据回退
5、应用接口、应用程序、工作流等版本回退
6、回退完成通知各周边关联系统
7、回退后进行相关测试，保证回退系统能够正常工作
8、通知用户回退完成等
0 条评论
下一页
为你推荐
查看更多
