配置管理流程Word下载.docx

配置管理流程Word下载.docx

《配置管理流程Word下载.docx》由会员分享，可在线阅读，更多相关《配置管理流程Word下载.docx（14页珍藏版）》请在冰豆网上搜索。

1.1

魏珍

2012-4-26

1、增加文件编号

2、调整页眉页脚

3、增加版本历史

1简介

1.1目的

配置管理是一种标识、组织和控制修改的技术，目的是使软件开发过程中的错误降为最小并最有效的提高生产效率。

通过对开发过程进行有效的管理和控制，完整、明确的记载开发过程中的历史变更，形成规范化的文档。

使日后的维护和升级得到保证，保护代码资源，积累软件财富，提高软件重用率，加快投资回报。

1.2适用范围

汉柏科技有限公司

1.3引用文件

无

1.4术语和缩略语表

●SCM：

软件配置管理，是一套规范、高效的软件开发基础结构。

通过对软件开发过程的各种输出物进行管理，保证开发的完整性、正确性及可追溯性。

●配置项：

配置管理的对象，简单来讲它符合以下任意一个特点：

◆它会被两个或两个以上的项目成员共同使用；

◆它会随着项目的开展而发生变化；

◆对项目重要的工作产品；

◆一些工作产品之间的关系非常紧密，一个变化其他的就会受到影响。

●基线：

◆项目存储库中每个工件版本在特定时期的一个“快照”。

它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准；

◆简单来讲就是将一组配置项拿“线”穿起来作为一个整体进行统一命名。

●检入：

将文档或代码通过配置管理工具从本地提交到服务器的动作。

不同的配置管理工具检入的命令不同，如：

◆SVN的检入命令叫：

SVNCommit，汉柏研发中心使用SVN作为配置管理工具；

◆Clearcase的命令叫：

Checkin。

2过程总体描述

2.1过程概述

配置管理主要包括配置项标识，版本管理，变更管理，报告配置状态和发布管理等活动。

本流程将项目的配置管理活动分为三个主要的阶段：

配置管理策划，配置库管理和发布管理。

●配置管理策划主要是在项目初期进行配置管理活动的整体计划，项目的配置管理策略，配置管理活动的执行周期在计划中确定；

●配置库管理是贯穿于项目的整个过程的，它主要包括了配置标识及版本管理，变更管理，配置状态报告等内容，主要目的是为了保持配置库的正确，完整和可追溯性；

2.2过程流程图

图21配置管理过程流程图

3过程活动描述

3.1步骤1：

创建配置库

名称（What）

责任人（Who）

配置管理员

时间（When）

Charter评审通过后

输入（Input）

●无

输出（Output）

●项目配置库

方法（How）

1、项目经理通知配置管理员建立项目的配置库，通知中需包括配置库的名称，需开通权限人员；

◆如需为项目定制单独的配置库结构，需提供目录结构并向研发管理部经理申请。

获得批准后方可建立；

◆如此目录结构适用于某类项目，研发管理部经理可考虑将其加入到公司标准目录结构中。

2、配置管理员按照公司标准目录结构建立配置库，并邮件通知项目经理及已开通权限人员。

注解（Comments）

公司标准目录结构参见附录B

3.2步骤2：

制定配置管理计划

●项目启动阶段，确定TR1-TR2的《配置管理计划》

●项目计划阶段，输出完整的《配置管理计划》

●项目过程定义

●项目计划

●配置管理计划

1、配置管理员根据配置管理计划模板制定配置管理计划，主要内容：

◆配置项标识：

基于项目过程定义中定义的输出物

确定本项目的配置项，原则上需要后续进行维护和修改的工作产品可作为配置项；

确定管理级别，如对于需求文档需要加大管理力度，而对于报告类的文档则无需花费太多时间。

◆基线计划，确定各基线的建立时间

按照工作产品单个入基，逐步完善的原则建立基线。

如设计基线包括：

概要设计、详细设计等文档。

当完成概要设计评审后可先入基线，然后详细设计完成后再入基，最终形成设计基线。

◆汇报机制及计划

配置项状态报告的时间点。

◆分支集成策略

Trunk分支及Branch分支如何集成，何时集成的策略。

2、完成配置管理计划的编制后，发送给项目经理进行审批。

3.3步骤3：

评审通过？

项目经理

TR1-TR2

1、将本计划同项目各计划一同进行评审。

◆如评审通过，则进行后续活动；

◆如不通过，则修改直到通过为止。

3.4步骤4：

完成工作产品

项目组

TR1-TR6

●工作产品

1、项目组按完成工作产品

◆具体的时间点参考项目计划中规定的时间点。

