项目的目地是为了创造一项产品或服务，因此，产品本身的生产工艺必然会成为项目管理过程的核心内容。无论在哪一种软件工程方法中，软件配置管理都是一项不可或缺的重要管理内容，特别是对于服务企业内部的信息技术部门来说，从产品生命周期出发，同时支持服务
务产品和软件产品，同时负责开发与运行，其管理复杂度很高，要想理顺各项工作的内部关系、理清各项工作之间的配合关系，都离不开配置管理这个基本手段，它是许多管理工作的“落地”部分。其实，配置管理并不是一个时髦的概念，在许多传统行业（例如制造业）中早已有之，软件行业只是在软件工程方法中继续延用了这一概念，它是一流软件开发企业所必备的基础设施。
在项目管理中，配置管理是一种重要的管理手段。在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），其实反映的都是软件设计的思想。在有的软件企业中，配置管理不只是程序员的操作工具，它已经成为工程技术管理的重要手段，是由公司的总工牵头负责的。因此，配置管理是软件工程过程中技术管理的基本手段，起到对技术结构进行分解、识别、跟踪和控制的作用。
投产服务与软件产品的部署有关，是对项目服务特性的要求。运营企业中可能同时有多个应用系统，相互之间往往具有很高的耦合度，一项新业务的推出，往往需要多个软件产品配合修改和同步投产。因此，从业务角度来说，一个新的业务产品的实现，需要多个软件模块（产品）的支持，不同投产单位中这些软件模块（产品）的版本配合关系不同。那么对于运行中心来说，需要面临同时满足业务产品和软件产品的双重要求，既要保证业务产品的完整性和多样性，又要保证软件产品的一致性和兼容性。因此，对于投产管理来说，也有同样的配置管理的要求，是必须在企业级来考虑的。
配置管理中的版本管理和变更管理
配置管理中要记录、控制、报告各种属性（配置项）的变化状态，这就是配置管理中的版本管理和变更管理，有变更才有不同的版本，版本又成为变更控制的主要对象，这两者是紧密关联的。
首先要澄清一下版本的概念。在配置管理中，每个配置项的每个状态都可以称为一个版本，配置项的演变过程就可以体现为一棵版本树。而我们平时经常说的版本，实际是指软件产品的版本，不是具体配置项的版本。一个软件产品版本是由众多配置项组成的，每个配置项最多只能选取它的一个版本组成一个特定的产品版本。因此，在我们平时谈到“版本”时，需要明确是配置项的版本还是软件产品的版本，否则容易在沟通中带来混淆。既然版本管理是配置管理中的一项内容，那么对于在软件产品版本管理中遇到的各种实际问题，就需要放在配置管理这个大背景中，基于配置管理的理论、方法和工具来考虑，才能逐步理清。
项目中的变更管理是大家都已经很熟悉的工作，从概念上来说，变更管理也属于配置管理工作的一部分。在软件开发项目中，无论是功能需求的变更、技术需求的变更还是服务需求的变更，也都可以将变更要求与配置项建立对应关系，演变成为配置项的变更，配置项在变更前后形成不同的版本，这样就使得变更管理能够有的放矢。如果不能将变更要求落实到具体的配置项上，项目中许多的变更控制就难以具体落实。
具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪，必要时还可以回退到以前的版本，例如当开发需求或需求变更被取消时，就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实就是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并，形成新的升级包版本。
配置审计是配置管理中的一项重要工作内容，有时被分为物理审计和功能审计，通过物理审计按照配置管理计划来验证所要求的各配置项的完整性，通过功能审计来检查各配置项的内容是否完全符合用户的要求。配置审计是配置管理工作中的重要一环，也是项目质量管理工作中的一项内容。 [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
