软件配置管理(SCM)是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。 (Software configuration 管理学 (SCM, or just plain CM) is an organizational framework — that is, a discipline — for managing the evolution of computer systems throughout all stages of systems development.)

SCM（Software Configuration Management，软件配置管理）是一种标识、组织和控制修改的技术。它应用于整个软件生存期。在软件建立时会经常产生变更，而变更加剧了项目中软件人员之间的混乱。之所以产生混乱，是因为在进行变更前没有仔细分析，或没有进行变更控制。因为变更在任何时刻都可能发生，因此软件配置管理活动的目标就是为了标识变更，控制变更，确保变更正确地实现，向其他有关的人报告变更。软件配置管理是一组追踪和控制活动，它们开始于软件开发项目开始之时，结束于软件被淘汰之时。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。

软件配置管理（Software Configuration Management，SCM）作为CMM2级的一个关键域（Key Practice Area，KPA），在整个软件的开发活动中占有很重要的位置。正如Pressman所说的：“软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现，以及（4）向其他可能有兴趣的人员报告变化。”所以，我们必须为软件配置管理活动设计一个能够融合于现有的软件开发流程的管理过程，甚至直接以这个软件配置管理过程为框架，来再造组织的软件开发流程。

如果没有软件配置管理，最大的麻烦是工作成果无法回溯。为了避免成果被覆盖，包括我自己在内的很多人早期采用手工管理版本的方式，例如当一个新版本产生时用当时的日期来命名文件夹，然后再复制一下以后的修改在复制的文件夹内进行，这样上一个版本就被保存下来了，周而复始不同的版本不会被覆盖。虽然这种方式可以从某种程度上解决版本的回溯问题，但他存在的缺点是显而易见的：第一点如果保留结果过于频繁，将会导致产生大量的有着重复内容的文件夹，庞大的物理空间，管理起来很麻烦；如果保留旧版本的时间间隔太长，可能产生某些有用的老程序无法回溯。第二容易产生版本的混乱，如果是团队开发软件，这种简单的方法更难解决问题的本质了。

配置管理的方法是成熟的，而且相应的软件工具也是成熟的，基本上不存在看不懂、不会用的问题。配置管理的执行效果如何，完全是事在人为。妨碍配置管理的主要问题是人们嫌麻烦和侥幸心理作怪。

在没出乱子的情况下，执行版本控制看起来有些麻烦。每次修改工作的时候总是要Get Latest Version，接着Check Out，修改完后又要Check In，多做了三步。其实这三步加起来也就十几秒钟，而且不费脑子，根本没有添加多少麻烦，仅仅是个人感觉不爽而以。然而不执行版本控制的话，万一发生工作成果被覆盖或丢失等问题，麻烦就大了。

软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，他们都应当妥善地保管起来，以便查阅和修改。如果把所有文件一股脑的塞进计算机里，那么使用起来很麻烦。

凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：一类是属于产品的组成部分，例如需求文档、设计文档、源代码、测试用例等等；另一类是在管理过程中产生的文档，例如各种计划、报告等。

每个配置项的主要属性有名称、标识符、文件状态、版本、作者、日期等。配置项及历史纪录反映了软件的演化过程。

基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被冻结后，不能再被任何人随意更改。基线通常对应于开发过程中的里程碑。通常将交付该客户的基线称为一个Release，为内部开发用的基线称为一个Build。

版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混乱等现象。配置项的状态有三种：“草稿”、“正式发布”和“正在修改” 。

配置项的版本号与配置项的状态紧密相关：

（1）处于“草稿”状态的配置项的版本号格式为：0.YZ

（2）处于“正式发布”状态的配置项的版本号格式为：X.Y。

一般只是Y值递增，当Y值到达一定的范围时X值才发生变化。

（3）处于“正在修改”状态的配置项的版本号格式为：X.YZ。

一般只增大Z值，当配置项修改完毕，状态重新变成“正式发布”时，将Z值变为0，增加X.Y值。

配置管理的概念源于美国空军，为了规范设备的设计与制造，美国空军1962年制定并发布了第一个配置管理的标准“AFSCM375-1，CM During the Development \u0026 Acquisition Phases”。

