软件配置管理（SCM）

软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。我们知道，在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。

 

 

目录

概况

1. 简介
2. Version Control-版本控制
3. Change Control-变更控制
4. Process Support-过程支持

介绍

迅速发展的软件配置管理

基本目标

XSSC有关软件配置管理的方针

常用的软件配置管理工具

软件配置管理角色职责

软件配置管理过程描述

1. 概述
2. 项目计划阶段
3. 项目开发维护阶段

关键活动

1. 配置项
2. 工作空间管理
3. 版本控制
4. 变更控制
5. 状态报告
6. 配置审计

实施配置管理的收益

展开

概况

1. 简介
2. Version Control-版本控制
3. Change Control-变更控制
4. Process Support-过程支持

介绍

迅速发展的软件配置管理

基本目标

XSSC有关软件配置管理的方针

常用的软件配置管理工具

软件配置管理角色职责

软件配置管理过程描述

1. 概述
2. 项目计划阶段
3. 项目开发维护阶段

关键活动

1. 配置项
2. 工作空间管理
3. 版本控制
4. 变更控制
5. 状态报告
6. 配置审计

实施配置管理的收益

展开

 

编辑本段概况

简介

软件配置管理（Software Configuration Management），又称软件形态管理、或软件建构管理，简称软件形管（SCM）。界定软件的组成项目，对每个项目的变更进行管控（ 版本控制），并维护不同项目之间的版本关

 

联，以使软件在开发过程中任一时间的内容都可以被追溯，包括某几个具有重要意义的数个组合。

软件配置管理，贯穿于整个 软件生命周期，它为软件研发提供了一套管理办法和活动原则。 软件配置管理无论是对于 软件企业管理人员还是研发人员都有着重要的意义。 软件配置管理可以提炼为三个方面的内容：

Version Control-版本控制

版本控制是全面实行 软件配置管理的基础，可以保证 软件技术状态的一致性。我们在平时的日常工作中都在或多或少地进行 版本管理的工作。比如有时我们为了防止文件丢失，而拷贝一个后缀为bak或日期的 备份文件。当文件丢失或被修改后可以通过该 备份文件恢复。版本控制是对系统不同版本进行标识和跟踪的过程。版本标识的目的是便于对版本加以区分、检索和跟踪，以表明各个版本之间的关系。一个版本是 软件系统的一个 实例，在功能上和性能上与其他版本有所不同，或是修正、补充了前一版本的某些不足。实际上，对版本的控制就是对版本的各种操作控制，包括检入检出控制、版本的分支和合并、版本的历史记录和版本的发行。

Change Control-变更控制

进行变更控制是至关重要的。但是要实行变更控制也是一件令人头疼的事情。我们担忧变更的发生是因为对 代码的一点小小的干扰都有可能导致一个巨大的错误，但是它也许能够修补一个巨大的 漏洞或者增加一些很有用的功能。我们担忧变更也因为有些流氓 程序员可能会破坏整个项目，虽然智慧思想有不少来自于这些流氓程序员的头脑。过于严格的控制也有可能挫伤他们进行创造性工作的积极性。但是，如果你不控制他，他就控制了你！

Process Support-过程支持

一般来说，人们已渐渐意识到了 软件工程过程概念的重要性，而且人们也逐渐了解了这些概念和软件工程支持技术的结合，尤其是 软件过程概念与CM有着密切的联系，因为CM理所当然地可以作为一个管理变更的规则（或过程）。如IEEE 软件配置管理计划的标准就列举了建立一个有效的CM规则所必需的许多关键过程概念。但是，传统意义上的 软件配置管理主要着重于软件的 版本管理，缺乏 软件过程支持的概念。在大多数有关软件配置管理的 定义中，也并没有明确提出配置管理需要对过程进行支持的概念。因此，不管软件的 版本管理得多好，组织之间没有连接关系，组织所拥有的是相互独立的信息资源，从而形成了信息的"孤岛"。在CM提供了过程支持后，CM与CASE环境进行了集成，组织之间通过过程驱动建立一种单向或双向的连接。对于开发员或测试员则不必去熟悉整个过程，也不必知道整个团队的开发 模式。他只需集中精力关心自己所需要进行的工作。在这种情况下，可以延续其一贯的工作 程序和处理办法。

编辑本段介绍

软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。 软件配置管理应用于整个 软件工程过程。我们知道，在软件建立时变更是不可避免的，而变更加剧了项目中 软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员 报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高 生产效率。

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

编辑本段迅速发展的软件配置管理

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

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

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

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

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

编辑本段基本目标

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

目标 1: 软件配置管理的各项工作是有计划进行的。目标 2: 被选择的项目产品得到识别，控制并且可以被相关人员获取。目标 3: 已识别出的项目产品的更改得到控制。目标 4: 使相关组别和个人及时了解软件基准的状态和内容。

编辑本段XSSC有关软件配置管理的方针

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

