软件配置管理

 配置管理的概念源于美国空军，为了规范设备的设计与制造，美国空军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

 五．软件配置管理角色职责

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

 项目经理（Project Manager，PM）：

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

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

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

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

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

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

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

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

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

 系统集成员负责生成和管理项目的内部和外部发布版本，其具体职责为以下几项：
    1、集成修改；
    2、构建系统；
    3、完成对版本的日常维护；
    4、建立外部发布版本。

 开发人员（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的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。

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

 七. 软件配置管理的关键活动

 1．配置项（Software Configuration Item，SCI）识别

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

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

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

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

 配置项的标识和控制

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

 2．工作空间管理

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

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

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

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

 3．版本控制

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

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

原文转自：http://www.ltesting.net