在CMMI和IEEE关于配置管理的正式定义是：软件配置管理是软件工程中的一项规程，包括相关工具和应用技术（过程或方法），公司用它来管理软件资产变更。
一般的来说，配置管理的主要目的是进行工作产品管理，其中包括各类文档、代码、版本、纪要、bug等等。但不要简单理解为，配置管理就是版本管理，配置管理是所有工作产品的管理。
如果一个组织缺乏配置管理，会有哪些问题？【以下8点描述，部分摘录互联网相关内容】
-
组织的知识和过程财富流失
现代的社会竞争激烈，人员流动频繁，如果由于没有必要的配置管理流程和工具，大量的文档和代码等知识财富必然缺乏统一的管理，可能随意地保存在项目经理和软件工程师各自的机器里，往往会因为硬盘的故障或人员的离职而永远的消失，软件组织的数字财富就这样因为缺乏必要的配置管理而白白的流失。
-
不能及时了解项目的进展状况
现代软件工程思想认为越早发现缺陷和风险，采取相应措施的代价越小。CMM /CMMI的 一个重要作用就是要提高软件开发过程中的可视性，使得问题能够被及时的发现。然而由于缺乏配置管理的流程和工具的支持，部门主管无法确切得知项目的进展情 况，即便是项目经理也不知道各个开发人员的具体工作，项目进展随意性很大。所有的问题往往都会集中到项目里程碑时一起出现，这必然会造成巨大的开销，其结 果往往是容忍部分缺陷存在或者延误开发周期。所有问题只能寄希望于最终实施时再解决，项目的实施工作因此变成了无法汇报、无法理清、无休止的维护。
-
缺乏实现并行开发的手段
在日常的开发工作中，经常会出现并行开发的需求，比如：对于一个项目可能要在开发新版本的同时继续对先前的版本进行必要的维护，或者针对某个特定的版本需要针对不同的客户同时进行客户化的修改等等。在并行模式下，不同开发人员可以同时编辑修改某一文件，并行开发有可能产生冲突，但是却能够提高开发效率。如果没有配置管理工具的支持，进行并行开发将十分困难，单单通过人工操作，往往会造成修改过的bug 重复出现或者几个人进行相同的工作，产生不必要的浪费。
-
软件复用率低下
软件复用是现代软件工程中的重要思想，是提高软件产品生产效率和质量的重要手段。软件产品是一个公司的宝贵财富，代码的可重用性是相当高的，如何建好知识库，用好知识库将对公司优质高效开发产品产生重大的影响。但如果没有良好的配置管理流程，软件复用的效率将大打折扣，比如对于复用的代码进行了必要的修改或改进，却只能通过手工的方式将发生的变更传递给所有复用该软件的项目，效率如何可想而知。另外由于缺乏进行沟通的必要手段，各个开发人员各自为政，编写的代码不仅风格迥异，而且编码和设计脱节，往往会导致开发大量重复的难以维护的代码。
-
无法开展规范化的测试工作
在传统的开发方式中，由于缺乏必要的配置管理和变更控制，测试工作只是人们的一种主观愿望，根本无法提出具体的测试要求，加之开发人员的遮丑，测试工作往往是走走过场，测试结果既无法考核又无法量化，当然就无法对以后的开发工作起指导作用。
-
对软件版本的发布缺乏有效的管理
因为缺乏有效的管理手段，往往会在产品发布时却无法确定该版本所有的组件，或者向用户提供了错误的版本。对于特定客户出现的问题，无法重现其使用的版本，只能到用户的现场才能进行相应的调试工作。由于应用软件的特点，各个不同的客户会有不同的要求，开发人员要手工地保持多份不同的拷贝，即使是相同的问题，但由于在不同地方提出，由不同人解决，其做法也不尽相同，程序的可维护性越来越差。这些都会延长实施的周期，同时意味着人力物力的浪费。
可见，版本管理只在第六位。 -
缺乏历史数据的积累，没有软件开发的历史数据
缺乏软件开发的历史数据是大多数软件项目失败的关键所在，这样的结论也许使很多人感到吃惊，但事实就是如此。因为软件开发的历史数据是反映软件开发队伍的能 力的标尺，没有了这个标尺，就无法对软件的开发过程有一个清醒的认识。而良好的配置管理正是收集软件开发历史数据的重要来源。
-
无法有效的管理和跟踪变更
软件的一个显著特点就是易于改变，没有配置管理将无法对软件的变更进行有效的记录、跟踪和控制。
这八点做好了，就是一个合格的配置管理过程
- 组织的知识和过程财富流失
- 不能及时了解项目的进展状况
- 缺乏实现并行开发的手段
- 软件复用率低下
- 无法开展规范化的测试工作
- 对软件版本的发布缺乏有效的管理
- 缺乏历史数据的积累，没有软件开发的历史数据
- 无法有效的管理和跟踪变更
这里要强调的是，要制定好配置管理计划才能有效开展配置管理。也就是说，以上这8条是公司都非常关注的点，但每个项目的重点是不一样的。文档、代码、记录、版本控制以便于并行开发或回退、变更管理是重中之重。
配置管理的内容涉及的很多，最核心内容有三点。
-
- 没有文档记录、代码记录，我们无法衡量结果是否有效
举个例子，评审通过的文档要受控，即入库。评审纪要不受控，如何知道评审时如何开展的，评审质量如何等等。 开发计划要求9.10提交代码，配置管理库看到的是9.12入库的，那么我们怎么知道是按时提交的代码？
-
- 版本控制以并行开发或回退
版本是很关键的。做产品不是一蹴而就，中间会出来大量的正式、非正式、补丁版本等等。那么，在不同的版本上衍生的功能、bug修改如何管理，是否要管理都是配置管理非常看重的点。如果没有配置计划，合并基线版本、新增功能代码增加、bug修改代码更新等工作，可能会是一个可怕的灾难工作。挂一漏万太容易了。
-
- 变更管理
这是配置管理的重点项。一个项目、产品开发过程变化是难免的，但要通过配置管理将变化前后的东西记录下来。变更带来的是范围变化，范围变化带来的是工作量的变化，那么进度计划随之而变。如果不控制、记录变更，拿什么保证最终交付给客户的客户要求的100%？
那么如何制定配置计划呢？
配置计划，要根据公司具体情况，结合上面提到的内容制定。这个计划要把配置库如何建立、配置权限等等细节给与明确规定。下面给大家一个参考：
-
引言 1.1 目的 1.2 术语定义 1.3 参考资料
-
软件配置 2.1 软件配置环境 2.2 软件配置项 2.3 配置管理员
-
软件配置管理计划 3.1 建立示例配置库 3.2 配置标识管理 3.3 配置库控制 3.4 配置的检查和评审 3.5 配置库的备份 3.6 配置管理计划的修订 3.7 配置管理计划附属文档
-
里程碑
附录1 文档命名规定 1、受控配置库文件命名规则 2、非受控配置库文件命名规则 3、提交文档文件命名规则 附录2 文档编码规范 附录3 帐号及权限管理 附录4 配置库使用规定 文档修改记录
上面是配置计划模板的目录，从中可以指导配置计划的开展。
配置管理计划中，通常给出配置管理名词定义，以便于项目成员对配置工作的理解。例如：
软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。
基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。
配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。
配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。
配置管理的核心是配置项的建立和相应权限设置，需要明确定义配置管理员、PM、产品经理等角色和职责。
通常，可以将配置库分为受控配置库和非受控配置库两种。
-
受控配置库
在项目开发实施的整个过程中，可以根据不同阶段的配置管理划分为11个受控配置目录，只有配置管理员拥有增加和修改的权限，其它用户只有只读的权限。受控配置库的目录为：
00 初始配置 01 启动 02 需求分析 03 设计 04 编码 05 测试 06 安装 07 总结 08 变更 09 项目管理 10 环境配置初始配置库的根目录中包含XXXX项目的配置文件清单，该文档包括本项目开发过程中应该提交的文档的清单，在实际开发过程中，根据实际情况，可以在清单中酌情修改、增加和删除需要提交的文档。
-
非受控配置目录
设立非受控配置目录的目的是为了统一管理和存放开发过程中产生的临时文档和过程性文档，没有格式及命名上的严格要求，使项目组成员在思考、设计时不受太多的限制和约束，能够更有效地发挥个人能力，符合以人为本的原则。
在项目初期，可以设立以下三个目录：
| 目录名称 | 用途及说明 |
|---|---|
| 个人工作区 | 用于保存项目成员自己编写的文档，每个项目成员都有自己独立的工作目录 |
| 小组工作区 | 用于保存小组成员写作编写的文档，每个小组都有自己独立的工作目录 |
| 文档提交区 | 作为非受控配置库和受控配置库之间的缓冲，用于提交已经定稿的文档和代码，在评审通过后，再由配置管理员取出并提交到受控配置库中 |
配置管理要做得好是件不容易的事情，通常还需要一些配置管理工具来操作。业内通常用的配置管理工具很多，有国产的和外国的。各不相同，功能强大程度也不一样，要根据自身需要筛选。支持常见的平台有：
-
SVN
目前比较流行的开源配置管理工具，支持几乎所有的操作系统，适用于中小规模的开发团队。
-
CVS
支持几乎所有的操作系统。较高的运行性能，适用于各种级别的开发团队。
-
PVCS
软件本身基于Java开发，能够支持常见的平台。服务器采用文件系统共享方式，对CPU、内存及网络要求较高，性能一般，仅适用于中小型项目团队，不适合于企业级应用。
-
VSS –微软的工具
仅支持Windows操作系统。相对功能单一、简陋，适用于几个人的小型团队，在数据量不大的情况下，性能可以接受。
-
Telelogic CM Synergy
Telelogic DOORS、Telelogic CM Synergy 和Telelogic Tau 覆盖了复杂软件开发的所有关键部分：需求管理、变更管理及可视化软件工程。比较贵。
-
ClearCase
IBM的，非常细致庞大的工具。服务器采用多进程机制，使用自带多版本文件系统MVFS，对性能有较大负面影响。做为一款企业级、全面的开发配置管理工具，适用于大型开发团队。比较贵。
-
Firefly –是国内的一家公司
软件本身基于Java开发，可在Windows、Linux、Solaris、HP-UX、AIX等常见平台上使用，平台之间的移植也非常方便。服务器采用了多线程的应用服务器，性能表现优秀，做为一款企业级、全面的开发配置管理，能适用于中小团队。
-
其他。
FAQ交流讨论
-
- 将代码放到VSS上怎么组织呢？因为我们有框架，框架中有项目。是放在一起呢？还是分开放？
这个是基线和分支的管理模式细节，各走各的版本，在不同的点分支、融合。这个是需要公司系统架构师来协助定计划的。就是说，国外的配置管理工程师是系统级的，是公司产品、项目开发的大牛。可以提出自己在产品基线的规划。
一般的项目不需要分支，只做简单的管理即可，即文档、代码、版本受控。但项目多了，产品多了，平台是节省费用和降低管理的好方法。
-
- 项目经理需不需要懂配置管理？
项目经理要懂得配置管理方能较好的管理项目。只要是正规公司必须要配置管理，否则，你今天能找到08.9月的版本，代码么？其实，配置管理工具对于项目成员使用来说很简单，大家把文档、代码传上去记得checkout,checkin就行了。
项目经理只要有意识check in文档、代码、版本是基本的要求，即没人力天天做，那么在项目的阶段点集中做下。否则出问题哭都来不及。还会有配置库异地备份的问题等等。
-
- 配置管理人员
在很多中小项目组，配置管理员是兼职的，甚至可以开发、测试分开管理，然后需要QA人员来检查他们的工作。
大公司配置管理和质量管理，都应有专人任职。版本是一方面，基线是一方面。
-
- 甲方如何参与到乙方的配置管理中呢
甲方对配置管理估计不需要太多控制，阶段点监察他们的库足够了，否则太累。