软件配置管理（简称SCM）给使用者支持，管理资料库，并维持基线的完整性。先进的自动化工具，基线的生成，维护和产品的交付都要求细致和细节化的规划。为了工作更有效率，SCM必须辅以每日的强化，更新和维护。

不管你走到哪，面对什么人，只要你问起“SCM是一个支持组织还是管理组织？”即使你问的是两个在同一项目中工作的同事，你也很有可能得到两个不同的答案。那些疑心这是个坑人的问题或想显得懂得挺多的人可能会回答：“当然两者皆是。”但一旦要继续问“两者皆是”是什么意思？他们通常都会有更重要的事要先处理。

真正的答案是SCM是一个集支持与管理为一体的组织，但当它被正确的运用后，人们不得不开始考虑第三个要素，服务。

如果你跟软件工程师谈起这个问题，他们可能会告诉你，他们的确需要支持和一定量的管理，但不要太多。管理人员则一般会说管理是一个相对更重要的问题，如果这些管理不太耗资金和时间。一个有10年甚至更丰富经验的老SCM人，譬如一位一线主管或经理会同意这位管理人员的意见，也会坚持认为有些时候这些资金和时间是不可避免的需要投入的。一个SCM新人则很有可能会同意那些软件工程师的意见，并力图尽其可能的帮助他把工作完成。

这个问题变成了“SCM怎样才能在项目工作量增加的情况下，既能很好地完成支持、管理工作，又为项目提供服务？”

支持：SCM是一个提供支持的组织。它能给予项目工程师，项目本身，公司本身提供支持，甚至在很多情况下它也能对公司客户提供支持。

管理：SCM也是一个管理组织。它能对各种规格说明，文档，图表，需求，工具，软件及其它可交付物进行管理。

服务：SCM同时还是一个服务提供者。它提供各种支持并管理产出。这个看似简单的词却是一个成功的SCM系统中最重要的关键词。

SCM工作人员通常应具备两项能力：一是对公司工作提供支持，另一个则是管理产出。但当这两种工作被混淆，亦即SCM人员尝试管理开发人员工作的时候，麻烦和瓶颈就出现了。一般在这个时候，真正的SCM就会被绕过，人们通常用的籍口是“算了，以后再修改。”

这样一来，SCM经理的责任就包括：

• 确保SCM工程师都经过专业正式的培训，并且有一定量的资源（包括预算和工具）来有效的完成工作。
• 确保每一个项目支持方案既能够量身定做，又能平衡支持与管理。
• 确保SCM的功能非常灵活，能够适应工程师、客户、项目或公司本身不断变化的需求。

前景预测：

SCM的任务在过去的20-30年中并没有太大改变。然而，SCM工作的环境却有了相当大的变动；而且这种变动很有可能继续下去。软件的应用语言变了：从Basic, COBOL和FORTRAN，到Ada和Pascal，再到C++，Java等等。但这并未能真正给SCM冲击，毕竟代码换了个名字还是代码。

真正的给SCM带来影响力的冲动，来自于自动化工具和配置库系统的使用。

工具从版本控制和半自动化构造，发展到能建立和监视整个软件开发和产品环境。工具已变得更复杂精密，供应商也越来越多。不久前，对于SCM来说选择工作中需要的最佳操作工具还只是小菜一碟，但在如今的市场，在做出决定之前新的论点得先被提出来。对于各个工程部的代表们来说，在着手工作之前先根据他们自己的要求，考虑、评估和衡量各种可使用的工具和这些工具的工作能力，变得越来越重要。

今天SCM可使用的自动化工具，及其应用于制图方面的工具，都比以前的类似功能的工具要先进强大许多。但被问及“难道没有一个工具是可以做所有这些工作的吗？”时，答案仍然是否定的。主要原因在于，SCM的操作环境仍在不断发展着。

在近几年里，SCM一直在处理代码和一些文件，这些东西通常都被塞在基线里，因为这样一来，它们能相当方便地被管理。但随着基于WEB的配置库的引入，不断发展的商业离岸销售和子合同分包应用，基线，正如当初所定义的，迅速的变成了一个很自然的概念。想想你最后一次看到一个功能基线，分配基线或产品基线是什么时候的事了？可能是某次你处理硬拷贝文件或打印的程序表的时候？而在一个电子化的办公室里，你再找不到这些东西了。现在的趋势是以查阅现有的受控版本（如代码，文档和需求等等.）取代查阅基线版本；较早前则是这些受控的版本做为被归档的基线版本查阅。

在过去，大部分的程序同时有三种基线操作：功能线，分配线和产品线（或需求线，设计线和产品线，或其它类似配套的描述性标签）。美国航空航天局（NASA）曾经尝试建立了一个有9条基线的系统，不过这个系统持续时间并不长。NASA，还有其它许多开发人员，认为了解受控项在哪条基线上非常重要，并且一直往这个方向努力。这关系到受控项已被基线化，这样它就不能在没有经过正式的处理流程前被改变，并且还需要给这个受控项的电子部分取个名字。

是什么把他们的注意力终于从之前的3条基线上挪开呢？是SCM和其它开发工程师不断提出一问题，譬如“这个在不同文件中使用的JPG文件放在哪里呢？”“构造脚本和make 文件也应该受控吗？”和“我们可以在哪里管理公司的重用资产或重构？”

