模板
教程
环境
性能
功能
管理
关于软件配置管理浅析
一、软件配置管理的基本概念
1. 软件配置和配置管理
计算机配置是说明计算机组成的一种专门术语。这种“组成”由用户的需求决定。通常，计算机系统由CPU、存储器、输入/输出设备、传输设备等组成；其中就存储器而言，除内存外，外存又分软盘、硬盘、光盘等，它们又有容量和速度之别。现在，可以将计算机配置定义为是用户根据不同用途，选择不同功能-性能的设备和部件组成的最优计算机系统的一种构建方案。推广到系统，则系统配置就是根据用户需求优选各种设备，组成最佳系统的一种建构方案（或者是按最佳性能价格比，组成系统的各种设备的一种优化组合）。
同样，软件配置也是说明软件组成的一种术语。与计算机配置中选择的部件都是现成的产品不同的是组成软件的部件通常都是要开发的。软件配置（ software configuration）是指开发过程中，构成软件产品的各种 文档、程序及其数据的优化组合。该组合中的每一个元素称为配置中的一 个配置项(configuration item)。也可以把软件配置项定义是软件中可以独立进行开发的一个实体，该实体包括程序、数据及其相应的文档和说明。
配置管理要对软件生存期内各阶段的文档、实体和最终产品的演化和变更进行管理；同时要解决变更的标识、控制和发布等问题。目的是使对设计变更的管理制度化，从而提高开发效率、减少错误，保证产品的质量。
软件配置管理主要任务有以下几方面的内容
确定软件配置项；
定义配置项和版本的标识规则；
制定控制变更的权限和实施步骤；
记录、追踪配置项的变更状态；
验证配置项的正确和完整性；
进行版本管理和发行管理。
2. 配置管理源头设计变更
软件设计不可能一步到位，变更是不可避免的；特别是用户需求多变 （如组织体制、业务流程的变化）必然会引起设计的变更。如何记录这些变更，需要做二件事。一是要标识这些设计文件（即根据文件名，确定一个唯一的标识符）；二是要动态地记录这些变更文件（即用版本的方法记录这些变更）．
3. 软件配置标识规则
软件配置标识就是对每个软件配置项的标识。对一个软件项目而言，它的配置项有以下内容需求分析文档、概要设计文档、详细设计文档、软件实体、测试文档、客户文档等。当然，这些软件实体及其相应的文档都可以按其功能进行逐级细化，被分解为分系统、子系统和功能模块。功能分解后能单独实现的这些软件和文档都是软件配置项，都应该加以标识。与系统的逐级细化相似，软件配置项的标识也可以按层次进行，现以3层为例，叙述如下〈第一层标识〉〈第二层标识〉〈第三层标识〉；如果第二层标识是本配置项标识的话，那么第一层标识就称为前缀（即前一层的标识），第三层标识称为后缀（即后一层的标识）依次类推。这样标识规则的好处是可以看出配置项的前后关系，比较直观又便于理解。有关配置项标识的实例后面还会给出。 [Page]
4 版本管理
标识一个配置项变更（如设计修改）的最好方法就是版本。版本不仅记录了配置项的当前状态，为后续开发提供依据；而且还可以根据版本追溯以前的状态。
版本标识规则
＜配置标识＞V＜主版本号＞·＜版本号＞·＜次版本号＞
主版本号、版本号和次版本号都可以由 1至2位的整数组成。通常，＜次版本号＞可省，因为二个层次的版本号就足以表示一个配置项的变化了；对于大型软件项目，其版本标识可以扩大到三层或更多的层次。
当配置项出现大的变化时（如因需求变化，导致《功能规格书》需要增加新功能时）主版本号升级（如从 1.**升级为2.**）；当配置项出现小的变化（如局部的完善和修改等，一般在阶段结束时，经过评审确认后）主版本号不动，次版本号升级 （如从**.0升级为**.1）。
版本管理是指对软件生存期内各种软件实体、文档等的修改和变化的管理。它的主要的功能就是记录和追踪文件的变更，如记录文件更改的内容、时间和更改 -审批人员等。此外，版本管理的另一个功能是并行开发，它能有效地解决版本的同步以及不同开发者之间的沟通问题，从而减少错误、保证质量、提高了效率。
根据经验，在软件开发过程中，经常需要保存多个版本。因为有时可能会发生这样的情况，即在修改一个软件后，却发现是改错了，需要恢复到修改前的一个老版本。如果不保留多个版本，没有版本管理，会给工作带来很大的麻烦，也会浪费很多时间。
对于大型软件公司，为顺利解决用户在使用某个版本时发现的问题，须要借助版本管理工具的支持，否则要解决这类问题是很国难的。因为不是旧版软件找不到，就是原开发人员已离开了公司。但是，如果按版本管理要求，将文件的不同版本形成一条链，并将它们存储起来。那么就能解决前面提到的找不到旧版软件的问提。
5. 基本概念
在配置管理中有几个常用的基本概念是需要弄清楚它们之间的联系和区别的。这些概念是配置项、里程碑、基线、受控库、基线库、产品库等。
软件配置项是软件生存期内，能相对独立开发的一个程序实体或文档。
里程碑即通常所说的软件开发过程中的“阶段”，如果说它们之间有 区别的话，那么“阶段”强调的是过程，而“里程碑”则强调过程的终点和终点的标识。这些阶段可以是需求分析阶段、概要设计阶段、详细设计阶段等等。
基线 是软件开发过程中最重要的里程碑，不过基线更强调的是一个开发阶段到达里程碑时的结果及其内容，如功能基线是 经过评审和批准的需求规格说明书；产品基线是经集成和确认测试后，经正式审批可交付客户的软件产品的全部配置项（包括软件实体和所有的文档）。 [Page]
正如清华大学郑仁杰教授所说 在一个开发阶段结束后，要对相应的配 置项进行基线化并形成各类基线。基线就是一个配置项（或一组配置项）在其生命期的不同阶段完成时，通过评审而进入受控状态的一组文档和程序实体，这个过程被称为 “基线化”。每个基线都是其下一步开发的基点和参考 点；它们都将接受配置管理的严格控制。因此，基线必须通过评审过程建立；基线存在于基线库中，接受更高权限的控制；基线是进一步开发和修改的基准和出发点。
受控库 是软件开发过程中，其修改权限受到控制的文档库和程序库，其中基线库和产品库，特别是产品库的修改权限将受到严格的控制，即使是授权修改的人，在修改前还必须得到批准。
基线库 是受控库中一些特别重要的库，如需求（基线）库和产品（基线）库。
产品库 是存放软件最终产品（即产品基线）的库，基于它的重要性，对它的修改将受到特别的控制。 产品基线是最初批准的产品配置标识。
6. 配置标识 方法与实例
6.1文档标识
通常，可把一个软件项目的文档分成 3类，即项目的管理文档、设计文档和客户文档。管理文档是项目管理过程中形成的文档，如项目的立项书、开发计划、质量计划、成本计划、配置管理计划、测试计划、设计评审报告、测试验证报告、验收确认报告、项目总结报告和维护服务报告等。设计文档是设计过程中产生的文档，如需求规格说明书、概要设计说明书、详细设计说明书、源程序、可执行程序等。客户文档是供客户使用的文档，如用户操作手册、系统安装手册、系统维护手册等。
二、软件配置管理过程及其关键活动
一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。
项目计划阶段：
一个项目设立之初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的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。
关键活动
1．配置项（Software Configuration Item，SCI）识别
Pressman对于SCI给出了一个比较简单的定义：“软件过程的输出信息可以分为三个主要类别：（1）计算机程序（源代码和可执行程序），（2）描述计算机程序的文档（针对技术开发者和用户），以及（3）数据（包含在程序内部或外部）。这些项包含了所有在软件过程中产生的信息，总称为软件配置项。”
由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。
软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线（Base Line）”这一概念。IEEE对基线的定义是这样的：“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。”
所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如：基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
配置项的标识和控制
所有配置项都都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。
所有配置项的操作权限应由CMO严格管理，基本原则是：基线配置项向软件开发人员开放读取得权限；非基线配置项向PM、CCB及相关人员开放。
2．工作空间管理
在引入了软件配置管理工具之后，所有开发人员都会被要求把工作成果存放到由软件配置管理工具所管理的配置库中去，或是直接工作在软件配置管理工具提供的环境之下。所以为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，对工作空间的管理和维护也成为了软件配置管理的一个重要的活动。
一般来说，比较理想的情况是把整个配置库视为一个统一的工作空间，然后再根据需要把它划分为个人（私有）、团队（集成）和全组（公共）这三类工作空间（分支），从而更好的支持将来可能出现的并行开发的需求。
每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上，例如：对于私有开发空间而言，开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素；而集成分支对应的是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限，它的管理工作由SIO负责；至于公共工作空间，则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的标准版本，并作为整个组织的Knowledge Base。
当然，由于选用的软件配置管理工具的不同，在对于工作空间的配置和维护的实现上有比较大的差异，但对于CMO来说，这些工作是他的重要职责，他必须根据各开发阶段的实际情况来配置工作空间并定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。
3．版本控制
版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数据（Metadata）来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程改进（Software Process Improvement，SPI）活动的进行。
对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。
4．变更控制
在对SCI的描述中，我们引入了基线的概念。从IEEE对于基线的定义中我们可以发现，基线是和变更控制紧密相连的。也就是说在对各个SCI做出了识别，并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就成为了软件配置管理的另一重要任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。
在本文的前面的部分中，已经把SCI分为基线配置项和非基线配置项两大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置项。
变更管理的一般流程是：
A) （获得）提出变更请求；
B) 由CCB审核并决定是否批准；
C) （被接受）修改请求分配人员为，提取SCI，进行修改；
D) 复审变化；
E) 提交修改后的SCI；
F) 建立测试基线并测试；
G) 重建软件的适当版本；
H) 复审（审计）所有SCI的变化；
I) 发布新版本。
在这样的流程中，CMO通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建立在前文所描述的版本控制和分支策略的基础上的。
5．状态报告
配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。
配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。
配置状态报告应该包括下列主要内容：
A) 配置库结构和相关说明；
B) 开发起始基线的构成；
C) 当前基线位置及状态；
D) 各基线配置项集成分支的情况；
E) 各私有开发分支类型的分布情况；
F) 关键元素的版本演进记录；
G) 其它应予报告的事项。
6．配置审计
配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。
总之，软件配置管理的对象是软件研发活动中的全部开发资产。所有这一切都应作为配置项纳入管理计划统一进行管理，从而能够保证及时的对所有软件开发资源进行维护和集成。因此，软件配置管理的主要任务也就归结为以下几条：（1）制定项目的配置计划；（2）对配置项进行标识；（3）对配置项进行版本控制；（4）对配置项进行变更控制；（5）定期进行配置审计；（6）向相关人员报告配置的状态。
在此，我想特别指出的是：由于软件配置管理覆盖了整个软件的开发过程，因此它是改进我们的软件过程、提高过程能力成熟度的理想的切入点。希望本文所描述的这个软件配置管理的角色分配和工作流程能在实践中不断地得到完善，从而使我们的软件开发活动能够更加有序、高效的进行！
三、软件配置管理的意义
提到软件配置治理，作为从事软件的人来讲，相必都不生疏。要想真正做到实施好配置治理，对于软件配置治理的意义及其重要性我想应该有必要的熟悉和理解。
软件配置治理，software configuration management，其简称SCM；在软件配置治理中，有一个要害的一环就是变更治理，而变更治理的基础是配置项的确定与版本治理。要正确理解这些问题，我们不能仅仅将SCM作为一个治理工具或者在项目洽谈与执行中一种合行规定的义务来履行。假如这样，在开展工作的过程中很轻易使这种工作变成一种官僚式的绊脚石。往往在我们开展项目时，很多合同对配置治理提出了明确的要求，需要熟悉的是，我们所需要进行配置治理的目的是为软件开发过程中的不同的角色控制和跟踪治理自已的工作提供支持与帮助。
很多软件开发过程中碰到的问题都是因配置治理不善而造成的。而发生这些问题需要时间去确定，而且有可能很多可能是重复的问题。有的是不必要的麻烦。比如说一个已花费较大精力和成本解决的高难度的软件错误忽然再次出现，已经开发或完成测试的一个特性神密的消失，一个已经通过完全测试的软件系统忽然间无法运行。配置治理通过对同一项目中不同人员的所产生的工作产品来帮助我们减少和消除这些问题。问题主要体现在： —— 现在项目的开发大部分都是以叠迭式，渐进式的模型进行开发。在一个版本交付的同时，另一个版本可能还是进行测试，而进行同步开发的后续版本可能还在进行设计与开发阶段。在这个循环的过程中，假如客户发现错误，那么不单只是针对客户的错误在现有的版本上进行修改完成就可以，同时要在后续的版本中体现。另外，假如在测试或开发的过程中发现了新的问题，那么对于以前正在使用的版本也需要考虑进行修改。在大系统开发的过程中，问题与修改问题的人，版本都会比较多，很轻易出现混乱的情况。 ——核心代码，或者公用构件和代码。在系统的开发过程中，当涉及到公用构件或代码的修改时，需要使与此相关的人都需要知道。假如没有有效的代码治理与报告与协调机制，对于修改的代码如何使相关人员都提到通知就存在一个问题了。 ——现在的软件项目，大多都是由一个团体协作完成的，那么，涉及到，对于最后某人对其所作的工作或输出很轻易损害到其它相关人员的工作。如在一个应该系统的开发过程中，数据流程比较密集，假如其接口的变化，可能会引起很多相关地方的变化。
这些问题是由什么而引的呢，不言而明，在软件开发过程中的缺少规范的治理而导致出这些问题。需要我们花费很大的精力与时间来处理。那么怎么来对这些问题来形成一个有效的解决方案呢，需要我们对以下的问题进行明确： ——在公司，目前的配置治理是什么，做了些什么？
——目前公司配置治理的状态是何状态？
——如何去控制配置的变更项？
——对于配置变更，怎么样通知相关的个人和组？
——公司的软件项目都有哪些类型的变更？
——假如在公司或同一项目组，其它人所做的变更会不会影响你所写的软件部分？
-
