5、CME维护配置状态记录（维护内容参见本文的【配置状态记录维护和发布】一节）

　　6、CME发布基准建立通知

　　基准建立后的配置项将指导后续的开发/管理工作，并需对这些配置项进行监控以应对变更。

　　【基准变更控制】

　　当需要变更基准时，应由相应配置项负责人提出变更请求，CME负责跟踪和管理变更的执行过程、跟踪变更请求状态直至变更结束，确保变更后的内容只有在经过 评审/测试/核准 后才生效。基准变更的一般步骤如下：

　　1、相应配置项负责人向PM提出变更请求，说明变更原因

　　2、PM指定相关人员对变更影响请求进行分析，分析内容一般为变更对范围、规模、工作量、质量等的影响

　　3、PM将分析结果提交相应级别CCB审批

　　4、如CCB认为可以变更，则由PM指定相关人员实施变更；如CCB认为不可变更，则变更结束

　　5、变更完成后的配置项需进行 评审/测试/审核 通过后提交CME

　　6、CME对配置项进行审计

　　7、CME将配置项放入受控库并进行标识

　　8、CME维护配置状态记录（维护内容参见本文的【配置状态记录维护和发布】一节）

　　9、CME发布基准变更通知

　　基准变更后后的配置项将指导后续的开发/管理工作，并需对这些配置项进行监控以应对变更。

　　【产品创建】

　　产品创建的一般步骤如下：

　　1、CME根据《产品发布计划》从受控库取出相应的配置项版本进行加工（如Build）

　　2、CME对加工后的配置项进行审计

　　3、CME将经审计的待发布产品放入静态库（静态库的概念请参见笔者之前的文章《配置管理漫漫谈之SCM基本知识》，静态库的实例请参见笔者的文章《配置管理漫漫谈之典型配置库结构》）并进行标识

　　4、CME维护配置状态记录（维护内容参见本文的【配置状态记录维护和发布】一节）

　　5、PM根据《产品发布计划》进行（内部/外部）产品发布

　　6、CME发布产品发布通知

　　用于创建产品的配置项必须从受控库取出，以保证正确性。

　　【配置审计】

　　配置审计不同于SQA针对配置管理活动进行的配置管理过程审计，由CME执行，审计对象是工作产品/配置项，审计重点为完整性、一致性、正确性。

　　配置审计的目的是配置管理员要确保配置库中的配置项和基准的完整性、一致性和正确性，这就是CMMI配置管理SP3.2所提到的概念。在开发库中的配置项是不需要进行审计的，一旦带有缺陷的配置项进入受控库，将有可能给项目带来很大的负面影响。 配置审计一般分为功能配置审计（Functional Configuration Audit）和物理配置审计（Physical Configuration Audit ）。