技术部门经理和具体项目主管应该使用和遵循XSSC的 OSSP中所描述的 软件配置管理的工作过程。施行 软件配置管理的职责应被明确分配。相关人员得到 软件配置管理方面的培训。技术部门经理和具体项目主管应该明确他们在相关项目中所担负的 软件配置管理方面的责任。 软件配置管理工作应该享有足够的资金支持，这需要在 客户，技术部门经理和具体项目主管之间协商。 软件配置管理应该实施于如下产品：对外交付的软件产品，以及那些被选定的在项目中使用的支持类工具等。 软件配置的整体性在整个 项目生命周期中得到控制。 软件质量保证人员应该定期审核各类软件基准以及 软件配置管理工作。使软件基准的状态和内容能够及时通知给相关组别和个人。

编辑本段常用的软件配置管理工具

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

l Rational ClearCase，CA CCC/Havest l Merant PVCS l Microsoft VSS，CVS

常用的开源免费的 软件配置管理工具有：SVN ^[1] 、 GIT ^[2] 、CVS ^[3] 。

编辑本段软件配置管理角色职责

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

项目经理（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通过配置管理计划后交项目经理批准，发布实施。

项目开发维护阶段

这一阶段是项目研发的主要阶段。在这一阶段中， 软件配置管理活动主要分为三个层面：

⑴主要由CMO完成的管理和维护工作；

⑵由SIO和DEV具体执行 软件配置管理策略；

⑶变更流程。这三个层面是彼此之间既独立又互相联系的有机的整体。

在这个 软件配置管理过程中，它的核心流程应该是这样的：

⑴CCB设定研发活动的初始 基线；

⑵CMO根据 软件配置管理规划设立配置库和 工作空间，为执行 软件配置管理计划做好准备；

⑶开发人员按照统一的软件配置管理 策略，根据获得的授权的资源进行项目的研发工作；

⑷SIO按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进；

⑸CCB根据项目的进展情况，审核各种变更请求，并适时的划定新的 基线，保证开发和维护工作有序的进行。

这个流程就是如此循环往复，直到项目的结束。当然，在上述的核心过程之外，还涉及其他一些相关的活动和操作流程，下面按不同的角色分工予以列出：

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

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

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

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

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

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

综上所述，配置管理的工作流程如图1所示：

软件配置管理

编辑本段关键活动

配置项

配置项（Software Configuration Item，SCI）配置项

Pressman对于SCI给出了一个比较简单的 定义：“ 软件过程的输出信息可以分为三个主要类别：

⑴计算机 程序（ 源代码和可执行程序），

⑵描述计算机 程序的文档（针对技术开发者和用户），

⑶数据（包含在 程序内部或外部）。这些项包含了所有在 软件过程中产生的信息，总称为 软件配置项。”

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

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

所以，根据这个 定义，我们在软件的开发流程中把所有需加以控制的 配置项分为 基线配置项和非基线配置项两类，例如：基线配置项可能包括所有的设计文档和 源程序等；非基线配置项可能包括项目的各类计划和 报告等。

配置项的标识和控制

所有 配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。在引入 软件配置管理工具进行管理后，这些 配置项都应以一定的目录结构保存在配置库中。所有 配置项的操作权限应由CMO严格管理，基本原则是： 基线配置项向 软件开发人员开放读取得权限；非基线配置项向PM、CCB及相关人员开放。

工作空间管理

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

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

每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的 工作空间上，例如：对于私有开发空间而言，开发人员根据任务分工获得对相应 配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素；而集成分支对应的是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限，它的管理工作由SIO负责；至于公共工作空间，则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的标准版本，并作为整个组织的Knowledge Base。

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

版本控制

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

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

变更控制

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

在本文的前面的部分中，已经把SCI分为 基线配置项和非基线配置项两大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置项。变更管理的一般流程是：

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

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

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

D) 复审变化；

E) 提交修改后的SCI；

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

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

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

I) 发布新版本。

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

状态报告

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

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

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

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

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

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

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

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

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

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

配置审计

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

总之， 软件配置管理的对象是软件研发活动中的全部开发资产。所有这一切都应作为 配置项纳入管理计划统一进行维护和集成。因此， 软件配置管理的主要任务也就归结为以下几条：

⑴制定项目的配置计划；

⑵对 配置项进行标识；

⑶对 配置项进行 版本控制；

⑷对 配置项 进行变更控制；

⑸定期进行配置审计；

⑹向相关人员 报告配置的状态。

在此，我想特别指出的是：由于 软件配置管理覆盖了整个软件的开发过程，因此它是改进我们的 软件过程、提高过程能力成熟度的理想的切入点。希望本文所描述的这个 软件配置管理的角色分配和工作流程能在实践中不断地得到完善，从而使我们的 软件开发活动能够更加有序、高效的进行！

编辑本段实施配置管理的收益

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