于是问题变成“控制委员会是管理文件还是文件包含的信息？”和“控制委员会管理的是软件代码还是别的？如果是，它是怎么工作的？又是怎么生成的？”在过去，SCM管理代码，有时候也包括文件。在我们正在开始处理应用的环境中，什么能被基线化呢？更简单的问题是“什么东西是不能被基线化的？”

答案：SCM能基线化所有针对某项目需要的东西，或使之可用。

答案：SCM能管理所有格式的资料，所以它能给人们支持并为项目提供一套完整的服务。

经验教训：

如果你不指望太多，看看SCM的标准，手册，指南，说明书等等，会发现SCM有4个主要功能：

1. 标识

2. 变更管理

3. 状态报告

4. 审计和验证

在几乎所有的教训中，计划都被忽略了。然而SCM还在使用更复杂的设备以建立和维护复杂的环境，比如在多重平台上建立多重基线，多重环境等等。象所有人一样，SCM不得不把项目做得更快，用更少的资金，更聪明的方式并且要比以往都好。计划则变得比以往任何时候都重要。在过去的10年里，人们一直相信这样的话：“让他们去做SCM。总得有人做它，然后其它人都能迅速的学会使用它。”现在这句话已逐渐失去可信性。这个工作变得太技术化，也太复杂，对于需要学会这项操作的人来说，它依赖于太多的变数。

事实如此，SCM仍然相当依赖于在职培训。没有哪所大学或学院提供4年的SCM专业课程。现在学术界已认识到这项工作所包含的复杂性。一些2年制的专科学院开始提供SCM的认证课程。1998年，我曾与3个在读博士生一起工作过，他们各自的论文都与SCM及其功能有关。

如果这些都是真实的，则计划不能被简单的认为是“写一个SCM计划。”计划是一个非常好的开始，但我们需要的不只是一纸解释SCM所扮演的角色和责任的文章。SCM计划中需要包括：

度量——多长时间，多少，什么时候和哪里？

技术综合——需要控制什么，谁拥有它，谁能得到它？

管理结构——谁在做什么，在哪里，什么时间，怎样做？

可能性——如果发生了，会产生什么结果？

工作量跟踪——需要人力及其素质，花费的人时

转包商——责任和权利

资源——预算，工具许可证，培训，管理开销

矩阵式管理——分布的工作队伍

管理转换——非正式到正式到分领域

记录保存——保存什么，哪里保存，保存多长时间？

管理——谁管理，管理什么，他们怎样进行管理？

过程——可重复的标准化程序

实案1

去年，东南部某大型宇航公司的一位SCM经理推荐购买一个自动化的SCM系统，这个系统可以满足SCM组列出的所有要求。管理部门暂时搁置了此推荐，希望其它工程部门给出这个工具的评审意见。最后此购买计划被取消了。工具的确给予了SCM部门支持，但它没有对工程师们列出的开发中需考虑的因素给予足够支持。不久后，他们买了另外一个工具，这个工具满足了SCM、软件工程师、软件质量保证、测试、集成以及管理层的所有主要需求。

实案2：

最近到一个位于新英格兰的私人企业访问（此企业不为政府所有），我发现工程师在使用SCM中最担心的是所谓限制。他们被错误的引导认为SCM意味着正式的管理，受限的访问，创造性的解决方案受到限制等等。当我解释资料能通过一系列的非正式管理步骤被转换为正式的管理基线，而且SCM并不等于完全禁闭或瓶颈，他们变得热切想加入到SCM的建设中来。一些会谈之后，一个逐步规范建立正式的SCM方法通过了，以取代非正式的管理和资料收集，这样可以产生基线项。每个人都对此而感到欣喜。工程师们很快意识到他们可以与SCM一起像一个团队一样工作来解决问题，而不是两个只关心自己和使用自己的方式解决问题的独立组织。更重要的是，SCM组懂得，当他们走出自己的办公室走到工程师中间时（即给予支持-面向服务），他们很快会变成开发过程以及开发团队的一个有机整体。

结论

在以上的两个案例中，SCM组和工程师们很快意识到他们可以象一个团队一样工作解决问题，而不是两个各不相干不相往来的独立体。一流的SCM运做只能通过对SCM的4个主要功能进行周到的计划才能实现。随着自动化的SCM工具和基线应用变得越来越复杂，SCM的基本原则已经开始有了新变化。SCM支持工程师，管理资料并提供维持基线完整性的服务。如果你所工作的地方，SCM不是这样工作的，那么现在该是时候问一声：为什么我们不是这样？

关于作者

Bruce Angstadt是纽约韦伯斯特的Xerox公司的软件过程改进经理。他为政府和产业公司做了35年工程支持方面的工作。他最感兴趣的领域是技术培训和软件配置管理。在为Xerox工作之前，他曾受雇Bell工作室的Navy和Harris公司。他同时还在加州的Systems Technology Institute of Malibu大学讲授一系列配置管理的课程。他毕业于佛罗里达州的奥兰多的Rollins College，是心理学和企业管理双学士。