版本控制  

　　版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。这里的某一特定对象是指版本维护工具管理的软件组成单元，一般是指源文件；具体实例则是指软件开发人员从软件库中恢复出来的某软件组成单元的具有一定内容和属性的一个真实拷贝。例如，对源文件的每一次修改都生成一个新版本。

　　版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。
当前，这方面典型的工具有如VSS和CVS。

　　变更控制

　　变更控制是通过对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。

　　变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修补。

　　对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。

　　下面是一个典型的变更机制：

　　接受
　　修改配置项
　　测试
　　提交
　　发布新版本或补丁
　　建立基线
　　关闭CR
　　CCB评估
　　来自用户的CR
　　拒绝

　　我们可以随着变更过程的推进，提升配置项的状态。这方面的工具有Bugzilla。

　　配置控制

　　配置控制使用户能够通过对适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策略使得配置管理系统象搭积木似的使用已有的积木（版本）组装成各种各样、不同功能的模型。

　　软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。配置控制就是要保证每个配置的完整性和精确性。

　　举个例子来说，我们要发布软件的32.6版本，那么我们就要把源代码、文档、数据中所有这个应该包含到这个版本中的正确配置项检出。

　　在开发过程中，我们在不同阶段要建立各种基线。基线的建立是配置控制功能的典型应用。所以说，基线是具有里程碑意义的一个配置。

　　一般的商业软件配置管理工具都具有配置控制的功能，只是灵活性和精确性有差别。

　　状态报告

　　状态报告要回答所谓4W的问题：

　　What：发生了什么事？
　　Who：谁做的此事？
　　When：此事是什么时候发生的？
　　Why：为什么做此事？

　　状态报告还要能够报告所有配置项以及变更请求的状态。

　　配置审计

　　配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否具有一致性等等。

　　由于现在软件行业越来越重视质量，许多项目专门成立质量保证部门专门来进行配置审计。所以现在也可以说，配置审计是一个SQA（软件质量保证）活动。

　　配置管理的商业模型

　　配置管理的实施包括两部分：工具和规范。

　　在软件开发过程自动化的今天，没有工具的支持而实施配置完整的配置管理是不能想象的。因此选择一个符合公司或项目的工具至关重要。在配置管理系统中，我们可归纳出四种模型。当前商业工具一般采用其中一种或几种模型。

　　我们通过对商业模型的理解可以帮助我们了解某种工具是否适合我们公司或项目。