项目的目地是为了创造一项产品或服务，因此，产品本身的生产工艺必然会成为项目管理过程的核心内容。无论在哪一种软件工程方法中，软件配置管理都是一项不可或缺的重要管理内容，特别是对于服务企业内部的信息技术部门来说，从产品生命周期出发，同时支持服务产品和软件产品，同时负责开发与运行，其管理复杂度很高，要想理顺各项工作的内部关系、理清各项工作之间的配合关系，都离不开配置管理这个基本手段，它是许多管理工作的“落地”部分。其实，配置管理并不是一个时髦的概念，在许多传统行业（例如制造业）中早已有之，软件行业只是在软件工程方法中继续延用了这一概念，它是一流软件开发企业所必备的基础设施。
在项目管理中，配置管理是一种重要的管理手段。在PMI的PMBOK中对于配置管理系统是这样描述的：

Configuration Management System. A subsystem of the overall project
management system. It is a collection of formal documented procedures
used to apply technical and administrative direction and surveillance to:
identify and document the functional and physical characteristics of
a product, result, service, or component;control any changes to
such characteristics; record and report each change and its
implementation status;and support the audit of the products,
results, or components to verify conformance to requirements.

It includes the documentation, tracking systems, and defined
approval levels necessary for authorizing and controlling changes.
In most application areas, the configuration management system
includes the change control system.

由此可见，配置管理是一个非常宽泛的概念，项目中只要是需要进行管理的任何特性，都可以纳入配置管理。配置管理不只是操作层面的问题，更是管理理念、管理方法的问题，是一个系统。

项目范围管理需要配置管理来落实

在项目范围管理中，需要识别和控制项目的交付成果，要描述交付物应有的各种特性。这些交付物及其特性，就是配置管理中的配置项。从项目管理的角度，WBS只需要分解到可管理（Manageable）的程度，而配置管理则要求分解到最终可操作的程度，管理的粒度更为精细。因此，良好的配置管理机制，是项目范围管理得到最终落实的保证。

在许多软件开发项目中，项目范围管理涉及三个方面：业务需求、技术结构、投产服务。编写哪些程序模块，实现哪些功能，部署到哪些地点，这其实都是项目范围管理所要关注的内容，在配置管理中对应了产品的物理属性和功能属性以及服务的属性，都可以通过配置管理来识别、记录和跟踪。只有做好软件配置管理，才能真正把项目的范围管理做实。

业务需求决定了软件产品的功能特性，对软件产品的配置管理，首先就是对业务需求的管理。在业务需求中，要求软件产品所提供的各种功能和特性，包括界面风格、操作方式、处理流程、业务规则、数据逻辑等，也都是软件产品的配置项，这种对业务需求的分解、管理的过程，就是对业务需求中的配置项的管理过程。当项目中业务需求发生变更时，其实就是对这些配置项的变更管理。因此，在软件工程过程中，配置管理是需求管理的基本手段，通过科学、严谨的配置管理方法，对业务需求进行识别、分解、跟踪、控制，直接决定了对业务需求的管理能力。许多公司目前在需求管理方面还处于粗放型的管理，虽然基本能够满足项目管理的需要，但对于软件工程过程来说，管理粒度还比较粗，而且缺乏明确的配置项的定义，缺少有效的跟踪控制手段，还需要更精细的管理。

技术结构是软件产品的物理属性，软件产品的配置管理，也是对软件内部技术结构的管理。从技术方案到软件产品、再到产品内部结构，这也是项目范围不断分解、细化的过程。为了实现业务需求、满足产品外部特征的要求，软件产品应如何设计其内部结构，划分内部模块、定义模块接口、确定有多少个程序等等，产品分解到最后，每一个程序都作为一个单独的配置项进行管理，在开发过程中对于程序的修改都纳入配置管理，跟踪程序变化过程。这种对软件产品从技术角度的不断分解和定义，就是基于技术结构的配置项管理，是与软件结构设计相对应的，配置项的划分是否合理，使用起来是否灵活、方便，哪些可以成为公共组件（Component），其实反映的都是软件设计的思想。在有的软件企业中，配置管理不只是程序员的操作工具，它已经成为工程技术管理的重要手段，是由公司的总工牵头负责的。因此，配置管理是软件工程过程中技术管理的基本手段，起到对技术结构进行分解、识别、跟踪和控制的作用。

投产服务与软件产品的部署有关，是对项目服务特性的要求。运营企业中可能同时有多个应用系统，相互之间往往具有很高的耦合度，一项新业务的推出，往往需要多个软件产品配合修改和同步投产。因此，从业务角度来说，一个新的业务产品的实现，需要多个软件模块（产品）的支持，不同投产单位中这些软件模块（产品）的版本配合关系不同。那么对于运行中心来说，需要面临同时满足业务产品和软件产品的双重要求，既要保证业务产品的完整性和多样性，又要保证软件产品的一致性和兼容性。因此，对于投产管理来说，也有同样的配置管理的要求，是必须在企业级来考虑的。

配置管理中的版本管理和变更管理

配置管理中要记录、控制、报告各种属性（配置项）的变化状态，这就是配置管理中的版本管理和变更管理，有变更才有不同的版本，版本又成为变更控制的主要对象，这两者是紧密关联的。

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

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

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

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

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

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

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

对应这种组织方式，配置管理也需要支持矩阵式管理结构。对于属于项目管理的内容，可以针对项目建立配置库进行配置管理，包括项目级的业务需求、项目的整体技术方案、系统功能测试、项目管理过程等内容，而对于单个软件产品，则需要纳入产品配置管理的范畴，针对产品进行配置管理。这和产品文档与项目文档的划分思路是基本类似的。

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

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

多项目并行开发需要软件配置管理的协调

通常情况下，软件部门会同时承担众多的开发任务，都可能会同时需要修改同一软件产品。从软件产品的角度来看，就是并行开发的问题。在企业内部，基于同一产品的并行开发任务通常不会产生不同的软件产品，而是形成同一产品的顺序的多个版本，这就要对软件产品的并行开发做好配置管理，避免并行开发中的版本冲突，这是软件配置管理策略中最为复杂的部分，也是软件配置管理最大的价值所在。只有做好基于产品的配置管理，对并行开发加以协调和控制，管理好版本分支，才能灵活的处理好并行开发任务之间的产品版本的顺序关系。产品版本之间的顺序关系，与项目之间的依赖关系是相互影响的。哪个项目的业务产品需要先投产，那么与之相关的产品版本就要先形成，产品版本顺序一旦确定后，要重新调整版本顺序，就需要退回到最初的开发基线，恢复已经合并的原有分支，选择另外的分支重新进行归并，重新形成新的软件产品版本，这也会对项目管理产生很大的影响。

在并行开发的情况下，企业级的配置管理系统，为并行开发任务之间提供了重要的沟通平台，这种沟通不是一般意义上的项目管理范畴中的协调，而是各项目之间针对产品版本关系对具体工程活动的协调，会对最终产品产生直接的影响，所以软件产品的版本策略是多项目并行开发中必须要关注的问题。因此，在多项目管理中，需要更加深入地关注到各个项目当中的工程活动之间的协调关系，工程类活动之间的依赖关系，往往是项目之间各种依赖关系的决定因素。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号