配置管理指导书.docx
- 文档编号:16749452
- 上传时间:2023-07-17
- 格式:DOCX
- 页数:19
- 大小:35.20KB
配置管理指导书.docx
《配置管理指导书.docx》由会员分享,可在线阅读,更多相关《配置管理指导书.docx(19页珍藏版)》请在冰点文库上搜索。
配置管理指导书
配置管理指导书
1介绍4
1.1目的4
1.2范围4
1.3定义和术语4
2职责4
3概述5
3.1选择配置管理工具5
3.2工作产品的生命周期5
3.3配置库的目录结构6
4配置管理过程7
4.1准备配置管理计划8
4.2建立配置管理环境9
4.3开发初始化阶段管理9
4.4配置项从开发库到受控库的管理10
4.5变更过程中配置项的管理10
4.6发布阶段配置管理的活动12
4.7执行其它配置管理的活动13
5记录表和文档的保存期14
6附录14
6.1clearcase中的开发库和受控库14
6.2确定并标识配置项14
6.3定义基线14
6.4版本号命名约定15
6.5标签命名约定15
6.6配置项命名约定15
配置管理指导书
1介绍
1.1目的
配置管理是一门应用技术、管理和监督相结合的学科,通过标识来记录配置项的功能和物理特性,控制这些特性的变更,记录和报告变更的过程和状态,并验证它们与需求是否一致。
1.2范围
配置管理的活动包括:
∙制定配置管理计划
∙创建受控库
∙受控库存放标识配置项
∙制订变更管理流程
∙按照制订的流程发布工作产品
1.3定义和术语
术语/缩写
意义/全称
CI(s)
配置项ConfigurationItem(s)
CR
变更申请ChangeRequest
CM
配置管理ConfigurationManagement
CMO
配置管理员ConfigurationManagementOperator
CCB
变更控制委员会ConfigurationControlBoard
PM
项目经理ProjectManager
QA
质量保证QualityAssurance
PMP
项目管理计划ProjectManagementPlan
2职责
角色
CM职责
PM
1)评审和批准SCM计划
2)履行变更需求影响分析
3)关闭变更请求
4)作为CCB的成员
5)评审CM活动
6)发版许可
CMO
1)建立和管理配置库
2)保存变更请求
3)基线化配置项
4)生成并发布配置状态发布表
5)对已基线化的配置项分配checkin和checkout权限
6)管理配置库的访问权限
7)增加/删除配置项(仅在收到已获批准的请求时)
8)备份/恢复和归档配置库
CCB
1)评估和批准对配置项的更改
2)确保批准后的更改的实施
QA
1)基线审计
2)评审配置管理计划
3)验证配置库的备份
团队成员
1)提供将要放入受控库的配置项
2)实施配置项的变更
3概述
每一个项目都分配一个配置管理员(CMO),它可以是一个兼职的分析或者设计人员,对所有配置管理员需要提供基于CMO角色的培训以及相关配置管理工具的培训。
CMO制定配置管理计划,PM评审该配置管理计划,QA确保所有的配置管理活动都依照计划和本文挡执行。
这些活动包括:
∙对团队成员进行配置管理和工具的培训
∙建立基线库
∙将已标识配置项按照预定义方式受控
∙控制配置项访问权限
∙依照定义程序对受控配置项进行变更
∙按照已定义程序发布软件产品(或部分软件产品)
∙负责备份工作的进行
∙发布配置管理月报
3.1选择配置管理工具
本公司使用ClearCase、VSS、CVS等作为配置管理工具,用于管理在开发过程中生成的源代码、文档等资料,记录他们的更新历史,使开发团队各成员可以更好的协作。
具体采用何种工具由项目组根据实际情况决定,XX工具的使用方式可参考《XX的使用说明》。
3.2工作产品的生命周期
工作产品从最初的概念到最后形成产品的发布,在整个的生命周期中,每个工作产品都要通过一系列的阶段。
下图表示一个工作产品的生命周期,它包括开发初始化、受控、发布三个阶段。
在开发初始化阶段,工作产品在开发库中进行管理,进入受控库必须经过评审(包括走查)和批准。
在受控阶段,工作产品作为配置项在受控库存在。
工作产品的变更由变更申请(CR)触发一个正式的变更控制程序,由CCB会议决定拒绝或批准变更申请。
当工作产品经过最后的发布审批后,工作产品进入发布状态。
此时工作产品不允许做任何修改。
当然对于不向外发布的工作产品,可能经过一个最终的审批后就完成了发布阶段的工作。
请查看ClearCase中的开发库和受控库来了解ClearCase中开发库和受控库的概念。
3.3配置库的目录结构
为了更好的管理配置库,使配置库具有较好的的保密性和易用性。
各项目在配置库中建立的模块按统一的要求建立项目目录结构。
建立目录结构的方法可参考以下两种:
a、按项目的阶段划分:
项目通常可分为:
高级需求阶段(HLD)、计划阶段(plan)、详细需求阶段(SRS)、设计阶段(design)、编码阶段(coding,含集成测试阶段(IT))、系统测试阶段(ST)、发布阶段(release)、实施阶段(actualize)。
运行环境(env)可平行于各阶段设立单独的目录。
各阶段下的目录结构可根据阶段的特点进行目录的设置,如:
文档(doc)、过程管理(process)、测试(test)等。
以项目ABC为例,按项目的阶段划分,其目录结构如下图所示:
ABC
├─plan
├─design
├─SRS
├─ST
├─HLD
├─coding
│├─setup
│├─src
│└─IT
├─release
├─actualize
└─env
b、按项目的组件划分:
按项目所包含的子系统进行划分,子系统的下级目录根据子系统的特点设置目录如:
coding(编码)、doc(文档)、process(过程)、test(测试)等。
各子系统可共用的配置项可平行于各子系统目录建立一个“总体”(share)文件夹,如:
doc(文档)、ST(系统测试)都可包含在“总体”(share)文件夹内。
可执行程序(安装包setup)、运行环境(env)可平行于各子系统设立单独的目录。
以XYZ项目为例,按项目的组件划分的目录结构如下图所示:
XYZ
├─share
│├─doc
│└─ST
├─module1
│├─coding
│├─doc
│├─process
│└─test
├─module2
│├─process
│├─coding
│├─doc
│└─test
├─setup
└─env
以上两种建立目录的方法,可根据项目特点的不同进行选择使用。
4配置管理过程
1)准备配置管理计划
2)建立配置管理环境
3)开发初始化阶段管理
4)配置项从开发库到受控库的管理
5)变更过程中的配置项管理
6)发布阶段配置管理活动
7)执行其他日常配置管理相关活动
4.1
准备配置管理计划
进入条件
1.项目任务书的下达
2.指定PM
3.确定团队成员
输入
1.项目任务书
步骤
1
指派CMO并确定配置管理工具
PM为项目指派CMO
CMO确定配置管理工具
2
制定配置管理计划
由CMO为配置管理活动做计划,计划包括:
•确定CMO、CCB的组成
•确定配置项、标识配置项
•定义基线
•确定配置活动,如变更控制、发布等
•确定进度安排,如提交基线进度安排、配置管理审核、发布时间等;
•确定基线变更控制等级及控制机构、控制方式;
•确定配置管理状态报告的时间、内容、报告人、报告对象、报告方式、周期等;
•确定配置管理库备份的时间、周期等;
CMO根据以上所述编制配置管理计划
3
配置管理计划评审
QA评审配置管理计划
4
项目成员培训
CMO培训项目成员,包括:
•配置管理基本概念
•应用于项目的配置管理过程
•配置管理工具的使用
输出
1.配置管理计划
退出条件
1.配置管理计划成功通过评审
2.已经在配置管理概念、流程、工具等方面培训项目成员
4.2
建立配置管理环境
进入条件
1.配置管理计划通过评审
输入
1.配置管理计划
步骤
1
建立环境
CMO按照下面的要求安装配置管理环境
∙安装配置管理工具
∙设计受控库结构
∙设置安全(读/写)访问权限
2
环境测试(组内)
由PM、QA和项目组其他成员对配置环境进行测试。
发现问题后进行修改,直到所有问题关闭为止。
3
环境培训
CMO给项目组成员做配置管理环境的培训或者说明
输出
1.配置管理环境
退出条件
1.配置管理环境通过测试
4.3开发初始化阶段管理
进入条件
1.配置管理计划成功通过评审
2.配置管理环境已建立、已评审
输入
1.配置管理计划
步骤
1
开发库管理
在开发初始化阶段,要求每个开发者根据自己的专业经验和谨慎原则,在开发库中对工作产品进行管理。
对工作产品控制的要求:
∙工作产品置于版本工具的控制之下。
∙所有工作产品保存在开发库上。
∙定期备份本阶段的工作产品。
2
提交评审
当工作产品达到预期的完整性状态时,通过评审和批准,PM或评审负责人通知CMO分配权限,把工作产品入受控库。
输出
1.开发阶段工作产品、评审记录
退出条件
1.工作产品成功通过评审
4.4配置项从开发库到受控库的管理
进入条件
1.工作产品已经审批。
2.提交一个新的配置项
输入
1.新的配置项
2.配置管理计划
步骤
1
标识配置项
CMO执行以下确认:
∙提交项作为配置管理计划的一个CI
∙该CI有一个唯一的标识
∙该CI经过必需的质量控制检查(评审和检验)
∙该CI有正确的版本并且遵循命名规则
2
入库
CMO分配权限给项目组成员,项目组成员在受控库中提交(Check-in)配置项,配置项必须有正确的名字,唯一的标识和版本号码
3
登记配置项
CMO在配置项登记表中增加一条记录
4
确认配置项
CMO通知QA该工作产品已经入库
输出
1.受控库中新配置项
退出条件
1.配置项进入受控库
2.修改配置项登记表
4.5变更过程中配置项的管理
进入条件
1.当变更请求被接收,并需立即执行变更时。
输入
1.审核通过的变更申请表(申请人填写,审核人已确认签字)
步骤
1
分配Check-Out的权限
CMO查找《变更申请表》中的需变更的配置项,为变更实施人分配CheckOut权限,并且通知变更实施人。
同时修改配置项登记表。
2
提交
变更实施人完成变更,在审核人审核完成后,通知CMO。
CMO确认下列事项:
∙被提交的配置项是因为变更而Check-Out的项目,或者是一个在CR中被标识的新配置项。
∙配置项经过了必须的检查(审核和测试)。
∙配置项有正确的格式,并遵循命名、版本编号和修订历史的规则。
CMO分配CheckIn权限,通知变更实施人提交变更的配置项到受控库。
同时修改配置项登记表。
3
关闭
所有与变更请求相关的配置项都已经变更后,CMO通知审核人。
审核人确认变更后在《变更申请表》中签字,关闭申请单。
输出
1.变更申请表
2.更新的配置项登记表
退出条件
1.变更请求被成功关闭
4.6发布阶段配置管理的活动
进入条件
1.验收测试完成
2.决定进入发布阶段
输入
1.配置管理计划
步骤
1
冻结
在工作产品经过最后验收后,CMO将受控库中的配置项冻结,进入产品库。
2
编写产品发布报告
编写《产品发布报告》
3
进入发版流程
由CCB授权,产品进入发布流程。
输出
1.开发阶段工作产品、评审记录
退出条件
1.工作产品成功通过评审
4.7执行其它配置管理的活动
进入条件
1.配置管理计划成功通过评审
输入
1.配置管理计划
步骤
1.协助QA进行配置审核;关闭在审核中标识的不符合项。
2.保存并及时更新所有CI记录和CR跟踪记录
3.维护所有配置管理相关记录
4.执行备份或者确认备份执行,并随时可进行备份恢复以检查备份完整性。
5.对新员工进行配置管理和相应工具的培训
6.准备配置管理月报并提交给PM
输出
1.配置管理月报
退出条件
1.项目结束
5记录表和文档的保存期
内容
保存期
配置管理计划、配置管理月报、配置项登记表、变更申请跟踪登记表、产品发布报告
由配置管理员保存到项目结束,
由质量部经理保存至少三年
配置管理计划的评审记录
由配置管理员保存到项目结束,
由质量部经理保存至少一年
6附录
6.1clearcase中的开发库和受控库
关于开发库、受控库的概念对应到ClearCase中可以看为ClearCase的分支,即开发分支,受控分支(或者集成分支)以及发布版本分支。
开发人员工作在开发分支上;受控分支由集成人员控制,供集成各个开发分支的成果之用,可以在关键性里程碑进行标注;而版本发布分支用于正式版本发布,基本不允许任何人修改。
由于ClearCase的视图机制可以与分支紧密结合从而完成不同角色人员工作空间的隔离,因此实际上形成了不同的工作“库”。
6.2确定并标识配置项
CI应在项目的配置管理计划中事先进行确定。
项目开发过程中需纳入配置管理的CI大体可进行如下分类和识别(根据不同的项目,可进行增加或减少):
文档类:
IPD产品开发各阶段的所有交付件;支撑流程的所有交付件;项目管理体系的所有交付件。
代码类:
源代码、可执行程序/安装包;
环境类:
开发环境、运行环境等;
不同项目中识别出的CI,需要进行统一规范的标识。
项目组及相关人员(包括测试人员、CMO、QA)须按照配置项命名约定赋予CI标识。
6.3定义基线
配置管理计划中对基线需进行定义,如需对基线进行变更,可遵循《变更控制过程》后建立新基线。
在项目开发过程中的关键里程碑点必须建立相应的基线,可参考建立的基线和建立时机如下(根据不同的项目,可进行增加或减少):
产品包需求基线:
产品包需求和产品概念通过TR1评审时建立
计划基线:
项目计划批准时建立
详细需求基线:
需求规格通过TR2评审时建立
设计基线:
概要设计、详细设计批准时建立
单元测试基线:
编码、检查、单元测试通过时建立
集成测试基线:
集成测试通过时建立
系统测试基线:
系统测试通过时建立
发布基线:
验收测试通过,发布评审后建立
基线同样需进行统一规范的标识,标识规则参见标签命名约定。
在项目开发过程中所建立的基线,应由CMO及时的进行发布,发布的详细流程和情况可参看发布。
6.4版本号命名约定
版本号表示方法:
一位整数,代表主发布版本号,一般从1—9进行编号,如:
1,5
一位整数,代表次发布版本号,一般从0—9进行编号,如:
0,2
6.5标签命名约定
Ø基线版本标签:
用途:
用于项目组内部发布
书写规则:
由大写英文字母与阿拉伯数字组成
表示方法:
<项目名称><版本号>-<基线类型>-yyyymmdd-<序号>
主要基线类型表示举例:
产品包需求基线:
HLR
计划基线:
PLAN
需求基线:
REQUIRE
设计基线:
DESIGN
集成测试基线:
IT
系统测试基线:
ST
Ø发布版本标签:
用途:
用于项目组对外发布
书写规则:
由大写英文字母与阿拉伯数字组成
表示方法:
<项目名称><版本号>-<发布类型>-yyyymmdd-<序号>
发布类型说明:
◆Alpha版(内部测试版):
一般只在软件开发公司内部运行,不对外公开。
主要是开发者自己对产品进行测试,检查产品是否存在缺陷、错误,验证产品功能与说明书、用户手册是否一致。
◆Beta版(外部测试版):
软件开发公司为对外宣传,将非正式产品免费发送给具有典型性的用户,让用户测试该软件的不足之处及存在问题,以便在正式发行前进一步改进和完善。
一般可通过Internet免费下载,也可以向软件公司索取。
◆Demo版(演示版):
主要是演示正式软件的部分功能,用户可以从中得知软件的基本操作,为正式产品的发售扩大影响。
如果是游戏的话,则只有一两个关卡可以玩。
该版本也可以从Internet上免费下载。
◆Release版(发行版):
不是正式版,带有时间限制,也是为扩大影响所做的宣传策略之一。
比如WindowsMe的发行版就限制了只能使用几个月,可从Internet上免费下载或由公司免费奉送。
◆FullVersion版(完全版):
也就是正式版,是最终正式发售的版本。
6.6配置项命名约定
Ø文档命名约定:
书写规则:
由汉字、英文字母与阿拉伯数字组成
表示方法:
项目名称-IPD产品开发各阶段名称-文档名称-Vx.y
项目名称-支撑流程名称-文档名称-Vx.y
项目名称-项目管理体系-文档名称-Vx.y
IPD产品开发各阶段名称包括:
概念阶段
计划阶段
开发阶段
验证阶段
发布阶段
生命周期阶段
支撑流程名称
产品规划流程
决策评审流程
技术评审流程
新品选用流程
实验局流程
EC流程
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 配置管理 指导书
![提示](https://static.bingdoc.com/images/bang_tan.gif)