配置管理流程
配置库的建立及使用、是别配置项、定义基线、组建项目CCB、配置管理计划、配置记录及报告、产品检查及入库、基线发布、配置审计、产品构造、产品发布、变更控制。
下面的就是具体的内容了，看了一遍没有什么感觉，拷贝上来慢慢看。好像是让我提意见的：）
配置库建立及使用
【1】存储域的定义
l 每个项目立项后，项目经理申请在配置服务器上为项目建立配置库，经批准后CM负责人为该项目建立配置库。
l CM负责人建立的标准配置库共分为六个域：分别是管理域、工程域（可选）、开发域、基线域、测试域、发布域。
l 各个域存储不同产品并由不同的角色控制。具体参见《CM SERVER管理规程》。
【2】域的控制流程
项目组在使用配置库的域区间时，具体控制流程也参见附表《CM SERVER管理规程》。
【3】CM工具选用
从便于管理和组织级的角度考虑，选用CVS作为配置管理工具。
【4】使用权限分配
CM负责人必须对配置库中各区域的访问权限实施控制，确保只有被授权的人才有权访问控制项（如读、写、录入、检出），权限的分配参阅《CM SERVER管理规程》。
【5】资源备份
备份CM库是非常重要的，目的是最小化丢失或在项目产品生命周期的开发期间和运行/维护阶段没有基本配置信息的风险。需要保存灾难恢复备份副本。具体的备份方案参阅《CM SERVER管理规程》。
识别配置项
识别配置项是项目配置管理计划的一部分，通常是在WBS完成后才进行的，但是在启动计划时先要识别出启动计划阶段的配置项。配置项的最小集合是：需求、设计文档、源代码。将识别出的每种不同的配置项进行标识。标识时使用统一的命名规则。具体参见《CM Server管理规程》之配置项标识命名规则。将标识后的产品形成文件，记录到《应用软件综合进度计划》或《嵌入式综合进度计划》中。标识工作由CM负责人完成。CM负责人确保标识符不重复。
定义基线
根据定义的生命周期模型和项目特征来定义基线。在开发周期，基线的建立时间是不同的，可能会受到不同变更权威的控制。计划期间，项目应按如下所述建立基线，用以维护对配置项的完整性的适当控制。每个基线必须记录在配置管理计划中，包含：基线名称、基线内容、在生命周期的什么时候建立、谁有对基线更改的批准权。
组建项目CCB
CCB最小应该由下面几部分组成：高层经理、项目经理（技术负责人）、CM负责人、QA负责人、测试负责人。制定项目的启动计划时就要建立项目的CCB，它是在项目初期建立的，将确定的CCB人选记录到配置管理计划中，并发通知给项目组和相关组。当正式基线建立或变更时，要召开CCB会议，并进行会议记录，会后形成《CCB会议纪要》。
配置管理计划
项目配置管理计划和项目计划同时制定。项目配置管理计划同项目计划一起进行评审。项目配置管理计划由项目经理和组内成员达成一致才能被批准。批准以后的项目配置管理计划放在配置库中。纳入配置库的项目配置管理计划用E—MAIL形式或者是书面形式通知相关人员。配置管理计划的制定遵照《项目配置管理计划制定规程》和《项目配置管理计划》模板。
配置记录及报告
配置状态记录从配置库建立时就要开始记录。CM人员要在配置项得到批准后、纳入到基线库后、以及进行基线发布后进行状态记录。首先登录到CVS上，根据项目经理或开发人员提供的产品审批表核对产品。检查产品的版本标识情况，确认无误。将该产品从工程域或开发域提取到基线库对应的域中进行控制。然后，在配置区域打开配置状态记录文件。将纳入到基线库中的产品按要求登记到配置状态记录文档中。将产品的批准时间、纳入到基线库的时间、发布的时间以及产品在完成变更后的所有状态都记录到配置状态记录中。要求记录各阶段所产生的全部配置项。对变更项也要进行记录，应该记录相应的变更信息。如新版本号、配置时间等。记录时采用《配置状态记录（报告）》模板。将与配置活动相关的报告统称为配置报告。配置报告的编制由项目的CM人员完成。
产品检查及入库
产品检查的时机是项目经理向配置人员提交经批准的产品时。检查产品是否成功通过质量检验。入库前的检查步聚如下：首先要确定产品类型。其次确定质量检查方式。如果是代码检查，需要确定所有的产品都已经通过评审，代码还需通过单元测试。评审要有评审记录，并对评审问题进行跟踪。成功通过质量检查的产品，相关责任人（开发人员或变更人）要提供检查人员签字的《项目任务及审批单》（如有变更，需提供《配置变更请求表》）给CM人员。CM人员负责证实在接受产品前，该产品得到了适当的质量检查。
基线发布
发布时机：基线的发布是在阶段产品完成，并成功通过检查，下一阶段开始之前进行。
发布条件：①必须是认可的变更权威批准的。②测试基线和运行基线发布前已完成基线审计。③所有发布的配置项是在配置控制下的。④创建了《基线发布报告》。
发布类型：①正式基线：包括需求基线和运行基线。②非正式基线：通常包括概要设计基线、详细设计基线、代码/调试基线和测试基线。发布的各基线通常包含的产品（具体内容根据CM计划确定）
发布的批准权威：①正式基线发布由CCB批准从项目基线库生成产品。②非正式基线的发布由项目经理批准从项目基线库生成产品。
发布对象：①正式基线发布给外部客户和内部所有受到影响的组和个人。②非正式基线仅发布给内部所有受到影响的组和个人。
发布形式：通过E-mail、书面文档、备份文件到磁盘或刻录光盘等方式发布给外部客户或内部受到影响的组和个人。
具体实施步骤：依照CMP的发布时间表进行发布。依照本过程对基线进行发布。由项目组的配置负责人负责基线的发布。已经将产品纳入到基线库中，所有的配置项均受控。对所要发布的产品创建了《基线发布报告》。发布的批准权威已经批准了从项目基线库生成产品。确认发布时间。发布给外部客户和所有受到影响的组和个人。发布的内容包括《基线发布报告》和从项目基线库生成的产品，具体所有发布的产品参见项目的配置项标识文档。
配置审计
审计要求：在CMP中计划并记录执行审计的时间表。由没有涉入被审计产品的合格技术人员执行审查。认可的变更权威负责指定执行审计的人员。CM负责人负责安排和准备审计并执行审计。
审计对象：已经建立的项目基线。审计时机：对基线的全面审计（项目经理、CM负责人、技术权威、测试人员、QA负责人等共同参加）通常为两次，一次是在进行系统测试之前，另一次是向客户交付产品前。配置管理员应定期独立进行配置审计，以避免出现未经授权的非法操作等。配置管理员的定期独立审计时间应写入《项目配置管理计划》。
审计的类型：产品审计：审计基线库中产品的完整性，由配置小组来完成。功能审计：审计产品的技术是否符合需求功能，由项目经理或指定相关技术权威负责完成。
审计工作准备：审计工作的准备由CM组来完成。认可的变更权威确认审计组成员，通常①CM负责人、CM人员负责产品审计。②项目经理、技术权威、测试负责人负责功能审计。③QA人员负责对审计过程进行监督。确认审计日程安排。
为审计准备材料：①准备配置审计检查表。②准备待检查的基线内容清单。③准备CCB批准的本次将要审计的基线和基线发布报告。
审计的实施：按照本规程对项目基线进行审计。按照CMP中的审计时间表进行。审计工作由CM负责人全面负责执行。依照配置审计“检查表”实施审计。评估项目基线的完整性。评审配置管理库系统的结构。验证项目基线库内容的完备性和正确性。验证与适用的CM标准和规程的符合性。验证产品和需求的一致性。每次审计后CM负责人生成《基线审计报告》，报告里包括发现的问题、缺陷和解决措施。CM负责人向项目经理报告审计结果。CM负责人负责跟踪审计问题的解决措施的执行情况。
产品构造
产品构造一般应在集成、系统测试前，和产品交付客户前进行。构造方法和步骤：首先由构造人员在本地机器或者其他目标计算机上为产品建立一个目录。将项目产品需要的配置项从CVS上的基线域中复制到这个路径下，然后编译或者组装软件产品。不同项目使用的开发语言不同，各项目的CM人员根据实际情况在项目配置管理计划中详细描述产品构造方式。构造的项目产品可以放在CVS上的基线域或者测试域用来测试或者提交给客户。如果项目产品需要修改，则重复上述过程，进行多次构造，直到项目产品通过QA的检查，达到发布标准。将产品构造过程记入到项目配置管理计划中。
产品发布
发布必须经CCB批准。产品发布是在系统测试完成后，进入试运行阶段时进行第一次发布。当客户验收签字完成后，对客户进行正式发布。在试运行阶段到验收完成期间通过适当的变更控制，根据需要可发布多个不同版本。产品发布所包含的内容要根据与客户签订的合同从上述产品中选取。最小集合为：项目产品（可执行代码）。产品发布的步骤：CM人员使用《产品发布报告》模板形成产品发布报告，并将待发布的产品从基线库中提取进行编译后配置在发布域下，并标识出相应的版本。要求配置在发布域下的产品必须包含系统的全部技术文档。CM人员提交报告和产品，请求CCB批准，CCB召开会议批准发布。CM人员通过E-mail或书面形式通知项目组产品已发布。项目经理根据与客户签订的合同将客户需要的技术产品从发布域下提取，刻成光盘或通过其他形式，提交客户。
