clearcaselt配置

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．配置库的设置
决定配置库的结构是配置管理活动的重要基础。一般常用的是两种
组织形式：按配置项类型分类建库和按任务建库。
按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，
它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较
强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利
于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由
于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会
造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。 而
按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织
内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有
必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认
为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵
活。

bmccbj

61
2．分支的划分
在实际的开发活动中系统中，为了让每个开发人员和各个开发团队
能更好的分工合作，同时又互不干扰，我们基本上为每个配置项从建立
开始就划分成3 个不同的分支，让它们分别对应3 类工作空间。
l 私有分支
私有分支对应的是开发人员的私有开发空间。开发人员根据任务分
工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工
作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，
除该开发人员外，其他人员均无权操作该私有空间中的元素。
l 集成分支
集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的
配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成
果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人
协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团
队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的
管理工作由系统集成员及相关指定人员负责。
l 公共（主干）分支
公共分支对应的是整个软件开发组织的公共空间。各个开发小组在
现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查

bmccbj

62
阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人
员开放只读权限。该分支的管理工作由系统集成员负责。
上面定义的3 类工作空间（分支）由配置管理员统一管理，根据各
开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常
运作。在变更发生时，应及时做好基线的推进。
3．变更控制
对于大型的软件开发项目，无控制的变更将迅速导致混乱，变更控
制就是通过结合人的规程和自动化工具，以提供一个变化控制的的机
制。本文所涉及的变更控制的对象主要指配置库中的各基线配置项。变
更管理的一般流程是：
A) 由开发人员或系统集成员提出变更需求；
B) 由SCCB（软件变更控制委员会）审核并决定是否批准；
C) 配置管理员根据SCCB 的决定临时开放相应的权限，并备案；
D) 系统集成员执行相应的变更。
在这里，将要涉及的变更控制分为两类：一类是基线的变更控制，
另一类是软件版本的变更控制。 l 基线的变更控制
基线的变更是指在一个软件版本的开发周期内对基线配置项的变
更，主要包括基线的应用和更新等活动。