配置管理过程
1. 目的
该过程用于规范项目配置管理工作，保证项目生成的工作产品在整个生命周期中的完整、一致性。
2. 适用范围
本过程适用于项目级和公司级的配置管理工作。
3. 术语和缩写
无
4. 职责
| 角色 |
职责 |
| CM工程师 |
l 编制项目的《配置管理计划》 l 定期备份配置库 l 基线建立 l 配置项变更控制 |
| 项目经理 |
l 协助CM工程师确定配置项、基线建立时间以及CCB成员 l 审批《配置管理计划》 l 执行配置审计及审计发现问题跟踪 |
| 变更发起人 |
l 填写变更申请 |
| CCB（Change Control Board, 变更控制委员会） |
l 评估需求变更影响及配置项变更范围 |
| 变更实施人 |
l 实施配置项变更 |
5. 入口准则
l 项目启动
6. 输入
l 项目总体计划
7. 过程流程图
8. 过程描述
项目立项后，CM工程师根据《项目配置管理目录》中的库结构在配置库中为项目组分配区域，建立配置管理目录。
《项目总体计划》及《项目进度安排》初稿完成后，CM工程师根据《PDP》及项目特征等信息制定《配置管理计划》，与项目经理沟通确定配置项、基线以及CCB成员。
在项目开发过程中，项目组成员根据规定使用配置库，并及时提交工作产品。CM工程师根据计划建立基线，并由项目经理审计确认。
CM工程师负责管理变更流程，确保配置项的变更受控。
CM工程师根据规定或计划定期对配置库进行备份，并妥善保管备份文件。
项目结项时，CM工程师根据《项目结项报告》，将确定需要提交组织财富库的文档放入正确位置。
1
2
3
4
8.1 建立配置库
项目立项后，CM工程师根据《项目配置管理目录》中的库结构在配置库中为项目组分配区域，建立配置管理目录。
配置库总体划分为开发库及受控库：
开发库：用于存放项目开发期间处于开发状态的相关文档及代码。
受控库：用于存放各基线包含的配置项文档。
配置库创建后，CM工程师初步为开发团队分配权限，并将配置库信息告知项目组。
8.2 制定配置管理计划
CM工程师负责编写《配置管理计划》，计划内容包括以下信息：
CCB成员 CM工程师与项目经理沟通确定CCB成员，一般包括：项目经理、CM工程师、项目关键技术人员以及产品负责人（如果有）
配置项及非配置项（数据项） CM工程师与项目经理沟通确定需要纳入基线的配置项
访问权限 配置库各目录的访问权限
基线及建立时间 CM工程师与项目经理沟通确定需要建立的基线、包含内容以及建立触发时间
备份方法 可以根据组织习惯或项目特殊情况确定备份方法
纸质文档管理方法 确定纸质文档在开发过程以及结项之后的保存方法
计划编写完成后，CM工程师提交项目经理审核，并通过计划评审（见《项目管理过程》）。计划评审后，CM工程师根据计划对配置库设置进行调整。
8.3 日常配置库使用
8.3.1 文档命名
项目组成员创建文档记录时，根据以下方式对文档进行命名：
项目名_文档名称
项目名：项目立项时的项目名称或项目编号
文档名称：文档原始模板名称
例如AL83项目的总体计划文件名为“AL83_项目总体计划”。
8.3.2 文档版本管理
对于可能修改多次的技术文档（如需求规格说明书、概要设计等）及管理文档（项目计划），需要在文档中使用修订履历对其版本变更情况进行记录。
其版本的编号规则如下：
V0.1 创建
V0.x 评审前的修改
V1.0 通过评审
V1.x 评审后的修改
V2.0 文档内容变更较大，需要再次正式评审
8.3.3 文档Check In
对于源代码及设计开发文档，要求编写负责人每天在下班前check in 配置库。
8.4 建立基线
基线是项目储存库中配置项在特定时期的一个“快照”，它由一组确定的配置项组成。基线中的文档应该是已经通过验证（测试或评审）的，或者下阶段工作需要以其为基础的工作产品。
CM工程师根据《配置管理计划》中确定的基线建立触发时间建立基线。
基线建立步骤如下：
CM工程师填写《基线记录表》
CM工程师将该基线包含的配置项从开发库提取到受控库的相应位置
项目经理及CM工程师对已建立基线进行配置审计，检查配置项的正确性。（详见4.6配置审计）
8.5 变更控制
该小节仅描述配置管理变更控制程序。
配置管理变更控制是指对纳入基线的配置项变更进行评估、跟踪及控制的一系列活动，可能由需求变更、设计变更或计划变更引起。关于需求变更流程，请参见《需求开发及管理流程》。
配置管理变更遵循以下流程：
变更申请
当配置库中确定（通过评审或测试通过）的配置项在项目需求发生变化或相关人员发现原先配置项存在问题的情况下，由变更提出者向CCB提出变更申请。CCB对项目的类别、规模、变更类型以及受影响的变更类型等进行识别，填写《变更记录表》上的各项相关内容(参见模板)。
变更评估
评估内容可从涉及变更的配置项、变更工作量、成本、可能的风险以及影响范围等方面考虑，在评估基础上进行变更审批后，评估、审批结果填入《变更记录表》。
变更跟踪
变更实施结果需经CM工程师验证，若验证不通过则由CM工程师通知变更实施人及相关人员，并跟踪直至验证通过，验证结果由配置管理填入《变更记录表》。
如变更后需建立基线，参见4.4建立基线。
8.6 配置审计
配置审计包括配置库审计及基线审计，审计依据《配置管理计划》中的配置审计时间安排及《配置审计表》进行。
配置审计类型包括以下三类：
配置管理审计
该审计验证配置管理记录以及配置项完整性、一致性及正确性。
物理审计
该审计验证配置项与构建产品与技术文档的一致性。
功能审计
该审计验证配置项与待测试产品的功能特征与需求的一致性，以及操作及支持文档的完整性和正确性。
配置审计执行要求如下：
配置库审计
CM工程师负责根据《配置管理计划》中确定的审计周期对开发库及受控库进行审计，建议采用的审计方法为：配置管理审计及物理审计。审计结果填入《配置审计表》中，对发现的问题应及时处理关闭。
基线审计
项目经理及CM工程师负责在每次基线建立后（里程碑评审前）依据《配置审计表》进行配置审计，审计结果填入《基线记录表》中，对发现的问题应及时处理关闭。
基线审计建议采用的方法为：物理审计及功能审计。
8.7 配置库备份
配置库必须周期性备份到项目备份库中，具体备份时间在项目《配置管理计划》中确定，每次备份更新备份记录表，CM工程师定期对备份文件进行恢复测试。
8.8 向财富库提交项目文档
项目结项时，项目经理挑选可供组织未来参考的文档，并记录于《项目结项总结》中。CM工程师根据批准的文件提交清单将相应的文档提交到组织财富库的相应目录，并通知EPG。
9. 输出
《配置管理计划》
《变更记录表》
《基线记录表》
《配置审计报表》
10. 出口准则
项目结项
项目文档提交组织级配置库
11. 引用文档
无
12. 使用模板
《配置管理计划》
《变更记录表》
《基线记录表》
《配置审计报表》