随着软件产业的崛起，软件工程技术正吸引着越来越多关注的目光。作为软件工程的一个重要的领域，软件配置管理（Software Configuration Management）也日益受到人们的重视。在这里，笔者并不打算对软件配置管理的细节进行讨论，几乎任何一本关于软件工程的教材中都有专门的章节对此进行介绍，而是想从一个实践者的角度来阐述关于软件配置管理的一些想法。

一． 软件配置管理的目的

对于任何一个软件组织（企业）来说，开发出满足用户需求的、高质量的软件产品是其追求的目标。而要实现这一目标的关键是建立起一个稳定、可控、可重用的软件流程（Software Process）。因为某一软件产品的成败可能维系于关键技术的突破和创新；但对于软件组织而言，要想永葆竞争优势并不断取得成功，那就必须不断地改进它的软件流程。要进行软件流程改进（Software Process Improvement）就需要有明确的、量化的对现状的分析和对未来的预期，这些数据来源于对软件过程的度量，而进行度量的前提和基础就是软件配置管理。

与一般制造业相类似，软件流程就像是一条流水线，在它的各个环节上都会有“零部件”产生，它们就是我们所熟悉的程序、相关文档以及数据。这些正是软件配置管理的对象——（软件）配置项。它们不仅是大量人力物力投入的结晶，更是开发经验的积累，是软件组织最宝贵的财富。软件配置管理贯穿于软件开发活动的始终，覆盖了开发活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。

那么我们对这些配置项进行管理只是为了保存这些信息吗？众所周知，人员的高流动性和知识和技术的快速更新是软件业的重要特点。应对这样的特点我们只有努力地把开发人员个人的成功经验转化为团队的以及整个组织的经验。在这样的一个转化过程中，软件配置管理也起着极其重要的作用。因为对于一个大型的软件企业来说，它的配置库有如一个巨大的图书馆，随着产品版本的不断演进，越来越多的配置项会充斥其间，以至于没有任何一个人能了解其中的全部内容。当我们需要在开发组织内部迅速的共享以往的成果时，配置管理就能发挥作用了。它就像常见的图书编目法那样，帮助图书管理员（配置管理员）迅速的找出所需的资料（配置项），而不必彻底了解其中的确切内容。这样工作效率大为提高，很多常见的容易引起混乱的问题都能尽量得以避免。

所以，我们在从事软件配置管理工作时应以整个软件流程的改进为目标，为软件项目管理和软件工程的其它领域打好基础，以便于稳步推进整个软件组织的能力成熟度。

二． 工具的选择

古语有云：“工欲善其事，必先利其器。”软件配置管理是一项十分繁琐的工作，同时又和整个软件的开发活动紧密地联系在一起，所以在实际工作中更需要有得力的工具辅助。目前常用的配置管理工具主要有MS SourceSafe、Rational ClearCase等，这些工具各有所长，因而只有根据项目的预算和开发组织的些实际情况出发来选择，正所谓“好用就好”。在这里，笔者提出一些个人的看法供大家参考。

首先，配置管理工具应该提供完善的版本管理的功能。在该工具的所管理的配置库中，所有的配置项都应清晰、完整的得到保存，相应的操作纪录完备，使得开发组织中的任何人员都能迅速的了解任一配置项的演进过程，并快捷的找到所需的资源。

其次，配置管理工具应具备一定的工作空间的管理功能。正如前文指出的那样，一个软件企业往往有多个项目同时进行着开发，为了最大程度的利用组织的经验、共享成果，我们有必要在一个共同的配置库里提供多视角的观察手段，在逻辑上按照不同的角色分工来组织信息的选取规则和显示方式，从而能根据需要，在开发人员间灵活的进行分工合作。

由于我们把配置管理工作立足于软件过程的改进，那么我们所选用的工具最好能具有一定的过程控制的能力，能利用它按照企业本身的开发流程来灵活的建立相应的电子流，并在此过程中记录用于过程度量的相关数据，整合软件过程管理的各个环节，以便于客观的发现问题，高效的解决问题。

另外，我们选取得工具一定要操作简便，不能给开发人员增加过多的负担，因为过多的形式化的约束往往带来人们的反感，使得大家不约而同的选择规避的措施，其结果只能是事倍功半，甚至和我们的目标南辕北辙。

三． 实现的策略

笔者所在的软件组织从事的通信软件的研发，我们把配置管理作为推进软件过程改进的一个很重要的工作领域。我们明确定义了配置管理相关的角色、工作职责和工作流程，通过一段时间的努力，已经取得了明显的效果。 1． 配置库的设置

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。

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

2． 分支的划分

在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，我们基本上为每个配置项从建立开始就划分成3个不同的分支，让它们分别对应3类工作空间。

l 私有分支

私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。

l 集成分支

集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。

l 公共（主干）分支

公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。

上面定义的3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 3． 变更控制

对于大型的软件开发项目，无控制的变更将迅速导致混乱，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的的机制。本文所涉及的变更控制的对象主要指配置库中的各基线配置项。变更管理的一般流程是：

A) 由开发人员或系统集成员提出变更需求；

B) 由SCCB（软件变更控制委员会）审核并决定是否批准；

C) 配置管理员根据SCCB的决定临时开放相应的权限，并备案；

D) 系统集成员执行相应的变更。

在这里，将要涉及的变更控制分为两类：一类是基线的变更控制，另一类是软件版本的变更控制。 l 基线的变更控制

基线的变更是指在一个软件版本的开发周期内对基线配置项的变更，主要包括基线的应用和更新等活动。

基线变更所涉及的操作主要包括基线标签的定义和标签的使用。基线标签属于严格受控的配置项，它的命名必须严格按照相关的命名规范来进行。基线在建立时，按照角色职责的分工，须经SCCB同意并以正式的将该基线的标识和作用范围通知系统集成员，由后者负责执行；基线一旦划定，由该基线控制的各配置项的历史版本均处于锁定或严格受控状态，任何对基线位置的变更请求都必须按变更控制流程，提交SCCB批准，然后由系统集成员执行。

l 软件版本的变更

软件版本的命名规范应事先制定，并按照开发计划予以发布使用。在软件版本的演进过程中既需要从以前的版本中继承，又需要相对的独立性。所以在对于一个子版本（例如某特定用户的定制版本）就需要对一系列配置项从统一的开发起始基线所确定的版本上建立新的分支，然后在此分支上开发新的版本。因此在这样的变更控制流程中，受控的对象还应包括特定的分支类型，以及工作视图的选取规则，同时配置管理员将在这一过程中担负更多的操作职责。

上述几点是笔者在从事软件配置管理过程中的一些心得体会，在此抛砖引玉，供大家参考。

本文来自《PMT评论》总第23期