|
|
|
|
|
配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。
|
|
|
|
GB/T 11457—2006中，对“配置管理”的正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
|
|
|
|
|
|
GB/T 11457—2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”配置项的例子有：交付的软件产品和数据，用于创建或支持软件产品的支持工具，供应商提供的软件和客户提供的设备/软件，各类文档，源代码，可执行代码，测试用例，运行软件所需的各种数据等。
|
|
|
|
在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
|
|
|
|
|
|
配置项的状态可分为“草稿”“正式”和“修改”三种。配置项初始状态为“草稿”，通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”，当修改完毕并重新通过评审后，其状态又变为“正式”。
|
|
|
|
|
|
|
|
配置项的版本号规则与配置项的状态相关，一般规则如下：
|
|
|
|
|
|
|
|
.“草稿”状态的配置项：版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
|
|
|
|
.“正式”状态的配置项：版本号格式为X.Y, X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1，……。当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加到一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。
|
|
|
|
.“修改”状态的配置项：版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值，此时规则同上述“正式”状态的配置项。
|
|
|
|
|
|
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速、准确地查找到配置项的任何版本。
|
|
|
|
|
|
配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项不能随意修改，对基线的变更必须遵循正式的变更控制程序。
|
|
|
|
基线可以是一组拥有唯一标识号的需求、设计、源代码文件以及相应的可执行代码、构造文件和用户文档构成的产品，也可以是产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例与使用手册等）。基线需要定义的内容包括建立基线的事件，受控的配置项，建立和变更基线的程序，批准变更基线所需的权限。
|
|
|
|
基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线（Release Baseline），内部开发使用的基线一般称为构造基线（Build Baseline）。
|
|
|
|
|
|
|
|
.新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
|
|
|
|
.当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
|
|
|
|
.可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。
|
|
|
|
|
|
配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多有关配置管理的问题，例如：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
|
|
|
|
|
|
.开发库：也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。
|
|
|
|
.受控库：也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。可在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
|
|
|
|
.产品库：也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
|
|
|
|
配置库的建库模式有两种，即按配置项类型建库和按开发任务建库，如下表所示。
|
|
|
|
|
|
|
|
|
|
配置管理员负责为每个项目成员分配对配置库的操作权限，对配置库内存放的配置项的操作权限一般有Read（可读但不能修改）、Check（可检出、检入并对文件内容进行变更）、Add（可使用［文件追加］［文件重命名］［删除］等命令）、Destroy（有权进行文件不可逆毁坏、清除、［rollback］等命令）。
|
|
|
|
针对不同的配置库，配置管理员可对不同的项目组成员设置不同权限，如项目成员可以对开发库拥有所有权限，可以对受控库拥有除Destroy以外的权限，而对于产品库只能拥有Read和Check的权限。
|
|
|
|
|
|
配置控制委员会（Configuration Control Board, CCB）负责对配置变更做出评估、审批以及监督已批准变更的实施。
|
|
|
|
CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员和配置管理员等。CCB不必是常设机构，可以根据工作需要组建。小的项目CCB可以只有一个人，甚至只是兼职人员。通常，CCB不只控制配置变更，还负有更多的配置管理任务，如配置管理计划审批、基线设立审批和产品发布审批等。
|
|
|
|
|
|
配置管理员（Configuration Management Officer, CMO）负责在项目的整个生命周期中进行配置管理活动，包括：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置管理系统是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项（包括各种文档、数据和程序）的完备、清晰、一致和可追踪性，以及配置项状态的可控制性。
|
|
|
