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