配置管理

梦幻小丑灯

配置管理的概念
配置管理通过技术和行政手段对产品及其开发过程、生命周期进行控制、规范的一系列措施和过程。配置
管理的一个重要内容是对变更控制，使变更对成本、工期、质量影响降低到最小。

产品配置指一个产品在生命周期各个阶段产生的各种形式各种版本的文档、计算机程序、部件、数据的集
合。该集合中的每一个元素称为该产品配置中的一个配置项，配置项主要有两类：
1.属于产品组成的工作成果
2.属于项目管理和机构支撑过程产生的文档
每一个配置项主要属性有：名称、标识符、文件状态、版本、作者、日期等。
置于配置管理之下的工作产品包括将交付给顾客的产品、指定的内部工作产品、采购的产品、工具、其他
用于创建和描述致谢工作产品的实体。

配置管理系统包括提交建议变更的过程，评审和批准建议的变更跟踪系统，为授权和控制变更规定的批准
级别，确认批准变更的方法。

CMMI定义的配置管理：配置管理的目的在于运用配置标识、配置控制、配置状态统计、配置审计，建立和
维护工作产品的完整性。

配置管理定义概括为：它是采用技术手段和行政手段进行管理和监督的一套规范化方法；对配置项的功能
特性和物理特性加以标识，并将其文档化；控制这些特性的变更；报告变更进行的情况和变更实施的状态，
验证与规定需求的一致性。
项目配置管理的任务：
1.制定项目配置管理计划
2.确定配置标识规则
3.实施变更控制
4.报告控制状态
5.进行配置审核
6.进行版本管理和发行管理

配置管理计划
配置管理计划主要包括：配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。它由配置
控制委员会审核批准。
指定配置管理计划的主要步骤有：
1.建立并维护配置管理的组织方针
2.确定配置管理需要使用的资源
3.分配责任
4.培训计划
5.确定配置管理的项目干系人，并确定他们的介入时机
6.制定识别配置项的准则
7.制定配置项管理表
8.确定配置管理软硬件资源
9.制定基线计划
10.制定配置库备份计划
11.制定变更控制流程
12.制定审批计划

配置标识和建立基线
配置标识是配置管理的基础工作，是管理配置的前提。
基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项不能被随意修改。
基线的主要属性有：名称、标识符、版本、日期等。给客户用的基线称为“Release”，给内部开发用的基线
称为“Build”。

识别配置管理指识别配置管理下的配置项和相关的工作产品。识别配置项的主要步骤如下：
1.识别配置项
2.为每一个配置项指定唯一性的标识符
3.确定每一个配置项的重要特征
4.确定配置项进入配置管理的时间
5.确定每一个配置项的拥有者责任
6.填写《配置项管理表》
7.审批《配置项管理表》

配置管理系统用于控制工作产品的配置管理和变更管理，包括存储媒体、规程和访问配置系统的工具、
用于记录和访问变更请求的工具。建立和管理配置管理系统的主要步骤如下：
1.建立适用于多控制等级配置管理的管理机制
2.存储和检索配置项
3.共享和转换配置
4.存储和复原配置项的归档版本
5.存储、更新、检索配置管理记录
6.创建配置管理报告
7.保护配置管理系统的内容
8.权限分配

基线是一组经过正式审查并且达成一致的规范或工作产品，是开发工作的基础。交付给客户的基线一般称
为发行基线，内部使用的基线一般称为构造基线。创建或发现基线的主要步骤如下：
1.获得CCB的授权
2.创建构造基线或发行基线
3.形成文件
4.配置基线可用

变更管理
变更是信息系统的一个突出特点，比较普遍。配置管理的一个重要任务是对变更进行有效的控制和管理。
项目变更是不可避免的。两方面：变更来源于用户，原因是用户对需求的变更；变更来源于系统开发人员，
原因是开发人员已提供方案不合适的地方修改。

信息系统变更的复杂性会使变更变得更加困难。
变更管理的任务：
1.分析变更。研究变更的必要性和可行性
2.记录和追踪变更
3.采取措施保证变更在受控情况下进行
配置库，也称配置项库，是配置管理的有力工具。配置库的主要作用表现在：
1.记录与配置相关的所有信息
2.利用库中的信息可评价变更的后果
3.从库中可提取各种配置管理过程信息

