clearcaselt配置

bmccbj

51
5、 维护稳定、一致的工作空间；
6、 支持对于工件和控件的并发修改；
7、 尽早集成、持续集成；
8、 保证软件构建的重现能力；
9、 以控件（Component）为单位实施版本控制；
10、 使用“活动”（Activity）来组织和整合版本集。
下文将介绍前5 条最佳实践。
1、标识需要进行存储的工件（Artifact）并保障安全存储
在软件开发过程中，我们会得到各种各样的产出，比如各种文档、模型、
源代码以及测试脚本等，我们把这些大家劳动的成果统称为工件
（Artifact）。对于一个软件开发组织来说，这些工件就构成了组织的核
心资产。对于如现金、有价证券之类的资产，我们都会准备一个保险箱，
好好地保存；对于软件资产，我们也需要相似的措施。所以，软件配置
管理工作的第一步就是建立一个安全、可靠的存储库（Repository），用
于保存组织的核心软件资产。 这个库对于开发团队来说，就像是财务
室里的保险箱。因此，容错能力和高可靠性是这个库最重要的属性。除
此之外，随着组织的增长，置于库中的数据会越来越多，为保证运行效
率，库的可扩展性也是非常重要的一个属性。

bmccbj

52
对于存储库来说，良好规划的备份和灾难恢复过程是必不可少的。
令人惊讶的是，很多软件组织在这方面都没有给予必要的重视，因而也
给组织的发展留下了严重的隐患，一旦灾难发生，后果不堪设想。
在建立好存储库以后，需要做的工作就是确定将哪些工件置于库
中。根据实际需要，组织可能会决定只将正式文档、模型文件、源代码、
发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，
则不将它们放入库中。我们把放入库中的文件称之为配置项
（Configuration Item）。
2、控制并且审计（Audit）对于工件的修改
在标识相关的工件并将它们置于存储库中以后，我们需要建立对于这些
工件的修改控制机制以及审计机制。
库里的工件不是谁想修改就可以修改的。控制机制必须保证只有拿
到授权的人员才能对相关工件进行修改，而审计机制则保证修改的动作
被完整地记录，也就是说，谁修改了这个工件，什么时候做的修改，为
什么原因做出这个改动，以及修改了哪些地方（Who、When、Why、
What）。
审计机制通常通过“检出/检入”（Check out/Check in）模式得到实
现。在这种模式下，工件一旦入库，读写权限就变成只读（read only），
如果要对该工件进行修改，则需要通过“检出”这个步骤；在修改结束
以后，如果希望将修改的成果入库，则需要通过“检入”这个步骤。在
经过一次“检出/检入”步骤以后，会形成该工件新的版本，因此也有人
把上边的过程称之为“版本控制”（Version Control）。在版本控制过

bmccbj

53
程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可
以自动地记录审计工作所需的四个“W”（Who、When、Why、What）。
3、设立并管理基线
通过审计机制我们可以保存一个工件完整的变更历史；但是一个项目通
常是由成百上千个工件构成的，每个工件在变更过程中都会形成一系列
的版本，如何确认系统在某个时刻分别由哪些工件的哪些版本构成？这
就需要引入一个概念：配置（Configuration）。对于软件系统来说，在
开发过程中某个时刻存储库中所有工件的一个“快照”（snapshot），
就形成一个“配置”。对于一些重要时刻的系统配置，我们可以使用基
线（Baseline）来进行标志。
IEEE对于基线的定义是：已经通过正式复审和批准的某规约或产
品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制
过程进行改变
简单地说，基线就是项目储存库中每个工件版本在特定时期的一个
“快照”。它提供一个正式标准，随后的工作基于这个标准进行，并且
只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对
它进行的变更都将记录为一个差值，直到建成下一个基线。
建立基线的主要原因是：重现能力、可追踪性和报告能力。
重现能力是指返回并重新生成软件系统给定发布版本的能力。可追
踪性建立项目各种类型工件（需求、设计、实现、测试等）之间的横行
依赖关系，其目的在于确保设计满足需求、代码实施设计以及使用正确

bmccbj

