中小企业配置管理基本流程

贾莉英

【摘 要】在中小企业应用配置管理流程中，为了节约资源，提高企业工作效率，必须根据实际情况变通配置流程中的不切实际的环节，针对各子环节有相应的变通方法。

【关键词】中小企业、配置管理流程

【中图分类号】C29【文献标识码】A【文章编号】1672-5158（2013）07-0492-02

一、 引言

软件配置管理的发展在国内虽然是21世纪的事，但是发展比较迅速，得到了软件公司的普遍认可。但是对于中小公司，由于重视不够或缺少相关知识，在实际使用中存在一些问题。中小公司照搬大公司流程存在也不切合实际。

二、 配置管理流程

2.1制定配置管理计划

在《项目开发计划》完成后，配置管理员（SCME）参考项目经理制定的《项目开发计划》完成《配置管理计划》，《配置管理计划》中需要明确项目的基线配置项计划，以及基线计划等信息。

不同的项目，配置管理计划的内容可以不同。主要受以下方面影响：

项目的大小和复杂性会影响到配置管理计划。特别简单的项目可能只需要一个配置管理工具，简单管理一下源代码；但是大项目、复杂的项目则需要详细的配置计划。

特殊的项目需要更详细的计划。举例来说，如果企业中绝大多数产品都是完整独立开发，而某产品使用了开源代码。那么在该项目的配置计划中，此点就要考虑。

2.2 项目配置库的建立

项目立项后，项目经理通知配置管理员建立项目的配置库，同时为项目组人员开放配置库权限。

2.3 配置识别

配置识别的目的是识别配置项和基线。

配置项是指处于配置管理之下的软件或/和硬件的集合体。这个集合体在配置管理过程中作为一个实体出现。

基线是已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程来改变。

配置识别活动包括以下几个内容：

* 配置项识别

配置项可以分为基线配置项和非基线配置项。基线配置项包括所有的技术类文档和源程序等；非基线配置项包括项目的各类计划和报告等。

配置管理工作的关注重点是基线配置项。配置项识别由SCME参照项目开发计划中的交付物，同项目经理共同识别基线配置项，以及配置项间的依赖关系。配置管理员需要完成《配置管理计划》中的配置项计划。

* 配置项标识

配置项的标识，版本等规则，参见企业标识规范。

* 基线建立

一般在项目的不同阶段有对应的基线。

> 基线建立

当基线包含的配置项稳定后，由项目经理通知SCME建立基线。基线建立后一般不允许随意更改。SCME需要对基线库的权限进行设置。

> 基线变更

当基线建立后，如果基线配置项经过若干次变更，在配置项稳定后，项目经理认为有必要进行变更（再发布等），或者基线不稳定，需要回朔到上一基线，由项目经理通知SCME对基线进行变更。

2.4 版本控制

版本控制能够简单、明确地重现软件系统的历史版本。一般的配置工具都能自动保存配置项的版本历史，但是大多时候，针对项目不同阶段需要整体化的标识。以下是整体化版本控制的方法：

* 标签

如果项目只有一个主干，只需要通过打标签的方式，来辨明当前的整体版本。这样将来搜索所有的以这个整体版本命名的标签，就能找到这个整体版本对应的所有文件的正确版本，包括源代码。

* 分支

不同的客户，基本需求一定，但是有不同的差别，此时就需要用到分支。使用分支，能够有效地实现隔离，也实现共享。但是分支是有管理成本的。如果标准版的发布比较频繁，而客户又要求变体的发布跟上标准版发布的话，那么需要频繁创建分支。另一方面，如果变体所在的分支上，包含了一些应该共享的改动，那么应该合并到主干。这样，相应管理成本也会提高。

2.5变更控制

在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。

在瀑布模型的管理中：修改处于“草稿”状态的配置项不算是“变更”。当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据变更的规则执行。

以下为变更规则：

1） 变更请求

2） 变更审核

3） 配置项出库

4） 变更实施

5） 变更验证

6） 配置项入库

SCME负责实施配置项入库，确保配置项处于“正式”状态，并且版本正确。并通知项目经理，项目组人员，质量保证人员等变更已经完成。

但是还有两种情况，可能不需要严格的变更流程：

1） 功能小变动：把程序已有的功能，稍微增强或改变一下。特点是：数量多容易丢，改动量不太大。对这类请求的管理，建议像对缺陷的管理，进行分别跟踪、处理，直至解决。

2） 迭代模型中管理变更

迭代开发把一个大项目在时间轴上分解成很多小项目，每个小项目被称作一个迭代。几乎每次迭代，都会包含需求分析，系统设计、代码实现，以及集成和测试。这样就不必刻意走变更流程，只要通过基线或标签的方式就可以对配置项进行识别。但是在每一个迭代中，出现的对正式发布的配置项进行修改，还需要走变更流程。

2.6配置审计

配置审计是对交付的软件基线进行检验，以验证其中包含了所有必需的内容，并且这些内容本身都是经过验证而满足了需求。配置审计分为功能审计和物理审计两种：

1） 功能审计是一种验证审核，它验证配置项的开发是否完全满足特定的性能和功能特性，并且所有的操作和支持文档是齐备的。功能审计主要方法有评审、测试等。一般由研发人员和测试人员来做。

2） 物理审计的目的是为了验证配置项是按照技术文档中的规定构建的。

物理审计工作主要由配置管理人员定期（每月）执行。也可因事件驱动进行，比如配置项发布，新版本发布等。

主要进行以下内容：

> 审核配置项一致性，具体检查点如下：

* 参照配置管理计划检查配置项是否按时提交；

配置项是否满足配置管理相关规定，如配置项标识，版本，状态，版式等；

配置项信息是否正确；

配置项评审记录、变更记录是否完备等。

审核配置项版本一致性：检查配置管理工作表中配置项版本信息与配置库中配置项版本信息是否一致，以免工作疏漏造成不一致情况。

审核基线一致性：检查配置管理工作表中基线内容与配置库中基线信息是否一致。

审核结构权限一致性：检查配置库结构权限是否合理，是否满足安全适用需要。

2.7配置状态报告

配置状态报告工作主要由SCME定期执行。也可因事件驱动进行，比如阶段总结，阶段评审等。

常用的配置状态报告分为：

> 周报告

周报告每周进行，主要内容为本周开展的关于SCM的活动总结，以及对SCM工作发现的问题的跟踪。周报告的审阅人为项目经理、质量部经理。

> 总结报告

总结报告主要用于项目结束时，或者因事件驱动而对SCM工作的当前状态进行概括总结。总结报告的审阅人为项目经理、质量部经理。

2.8 配置中止

当项目结束时，由项目经理确认此项目已不会再有配置管理方面的变更，由项目经理通知配置管理员项目关闭。

配置管理员关闭该项目的所有读写权限，并将项目基准库内容移入产品库中。该项目配置管理活动中止。

三、 结束语

本文对配置管理各环节都根据实际进行了简化变通，或提供了方法，对中小企业的配置工作有一定的借鉴意义。

参考文献

[1] 董越 理解软件配置管理 电子工业出版社 2008

[2] [美] Dave Thomas Andy Hunt 版本控制之道——使用CVS 电子工业出版社 2006