配置库有三类：开发库，受控库，产品库。
变更控制委员会，也称配置控制委员会，是配置项变更的监管组织，主要任务是对配置项变更做出评价、
审批、监督已批准变更的实施。
变更请求的主要内容有三方面：1.变更描述；2.变更的审批；3.变更的实施

变更控制过程的主要步骤如下：
1.在整个生命周期中控制对配置项的变更
2.在配置管理系统保存更改的配置项之前，要先获得批准
3.把涉及变更的配置项在保证正确性和完整性的前提下存入和取出配置库
4.对变更进行审查
5.记录变更及原因
故障报告是已经入库的基线发现了新的缺陷，对这种情况下的表现提出的报告。其包含内容有：故障信息，
变更控制委员会的评估意见；故障修复信息。

版本管理
版本管理是按照一定规则保存配置项的所有版本，避免丢失混乱的同时可以快速查新配置项版本信息。
配置项的状态有三种：草稿、正式发布、正在修改。配置项版本控制流程：
1.创建配置项
2.修改处于草稿状态的配置项
3.技术评审或领导审批
4.正式发布
5.变更
Note:所谓的配置库可以参考SVN，ClearCase 。里面版本的控制可以非常清楚的明白版本控制是怎么一回事。

配置审核
配置审核的任务是验证配置项对配置标识的一致性。这些验证包括：
1.对配置项的初始是否背离初始的规格说明或以批准的变更请求
2.配置标识的准则是否得到了遵循
3.变更控制规程是否已遵循，变更记录是否可用
4.在规格说明、项目产品、变更请求之间是否保持了可追溯性
实施配置审核的时间：
1.项目产品交付或者正式发行之前
2.系统开发阶段工作结束之后
3.维护期定期进行
参与实施配置审核的审核人员包括项目组和非项目组人员。配置审核的步骤如下：
1.项目经理决定何时进行配置审核
2.质量保证组或项目组的配置管理组指定该项目的配置审核人员
3.项目经理和配置审核人员决定审核范围
4.配置审核人员准备配置审核检查单
5.配置审核人员安排时间审核文档和记录
6.配置审核人员在审核中发现不符合的现象，并记录
7.项目经理负责消除不符合的现象
8.配置审核员验证所有发现的不符合均得到解决

配置状态报告
配置状态报告也称配置状态说明与报告，是配置管理的一个组成部分，有效的记录和报告管理配置所需要的
信息，及时、准确地给出配置项的当前状态。变更状态说明反映了变更的状态，可以通过变更请求和故障报
告得到。变更状态可分为活动态（正在实施变更）、完成态（已完成变更）、未列入三种。

配置管理的范围是记录各种在项目过程中的信息变化和波及的范围内联动信息的变化，以需求变化影响最大。
这一部分的内容是如何去利用工具和方法来降低这些修改带来的波动性和保持项目的一致性。工具有版本库，
方法有评审等。

选择性考察、客观性考察，论述性考察

梦幻小丑灯

配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行
控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期
中各个阶段都能得到精确的产品配置。

配置管理简介
配置管理的功能 管理过程 配置管理的流程 配置管理的实施配置管理经验谈 配置管理的精髓
配置管理简介
配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、
一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改
生成的软件组成部件来实现对软件产品的管理功能。
早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文，提出控制变更和配置的概

  配置管理相关书籍
念，之后在1975年，他成立了一家名为SoftTool的公司，开发了自己的配置管理工具：CCC，这也是最早的
配置管理工具之一。之后，随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了软件配置管理的
重要性，而相应的软件配置管理工具也如雨后春笋一般，纷纷涌现，比较有代表性的有：Marc Rochkind的S
CCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System)，这两种工具对日后的配
置管理工具的发展做出了重大的贡献，目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计
思想和体系架构。

