配置
CMDB: 配置管理库
配置项的操作权限应该有配置管理员CMO严格管理
基线配置项向开发人员开放读取权限
非基线配置项向项目经理、CCB以及相关人员开放；
配置项状态
草稿 -> 评审后 -> 正式 -> 修改 -> 评审后 -> 正式
0.yz 草稿 0开头的都是草稿
x.y 正式
x.yz 修改
基线变更必须走变更流程；产品的一个测试版本也是基线
发行基线：给客户使用的
构造基线：内部使用的
配置管理数据库：
配置库：存放配置项的
开发库：动态库、程序员库、工作库。保存开发人员当前正在开发的配置实体；由开发人员自行控制，无需进行配置控制
受控库：主库。当前基线+基线的变更。开发阶段结束时，把当前工作产品存入受控库。可以修改，要走变更流程 CMO
产品库：静态库、发行库、软件仓库；最终产品存入。一般不再修改，要修改必须走变更流程
建库模式：
按配置项类型：通用软件开发组织。产品继承性较强，工具单一，并行开发
按开发任务建立：
角色与职责：
CCB：配置管理员委员会
配置管理负责人：配置经理，负责管理和决策整个项目中的配置活动。
配置项管理员：CMO 负责配置管理的主要实施活动
配置项负责人：负责配置项的准确和真实
管理活动：
制定配置管理计划：CMO写，CCB审批
配置项识别：
配置项控制：CCB负责变更申请的评估，决定是否变更
配置状态报告、
配置审计：
功能审计：一致性，实际功能与需求一致
圆满完成
达标
文档符合要求
物理审计：完整性，配置项的物理存在是否与预期一致
要交付的配置项是否存在
配置项中包含了所有项目信息
配置管理回顾与改进：
变更
原因：
产品范围
项目范围
增值变更
应对风险的紧急计划或回避计划
执行过程与基准要求不一致带来的被动变更
外部事件
分类：
重大变更、重要变更、一般变更 （不同的审批权限）
紧急变更、非紧急变更
每次变更后需要重新确定基准
变更需要遵循流程
项目经理在变更中的作用：
响应变更需求
评估变更对项目的影响及应对方案
把需求有技术要求转变为资源需求，供授权人决策；
评估实施结果，确保项目基准反应项目实际情况
变更管理负责人：变更经理
变更请求者：
提交初步的变更方案和计划
初步评价变更影响和风险
对理解变更过程有能力要求
变更实施者：
有实施变更的技术能力
负责按照计划实施变更
变更顾问委员会：变更控制委员会 CCB
负责对重大变更的审批
紧急变更时，行使审批权限
定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议
变更申请：
评估前需要以书面形式提出、任何人都能提，项目经理或CMO收集变更，并完成初审
变更流程：
变更申请
变更初审
变更方案论证
变更审查 CC B负责组织评估，决定是否实施变更，并通知相关人员
发出通知并实施 项目经理组织修改配置项
实施监控
效果评估 项目经理制定人员验证测试，提交给CCB确认是否按要求完成
变更收尾 配置管理员将变更后的配置项纳入基线
文档管理：
开放文档：可研报告
产品文档：培训手册
管理文档：进度和进度变更记录，项目计划
文档质量级别
最低限度文档 一级：一人月自用
内部文档
工作文档：有外部人员参与了
正式文档：公开的文档
1297
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
