1) 制定配置管理计划: 参加项目规划—>规划配置管理任务—>形成配置管理计划—>评审配置计划. **配置管理计划的主要内容：**
1.1 配置管理组织及其职责
1.2 配置管理工具和配置库的组织结构
1.3 配置项标志和基线定义
1.4 变更管理流程
1.5 配置审核和配置状态统计
2) 识别和标志配置项
l 将软件项目中需要进行控制的工作产品定义为配置项（SCI）。
l 为每一个配置项分配唯一的标志。注意：配置项标识并不是指程序/文档文件的文件名，而是该程序/文档作为一个配置项的标识。
l 建立配置项间的对应关系。
两类配置项：
基本配置项：软件开发者在项目开发过程中所创建的基本工作单元。
集成配置项：一个集成配置项是基本配置项或其它集成配置项的集合。
3) 搭建配置管理环境
l 配置管理环境是用于进行软件配置管理的系统环境，其中最重要的是配置管理库，简称配置库。
l 配置库存储配置项（SCI）、修改请求、变化记录等，并提供对库中所存储文件的版本控制。
l 为不同的开发人员分配不同的访问配置库的权限。
l 一般需采用配置管理工具来建立配置库。
l 配置库中文件的更改是受控的。
4) 配置项的版本控制:配置库的检入检出和版本控制机制解决了软件开发中的两个重要问题
l 访问控制：保证具有相应权限的人员才能修改配置项。
l 并行控制：保证不同人员同时对某配置项进行的修改不会互相覆盖。
1) 对配置项的修改（不同版本间的差别）应被记录下来: 更动者（姓名及其身份）；更动日期和时间；被更动SCI（名及其版本号）；更动内容及其位置；更动原因；受此更动影响的诸SCI名表。
软件产品版本编号方法:
l 数字顺序型版本编号
- 普通版本编号: x.y.z，x为主版本号，y为特征版本号，z为缺陷修复版本号，如V3.10.16。
- α和β版本编号: 在普通版本编号后面增加一个大写字符A或者B来分别表示α版本或β版本。例如1.2.4A或1.2.4B。如果存在多次的α发布和β发布，可在A或B后面添加一个数字来说明发布的次数，例如：1.2.5A1，1.3.0B2。
补充: **α测试是由公司内部的用户在模拟实际操作环境下进行的测试。β测试**是由软件的多个用户在实际使用环境下进行的测试。
l 属性版本编号: 把版本的重要属性反映在标识中。可以包括的属性有：客户名、开发语言、开发状态、硬件平台、生成日期等. 包含的信息丰富，方便了查询和管理，版本间的关系易于保持，但由于太复杂，一般只用于软件组织内部的管理。如： J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122
5) 基线变更管理: 变更请求—>变更评估—>变更批准/拒绝—>变更实现
变更评估考虑技术影响,接口影响,进度影响,预算影响等；
根据评估结果对变更作出决策:直接实现变更、挂起或延迟变更、拒绝变更。；**
对于批准的变更，要确定其实现进度：立即实现变更、在特定的日期实现变更、在软件另外的版本中实现。
变更实现：检出(check out)基线——对基线进行变更——测试和验证——检入(check in)基线
6) 配置审核
l 配置管理活动审核：确保所有配置管理活动符合已批准的软件配置管理规程。
l 基线审核：审核基线配置项的完整性和一致性，从而保证基线配置项可被正确地构造。
7) 配置状态统计
状态统计和评估：
l 变更请求的数量。
l 变更管理活动的执行情况。
l 配置管理系统存储量的变化。
l 配置管理系统和SCCB在运作中发生异常的次数。
配置状态报告
l 每次配置的更改被批准或实现时，都会产生一个配置状态报告，通知相关人员：更改了哪些内容？由谁更改？什么时候更改？更改会产生哪些影响？
l 对于大型项目的开发，配置状态报告非常重要，它促进了人员之间的通信。
