软件配置管理指南_V1.0

修订历史

为了指导和帮助XX公司项目的配置管理工作，特制定本指南。

2. 范围

本过程文件适用于所有的软件开发及测试项目。

读者为项目组中负责配置管理活动的人员。

3. 术语和缩写语

表格1术语和缩略语

表格2角色和职责

5.1配置管理作用

配置管理是通过标识配置项，变更控制，配置状态跟踪，配置审计来建立和维护工作产品的精确配置，保证工作产品一致稳定。

5.2配置管理常用术语

5.2.1配置项

配置管理中最基本的元素是配置项，它是被唯一标识的实体。

凡是纳入配置管理范畴的工作产出都是配置项（CI）。

配置项主要有两大类：

1)属于产品组成部分的工作产出；

2)项目管理和机构支撑过程产生的文档。

配置项，指一个产品在生命周期各个阶段所产生的各种形式和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项。（要和过程中配置项的定义一）

配置项在大小，复杂程度和类型上划分非常广泛，可以从整个的系统（包括硬件，软件和文件）到一个单一的模块。通常我们的项目计划，需求规格书，设计文档，编码，测试用例等都是配置项。配置项选择可参考本文“配置项标识”章节。

5.2.2基线

基线是一组配置项集合的稳定版本，是进一步开发的基础。基线保证了后续开发活动所需工作产品及支持文档数据的稳定性和一致性。基线的变更要遵循变更控制的流程。

在配置管理系统（SVN）中，基线是一组特定版本的配置项副本拷贝，凡纳入此基线范围的配置项，称为此配置项已基线化。

以下是建立/修改基线注意事项：

1)通过正式的评审过程建立。

2)基线变更要执行变更流程。

3)基线的变更由CCB裁决。

4)基线是进一步开发和修改的基准。

5.2.3版本

版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。版本以版本号进行标识。

5.3配置管理活动简介

5.3.1配置标识

配置标识是对配置管理的前提和基础。

配置标识包括了配置项的选择、划分以及功能物理属性进行描述的过程。

配置项是逻辑上组成软件系统的各组成部分。比如一个软件产品包括数个程序模块，每个程序模块及其相关文档和支撑数据就是软件的配置项。它们可以作为一个配置项，也可以根据类型划分为几个配置项。这个过程就是配置项的选择与划分。

5.3.1.1 配置项的识别

软件配置项包括但不限于：

1)用户需求

2)SOW (工作任务书)

3)估算记录

4)项目计划

5)配置管理计划

6)需求规格

7)功能规格

8)产品规格

9)设计规格

10)需求跟踪矩阵

11)用户手册

12)测试计划

13)测试方案

14)测试用例

15)代码

16)测试工具

17)脚本

配置项可以分成以下类型：

表格3配置项分类表

软件配置项一般可分为两大类：文档与代码。

对于这两种类型，其配置项划分方法不同：

1)文档

一般将一篇文档可以划分为一个配置项。根据需求一类文档也可作为一个配置项。

2)代码

对于单板软件、模块、开源软件、外购软件或需要单独管理的软件代码可设置为一个配置项。如果没有特别管理需求，所有组成一个Build的代码也可作为一个配置项。

5.3.1.3 配置项命名

每个配置项都必需被唯一地标识，这个唯一的标识被用于与其它配置项进行区分，跟踪和报告该配置项的状态。一般地，每个配置项被赋予一个标识符。

1)文档命名规则    

    项目名称名称+文档名称+文档版本。中间使用“_”下划线连接。

格式：项目名称_文档名称_文档版本

例如：

中信CRM零售管理项目_详细设计_V1.0.xls

    如客户方有其他要求，则按客户要求操作。

2)工具命名规则

    工具名称+空格+版本号

    例如：

    Subversion 1.6.17

5.3.1.4 版本命名

版本命名必须与客户下发的工作任务书所要求的版本命名保持一致。

如版本规则不明确，则应采用本版本规则，但必须保证版本号与客户方版本号的对应关系。

1)版本命名

文档的版本标识形式为以下的十进制标识符：

    xx.yy

其中xx起始为“1”，yy起始为“0”。

所有数字均是阿拉伯数字，并且单调递增。如果发生了重大的修改，xx递增；如果只有小修改，递增yy。