针对市场的这些需求，Hansky公司在 中国市场推出了业界技术领先的 软件配置管理解决 方案，产品包括配置管理工具Firefly和变更管理工具Butterfly。Firefly是Hansky公司推出的 软件配置管理系统，它可以轻松管理、维护整个企业的软件、 代码和文档。Firefly是一个高性能、运行速度极快的 软件配置管理系统，支持不同的开发、运行平台，因此它能在整个企业中的不同团队、不同项目中都得以广泛的应用。Firefly能够对团队开发提供有力的支持，开发团队一旦拥有了Firefly，就可以非常准确的 定义：

软件将在什么时间发布；

当前发布版本中有哪些功能，由哪些组件构成；

当前版本中加入了针对哪些Bug的修改；

软件的某个修改是谁认可的；

如何建立新的发布版本；

等等…

Butterfly是Hansky公司提供的新一代的软件变更请求管理软件。它以软件产品为中心，有效的协调软件项目中各职位人员的工作，能够使软件项目在较短时间内高质量完成。

Butterfly的主要功能如下：

提供对开发过程中的缺陷、建议和任务的追踪管理；

规划开发过程，完善 源代码编写，提高 软件重用率，最大限度保护企业知识财富；

提供丰富的 报表功能，以直观 图形统计开发人员的工作进度和编码质量，客观评价员工表现；

优化业务流程，科学的 工作流系统使用户工作起来有条不紊，大大提高工作 效率，同时用户可以根据实际情况简单、快捷地定制自己的业务流程；

掌握工作进度，在 软件开发的各个阶段进行都可以进行强大的过程控制；

开发人员可以明确地了解他被分配的开发任务，并根据优先级依次完成；

提供友好的人机界面，支持工作分配的 电子邮件自动通知，方便各种类型的工作人员使用，增加沟通和交流；

对软件的错误进行 系统管理，从根本上提高软件产品竞争力，提高产品质量；

加速开发进程，规范软件产品开发的各个阶段，避免浪费不必要的时间。

Hansky公司的配置管理解决 方案给公司带来的益处将是显而易见的：管理者能够轻松控制产品的进度、质量；开发人员将有更多的时间进行创造性的工作；测试人员将依照一个标准的流程高效完成日常工作；

产品发布人员能够确保交到用户手中的产品的质量。

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

节约用户资金

⑴ Hansky配置管理系统的总体实施成本低

对 硬件系统性能的要求低，可以跨平台使用，节约了用户的投资；

安装简单，易于维护，无需专职的系统 管理员；

功能简洁、实用，易于学习和掌握，可以有效缩短配置管理系统投入实际使用的 周期；

良好的扩展性和灵活的License管理方式，以及组件式的解决 方案，使得我们的配置管理系统既支持小组 模式的用户，也能够支持大规模团队的协同开发工作，并且能够方便地进行扩展，用户可以根据实际需要，灵活的配置，大大降低了降低初期投入的资金；

具有前瞻性，保护用户的投资。Hansky公司的 软件配置管理产品采用最新的技术（如纯TCP/ IP技术、J2EE技术、MS .NET的 开发环境等）和全新的 应用模式（如 三层结构、B/S应用结构等），确保系统在较长的时间内不会落后于同类产品或不需要技术上的更新；

自带存储库 增量备份/恢复功能，节约用户在备份方面的支出。

⑵ 缩短用户的产品开发周期

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

⑶ 降低产品的部署费用

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

提高 软件开发管理的水平

⑴ 改进用户的开发工作 模式

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

借助Firefly和Butterfly，用户可以：

有效的管理 工作空间，各个成员的具有独立的工作空间，并能记录其变更集和整个生命周期中的完整变更历史；　 简便建立分支，支持分支之间的比较与合并，归并，管理 基线； 支持并行开发 模式，提高开发效率； 支持异地开发，Firefly通过自动或手动同步不同开发地点的的存储库，为 地理分布的开发团队提供很好的支持； 集成变更请求管理与项目 生存周期中的变更记录与追踪，优化测试流程； 完善的发布管理，可以方便的回溯任意版本，为不同的用户定制 应用程序的版本，促进系统的快速部署，提供发布版本内容的审计能力； 支持变更集和原子 事务，确保变更的一致性； 支持离线的 版本管理，帮助用户记录项目证明周期内的完整历史； 内置Defect、RFE、Task（问题、建议、任务）工作流，符合正规软件公司的 软件开发流程。科学的工作流系统可以使公司人员工作起来得心应手，有条不紊，从而大大提高 工作效率。

⑵ 加强 项目管理能力

通过 浏览器，项目负责人可以方便地查看项目进展情况以及员工工作情况； 利用Web界面即可实现 代码复查和项目状态复查； 丰富的图表、 报告功能，可以自动生成变更统计报告、配置 审计报告，支持过程管理与进度分析，能够帮助管理者进行决策。

⑶ 量化工作量考核

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

⑷ 规范测试流程

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

⑸ 加强协调与沟通，增加团队竞争力

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

保护企业的知识财富

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

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

⑵ 业务及经验库

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

⑶ 安全性和可靠性

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

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