而软件配置管理概念的提出则在20世纪60年代末70年代初。当时加利福尼亚州大学圣巴巴拉分校的Leon Presser教授在承担美国海军的航空发动机研制合同期间，撰写了一篇名为“Change and Configuration Control”的论文，提出控制变更和配置的概念，这篇论文同时也是他在管理该项目（这个过程进行过近一千四百万次修改）的一个经验总结。

Leon Presser在1975年成立了一家名为SoftTool的公司，开发了配置管理工具：Change and Configuration Control（CCC），这是最早的配置管理工具之一。

随着软件工程的发展，软件配置管理越来越成熟，从最初的仅仅实现版本控制，发展到现在的提供工作空间管理、并行开发支持、过程管理、权限控制、变更管理等一系列全面的管理能力，已经形成了一个完整的理论体系。同时在软件配置管理的工具方面，也出现了大批的产品，如：最著名的ClearCase；开源产品CVS；入门级工具微软 VSS；新秀Hansky Firefly。

在国外已经有30多年历史的软件配置管理，但在国内的发展却是在21世纪这几年的事。但是通过专家们的介绍，我们感受到，国内的软件配置管理已经取得了迅速发展，并得到了软件公司的普遍认可。

软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。它的基本目标包括：

目标 1: 软件配置管理的各项工作是有计划进行的。

目标 2: 被选择的项目产品得到识别，控制并且可以被相关人员获取。

目标 3: 已识别出的项目产品的更改得到控制。

目标 4: 使相关组别和个人及时了解软件基准的状态和内容。

为了达到上述目标，如下的方针应该得到贯彻执行：

技术部门经理和具体项目主管应该使用和遵循XSSC的OSSP中所描述的软件配置管理的工作过程。

施行软件配置管理的职责应被明确分配。相关人员得到软件配置管理方面的培训。

技术部门经理和具体项目主管应该明确他们在相关项目中所担负的软件配置管理方面的责任。

软件配置管理工作应该享有足够的资金支持，这需要在客户，技术部门经理和具体项目主管之间协商。

软件配置管理应该实施于如下产品：对外交付的软件产品，以及那些被选定的在项目中使用的支持类工具等。

软件配置的整体性在整个项目生命周期中得到控制。

软件质量保证人员应该定期审核各类软件基准以及软件配置管理工作。

使软件基准的状态和内容能够及时通知给相关组别和个人。

现在常用的软件配置管理工具主要分为三个级别：

Rational ClearCase，CA CCC/Havest

Merant PVCS

微软 VSS，电脑视疲劳综合症

对于任何一个管理流程来说，保证该流程正常运转的前提条件就是要有明确的角色、职责和权限的定义。特别是在引入了软件配置管理的工具之后，比较理想的状态就是：组织内的所有人员按照不同的角色的要求、根据系统赋予的权限来执行相应的动作。因此，在本文所介绍的这个软件配置管理过程中主要涉及下列的角色和分工：

项目经理（Project Manager，PM）：

项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。其具体职责为以下几项：

制定和修改项目的组织结构和配置管理策略；批准、发布配置管理计划；决定项目起始基线和开发里程碑；接受并审阅配置控制委员会的报告。

配置控制委员会（Configuration Control Board，CCB）：

负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体职责为以下几项：

定制开发子系统；定制访问控制；制定常用策略；建立、更改基线的设置，审核变更申请；根据配置管理员的报告决定相应的对策。

配置管理员（Configuration Management Officer，CMO）：

根据配置管理计划执行各项管理任务，定期向CCB提交报告，并列席CCB的例会。其具体职责为以下几项：

软件配置管理工具的日常管理与维护；提交配置管理计划；各配置项的管理与维护；执行版本控制和变更控制方案；完成配置审计并提交报告；对开发人员进行相关的培训；识别软件开发过程中存在的问题并拟就解决方案。

系统集成员（System Integration Officer，SIO）：

系统集成员负责生成和管理项目的内部和外部发布版本，其具体职责为以下几项：