54
代码编译生成可执行文件。报告能力来源于一个基线内容同另一个基线
内容的比较，基线比较有助于程序调试并生成发布说明（Release notes）。
建立基线有以下几个好处：
(1) 基线为开发工件提供了一个定点和快照。新项目可以从基线提
供的定点之中建立。
(2) 当认为更新不稳定或不可信时，基线为团队提供一种取消变更
的方法。
(3) 可以利用基线重新建立基于某个特定发布版本的配置，这样也
可以重现被报告的错误。
在开发过程中，需要定期建立基线以确保团队开发人员的工作保持
同步，通常，在项目生命周期中的里程碑处定期建立基线。
4、记录并跟踪变更请求
以上我们谈论的都是对于工件的变更活动的实施，下面我们要谈到的是
软件配置管理的另一个方面：对于变更请求的管理。这是变更活动的源
头。
著名的软件大师Brooks 曾经谈到导致软件开发困难的一个原因就
是软件的可变性。大家都知道，各种要素，如市场的变化、技术的进步、
客户对于项目认识的深入等等，都可能导致软件开发过程中的变更请求
的提出，而且承认这种变更请求的合理性也已经是工业界的共识。

bmccbj

55
但是，如果缺乏对于变更请求的有效的管理能力，纷至沓来的变更
就会成为开发团队的噩梦。缺乏有效的变更请求管理会导致以下一些问
题：
（1） 软件产品质量低下，对一些缺陷的修正被遗漏；
（2） 项目经理不了解开发人员的工作进展，缺乏对项目现状进行
客观评估的能力；
（3） 开发人员不了解手头工作的优先级别，可能出现将紧急的事
情放在一边、而工作在一般优先级任务上的情况。
变更请求管理的复杂程度与变更的具体类型有关。简单地说，变更
请求管理会涉及到变更请求的提交、变更请求的复审、变更任务分配、
变更结果的验证等一系列活动。通常，变更请求管理的流程是：由请求
者提交变更请求，变更控制委员会（Change Control Board，CCB）召开
CCB 复审会议对变更请求进行复审，以确定该请求是否为有效请求。如
果是，则基于项目团队所确定的优先级、时间表、资源、变更难度、风
险、严重性以及其他相关标准，判定对该变更的修改程序，并分配实施
变更任务的人力资源和时间资源；变更任务实施人员负责实施该变更；
实施结束以后提交验证人员，由验证人员负责对变更结果进行验证，如
果变更成功则通知相关人员，否则由变更实施人员返工。
典型的变更请求管理如需求变更管理、缺陷追踪等。实施有效的变
更请求管理有以下好处：
（1） 提高软件产品质量；

bmccbj

56
（2） 提高开发团队沟通效率；
（3） 帮助项目管理人员对产品状态进行客观的评估。
关于变更请求管理的详细过程以及相关准则PMT 将在相关报告中
阐述。
5、维护稳定、一致的工作空间
在我们把相关工件纳入集中的存储库、大家也都遵照“检出/检入”的工
作模式对工件进行修改以后，下一步的工作就是要为每位开发人员设定
“私有”的工作区，或者叫做工作空间。
工作空间通常以特定的基线为基础创建，要求能够做到为指定的任
务方便地取出正确的工作版本建立私有工作空间；开发人员根据项目要
求在自己的私有空间中对工件进行修改和测试活动，而与其他开发人员
相对保持隔离，也就是说，自己的修改活动不会受到他人的影响，也不
会影响到其他开发人员。但是，在保持隔离的同时，又应该提供相应的
机制，当开发人员希望共享工作成果的时候，能够很方便地实现共享。
开发人员日常的开发工作都是在工作空间里进行的，因此，稳定性
应该是工作空间首要的特性，只有高度稳定的工作空间才能保证开发人
员的工作效率。
第三节 软件配置管理实施体会
随着软件产业的崛起，软件工程技术正吸引着越来越多关注的目
光。作为软件工程的一个重要的领域，软件配置管理（Software

bmccbj