2、个人对工作产品的配置管理

◆文档：

建议开始编写时就检入到文档库的规定位置，每次修改后进行提交，这样可以随时获取之前的版本，防止误操作丢失，也更方便其他人查看；

最低要求在发出评审前将工作产品的初稿检入到SVN的文档库中进行管理，以保证文档的版本受控；

文档入基后，后续的工作以基线文档为准。

不能再以开发区中的文档作为参考；

入基后的文档不能随意修改，如需修改一定是由于变更引起的，变更的管理请参考《变更管理流程》。

◆代码：

代码分为开发分支和集成分支；

开始编码时将代码检入到开发分支；

代码经过单元测试和CodeReview后检入到集成分支；

向集成分支检入文件需要经过研发组长同意。

项目成员每次检入时，需要在comments中填写说明，说明内容包括：

修改了哪些内容，为什么修改等内容。

特别是为了解BUG而修改代码时，需要写明BUG的ID

3.5步骤5：

配置库管理

配置库管理

1、配置库结构

◆01_项目管理：

存放项目管理相关的一次性输出的配置项的初稿及过程版本，如：

项目通知，立项报告书等；

存放周期性输出物，如度量数据，变更控制报告。

◆02_硬件：

存放硬件的输出物，开发组长可根据需要增加目录；

◆03_软件：

存放软件的文档输出物的过程版本，如SRS、系统设计说明书；

存放代码，包括开发分支、集成分支以及build好的版本。

◆04_测试：

存放测试的过程文档及参考资料等；

◆05_质量保证：

存放QA的审计记录，流程提醒等输出；

◆06_里程碑：

作为项目的基线库，每个里程碑的输出物入基后放到本目录下；

◆07_会议纪要：

存放项目的各种会议纪要；

◆08_项目周报：

存放项目组周报，QA周报及项目状态报告。

2、权限管理

01_项目管理

02_硬件

03_软件

04_测试

05_质量保证

06_里程碑

07_会议纪要

08_项目周报

W

R

硬件开发

软件开发

测试人员

架构师

QA

CM

3、配置库备份

◆公司级配置管理员需要定期将SVN数据库备份到XXX机器上，备份的周期为每月备份一次。

3.6步骤6：

配置项控制

1、配置项选择准则：

配置项一般为对后续工作有指导意义，有可能需要更新的工作产品。

具体选择时可参考以下内容：

◆源码类配置项：

开发源码：

源码文件，可按照子系统或模块目录为单位标识；

测试源码：

测试程序、测试框架、测试脚本、测试数据等。

◆文档类配置项：

项目管理文档：

项目计划、测试计划、项目周报、项目状态报告等；

工程开发文档：

需求文档、设计文档、测试方案、评审报告、测试报告、参考资料等；

配置管理文档：

配置管理计划、配置状态报告等；

质量保证文档：

质量保证计划、SQA审计周报等；

会议纪要文档：

工作产品评审会议纪要、项目例会会议纪要、项目里程碑评审会议纪要等。

2、配置项命名规则

◆文档配置项命名规则：

项目名称_相应工作产品名称。

以下划连线“_”分开各名称域。

如：

F06_软件需求规格说明书.doc；

文档版本号在文档的修订历史中表明，不在文件命名中体现，从而确保在SVN配置库中仅保留有一个最新版本的文件存在；

文档命名，应以文档模板的命名为基准，如有特殊需求无法按照命名规则进行，需要进行说明。

◆代码命名规则：

名称由英文单词或字母缩写构成，应能标识出代码的功能特性；

名称中可以有两个或三个单词组成，但不应多于三个；

名称中可以包括合法的英文大小写字母、减号、下划线；

可以使用前缀或后缀来进一步区分，如function_usermanage、page_login等；

◆会议和报告类文档命名规则：

项目名称_报告名称_日期，日期形式为yyyymmdd；

✓对于会议纪要类的文档，日期为会议召开日期；

✓对于报告类文档，日期为报告提交日期。

此类文档不必标识其版本，若发现问题修改后只需重新提交，不必更新其标识。

3、配置项的状态：

◆“草稿”（Draft），配置项刚建立时；

◆“正式发布”（Released），配置项通过评审（或审批）后；

◆“正在修改”（Changing），正式发布后的配置项，变更过程中为此状态。

当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”

4、配置项版本号规则：

配置项的版本号与配置项的状态紧密相关：

◆处于“草稿”状态的配置项的版本号格式为：

0.Y；

Y数字范围为1-99；

随着草稿的不断完善，“Y”的取值应递增。

“Y”的初值和增幅由用户自己把握。

◆处于“正式