配置管理在软件开发过程和项目管理过程中的作用
随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置管理逐渐成为软件生命周期中的重要控
制过程，在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的
各个方面，同时对软件开发过程的宏观管理，即项目管理，也有重要的支持作用。良好的配置管理能使软
件开发过程有更好的可预测性，使软件系统具有可重复性，使用户和主管部门用软件质量和开发小组有更
强的信心。

软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化，为了
保证对产品有效地进行控制和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必须对动
态的、成长的产品进行管理。由此可见，配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发
过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，
并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期。通过配置管理过程的
控制，用户对软件产品的需求如同普通产品的订单一样，遵循一个严格的流程，经过一条受控的生产流水
线，最后形成产品，发售给相应用户。从另一个角度看，在产品开发的不同阶段通常有不同的任务，由不
同的角色担当，各个角色职责明确，泾渭分明，但同时又前后衔接，相互协调。

好的配置管理过程有助于规范各个角色的行为，同时又为角色之间的任务传递提供无缝的接合，使整个开
发团队象一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员
和最终产品，这些都是项目主管人员所关注的重点，因此配置管理系统在软件项目管理中也起着重要。配
置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率
和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应
付开发人员流动的困境，使新的成员可以快速实现任务交接，尽量减少因人员流动而造成的损失。
配置管理的功能
并行开发支持

因开发和维护的原因，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不
同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制；
修订版管理

跟踪每一个变更的创造者、时间和原因，从而加快问题和缺陷的确定 ；
版本控制

能够简单、明确地重现软件系统的任何一个历史版本 ；
产品发布管理：管理、计划软件的变更，与软件的发布计划、预先定制好的生命周期或相关的质量过程

  配置管理
保持一致；项目经理能够随时清晰地了解项目的状态 ；

管理过程
建立管理

基于软件存储库的版本控制功能，实现建立（build）过程自动化 ；
过程控制

贯彻实施开发规范，包括访问权限控制、开发规则的实施等 ；
变更请求管理：跟踪、管理开发过程中出现的缺陷（Defect）、功能增强请求（RFE）或任务（Task），
加强沟通和协作，能够随时了解变更的状态 ；
代码共享

提供良好的存储和访问机制，开发人员可以共享各自的开发资源 ；
配置管理的流程

制定配置管理计划

配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付
计划、备份计划等。CCB审批该计划。
配置库管理

配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。
配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等。
版本控制

在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都
将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的
是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找
到配置项的任何版本。

配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。
变更控制

在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修
改而导致混乱。
修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。
当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请－审批
－执行变更－再评审－结束”的规则执行。
配置审计

为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审
计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。
配置管理的实施

实施配置管理系统，一般的步骤和需要考虑的问题如下：
规划、调整网络开发环境
一个规划良好的开发环境，是实施配置管理系统的前提。在此阶段我们要对配置管理系统做出规划，主
要考虑以下问题：
* 网络的带宽、拓扑结构
*服务器的选择、命名规范
*存储区的定位
*开发人员及组的命名规约等
设计配置管理库
根据项目开发的要求，设计开发资源的存储模式，良好的存储模式有利于减轻管理上的负担，增强配置
管理库的访问性能，同时便于控制访问权限，保护软件资产。
定义配置管理系统的角色
在此阶段，我们需要确定与配置管理相关的所有角色，包括他们的相应的活动。在开发过程中，一个开
发人员可能兼任多种角色，但一项任务在同一时刻只能由一个角色来执行。

一般配置管理中的角色主要包括：
项目经理：项目经理在配置管理方面的职责是依靠配置管理员、系统管理员和系统体系结构设计人员的
帮助，制定项目的组织结构和配置管理策略。这些工作包括：定制开发子系统，定制访问控制，制定常
用策略，制定集成里程碑，以及进行系统集成；

