配置管理流程.docx
《配置管理流程.docx》由会员分享,可在线阅读,更多相关《配置管理流程.docx(15页珍藏版)》请在冰豆网上搜索。
配置管理流程
配置管理流程
文件属性
机密等級
普级
发行方式
公司发行
文件编写
马海坡
文件批准
研发管理部
版权宣告
本文內容涉及公司商业秘密,著作权属汉柏科技有限公司所有,非经准许不得以任何
形式复制、传播及使用
Allrightsreserved.ByOPZOON
版本历史
版本
作者
审批者
发布日期
修改内容
1.0
马海坡
许文新
初始版本
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:
制定配置管理计划
名称(What)
制定配置管理计划
责任人(Who)
配置管理员
时间(When)
●项目启动阶段,确定TR1-TR2的《配置管理计划》
●项目计划阶段,输出完整的《配置管理计划》
输入(Input)
●项目过程定义
●项目计划
输出(Output)
●配置管理计划
方法(How)
1、配置管理员根据配置管理计划模板制定配置管理计划,主要内容:
◆配置项标识:
基于项目过程定义中定义的输出物
确定本项目的配置项,原则上需要后续进行维护和修改的工作产品可作为配置项;
确定管理级别,如对于需求文档需要加大管理力度,而对于报告类的文档则无需花费太多时间。
◆基线计划,确定各基线的建立时间
按照工作产品单个入基,逐步完善的原则建立基线。
如设计基线包括:
概要设计、详细设计等文档。
当完成概要设计评审后可先入基线,然后详细设计完成后再入基,最终形成设计基线。
◆汇报机制及计划
配置项状态报告的时间点。
◆分支集成策略
Trunk分支及Branch分支如何集成,何时集成的策略。
2、完成配置管理计划的编制后,发送给项目经理进行审批。
注解(Comments)
3.3步骤3:
评审通过?
名称(What)
评审通过?
责任人(Who)
项目经理
时间(When)
TR1-TR2
输入(Input)
●配置管理计划
输出(Output)
●配置管理计划
方法(How)
1、将本计划同项目各计划一同进行评审。
◆如评审通过,则进行后续活动;
◆如不通过,则修改直到通过为止。
注解(Comments)
3.4步骤4:
完成工作产品
名称(What)
完成工作产品
责任人(Who)
项目组
时间(When)
TR1-TR6
输入(Input)
●项目计划
输出(Output)
●工作产品
方法(How)
1、项目组按完成工作产品
◆具体的时间点参考项目计划中规定的时间点。
2、个人对工作产品的配置管理
◆文档:
建议开始编写时就检入到文档库的规定位置,每次修改后进行提交,这样可以随时获取之前的版本,防止误操作丢失,也更方便其他人查看;
最低要求在发出评审前将工作产品的初稿检入到SVN的文档库中进行管理,以保证文档的版本受控;
文档入基后,后续的工作以基线文档为准。
不能再以开发区中的文档作为参考;
入基后的文档不能随意修改,如需修改一定是由于变更引起的,变更的管理请参考《变更管理流程》。
◆代码:
代码分为开发分支和集成分支;
开始编码时将代码检入到开发分支;
代码经过单元测试和CodeReview后检入到集成分支;
向集成分支检入文件需要经过研发组长同意。
注解(Comments)
项目成员每次检入时,需要在comments中填写说明,说明内容包括:
修改了哪些内容,为什么修改等内容。
特别是为了解BUG而修改代码时,需要写明BUG的ID
3.5步骤5:
配置库管理
名称(What)
配置库管理
责任人(Who)
配置管理员
时间(When)
TR1-TR6
输入(Input)
●配置管理计划
输出(Output)
●无
方法(How)
1、配置库结构
◆01_项目管理:
存放项目管理相关的一次性输出的配置项的初稿及过程版本,如:
项目通知,立项报告书等;
存放周期性输出物,如度量数据,变更控制报告。
◆02_硬件:
存放硬件的输出物,开发组长可根据需要增加目录;
◆03_软件:
存放软件的文档输出物的过程版本,如SRS、系统设计说明书;
存放代码,包括开发分支、集成分支以及build好的版本。
◆04_测试:
存放测试的过程文档及参考资料等;
◆05_质量保证:
存放QA的审计记录,流程提醒等输出;
◆06_里程碑:
作为项目的基线库,每个里程碑的输出物入基后放到本目录下;
◆07_会议纪要:
存放项目的各种会议纪要;
◆08_项目周报:
存放项目组周报,QA周报及项目状态报告。
2、权限管理
01_项目管理
02_硬件
03_软件
04_测试
05_质量保证
06_里程碑
07_会议纪要
08_项目周报
项目经理
W
R
R
R
R
W
W
W
硬件开发
R
W
R
R
R
R
W
W
软件开发
R
R
W
R
R
R
W
W
测试人员
R
R
R
W
R
R
W
W
架构师
R
W
W
R
R
R
W
W
QA
R
R
R
R
W
R
W
W
CM
W
W
W
W
W
W
W
W
3、配置库备份
◆公司级配置管理员需要定期将SVN数据库备份到XXX机器上,备份的周期为每月备份一次。
注解(Comments)
3.6步骤6:
配置项控制
名称(What)
配置项控制
责任人(Who)
配置管理员
时间(When)
TR1-TR6
输入(Input)
●配置管理计划
输出(Output)
●无
方法(How)
1、配置项选择准则:
配置项一般为对后续工作有指导意义,有可能需要更新的工作产品。
具体选择时可参考以下内容:
◆源码类配置项:
开发源码:
源码文件,可按照子系统或模块目录为单位标识;
测试源码:
测试程序、测试框架、测试脚本、测试数据等。
◆文档类配置项:
项目管理文档:
项目计划、测试计划、项目周报、项目状态报告等;
工程开发文档:
需求文档、设计文档、测试方案、评审报告、测试报告、参考资料等;
配置管理文档:
配置管理计划、配置状态报告等;
质量保证文档:
质量保证计划、SQA审计周报等;
会议纪要文档:
工作产品评审会议纪要、项目例会会议纪要、项目里程碑评审会议纪要等。
2、配置项命名规则
◆文档配置项命名规则:
项目名称_相应工作产品名称。
以下划连线“_”分开各名称域。
如:
F06_软件需求规格说明书.doc;
文档版本号在文档的修订历史中表明,不在文件命名中体现,从而确保在SVN配置库中仅保留有一个最新版本的文件存在;
文档命名,应以文档模板的命名为基准,如有特殊需求无法按照命名规则进行,需要进行说明。
◆代码命名规则:
名称由英文单词或字母缩写构成,应能标识出代码的功能特性;
名称中可以有两个或三个单词组成,但不应多于三个;
名称中可以包括合法的英文大小写字母、减号、下划线;
可以使用前缀或后缀来进一步区分,如function_usermanage、page_login等;
◆会议和报告类文档命名规则:
项目名称_报告名称_日期,日期形式为yyyymmdd;
✓对于会议纪要类的文档,日期为会议召开日期;
✓对于报告类文档,日期为报告提交日期。
此类文档不必标识其版本,若发现问题修改后只需重新提交,不必更新其标识。
3、配置项的状态:
◆“草稿”(Draft),配置项刚建立时;
◆“正式发布”(Released),配置项通过评审(或审批)后;
◆“正在修改”(Changing),正式发布后的配置项,变更过程中为此状态。
当配置项修改完毕并重新通过评审(或审批)时,其状态又变为“正式发布”
4、配置项版本号规则:
配置项的版本号与配置项的状态紧密相关:
◆处于“草稿”状态的配置项的版本号格式为:
0.Y;
Y数字范围为1-99;
随着草稿的不断完善,“Y”的取值应递增。
“Y”的初值和增幅由用户自己把握。
◆处于“正式发布”状态的配置项的版本号格式为:
X.Y;
X为主版本号,取值范围为1-9。
Y为次版本号,取值范围为1-9;
配置项第一次“正式发布”时,版本号为1.0;
如果配置项的版本升级幅度比较小,一般只增大Y值,X值保持不变。
只有当配置项版本升级幅度比较大时,才允许增大X值。
◆发布版本号规则:
构建版本号命名规则:
v*.*.*.*(patch)_*,即前三位是项目版本号,第四位是Build号,再接下来*是Alpha号或Beta号,例如:
v1.0.0.1010_alpha2,v1.0.0.1010patch1_alpha1,v1.0.0.1010_Beta1等。
注解(Comments)
3.7步骤7:
基线管理
名称(What)
基线管理
责任人(Who)
配置管理员
时间(When)
TR1-TR6
输入(Input)
●配置管理计划
输出(Output)
●基线
方法(How)
1、定义基线:
◆在配置管理计划中定义出项目过程中的基线。
2、建立基线:
◆文档基线:
每个里程碑(TR1-TR6)建立一条基线,基线内容包括本阶段的主要输出物,配置管理员在本阶段的里程碑评审前发出基线状态报告给项目组;
◆代码基线:
在项目的编码阶段,配置管理员在每个版本上打一个标签,建立一条基线。
3、基线变更:
◆当项目出现变更时,可能会引起基线的变化,此时依据《变更管理流程》执行,执行完成后,配置管理员要检查基线的状态,并出具基线状态报告。
注解(Comments)
3.8步骤8:
报告配置状态
名称(What)
报告配置状态
责任人(Who)
配置管理员
时间(When)
TR1-TR6
输入(Input)
●配置管理计划
输出(Output)
●配置状态报告
方法(How)
1、配置管理员根据配置管理计划中规定的周期发送配置状态报告
◆一般在某一阶段结束后及项目基线库发生变更后需要向项目相关人员发送项目配置状态报告通报配置项状态。
注解(Comments)
4附录
附录A配置管理模板
●配置管理计划模板《OPZOON_CM_TMP_CMP配置管理计划.doc》
●配置项状态报告模板《OPZOON_CM_TMP_CSR配置项状态报告.xls》
●配置活动进度计划模板《OPZOON_CM_TMP_CAS配置活动进度计划.xls》
附录B公司标准目录结构