【IT168 技术文章】

　　配置管理的概念

　　配置管理：通过对软件生命周期的不同的时间点上的软件配置进行标识，并对被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可塑性的过程。

　　作用：

　　●　　保障软件产品的完整性和可塑性

　　●　　对变更进行控制

　　配置管理术语

　　●　　配置

　　　　所谓的“配置”就是在技术文档中明确说明并最终组成软件产品的功能或物理属性。（例如：电脑配置中的配置）

　　　　包括：受控的所有产品特性、内容、相关文档、软件版本、变更文档、软件运行的支持数据及其他保证软件一致性的组成要素。

　　●　　配置项

　　为了方便对配置的管理，而对配置进行划分为各类配置项，是配置的组合。

　　　　大分类：

　　　　●　　文档：一篇文档就是一个配置项；

　　　　●　　代码：所有代码，或者一个模块的代码

　　　　详细分类：

　　　　●　　合同类文档：建议书、用户意向书、用户需求、工作任务书、合同

　　　　●　　计划类文档：项目过程手册、项目计划、配置管理计划等

　　　　●　　工程类文档：需求规格文档、测试计划、设计文档、需求跟踪矩阵等

　　　　●　　程序代码：所有开发的源代码、支持数据、二进制文件等

　　　　●　　第三方程序代码：由供应商提供的源代码

　　　　●　　工具：软件开发过程软件、测试工具、配置工具等

　　　　●　　用户文档：用户手册、安装指南等

　　　　●　　运行环境：系统运行环境的相关内容

　　●　　基线

　　配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状态。

　　●　　通过正式的评审过程建立

　　●　　基线存在于配置库中，基线的变更有CCB控制

　　●　　基线是下一步开发和修改的基准

　　　　基线化：基线的过程。草稿→评审→审核批准→打基线

　　●　　版本

　　　　表示一个配置项具有一组定义的功能的一种标识。随增删改而改变，

　　　　用版本号来标识。

　　●　　版本标示

　　　　软件版本以xx.yy.zz.pp的形式标识

　　●　　xx——主版本号——增加一个大特性—可能导致与原先版本不兼容

　　●　　yy——次版本号——增加一个小特性—保持与原先版本兼容

　　●　　zz——维护版本号——一些更改，包含上一次版本的所有补丁

　　●　　pp——补丁版本——客户或测试发现和报告的所有问题的解决。

　　配置管理活动

　　●　　配置管理角色介绍

　　　　○　　项目经理（PM——project management）

　　　　○　　配置管理员（CMO——configuration management officer）

　　　　○　　软件开发工程师（SWE——software engineer）

　　　　○　　软件测试工程师（STE——software testing engineer）

　　　　○　　质量保证人员(QA——quality assurance）

　　　　○　　变更控制委员会(CCB——change control board）

　　●　　配置计划

　　　　PM制定配置管理计划，是开展那所有配置管理活动的基础。

　　　　计划中要明确的要素：

　　　　○ 配置管理人员的组织和职责

　　　　○ 配置项的命名规则

　　　　○ 配置管理工具以及配置库结构

　　　　○ 标识的配置项和位置

　　　　○ 权限分配和管理方法

　　　　○ 配置库备份的周期、方法

　　　　○ 变更控制的流程和操作方法

　　　　○ 版本发布的计划和策略

　　　　○ 基线审计计划

　　●　　配置标识

　　　　配置标识是对软件配置进行管理的前提和基础。包括软件配置项的选择、划分和对配置项的功能物理属性进行描述的过程。

　　　　配置项标识规则：

　　　　○　　每个配置项都必须被唯一地标识

　　　　○　　文档：文件名作为配置项的命名

　　　　○　　代码：“项目名-模块名◇代码”或“项目名◇代码” 来命名

　　　　○　　工具：工具本身的名称命名

　　　　配置项版本：

　　　　○　　定义配置项的版本——为了标识配置项在两次修改之间的不同

　　　　○　　配置项版本命名原则

　　　　　　- 配置项的版本标识建议采用：xx.yy的十进制标识符，xx起始为1，yy起始为0

　　　　　　- 所有数字均为阿拉伯数字，并单调递增。

　　●　　配置控制

　　　　配置控制包括配置项在完成基线化后所产生的变更的评估、协调、批准、驳回以及实现的过程。

　　●　　建立CCB

　　　　○　　项目开始时，项目负责人来确定，并记录在配置管理计划中

　　　　○　　CCB组长根据事件驱动召集CCB会议

　　　　○　　可设立不同级别的CCB

　　　　○　　根据修改的影响范围，召开相应的评估会议

　　●　　定义配置项级别

　　　　○　　已基线化——已经完成审核、批准和签发，并成为其他配置项的输入的配置项

　　　　○　　受管理和受控的——已提交审核，但还没有批准通过的配置项

　　●　　基线变更请求

　　　　○　　基线变更的条件有：

　　　　　　◇ 评审发现问题

　　　　　　◇ 测试发现问题

　　　　　　◇ 审计发现问题

　　　　　　◇ 维护产生问题

　　　　　　◇ 客户需求

　　　　　　◇ 修改计划文档

　　●　　基线变更流程

　　●　　配置状态发布

　　配置状态发布是跟踪对软件的更改的过程，保证对正在进行和已完成的变更进行记录、监视并通报给项目组和相关成员。

　　- 一旦配置项基线化后，CMO应该通知项目组，内容包括基线化配置项的名称以及位置

　　- CMO应该周期或事件驱动地更新后的配置状态发给项目组成员以及相关组，确保配置项的状态能被相关人员所了解。

　　●　　配置审计

　　对配置管理的独立的检查过程，确认受控软件配置项满足需求并就绪。

　　- 配置项的完整性、正确性、一致性和可跟踪性

　　- 配置项的变更控制是否和配置管理计划中的描述相一致

　　配置库管理

　　●　　选择配置管理工具

　　VSS、CVS、Starteam、Clearcase

　　●　　定义配置库结构

　　树形结构、分阶段

　　●　　定义配置库权限

　　给用户分配权限，权限有：read/check in/check out/add

　　●　　选择备份策略

　　物理设备、异地备份

　　●　　配置归档