随着国内软件业的崛起和成熟，软件配置管理越来越得到重视。可以说，软件业要想更好的发展，没有软件配置管理的支持是不可能的。手工作坊式的软件开发模式将会成为历史，如何把国外成熟的软件配置管理理论和经验消化吸收，进而应用到国内软件开发中就成为国内软件业迫在眉睫的任务了。
软件配置管理是管理和技术相结合的一门学科。应该说，软件配置管理理论难以理解是其难以实践的原因。本文试从概念和商业模型两个角度来探讨这门对软件开发具有重要意义的领域。
什么是配置管理
在软件开发中，变更是不可避免的。从某种角度上讲，软件开发过程就是一个变更的过程。有些变更是有益的，是具有创造性的，但是，也有些变更是有害的，导致混乱的。正像James Bach总结的那样：
我们为变更所困扰，因为代码中的一个极小的混乱可能带来产品的大的故障，但是，他也能够修复大的故障或启用奇妙的新能力。我们为变更所困扰，因为某个喜欢恶作剧的单个开发者可能破坏掉项目，但是，一些奇妙的思想也源自那些喜欢恶作剧的人员。
因此，如何管理这些变更是一个软件开发能否成功的关键。简言之，软件配置管理就是管理变更的过程，它贯穿着几乎软件的整个生命周期。成功的配置管理系统可以最大限度的减少对个别“英雄”式人员的依赖。
软件开发过程的输出信息可以分为三个主要的类型：
1 计算机程序（源代码、中间代码和可执行程序）
2 描述计算机程序的文档（针对技术开发者和用户）
3 数据（包含在程序内部或在程序的外部）。
这些项包含了所有的在软件过程中产生的信息，总称为软件配置。该集合中每一个元素称为该软件产品软件配置中的一个配置项（CI, Configuration Item）。
尽管配置管理（Configuration Management ）这个概念被提出有几十年了，但是，业内还没有一个全面而权威的定义。
具体地说：
配置管理是标识和控制配置项，以维护其完整性、可追溯性以及正确性的学科。
具体来讲，配置管理包含如下内容：
标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
控制：通过一定的机制控制对配置项的修改
状态报告：记录并报告配置项以及元数据的状态。
配置审计：确认产品的完整性并维护配置项间的一致性。
从上面的描述，我们知道，配置管理的基本单位是配置项。
从“哲学”意义上讲，它记录配置项的三个方面：
从哪里来？此项可归结为WWW的问题，（Who）谁创建的？（When）什么时间创建的？（Why）为什么创建此配置项？
当前在哪里？此项纪录配置项当前的存储位置以及状态。
将到哪里去？通过配置控制来把配置项“组装”到正确的版本中去。
配置项可以是大粒度的，也可以是小粒度的。如果跟踪个别需求，那么不必要把整个需求规格说明文档定义为一个配置项，可以把每个需求定义为配置项；如果把软件开发工具也放入配置管理系统，那么把配置项定义为文件级就不合适了，只需要跟踪开发工具的版本，即把整个配置工具定义为一个配置项就足够了。
简而言之，配置项可以是文件级粒度的，也可以使文件版本级粒度的。当然，粒度越小管理的成本越高，但是配置的精度也就越高。
一个完整的SCM系统要具有三个核心功能：版本控制、变更控制、配置控制以及两个支持功能：状态统计和配置审计。
版本控制
版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。这里的某一特定对象是指版本维护工具管理的软件组成单元，一般是指源文件；具体实例则是指软件开发人员从软件库中恢复出来的某软件组成单元的具有一定内容和属性的一个真实拷贝。例如，对源文件的每一次修改都生成一个新版本。
版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。
当前，这方面典型的工具有如VSS和CVS。
变更控制
变更控制是通过对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。
变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修补。
对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。
下面是一个典型的变更机制：
-> 接受
-> 修改配置项
-> 测试
-> 提交
-> 发布新版本或补丁
-> 建立基线
-> 关闭CR
-> CCB评估
-> 来自用户的CR
-> 拒绝
我们可以随着变更过程的推进，提升配置项的状态。这方面的工具有Bugzilla。