57
Configuration Management）也日益受到人们的重视。在这里，笔者并
不打算对软件配置管理的细节进行讨论，几乎任何一本关于软件工程的
教材中都有专门的章节对此进行介绍，而是想从一个实践者的角度来阐
述关于软件配置管理的一些想法。
一． 软件配置管理的目的
对于任何一个软件组织（企业）来说，开发出满足用户需求的、高
质量的软件产品是其追求的目标。而要实现这一目标的关键是建立起一
个稳定、可控、可重用的软件流程（Software Process）。因为某一软
件产品的成败可能维系于关键技术的突破和创新；但对于软件组织而
言，要想永葆竞争优势并不断取得成功，那就必须不断地改进它的软件
流程。要进行软件流程改进（Software Process Improvement）就需要
有明确的、量化的对现状的分析和对未来的预期，这些数据来源于对软
件过程的度量，而进行度量的前提和基础就是软件配置管理。
与一般制造业相类似，软件流程就像是一条流水线，在它的各个环
节上都会有“零部件”产生，它们就是我们所熟悉的程序、相关文档以
及数据。这些正是软件配置管理的对象——（软件）配置项。它们不仅
是大量人力物力投入的结晶，更是开发经验的积累，是软件组织最宝贵
的财富。软件配置管理贯穿于软件开发活动的始终，覆盖了开发活动的
各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控
各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过
程的控制。

bmccbj

58
那么我们对这些配置项进行管理只是为了保存这些信息吗？众所
周知，人员的高流动性和知识和技术的快速更新是软件业的重要特点。
应对这样的特点我们只有努力地把开发人员个人的成功经验转化为团
队的以及整个组织的经验。在这样的一个转化过程中，软件配置管理也
起着极其重要的作用。因为对于一个大型的软件企业来说，它的配置库
有如一个巨大的图书馆，随着产品版本的不断演进，越来越多的配置项
会充斥其间，以至于没有任何一个人能了解其中的全部内容。当我们需
要在开发组织内部迅速的共享以往的成果时，配置管理就能发挥作用
了。它就像常见的图书编目法那样，帮助图书管理员（配置管理员）迅
速的找出所需的资料（配置项），而不必彻底了解其中的确切内容。这
样工作效率大为提高，很多常见的容易引起混乱的问题都能尽量得以避
免。
所以，我们在从事软件配置管理工作时应以整个软件流程的改进为
目标，为软件项目管理和软件工程的其它领域打好基础，以便于稳步推
进整个软件组织的能力成熟度。
二． 工具的选择
古语有云：“工欲善其事，必先利其器。”软件配置管理是一项十
分繁琐的工作，同时又和整个软件的开发活动紧密地联系在一起，所以
在实际工作中更需要有得力的工具辅助。目前常用的配置管理工具主要
有MS SourceSafe、Rational ClearCase 等，这些工具各有所长，因而
只有根据项目的预算和开发组织的些实际情况出发来选择，正所谓“好
用就好”。在这里，笔者提出一些个人的看法供大家参考。

bmccbj

59
首先，配置管理工具应该提供完善的版本管理的功能。在该工具的
所管理的配置库中，所有的配置项都应清晰、完整的得到保存，相应的
操作纪录完备，使得开发组织中的任何人员都能迅速的了解任一配置项
的演进过程，并快捷的找到所需的资源。
其次，配置管理工具应具备一定的工作空间的管理功能。正如前文
指出的那样，一个软件企业往往有多个项目同时进行着开发，为了最大
程度的利用组织的经验、共享成果，我们有必要在一个共同的配置库里
提供多视角的观察手段，在逻辑上按照不同的角色分工来组织信息的选
取规则和显示方式，从而能根据需要，在开发人员间灵活的进行分工合
作。
由于我们把配置管理工作立足于软件过程的改进，那么我们所选用
的工具最好能具有一定的过程控制的能力，能利用它按照企业本身的开
发流程来灵活的建立相应的电子流，并在此过程中记录用于过程度量的
相关数据，整合软件过程管理的各个环节，以便于客观的发现问题，高
效的解决问题。
另外，我们选取得工具一定要操作简便，不能给开发人员增加过多
的负担，因为过多的形式化的约束往往带来人们的反感，使得大家不约
而同的选择规避的措施，其结果只能是事倍功半，甚至和我们的目标南
辕北辙。

bmccbj

60
三． 实现的策略
笔者所在的软件组织从事的通信软件的研发，我们把配置管理作为
推进软件过程改进的一个很重要的工作领域。我们明确定义了配置管理
相关的角色、工作职责和工作流程，通过一段时间的努力，已经取得了
明显的效果。
1．配置库的设置
决定配置库的结构是配置管理活动的重要基础。一般常用的是两种
组织形式：按配置项类型分类建库和按任务建库。
按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，
它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较
强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利
于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由
于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会
造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。 而
按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织
内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有
必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认
为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵
活。