集成修改；构建系统；完成对版本的日常维护；建立外部发布版本。

开发人员（Developer，DEV）：

开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型来完成开发任务。

一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。

一个项目设立之初PM首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。

在软件配置管理计划的制定过程中，它的主要流程应该是这样的：

CCB根据项目的开发计划确定各个里程碑和开发策略；

CMO根据CCB的规划，制定详细的配置管理计划，交CCB审核；

CCB通过配置管理计划后交项目经理批准，发布实施。

这一阶段时项目研发的主要阶段。在这一阶段中，软件配置管理活动主要分为三个层面：（1）主要由CMO完成的管理和维护工作；（2）由SIO和DEV具体执行软件配置管理策略；（3）变更流程。这三个层面是彼此之间既独立又互相联系的有机的整体。

在这个软件配置管理过程中，它的核心流程应该是这样的：（1）CCB设定研发活动的初始基线；（2）CMO根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理就阿做好准备；（3）开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作；（4）SIO按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进；（5）CCB根据项目的进展情况，审核各种变更请求，并适时的划定新的基线，保证开发和维护工作有序的进行。

这个流程就是如此循环往复，直到项目的结束。

当然，在上述的核心过程之外，还涉及其他一些相关的活动和操作流程，下面按不同的角色分工予以列出：

各开发人员按照项目经理发布的开发策略或模型进行工作；

sio负责将各分项目的工作成果归并至集成分支，供测试或发布；

SIO可向CCB提出设立基线的要求，经批准后由CMO执行；

CMO定期向项目经理和CCB提交审计报告，并在CCB例会中报告项目在软件过程中可能存在的问题和改进方案；

在基线生效后，一切对基线和基线之前的开发成果的变更必须经CCB的批准；

CCB定期举行例会，根据成员所掌握的情况、CMO的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。

Pressman对于配置项（Software Configuration Item，SCI）识别给出了一个比较简单的定义：“软件过程的输出信息可以分为三个主要类别：（1）计算机程序（源代码和可执行程序），（2）描述计算机程序的文档（针对技术开发者和用户），以及（3）数据（包含在程序内部或外部）。这些项包含了所有在软件过程中产生的信息，总称为软件配置项。”

由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。

软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线（Base Line）”这一概念。IEEE对基线的定义是这样的：“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。”

所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类。

配置项的标识和控制

所有配置项都都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。

所有配置项的操作权限应由CMO严格管理，基本原则是：基线配置项向软件开发人员开放读取得权限；非基线配置项向PM、CCB及相关人员开放。

在引入了软件配置管理工具之后，所有开发人员都会被要求把工作成果存放到由软件配置管理工具所管理的配置库中去，或是直接工作在软件配置管理工具提供的环境之下。所以为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，对工作空间的管理和维护也成为了软件配置管理的一个重要的活动。

一般来说，比较理想的情况是把整个配置库视为一个统一的工作空间，然后再根据需要把它划分为个人（私有）、团队（集成）和全组（公共）这三类工作空间（分支），从而更好的支持将来可能出现的并行开发的需求。

每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上。当然，由于选用的软件配置管理工具的不同，在对于工作空间的配置和维护的实现上有比较大的差异，但对于CMO来说，这些工作是他的重要职责，他必须根据各开发阶段的实际情况来配置工作空间并定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数据（Metadata）来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程改进（Software Process Improvement，SPI）活动的进行。

对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。

在对SCI的描述中，我们引入了基线的概念。从IEEE对于基线的定义中我们可以发现，基线是和变更控制紧密相连的。也就是说在对各个SCI做出了识别，并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就成为了软件配置管理的另一重要任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。

变更管理的一般流程是：

A) （获得）提出变更请求；

B) 由CCB审核并决定是否批准；

C) （被接受）修改请求分配人员为，提取SCI，进行修改；

D) 复审变化；

E) 提交修改后的SCI；

F) 建立测试基线并测试；

G) 重建软件的适当版本；

H) 复审（审计）所有SCI的变化；

I) 发布新版本。