配置项未经过评审时，版本标注不得早于v1.0。

配置项通过评审后，版本可升为V1.0版，达成V1.0版的配置项纳入配置库，正式受控。配置项纳入配置库时，应在修订记录中注明版本号。

2)发布版本标识

一个发布软件由一系列配置项组成，由这些配置项共同构成一个广义的配置项－－版本。对于版本的标识建议采用如下的形式。如客户有该项要求，则按客户要求操作。

软件版本以xx.yy.zz.pp的形式标识，其中xx、yy、zz、pp的意义如下：

表格4发布版本标识

为清楚起见，下列关键词可以作为软件版本标识的前缀：

维护版本2.1.1.0

补丁版本2.1.1.1

内部版本2.1.1.1

5.3.2 标签/基线

5.3.2.1 标签

标签命名采用以下规则：

    Label _版本号_标签名

标签注释规范如下：

【标签人】：描述实际修改该问题的人员信息（格式：中文姓名）

【标签说明】：详细说明标签的内容。

5.3.2.2 项目阶段基线

1)瀑布模式的项目中，CMO必须在需求分析结束、code&UT结束、ST结束、SDV结束、验收结束时进行基线化操作。

每个基线都必须有被唯一的标识。基线内容包括文档和代码。

到达阶段点时，CMO检查该阶段配置项的完整性，并在阶段点评审通过5个工作日内建立基线。

表格5阶段基线

立项基线

在立项结束时候打基线，包含的配置项有：工作任务书、分配需求、客户提供物、方案建议书、方案选择表、项目估算表、项目计划、WBS、过程裁剪表、需求设计说明书、项目需求表，只需对01.CI目录打基线即可。

命名规则是：项目名称+“_”+“Init”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)

需求基线

该阶段尾所有文档通过评审后打基线，包含立项基线所有配置项及：SDV测试方案、SDV测试用例，只需对01.CI目录打基线即可。

命名规则是：项目名称+“_”+“RD”+“_”+“Baseline”

设计基线

在实现阶段结束以后打基线。除包含“立项基线”与“需求基线”所有包含的配置项以外增加源代码、单元测试计划及用例，系统测试计划及用例。

命名规则是：项目名称+“_”+“Design”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)

验收&产品基线

在整个项目开发结束以后打的基线，包含CI目录下的所有配置项。

命名规则是：项目名称+“_”+“Final”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)

5.3.2.3 版本构建代码基线（基线内容只含代码）

如在某个阶段中，需要对某个模块单独进行基线化操作，此时基线以下述标签规则建立。

标签命名规范：

    BaseLine_版本号_[子系统名称/模块名称]_阶段

例如：

    BaseLine _V100R002C02L00106_ CHG_SDV

5.3.3 备份文件命名

整体备份

命名规则是：项目名称+“_”+ back +“_”+“YYYY/MM/DD”+fully

例如：银行项目_back_20130810_fully

增量备份

命名规则是：项目名称+“_”+ back +“_”+“YYYY/MM/DD”+ hourly

例如：银行项目_back_20130810_hourly

5.4 配置控制

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

5.4.1CCB操作指导

在项目开始时，需根据项目的情况确定CCB成员，建议组成人员为、PM、、QA、CMO。PM为CCB负责人，PM根据变更请求的情况事件驱动地召集CCB会议。 CCB也可以批量处理更改请求或采用定期的方式进行处理。这些活动都应该在配置管理计划中体现。

5.4.2 配置项级别

5.4.2.1 草稿

当配置项处于创建之初未纳入基线之前，项目组成员可以修改。此时配置项是草稿状态。

5.4.2.2    受控

配置项自提交审核开始，即处于受控状态。

例如：

1)一个正在进行审核的设计文档。

2)一个已通过审核的配置管理计划。

5.4.2.3 已基线化

配置项被纳入基线范围，并且此基线已经建立，则称此配置项已基线化。

5.5 版本转测试

1.版本转测试由CMO负责。

2.每个版本转测试时CMO都必须检查确保交付件的完整性，对代码配置库打标签并对版本回收修改权限。

3.转测试交付件必须包括：基线化的需求、设计、规格、产品配套资料、文档等相关文档

5.6 版本交付

