软件配置管理
==================

配置管理(CM)的目的，在使用配置识别、配置控制、配置状态报告及配置审计来达到建立和维护产品(工作成果)的完整性。
涉及到需求变更，代码管理，版本管理，变更管理及配置审计等。

标识所选定的工作产品配置，组成工作产品特定时间点的基线。

* 控制配置项的变更
* 建立或提供规格说明书，以便从配置管理系统构造出工作产品
* 维护基线的完整性
* 提供正确的状态和当前配置数据给开发人员、最终用户及客户。


建立基线
--------------------


识别配置项
--------------

配置项为组成基线的实体单元，包含需求，设计，代码，构建脚本，编译工具及版本，测试方案，测试用例及测试结果等。

选择以下作为配置项 ::

	 1，交付给客户的产品，例如二进制安装文件，帮助手册等。
	 2，内部的工作产物，例如代码和设计文档。
	 3，获取的产品，例如购买的数据库或开源的动态库或操作系统。
	 4，编译工具和其他环境等。编译工具gcc 4.4.3 

给配置项赋予一个唯一的标识，识别每一个配置项的重要特征，包括作者，文档类型，编程语言，
最小可销售的市场特性以及配置项的服务目的。

建立配置管理系统
------------------

建立和维护对工作产品的配置管理和变更管理系统。例如采用subverison, jira等软件组合成为配置管理和变更管理系统。
并且配置管理系统包含变更申请数据。

建立或发布基线
------------------

定义:一个经过评审和认可的规格说明书或产品， 将来的开发将以此为基础，只有通过正规的变更控制程序才可以改变它。

建立或发布供内部使用和交付给客户的基线。

例如根据项目阶段建立基线，研发过程中每周创建研发基线来协调研发和测试的进度。

工作成果包含基线以及基线描述。

实践上有两种基线方式:


1, 按产出物进行基线化。每个项目有很多产出物，然后有多个产出物的基线，这样就需要有一个基线对照表来识别最新的项目基线。

2, 按项目进行基线，项目进行到某个阶段进行评审认可，然后对整个项目产出建立项目基线。

因为后续开发一般基于基线的需求设计及代码进行修改，第一种方式的基线各种文档冲突或不一致可能性比较大。因此需定期建立整体基线。

追踪并控制变更
----------------------

追踪变更申请
``````````````
	   需求变更，因缺陷对代码进行变更等等。并记录变更的状态，例如缺陷有Open,Accept,Fixed,Close等状态.
	   
控制配置项的变更
``````````````````

控制配置项的变更，例如需求变更需要经过批准，审查是否造成额外的影响，在项目后期，审查变得更为严格


建立并维护基线的完整性
-----------------------

用于记录和审计基线的完整性。
	 
建立配置管理记录
---------------------

工作产物包括 ::

		1. 配置项的修订历史记录 
		2. 变更过程的记录 
		3. 变更请求的记录 
		4. 配置项的状态 
		5. 不同基线间的差异   

实施配置审计
-----------------

例如结项时验证需求，测试用例，以及测试结果是否符合需求等
			  
工作成果包括以下内容:

* 1，配置审计结果 
* 2，针对不符合要求的行动，例如审计不通过继续跟踪修改等 
			
			 
多个模块开发如接口发生变化需要评审才能修改。项目开发中可以修改接口，如项目以产品形式对外发布，接口只能新增。

关键在于配置审计，项目的配置审计必须定期进行（建议每月），参加人员包括需求人员，开发人员，集成人员，测试人员及SQA。
参加人员必须包括具体功能的开发一线人员，因为项目成果主要有他们来产出。