在这样的流程中，CMO通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建立在前文所描述的版本控制和分支策略的基础上的。

配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。

配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。

配置状态报告应该包括下列主要内容：

A) 配置库结构和相关说明；

B) 开发起始基线的构成；

C) 当前基线位置及状态；

D) 各基线配置项集成分支的情况；

E) 各私有开发分支类型的分布情况；

F) 关键元素的版本演进记录；

G) 其它应予报告的事项。

配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。

总之，软件配置管理的对象是软件研发活动中的全部开发资产。所有这一切都应作为配置项纳入管理计划统一进行管理，从而能够保证及时的对所有软件开发资源进行维护和集成。因此，软件配置管理的主要任务也就归结为以下几条：（1）制定项目的配置计划；（2）对配置项进行标识；（3）对配置项进行版本控制；（4）对配置项进行变更控制；（5）定期进行配置审计；（6）向相关人员报告配置的状态。

国内很多软件企业已经逐渐认识到配置管理的重要性，都希望通过实施配置管理来提高软件开发管理的水平，增强企业自身的竞争力，应对市场的压力。

具体而言，用户可以在资金、管理水平和保护知识财富等方面得到切实收益。

Hansky配置管理系统的总体实施成本低；对硬件系统性能的要求低，可以跨平台使用，节约了用户的投资；安装简单，易于维护，无需专职的系统管理员；功能简洁、实用，易于学习和掌握，可以有效缩短配置管理系统投入实际使用的周期；良好的扩展性和灵活的License管理方式，以及组件式的解决方案，使得我们的配置管理系统既支持小组模式的用户，也能够支持大规模团队的协同开发工作，并且能够方便地进行扩展，用户可以根据实际需要，灵活的配置，大大降低了降低初期投入的资金；具有前瞻性，保护用户的投资。Hansky公司的软件配置管理产品采用最新的技术（如纯TCP/IP技术、JBoss技术、MS .NET的开发环境等）和全新的应用模式（如三层结构、B/S应用结构等），确保系统在较长的时间内不会落后于同类产品或不需要技术上的更新；自带存储库增量备份/恢复功能，节约用户在备份方面的支出。

利用Hansky的Firefly系统对开发资源进行版本管理和跟踪，可以建立公司级的代码知识库，保存开发过程中的所有历史版本，这样大大提高了代码的复用率，还便于同时维护多个版本和进行新版本的开发，最大限度地共享代码。利用Butterfly组建开发团体之间的问题跟踪及消息通讯机制，通过与电子邮件系统的结合大大增强了开发团体之间的沟通能力，通过丰富的报表功能可对发现的问题进行整理、以报表方式分类报出，作为开发的指导。通过使用Hansky的配置管理套件可以提高开发效率和产品质量，避免了代码覆盖、沟通不够、开发无序的混乱局面，大大缩短了产品的开发周期。

使用Hansky的软件配置管理解决方案后，用户可以在Hansky技术专家的帮助下建立规范的配置管理流程，所有的软件产品将得到统一有效的管理。借助Firefly和Butterfly，工程人员可以通过访问服务器直接获取所需的最新版本，查找公司的知识库，提交变更请求，收集用户的反馈意见。开发人员无需到现场即可再现用户环境，集中解决问题，发布补丁。这样可以同时响应多个地点的项目，防止开发人员分配到各个项目点、力量分散、人员不够的弊端，同时节约大量的旅差费用。

(1) 改进用户的开发工作模式

使用Hansky的配置管理解决方案，可以有效地改进用户的软件开发模式和过程，提高企业软件能力成熟度的级别。

借助Firefly和Butterfly，用户可以：

有效的管理工作空间，各个成员的具有独立的工作空间，并能记录其变更集和整个生命周期中的完整变更历史；

简便建立分支，支持分支之间的比较与合并，归并，管理基线；

支持并行开发模式，提高开发效率；

支持异地开发，Firefly通过自动或手动同步不同开发地点的的存储库，为地理分布的开发团队提供很好的支持；

集成变更请求管理与项目生存周期中的变更记录与追踪，优化测试流程；

