目前国内正在大张旗鼓地开展前所未有的“管理革命”，软件项目管理也取得喜人的进展：CMM遍地生花，PMP人才涌现，项目管理的思想“深入人心”。但笔者更想谈一个基本的话题——配置管理。很多人是在CMM中接触“配置管理”的观念的，对配置管理的作用理解也仅限于CMM的要求。其实，配置管理作为相对独立的管理分支，有着其自身特殊的作用和要求。
软件开发的“泥潭”
在一个软件开发项目中，会有大量的所谓“产品”产生，典型的如代码、文档（包括技术文档、产品文档、管理文档）、数据、脚本、执行文件、安装文件、配置文件、甚至一些参数等，这些产品实际上都是软件项目的直接产品，同时也都是项目资产。但随着软件技术的不断更新、软件系统功能的日趋复杂、以及参与人员数量的大规模增加，上述产品的数量也急剧增加。这些产品还有一个独特的特征，就是由于所有的产品都以“信息”的形式存放在计算机中，因此，与硬件比较而言，极容易被修改（不考虑权限问题）和变化。这样虽然有助于灵活性的提高，随之而来的是管理复杂性也急剧增加。如何有效地管理这些产品以及它们之间的关系成为一个棘手的问题。
另一方面，软件开发往往都是在“变化”中进行的。可以毫不夸张地说，对软件开发项目而言，“变化是持续的、永恒的”，找不到不会变化的项目。需求会变，技术会变，系统架构会变，代码会变，甚至连环境都会变，所有的变化最终都要反映到上述的项目产品中。如何应对这些变化，如何在受控的方式下引入变更，如何监控变更的执行，如何检验变更的结果，如何最终确认并固化变更，如何使变更具有追溯性，这一系列问题都将直接影响项目的进行。
另外，软件项目最终的目标是提交“高质量”的软件产品给最终用户。但是，我们经常面临的一个问题是，“提交了些什么？”为什么会产生这个问题，是因为最终的“高质量”，“可运行的”软件产品是由上千个甚至更多的“部件”按照某种特定的规则编译在一起完成的，但是每个部件都有自己特定的变化生命周期（Change Lifecycle），这样就产生了一系列的版本，许多的部件以及各自的许多版本，就形成天文数字般的组合，见下图示例。
遗憾的是，其中只有一种组合才是我们真正想要的。没有足够的信息，没有合理的管理手段，我们将面临危机（事实上，这种危机在许多项目中已经一再地出现了）。
还有另外的一些问题对项目同样会产生影响。比如，在软件项目组中，往往是许多人一起配合工作。这时会出现一种需求：每个人要求工作在一个“独立”的工作环境中，也就是要求每个人进行工作时，不能影响和干扰其他人的工作和成果。但同时，当经过一定的授权或者认定后，还要求可以比较便捷地和其他人的工作进行配合。这种既独立又联系的关系，使得通常的管理手段显得力不从心。
综合上面的问题可以看出，大量的问题已经不再是单纯的技术问题了，而是需要一项专门的管理手段来处理。这个管理手段直接的目的就是保持项目的稳定性（虽然也能间接提高质量），减少因上述原因引起的项目混乱而造成的负面影响。这就是“配置管理”的产生原因。
SCM的责任
根据IEEE的定义，“软件配置管理（Software Configuration Management , SCM）是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性、控制这些特性的变更、记录和报告变更的过程和状态，并验证它们与需求是否一致。”从定义可以看出，软件配置管理（SCM）是一门综合性的学科，其中不仅包含管理，也包含一些技术手段。另外，SCM通过管理配置项控制变更、验证变更，使项目的混乱减到最小，使错误达到最小，并最大限度地提高生产率。
实施软件配置管理的目的是保证软件项目的工作产品在整个项目周期中的“完整性”。所谓完整性是指，工作产品要求有完整的变更历史记录，要求有正式的变更过程，而且还要求保证工作产品能和需求以及变更保持一致性。
为应用SCM支招
从上述的定义中，我们已经可以归纳出要实施软件配置管理，需要进行哪些活动了。
首先，要进行配置项的标识。所谓配置项，简单地说就是受SCM控制和管理的工作产品单元，也是配置管理的目标。什么能作为配置项进行管理？下面举一些例子，程序（源代码、目标代码、可执行程序、函数等）、文档（需求定义、系统分析、系统设计、高层设计、低层设计、测试规格说明书、测试计划、安装手册、发布说明、用户手册等）、数据（测试数据和项目数据）、执行文件等，都是典型的配置项。但有几个问题需要讨论：一、配置项划分的颗粒度问题。也就是说，配置项实际上是逻辑的概念，不完全对应物理上的文件，因此为了便于管理，就要进行一定程度的划分，比如典型的，可以把用来生成一个“构件”的几个代码文件设定为一个配置项，这样在进行变更时就需要同时对这些文件进行修改。二、不一定要把所有的工作产品都作为配置项。有些工作产品，比如状态报告，相当稳定，不容易变化，同时对最终产品发布没有直接影响，就可以考虑不作为配置项进行管理。为什么要这样考虑呢？因为如果作为正式的配置项，需要进行配置项的标识、控制、报告等等工作，会给项目增加不必要的成本。因此，可以考虑对这些产品仅仅进行简单的管理就可以了。但是对诸如项目计划文档，仍然需要进行软件配置管理。三、对于一些没有实际物理文件，但仍然需要进行配置管理的工作产品，比如操作系统参数、编译器描述、物理特性、版本描述等，为了能进行配置管理，需要对其进行描述，并形成文档，再以配置项形式进行管理。比如进行技术变更时，就有可能需要改变系统参数。
其次，进行变更控制。可以这样说，我们所熟知的版本管理，其本身并没有什么直接作用，而真正起发挥作用是为变更控制进行支持。为什么这样说呢？我们仔细考虑一下，我们通过自动化的方法或者手工化的方法，保存了所有的配置项的所有版本，但是什么时候会有用处呢？往往没有进行变更控制的时候，就会发现所有的版本仅仅占用磁盘空间，而从来不会使用，甚至真正想找到以前某个状态时，反而难于查找。主要的原因是，所记录的配置项的所有状态，只有和变更控制进行配合，将变更的原因和变更的结果（配置项的某一版本）联系在一起，才能以变更为主线，将所有版本变为“有理由的”（reasonable），才能形成基线，真正发挥变更控制和版本管理的作用。
第三，要进行配置管理的状态监控和报告。这部分内容比较具有技术性，并且相对单一，基本上依照项目对配置管理的要求进行统计和分析。但是，配置管理状态报告往往能从另一个方面反映项目的进度情况，甚至有时比项目进度状况报告还要准确。比如，变更请求状态分布报告，就可以客观地反映按照计划应该完成多少变更请求，而实际上完成多少变更请求，这实际上客观地反映出已完成和未完成工作量。这方面的内容在项目进度报告中很难客观反映，从而造成项目实际情况与进度报告不符。
第四，就是要进行配置审核。可以说这个环节是配置管理达到效果的重要手段，但是在一般配置管理执行时，往往忽略配置审核，造成在产品测试、产品发布是仍然出现混乱。
最后，也是非常重要的配置管理活动，就是在项目开始之前就进行配置管理计划。配置管理计划往往和项目开发计划一起产生，并相互影响。配置管理计划的目标是规划整个项目的配置管理活动，尤其是重要的比如发布、基线管理等问题。配置管理计划的主要内容包括配置项的标识和命名规范、配置管理环境方案、配置管理活动计划和时间表、基线计划、发布计划等。可以说，配置管理计划直接决定了项目配置管理的方针，以及配置管理活动的准则。忽略配置管理计划，将使整个配置活动甚至项目都受到影响。
以上是配置管理的基本活动。
不要忽略SCM
从CMM的实施情况来开，配置管理实际上是项目管理的基础工作之一。原因如下：
一、软件配置管理是一个相对独立的管理活动，也就是说，配置管理活动不一定依赖其他的管理活动的开展。在很多企业中，配置管理完全可以在其他的管理活动没有开展或者还不成熟时独立进行。
二、其他许多的管理活动，多数都要以完善的配置管理作为基础。比如说需求管理，对需求管理而言，无论需求的变更影响分析，还是需求的变更执行都是依赖在变更控制和配置管理基础上的。其他的比如项目计划管理、质量管理、项目跟踪管理、子合同管理等都是类似的情况。
三、从实际经验的总结来看，配置管理是诸多管理活动中最易操作、最容易实现并且能在项目最先体现出效果的管理手段。配置管理相对其他的管理，技术性较强，变化不大，对开发人员来说收效明显，接受的程度高。
因此，我们将配置管理比做项目的“先行军”，意味着企业在实施CMM或项目管理时，首先要抓好的是建立一套完整的配置管理制度，有条件的还要建立配置管理工具环境，并在项目中推广实施。只有在此基础上，才能为今后更加深入的项目管理提供基础。
但是，仅仅意识到配置管理的重要性以及可行性还是不够的。根据大量的实践经验，还需要有一套配置管理自动化的平台，也就是一个配置管理工具作为实施的基础。一套功能强大、实施容易、管理方便的配置管理工具，可以极大地提高配置管理的实施效果，尤其是可以得到项目组开发人员的大力支持。在市场中已经有了一些较好的产品。其中CA公司推出的AllFusion Harvest Change Manager就是满足上述需要的一套非常优秀的配置管理工具。AllFusion Harvest Change Manager将配置管理和变更控制紧密地结合在一个产品中，并提供灵活的变更控制流程定制，支持从小团队开发到大型项目实施的各种规模软件项目，并具有简单易用、快速实施、安全稳定的突出特点。在国外市场上市场占有率非常高，现在正在被越来越多的国内用户认可。
我们相信，在不久的将来，配置管理将成为所有软件开发人员和管理人员所依赖和熟悉的管理手段。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/