首先要澄清一下版本的概念。在配置管理中，每个配置项的每个状态都可以称为一个版本，配置项的演变过程可以体现为一棵版本树。而我们平时经常说的版本，实际是指软件产品的版本，不是具体配置项的版本。一个软件产品版本是由众多配置项组成的，每个配置项多只能选取它的一个版本组成一个特定的产品版本。因此，在我们平时谈到“版本”时，需要明确是配置项的版本还是软件产品的版本，否则容易在沟通中带来混淆。既然版本管理是配置管理中的一项内容，那么对于在软件产品版本管理中遇到的各种实际问题，需要放在配置管理这个大背景中，基于配置管理的理论、方法和工具来考虑，才能逐步理清。

    项目中的变更管理是大家都已经很熟悉的工作，从概念上来说，变更管理也属于配置管理工作的一部分。在软件开发项目中，无论是功能需求的变更、技术需求的变更还是服务需求的变更，也都可以将变更要求与配置项建立对应关系，演变成为配置项的变更，配置项在变更前后形成不同的版本，这样使得变更管理能够有的放矢。如果不能将变更要求落实到具体的配置项上，项目中许多的变更控制难以具体落实。

    具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪，必要时还可以回退到以前的版本，例如当开发需求或需求变更被取消时，需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并，形成新的升级包版本。

    配置审计是配置管理中的一项重要工作内容，有时被分为物理审计和功能审计，通过物理审计按照配置管理计划来验证所要求的各配置项的完整性，通过功能审计来检查各配置项的内容是否完全符合用户的要求。配置审计是配置管理工作中的重要一环，也是项目质量管理工作中的一项内容。

    项目与产品的矩阵关系需要配置管理来执行

    项目管理与产品管理的矩阵关系，其实是集成项目管理中必须要解决的问题。对于项目管理与产品管理之间多对多的矩阵关系，已经被普遍理解，但是在细化到操作层面时，这种矩阵式的配合关系有时还存在一定的混淆。

    企业中的软件开发部门首先要关注产品，通过基于软件产品的开发工作来实现业务需求，并负责对整个软件产品生命周期的管理。许多公司目前的实际做法是，在组织层面上，项目组实际的组织方式是，在项目组中有多个产品开发小组，每个小组负责某个或某些软件产品的开发工作，项目中跨产品的整体的业务需求、技术架构、系统测试、项目管理等工作，仍由项目组统筹管理。项目组内的产品开发小组，可以与其他项目、维护任务共享资源，可以从产品角度保证软件产品的兼容性和一致性。通过这种组织方式，可以平衡项目管理与产品管理之间关系的，产品经理和项目经理是这两个管理维度的具体执行者。

    服务企业的项目的终产品是业务产品，而开发部门所管理的产品则主要是软件产品，项目管理与产品管理的矩阵关系，也对应成为业务产品与软件产品之间的矩阵关系。企业内部的软件开发部门，对这两类产品都需要进行管理，而且都需要做好配置管理，其中对业务产品的配置管理，核心是对业务需求的管理。这两类产品在配置管理中也会形成矩阵关系，某个业务需求的配置项，涉及若干个相关程序——技术配置项，一个程序也可以同时支持多个业务需求的配置项，形成多对多的关系。基于以上对项目和产品的配置管理管理的辨别，在实际操作中，将软件产品在某个项目中的分支，从产品的配置库中独立出来归入项目配置库进行管理的做法，或者把对应项目的配置项放在软件产品的配置库中进行管理，这两种做法都是有欠缺的。

    如果能够对两种产品都做好配置管理，并且能够建立起这样的矩阵关系，那么不仅在开发中很容易将整体的项目范围逐步细化到底，能够及时对各种变更的影响范围作出判断，做好变更控制，而且对于以后的维护工作能够提供很好的基础，有助于根据业务处理中的问题现象迅速定位到技术缺陷。