完善的发布管理，可以方便的回溯任意版本，为不同的用户定制应用程序的版本，促进系统的快速部署，提供发布版本内容的审计能力；

支持变更集和原子事务，确保变更的一致性；

支持离线的版本管理，帮助用户记录项目证明周期内的完整历史；

内置Defect、RFE、Task（问题、建议、任务）工作流，符合正规软件公司的软件开发流程。科学的工作流系统可以使公司人员工作起来得心应手，有条不紊，从而大大提高工作效率。

(2) 加强项目管理能力

通过浏览器，项目负责人可以方便地查看项目进展情况以及员工工作情况；

利用Web界面即可实现代码复查和项目状态复查；

丰富的图表、报告功能，可以自动生成变更统计报告、配置审计报告，支持过程管理与进度分析，能够帮助管理者进行决策。

(3) 量化工作量考核

传统的开发管理中，工作量一直是难以估量的指标。靠开发人员自己把握，随意性过大；靠管理人员把握，主观性又太强。采用Firefly和Butterfly管理后，系统能够客观的记录员工的工作内容和质量，可以作为工作量的衡量指标。

(4) 规范测试流程

Butterfly和Firefly集成后，可以有效地跟踪和处理软件的变更，完整地记录测试人员的工作内容，测试有了实实在在的工作，测试人员根据修改描述细节对每一天的工作做具体的测试。对测试人员也具有相应的可考核性，这样环环相扣，有效地增强了对测试的管理。

(5) 加强协调与沟通，增加团队竞争力

使用Firefly保存公司的所有知识财富、利用Butterfly的FAQ、检索以及Email自动通知功能，有效地加强了项目成员之间的沟通，做到有问题及时发现、及时修改、及时通知，却又不会额外增加很多的工作量，大大提高了开发团队的协同工作效率。

从整个企业的发展战略来说，如何在技术日新月异、人员流动频繁的情况下，本公司的知识库及经验库，把个人的知识及经验转变为公司的知识和经验，这对于提高工作效率、缩短产品周期以及提高公司的竞争力都具有至关重要的作用。采用科学的配置管理思想，辅之以先进的配置管理工具，可以帮助用户在内部建立完善的知识管理体系。

(1) 代码对象库

软件代码是软件开发人员脑力劳动的结晶，也是软件公司的宝贵财富，长期开发过程中形成的各种代码对象就像一个个零件一样，是快速生成系统的组成部分。然而长期以来的一个事实是：一旦某个开发人员离开工作岗位，其原来所编写的代码便基本成为垃圾，无人过问；或者由于文档不全，无从考究。究其原因，就是没有专门对每个开发人员的代码、组件和文档进行科学的管理，将其应用范围扩大到公司一级，进行规范化，加以说明和普及。Firefly为代码管理提供了一个平台和仓库，有利于建立公司级的代码对象库，增进代码复用，提高开发重用率和软件质量。

(2) 业务及经验库

通过Firefly和Butterfly，可自动生成完整的开发日志及问题集合，用文字记录开发的整个过程，不会因某人的流动而消失，有利于公司积累业务经验，无论对软件维护或版本升级，都具有重要的指导作用。此外，利用Butterfly内建的FAQ模块，可以建立检索方便的经验库，传播和共享集体的智慧。

(3) 安全性和可靠性

由于配置管理系统集中存储了企业的重要知识财富，因此对其安全性和可靠性有极高的要求。Firefly可以对所有存储的文件进行冗余校验，使用MD5作为文件的校验和，并提供备份和恢复工具，确保了数据的可靠性。同时Firefly支持用户身份验证和访问控制，支持用户组，便于权限设置。访问控制可以针对分支、目录，甚至单个文件设置，采用类似Windows NTFS的权限管理方式，既灵活又安全。这些措施使得企业的知识财富得到了安全可靠的存储和保护。

另外，由于Hansky的产品采用了三层结构设计，其存储库完全不依赖于网络文件体统，无需共享存储目录，能够有效防止病毒攻击所导致的存储库瘫痪或损坏，同时杜绝网络非法访问。