1.版本验收通过后，由CMO交付版本。

2.每个版本交付验收时CMO都必须对照工作任务书检查确保交付件的完整性，对代码配置库打标签，并对版本回收修改权限。

3.版本交付件必须包括工作任务书的交付件清单所有交付件。

5.7 配置状态跟踪与发布

配置状态跟踪是对配置库的状态，软件的更新或变更的过程进行记录、监视并通报给项目组和相关成员的活动。

1.责任人： CMO

2.发布对象：项目组所有人员

3.发布周期：例行发布或事件驱动发布

4.发布形式：邮件

5.发布内容：

1)月度例行发布内容：版本发布情况

2)阶段点发布内容：文档归档情况、基线建立情况、变更情况

3)事件驱动发布内容：配置库及权限变更情况

5.8 配置审计

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

配置审计的物理审计是由QA来做，检查配置项的一致性，完整性，规范性。

配置审计分为内部审计和外部审计。

内部审计：是指项目组内部人员（CMO、项目PM、QA）对项目的配置项完整性、正确性, 一致性和可跟踪性的基线审计，包括例行审计、每个版本发布前的质量审计及阶段点审计；

外部审计：是指客户CMO及QA对项目的所有配置管理活动否和要求相一致的配置审计。外部审计结果作为项目验收报告的输入，用于后续合作评估。

5.9 组织级配置管理

5.9.1 工具和使用规范

配置系统是实现配置管理的辅助自动化工具，它提供对配置项的增量式存贮和对各类流程（比如变更控制流程，配置状态发布）的支持。项目应根据其规模和配置管理的复杂程度使用专门的配置管理系统建立配置库系统。

公司目前将SVN选为配置管理的标准工具，项目组根据情况使用指定的配置管理工具并遵循相应的规范建立和使用配置库系统。

5.9.2 配置库结构及权限设置

5.9.2.1 配置库结构

过程配置库按存储内容分为代码库和文档库。代码库和文档库分别有其开发库和基线库的区分，开发库用于存放开发过程文档和源码，基线库用于存放基线化的内容。配置库结构请参见《配置库结构.xls》。

5.9.2.2 权限设置

配置库服务器帐户密码仅管理员持有，每3个月更新一次。

配置库必须有鉴权认证机制，可以使用域认证或其它认证方式。

项目配置库权限设置，见《配置库结构.xls》。在基线建立或阶段结束后，CMO将项目组员CR的权限收回，当有变更需要修改时，CMO会赋予修改人员修改权限，修改完成收回修改权限。对于CI外的文件夹权限可参考《配置库结构.xls》配置库结构及权限，不做强制要求。

5.9.3 配置库归档与下线

项目结束或终止一年，且配置库中数据不再需要修改，组织级CMO必须对配置库归档，配置库归档后，取消写权限，其他权限设置和在用库保持一致。

配置库归档后3年，且配置库中数据不再需要查阅，配置库进入下线状态，由组织级CMO统一进行刻盘存档。如客户有特别要求，可以参照客户要求操作。

若出现业务转移和业务异常中止的情况，配置库数据（指业务相关的所有信息资产，不只局限于当前版本）需要在七个工作日内转移给客户维护，经客户验证数据完整可用后，原合作公司可不再进行维护。

5.9.4 备份策略与执行

数据备份，简而言之即是创建数据的副本，在原始数据因各种原因被删除、覆盖或无法访问时，可以使用副本恢复丢失或损坏的数据。

数据备份的方法有很多种，可归纳为自动备份和手工备份两大方式。不论采用哪种备份，都要保证数据的正确性、完整性。

由于操作系统的不稳定性、盗窃、故意破坏及病毒和攻击普遍存在，因此备份作为保护公司数据的方式必须严格得以贯彻：

提倡备份——备份工作的根本原则；

备份制度化——是一项强制措施，而非可有可无的选项；

备份应简单易行；

目前公司采用本地备份、异地备份策略。

备份验证：组织级CMO保证至少每月进行一次备份的验证操作，以验证备份的有效性。一旦配置库服务器发生意外，配置库不能使用，要立即进行配置库恢复。

5.9.5  数据恢复

数据恢复工作由服务器管理员完成。

6. 参考文献

配置库结构

配置状态报告

7. 附录

无