配置管理员：配置管理员的职责是根据项目经理制定的开发组织结构和策略，实施、维护配置管理的环境。
其主要职责如下：创建配置管理库，对存储库进行日常备份和恢复，维护配置管理环境，及管理配置管理
相关的用户；
软件开发人员：软件开发人员依据项目的开发和配置管理策略，创建、修改和测试开发工件；
集成人员：对软件进行归并，形成相应的基线或发布版本 ；
QA人员：需要对软件配置管理有较深的认识，其主要工作是跟踪当前项目的状态，测试，报告错误，并
验证其修复结果；
制定配置管理流程
这是配置管理实施的一个重要阶段，其主要目的是根据项目开发的需要，制定相应的配置管理流程，以更
好地支持开发，主要活动包括：
定制并行开发策略：合理的并行开发策略应该具有以下特点：协调项目的复杂性和需求，统一创建分支类
型和元数据，为开发过程中的变更集成制定有效的规范，适时反映开发过程中方法和需求的变化
发布版本管理：软件开发过程中的一个关键活动是提取工件的相关版本，以形成软件系统的阶段版本或发
布版本，我们一般将其称为稳定基线。一个稳定基线代表新开发活动的开始，而一系列定制良好的活动之

  配置管理
后又会产生一个新的稳定基线。有效地利用此项功能，在项目开发过程中可以自始至终管理、跟踪工件版
本间的关联。
烽火猎聘分类来培训相关人员
一般来讲，实施配置管理系统，相关人员需要接受以下培训：
管理员培训：针对配置管理员，主要学习配置管理工具管理相关内容
开发人员培训：针对开发人员，主要学习配置管理工具与开发相关的常用操作
管理流程培训：针对全体人员，目的是了解配置管理策略和流程，以及如何与开发管理、项目管理相结合
配置管理经验谈

围绕配置管理,世界一些致力于软件工程研究的公司在深入理解ISO 9000的基础上, 推出了各种符合ISO 9000
配置管理标准的工具软件,如INTERSOLV公司的PVCS,Rational公司的Clear Case等。这些配置管理工具面向软
件规范化、工程化、自动化的需要,帮助开发团队提高科学管理水平,从而提高工程效率,降低工程成本。现以
PVCS为例,结合我们的实际经验,谈谈我们实施配置管理的益处:
节约费用

(1) 缩短开发周期
利用PVCS的Version Manager对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过
程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度
地共享代码。同时项目管理人员可以通过Version Manager查看项目开发日志,测试人员可以根据开发日志和不
同版本对软件进行测试,工程人员可以从Version Manager上得到不同的运行版本,并且Version Manager 可以安
装在Web Server供外地施工人员存取最新版本,无需开发人员亲临现场。

梦幻小丑灯

利用Tracker组建开发团体之间的问题跟踪及消息通迅,通过其Notify模块与电子邮件结合起来大大加强了开
发团体之间的沟通,Reporter模块可对发现的问题进行整理、以报表方式分类报出,作为开发的指导。
以上为PVCS的两个主要模块,科学地应用可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的
混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。

(2) 减少施工费用
利用PVCS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,内部直
接通过Netscape访问Version Manager,工程人员通过远程进入内部网,获取所需的最新版本。开发人员无需
下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部
讨论决定是否修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、
分散力量、人员不够的毛病,同时节约大量的旅差费用。
有利于知识库的建立

(1) 代码对象库
软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就
像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是:一旦某个开发人员离开工作岗位,其
原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用
范围扩大到公司一级,进行规范化,加以说明和普及。Version Manager为对象管理提供了一个平台和仓库,有
利于建立公司级的代码对象库。
(2) 业务及经验库
通过PVCS Version Manager的注释及Tracker,可形成完整的开发日志及问题集合,以文字方式伴随开发的整
个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指
导作用。
规范管理

(1) 量化工作量考核
传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自己把握,随意性相当大;靠管理人员把握,主
观性又太强。采用PVCS管理后,开发人员每天下班前对修改的文件 Check In,其中记述当天修改细节描述,
这些描述可以作为工作量的衡量指标。
(2) 规范测试
采用PVCS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的
测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。
(3) 加强协调与沟通
采用PVCS后,通过Version Manager文档共享及其特定锁机制、Tracker与电子邮件的集成,大大加强了项目成
员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。
配置管理的精髓

具体来讲，配置管理包含如下内容：

