配置管理虽然是软件项目过程控制的重要手段和工具，但是在项目的开发实践中却往往被忽视，或者是没有得到系统有效的应用。为什么会发生这种情况呢？究其原
因，主要还是大家对配置管理的概念以及配置管理的内容认识比较模糊，或者觉得使用一套版本管理工具（如微软的VSS、或CVS）就可以解决所有配置管理方面的问题。
什么是配置管理呢？配置管理有多种定义，在1986年出版的Wayne
Babich的《Software
Configuration Management: Coordinating for Team Productivity》一书中把软件配置管理描述为"对软件开发组所建立的软件的修改进行标识、组织和控制的艺术，其目标是减少错误，提高生产力"。这个定义比较简单，而在1993年出版的Steve McConnell的《Code Complete》一书中，从另一个角度对软件配置管理进行了定义："配置管理能够系统地处理变更，从而使得软件系统可以随时保持其完整性。配置管理又可称为'变更控制'，可以用来评估提出的变更请求，跟踪变更，并保存系统在不同时间的状态。" 更为通俗一点的定义是：软件配置管理是一套软件开发和维护过程中，对其中间的成果物进行有效管理的方法和规则，通过配置管理使得整个软件生命周期具有完整性和可追踪性，使得我们在需要的时候，可以把对应成果物回复到需要的时点。
从上面的定义中，我们不难看出配置管理主要有以下活动：
1．识别配置项。我们要从软件工程中找出哪些项目需要进行配置管理，通常的配置管理包含两部分内容：①、文档；②、代码。其实还有一项被我们忽略了，就是环境的配置管理，包括软件环境和硬件环境。
2．发布和变更控制。配置管理项目识别之后，我们需要建立一套规则和方法来规范成果物在发布或修改活动，在这套规则和方法中主要包含以下内容:
①．成果物的发布时点；
②．成果物发布的标准；
③．成果物的评审标准；
④．变更内容的记述方法和记述内容；
⑤．过程中相关角色以及作业内容和责任的定义
⑥．配置管理工具的选择等。
3．状态管理。即定义成果物在不同阶段对应的状态，这样便于我们跟踪控制。如对于一个全新的成果物，至少应该5中状态：做成中、做成完了、评审中、问题对应、归档；对于改修类成果物，特别是在项目后期维护过程中，对应的配置管理项应该包含问题报告、问题评审、问题发布、问题调查（需要记录原因和对策）、调查结果品审、问题修正、修正结果品审、归档等。
4．报告和审计。通过上面的状态的定义，我们可以清楚标识出配置管理项目前的状态，这样就不但为我们的作业进度管理打开方便之门，同时配置管理项目的版本控制提供全面的安全保障。
最后简单说一下配置管理的意义。
1．明确作业内容和作业标准，有利于作业的控制和跟踪；
2．方便系统集成，避免系统在最后集成时丢三落四等。