?? 标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
?? 控制：通过一定的机制控制对配置项的修改
?? 状态报告：记录并报告配置项以及元数据的状态。
?? 配置审计：确认产品的完整性并维护配置项间的一致性。
从上面的描述，我们知道，配置管理的基本单位是配置项。
从“哲学”意义上讲，它记录配置项的三个方面：
?? 从哪里来？此项可归结为WWW的问题，（Who）谁创建的？（When）什么时间创建的？（Why）为
什么创建此配置项？
?? 当前在哪里？此项纪录配置项当前的存储位置以及状态。
?? 将到哪里去？通过配置控制来把配置项“组装”到正确的版本中去。
      配置项可以是大粒度的，也可以是小粒度的。如果跟踪个别需求，那么不必要把整个需求规格说明文档
定义为一个配置项，可以把每个需求定义为配置项；如果把软件开发工具也放入配置管理系统，那么把配置
项定义为文件级就不合适了，只需要跟踪开发工具的版本，即把整个配置工具定义为一个配置项就足够了。

      简而言之，配置项可以是文件级粒度的，也可以使文件版本级粒度的。当然，粒度越小管理的成本越高，
但是配置的精度也就越高。
      一个完整的SCM系统要具有三个核心功能：版本控制、变更控制、配置控制以及两个支持功能：状态统
计和配置审计。
      版本控制
      版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。这里的某一特定对象是指版本维护工
具管理的软件组成单元，一般是指源文件；具体实例则是指软件开发人员从软件库中恢复出来的某软件组成
单元的具有一定内容和属性的一个真实拷贝。例如，对源文件的每一次修改都生成一个新版本。
      版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确
的版本以及版本的组合。
      当前，这方面典型的工具有如VSS和CVS。
      变更控制
      变更控制是通过对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。
      变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷
修补则是对已存在的缺陷进行修补。
      对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要
定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。
      下面是一个典型的变更机制：


      我们可以随着变更过程的推进，提升配置项的状态。 这方面的工具有Bugzilla。

      配置控制
      配置控制使用户能够通过对适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策
略使得配置管理系统象搭积木似的使用已有的积木（版本）组装成各种各样、不同功能的模型。
软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。配置控制就是要保证每个配置的完整
性和精确性。
      举个例子来说，我们要发布软件的32.6版本，那么我们就要把源代码、文档、数据中所有这个应该包含
到这个版本中的正确配置项检出。
      在开发过程中，我们在不同阶段要建立各种基线。基线的建立是配置控制功能的典型应用。所以说，基
线是具有里程碑意义的一个配置。
      一般的商业软件配置管理工具都具有配置控制的功能，只是灵活性和精确性有差别。
      状态报告
状态报告要回答所谓4W的问题：
What：发生了什么事？
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
状态报告还要能够报告所有配置项以及变更请求的状态。
      配置审计
      配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否
具有一致性等等。
      由于现在软件行业越来越重视质量，许多项目专门成立质量保证部门专门来进行配置审计。所以现在也
可以说，配置审计是一个SQA（软件质量保证）活动。
      配置管理的商业模型
      配置管理的实施包括两部分：工具和规范。
     在软件开发过程自动化的今天，没有工具的支持而实施配置完整的配置管理是不能想象的。因此选择一个
符合公司或项目的工具至关重要。在配置管理系统中，我们可归纳出四种模型。当前商业工具一般采用其中
一种或几种模型。
      我们通过对商业模型的理解可以帮助我们了解某种工具是否适合我们公司或项目。
      CICO模型
      CICO模型主要关注的是单个文件的版本控制。图显示了一个支持CICO模型的CM系统的工作过程。用户利
用库和文件系统来进行工作。文件被版本化并存储到库中，新版本的产生是由库工具控制的。然而， 文件在
库中不是可以直接存取的，用户必须去检出（即Check Out）一个文件的版本到工作空间中以便读取它的内
容。更改后的文件可以被检入库中（即Check in）,产生文件的一个新版本。
此模型的代表工具是SCCS和CVS。

      组织模型

      组织模型由CICO模型自然导出，建立于构件版本图的基础之上，同时依赖于存储库和工作空间的概念，
可以通过对构件加锁进行并发控制。组织模型的重点是在CM系统支撑下加强了对创建配置、对有关的历史
信息的管理和使用他们作为工作环境的支持。
      组织模型中的配置由系统模型和版本选择规则组成。系统模型列出了组成系统的所有的构件。版本选
择规则指出了组成配置的每一个构件选择版本。选择规则用于系统模型，选择构件版本，即绑定一构件到
某一版本。这个模型的操作方式是：开发员根据模型的构件定义整个系统，并在每一步骤中给每个构件选
择合适的版本。版本操作的工作方式如图所示。
      CM支持主要关心的是维护系统和其构件的版本历史，并选择符合一致性配置的构件版本。只有在所选
构件的版本与所选其它构件版本一致时才认为一个配置版本。
此模型的代表工具是CCC。
      长事务模型
      长事务模型主要支持包括一系列原子变更的全系统演变和由团队开发员对系统变更的协调。开发员主要
操作配置而非单独的构件。事务提交的结果是新配置版本，一系列连续的变更结果生成一系列的配置版本，
称为开发路径。
在长事务模型中，开发员主要的工作对象时配置，开发员首先选择系统配置版本，接下来把关注重点放在系
统结构上。构件的版本由配置隐式决定。长事务由两个概念组成：工作空间和并发控制方案。工作空间来源
于存储库或一个封闭工作空间中的一个固定配置。工作空间由工作配置和一系列已保存的配置组成。工作配
置代表构件和系统结构能够被动态更改的配置。提供通过工作空间进行的透明库访问、将高效的库存储技术
应用于工作空间和管理派生构件的版本。

此模型的代表系统是NSE。


      变更集模型
      主要集中于对系统配置的逻辑变更的支持。在这个模型中引入的变更集表示组成逻辑变更的对不同构件
修改的集合，它是创建变更的活动完成后对逻辑变更的记录。支持这个模型的CM系统用户可以直接操作变
更集。在变更集模型中，配置可描述为由基线和一组变更集组成。

      变更传播给其它配置可通过包含各自变更集来进行。开发员使用不同的集成策略将逻辑变更集包含到一
个新的系统发行中。这样的好处非常明显，例如，我们现在维护10个不同版本的产品，现在要对所有的版
本修改一个缺陷（Bug）。如果相同的工具简单的重复10次显然是不可接受的。而通过变更集把这个逻辑变
更从一个版本自由的传到另外一个版本。

      开发员可跟踪逻辑变更和确定这些变更是否属于特定配置。这种配置管理的方法，因为其将重点放于逻
辑变更上，所以被称作面向变更的配置管理。它不同于现在的其他3种CM模型，因为其它3种CM模型使用
的面向版本的方法把重点放在构件和配置版本上。

      在单一构件的情况下，变更集是两个文件版本之间区别的集合，通常指的是增量内容。对配置来说，变
更集就是两个配置版本之间区别的集合。这组区别就是两个配置版本间的修改构件增量集合，即变更构件
集的增量。
      面向变更的观点不同于面向版本的观点。这有两点不同，一是逻辑变更的显式表示允许对与单个构件和
配置有关的变更集进行跟踪。二是引用单个变更集并有选择地将它们纳入配置管理中的这种能力提供了对
系统演化管理的支持，这种演化是基于将逻辑变更传播到维护的系统配置进行的。
此模型的代表工具是UCM和SABLIME。

结束语
      配置管理本身无论从理论和实践都在不断丰富和发展。例如，配置管理应用于“知识库”的管理就产生了“
内容管理”这一新的领域。配置管理提供的状态报告和数据统计也为软件度量提供了决策依据。配置管理为项
目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员
提供了一个协作的平台，在此平台上，大家能够更有效率的交流和协作。可以说，配置管理是软件开发的基
石！
      配置管理近年来在中国得到了极大的认可，可以毫不夸张的说，没有配置管理，就谈不上软件开发，就
谈不上软件质量，就谈不上软件业的发展。随着软件业规模的扩大，配置管理的实施不是要不要的问题，而
是什么时间、如何实施的问题了。