CMDEV301 配置管理应用指南.docx
- 文档编号:11777497
- 上传时间:2023-06-02
- 格式:DOCX
- 页数:21
- 大小:224.10KB
CMDEV301 配置管理应用指南.docx
《CMDEV301 配置管理应用指南.docx》由会员分享,可在线阅读,更多相关《CMDEV301 配置管理应用指南.docx(21页珍藏版)》请在冰点文库上搜索。
CMDEV301配置管理应用指南
本资料仅供内部使用!
配置管理应用指南
XXXXXXXXXXX有限公司
2020年01月05日
本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容,除另有特别注明,版权均属XXXXXXXXXX有限公司所有,受到有关产权及版权法保护。
任何个人、机构未经xxxxxx有限公司的书面授权许可,不得以任何方式复制或引用本文件的任何片断。
修改记录
制定日期
生效日期
制定/修订内容摘要
页数
版本
拟稿
审查
批准
2020/01/05
创建
V1.0
李杨
2020/01/25
增加集成部分
V2.0
李杨
2020/02/23
增加异地项目说明
V3.0
李杨
2021/03/01
更换流程图
V3.1
肖果
2021/3/11
添加项目发布申请表
V3.2
李杨
1概述
1.1目的
本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。
1.2适用范围
本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减。
配置管理可采用各种工具及手工办法。
1.3术语和缩略语
术语
描述
软件配置管理
软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程。
是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。
配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。
基线
基线是项目开发库中每个工件版本在特定时期的一个“快照”。
在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。
每一个基线都是其下一步开发的出发点和参考点。
基线确定了元素(配置项)的一个版本,且只确定一个版本。
一般情况下,基线在指定的里程碑处创建,并与项目中的里程碑保持同步。
每个基线都将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再被任何人随意修改,对其修改要严格地按照变更控制的过程进行。
在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线。
基线的主要属性有:
名称、标签、版本、日期等。
配置项
凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的。
每个配置项的主要属性有:
名称、标签、文件状态、版本、作者、日期等。
所有配置项都被保存在配置库里,确保不会混淆、丢失。
配置项及其历史记录反映了软件的演化过程。
开发库
存放开发过程中需要保留的各种信息,供开发人员个人专用。
开发人员对其具有编辑、修改、删除等操作权限
基线库
存放基线的库,由配置管理工程师从开发库中提取出来。
以后的版本更新将在此基础上进行更新。
所有除SCM以外人员对基线库的最大权限只能为只读权限。
产品库
产品库的产品均出自于基线库,产品库存储的产品用于交付和存档
1.
1.1
1.2
1.3
1.4角色与职责
角色
职责
项目经理
1) 确定配置项、基线、配置库目录权限,审核批准配置管理计划;
2) 接收或拒绝小范围的变更申请,审查配置库变更;
3) 项目开发过程中,监督配置库使用情况;
4) 提出配置管理的建议和要求;
5) 配合配置管理工程师的工作。
变更控制委员会CCB
一个虚拟小组,可由EPG成员、项目经理、资深的项目成员、配置管理工程师、QA等组成,项目经理为CCB召集人;CCB对配置管理各项活动拥有决策权(例如评审核划、评审变更请求等)。
开发小组
1) 根据确定的配置管理计划和相关规定,提交配置项;
2) 负责项目组内部测试;
3) 按照软件配置管理工具的使用模型来完成开发任务。
测试小组
1)从配置管理工程师处获取版本进行整合测试;
2)负责验证代码变更及修改是否正确执行,测试小组测试通过的版本方可放入基线库。
QA
1)负责审核配置管理过程。
2)对配置审核中发现的不符合项,要求相关责任人进行纠正。
3)审核《配置管理计划》。
配置管理工程师
1) 编写配置管理计划;
2) 执行版本控制和变更控制方案;
3) 制定访问控制策略;
4) 负责项目的配置管理工作,包括搭建环境、权限分配、配置库的建立、配置项的控制等;
5) 负责软件集成和版本生成,产品交付
5) 定期备份配置库;
6) 配置管理工具的日常管理与维护;
7) 配置库的日常操作和维护;
8) 负责配置审核并提交报告;
9) 根据配置部署表单编译发布版本,并维护版本;
10) 建立和完善配置管理制度;
11) 对开发人员进行相关的培训;
12) 对配置审核中发现的不符合项,拟订纠正措施,要求相关责任人进行纠正;
13) 监督项目组成员规范的执行情况;
14)建立和发布基线;
15)编写配置管理状态报告
1.4
1.5配置管理过程图示
图1
2.
2配置项管理
2.1配置项的范围
软件配置可包括以下几方面:
开发文档,代码,第三方控件、插件,参考资料,测试文档,用户文档,项目管理文档,验收文档等。
项目文档主要指:
立项建议书、可行性分析报告、技术建议书、用户段性计划、产品需求规格说明书、概要设计报告、详细设计、数需求说明书、项目计划、项目进度计划、项目阶据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录。
代码主要指:
源代码等。
工具主要指:
脚本文件、插件、第三方控件等。
3版本控制
3.
3.1基线命名规范
基线即项目某一阶段配置项的快照,作为下一阶段软件活动的基础。
基线的建立通过打标签的方式实现,具体命名方式如下:
[项目名称]+[阶段名称]+[日期]+[版本类型]+[版本号]+[分支版本号]
[项目名称]:
即项目简称,大写。
如:
GD_JYPX
[阶段名称]:
可选,如计划阶段(PP)、需求阶段(RD)、设计阶段(SD)、编码阶段(CD)、测试阶段(TEST)。
[日期]:
YYYYMMDD。
如:
20110312
[版本类型]:
I表示增量版本,V表示全量版本。
[版本号]:
采用X_Y的形式,X表示大版本,Y表示子版本。
版本号反应了版本变化的程度。
如:
1_12
[分支版本号]:
可选,表示在某个主干上建立的分支。
如:
GD_JYPX_20110312_V1_13_Branch1_0表示在主干GD_JYPX_20110312_V1_13上建立版本为1_0的分支。
3.2发行版本表示
发行版本采用标签说明,结构如下:
[项目名称]+[大版本]+[版本类型]+[版本号]+[子系统简称(拼音)]+日期+序号
Ø[大版本]:
可选,表示同一项目为不同用户定制的版本。
Ø[子系统简称]:
可选,当一个项目有多个子系统时,为区分不同子系统而设置。
Ø[版本类型]:
分为3种
Beta表示项目组内部测试,标签:
NGTS_B1_0-20111015-01
Release系统测试,标签:
NGTS_Release1_0-SPmenhu-20111112-01
Version正式发行版,标签:
NGTS_Version1_0-SPmenhu-20111112-01
Ø[版本号]对于Version正式发行版是必须要注明的,而其它可选。
4配置库管理
4.
4.1配置库的建立
项目立项时,由项目经理申请建立项目配置库,配置管理工程师与项目经理确定配置项,并参考《配置库目录结构指南》,建立配置库以及配置库目录结构;项目经理提供配置库权限清单(内容应包括员工姓名、项目名称、目录权限等),由配置管理工程师为相关人员的设置配置权限。
配置管理工程师组织建立配置库。
程序库主要通过设置版本的分支来实现对配置项权限管理:
1)编辑区:
开发人员相对比较自由的存储空间,开发人员可以在自己的权限范围内任意取出提交。
2)管理区:
项目质保人员,测试人员,需求分析人员均有读写权限。
3)基线区:
配置管理工程师有最高权限,其余相关人员均为读的权限,发生变更时变更人员须提交变更申请后方可修改基线库内的配置项。
Ø 文档评审通过后,文档严格受控。
由配置管理工程师将通过评审后的文档移植到基线库里同时将该配置项从开发库移除。
Ø 代码一般在移交系统测试时纳入基线库受控,可根据项目的具体情况设置基线。
3)产品区:
产品库的产品均出自于基线库,产品库存储的产品用于交付和存档。
配置库统一由配置管理工程师管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作。
在变更发生时,应及时做好基线的推进。
4.2分配权限
项目开始后配置管理工程师编写配置库目录结构,明确项目组成员以及相关人员的权限。
一般配置库可设立的权限有两种,读(r)、写(w)权限。
在编辑区内,文档部分项目组成员有rw权限,其他相关人员只r权限;代码部分项目组成员有rw权限,其他相关人员没有任何权限。
在基线库内,项目组成员仅有r权限,其他相关人的权限视情况而定。
在产品区内,除配置管理工程师外其他人没有任何权限。
配置管理工程师在整个配置库内均拥有最高权限。
配置库权限设置完成之后,由配置管理工程师将配置库名称、访问路径、访问权限等信息以邮件方式通知各相关人员;配置库使用人员以各自的用户名和密码进行访问配置库。
配置库密码只能在服务器上设置,如配置库使用人员密码遗忘,可以与配置管理工程师取得联系,进行修改密码。
4.3基线库建立
基线存在于基线库中,它是进一步开发和修改的基准和出发点。
对基线的变更只有配置管理工程师能实施。
进入基线前不对基线进行管理或者较少管理,进入基线后,对变化进行有效管理,而且这个基线作为后续工作的基础。
对于每一时期基线库的建立都应遵循以下原则:
1.需要建立基线时,由项目经理提出基线建立申请,并填写《基线建立通知单》。
如项目经理未在计划时间点申请建立基线,配置管理工程师需主动提醒项目经理,CCB对基线建立申请进行评审,以保证组成基线的配置项是协调一致的、完整的、正确的。
2.CCB评审并批准基线建立申请后,配置管理工程师根据《基线建立通知单》中相应内容建立基线库,将正确的版本对应的所有资料纳入基线库管理。
3.基线区的使用者的权限只能为只读权限。
使用者向项目经理或部门经理提出权限需求,在领导同意之后,配置管理工程师设置相应权限,并通知相应人员。
纳入基线的原则:
1.不会变化的东西不要纳入基线。
例如:
会议纪要,周报,规范,方案
2.变化对其他没有影响的可以不纳入基线
例如:
风险跟踪表等
3.变化对其他有影响的配置项需要纳入基线。
例如:
需求规格书
4.4配置项基线管理
配置管理工程师根据配置管理规范及配置管理计划,对配置项进行分阶段管理,每一阶段在项目经理申请建立基线并且正式评审通过后纳入基线库,作为该项目的一个基线。
项目启动:
配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档,评审或审批通过后建立功能基线。
需求阶段:
系统调研后开发人员进行需求分析,并整理产品需求规格说明书。
产品需求规格说明书经过客户的确认后,建立需求基线。
如需升级版本则必须通过评审或审批并得到客户的确认。
项目计划:
需求分析完成后即可制定项目的开发计划,包括项目计划和主要下属计划。
包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划。
项目开发计划评审通过后,建立项目计划基线。
设计:
系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。
针对用户需求规格说明书进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系。
设计说明书评审或审批通过后,建立设计基线。
编码(设计实现):
编码按功能模块分子项目,即每个模块记作一个配置项。
代码在开发内部测试时提交Beta版,提交测试组系统测试时建立Release版本,系统测试产品正式发布后建立Version版本。
测试:
单元测试和系统测试。
单元测试通过提交《单元测试报告》,项目启动后应提交《测试计划》,系统测试完成后应提交《测试报告》。
配置时应说明测试的版本与编码版本的对应关系。
系统测试完成后建立测试基线。
版本发布:
指发布测试组测试,项目组提交《代码交付清单》,CME根据清单获取代码进行编译,并按照《代码交付清单》中的内容将缺陷管理流程中已经FIX的BUG状态置为Deliver,发布到测试区,并对版本进行维护。
测试组仅需测试已经Deliver的BUG。
待测试完毕后将发布测试的版本转移到基线区中的产品,以备发布。
交付与验收:
在交付前配置审核完成后建立产品基线,产品基线包含程序以及有关文档配置项,包括交付文档、代码、工具等。
产品部署:
部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档。
相关资料:
相关资料也应作为配置项纳入配置管理,此部分包括:
1)相关法律、法规;必须遵照或项目组约定的技术规范;
2)与客户或项目组内部重要的交互信息记录,如会议记录、会谈记录、e-mail和MSN记录等;
下面是各时期基线简要图示:
图3
4.5配置库备份
配置管理工程师应定期做好配置库的备份,以防意外引起的服务器上资料的丢失,避免给公司带来严重的损失。
配置管理工程师每周进行硬盘备份一次,每两个月进行光盘备份一次,备份后的光盘标记上备份日期并附上内容清单,移交公司保管。
配置管理部门在每次备份后要填写《配置库备份记录表》,里面需记录备份日期和内容。
5配置库使用规范
1.所有立项的项目,都必须申请建立配置库。
开发过程中所有文档和代码必须纳入配置库管理,若因未纳入配置库管理造成的资料丢失或版本差异,其责任皆由开发人员及项目经理承担。
2.配置库服务器密码只有配置管理工程师掌握,其他人如因特殊原因需要该密码,必须经过软件研发中心经理的批准后方能获取;并在使用完密码之后,通知配置管理工程师,配置管理工程师及时设置新的密码,以保证服务器资料的安全性和机密性。
3.各配置库的使用人员必须使用各自的用户名和密码进入配置库,访问各自的配置库。
各使用人员不得将自己的用户名和密码泄漏给其他人员,若因泄露密码而引起的后果将由泄漏密码者本人承担。
4.项目组成员未经项目经理同意不得更改他人的文档和代码。
各项目的配置库用于项目组正式开发使用,项目组成员不得恶意对其进行修改、删除、增加等操作;若因对SVN工具不熟悉,需要学习,可以向配置管理工程师提出需求,由配置管理工程师为其提供可以练习的配置库。
5.各项目经理负责定期检查配置库的使用情况,查看是否有员工进行无故删除或恶意修改文件的行为;并对开发人员提交的文档和代码的及时性、准确性和完整性进行检查。
6.在研发中心员工离职时,对于在项目中的人员,由其项目经理负责检查配置库,检查该人员提交的代码或文档是否完全放入配置库管理,确认版本和相应文件完整无误后,项目经理在“员工离职申请单”中签字,该员工方可离职。
同时项目经理应及时通知配置管理工程师,取消该人员的配置库账号。
若因项目经理审核不细致造成的代码或文档移交不完整,或项目经理未及时通知配置管理工程师取消账号,而造成的损失,该责任完全由项目经理承担。
对于不在项目的人员,由该部门的经理或主管通知配置管理工程师取消该人员的配置库帐号。
对于这两种情况配置管理工程师均需在“员工离职申请单”中签字,以确认离职员工的配置库帐号已被删除。
7.在配置库使用时,为了避免配置库update或commit时引起冲突,需注意:
项目经理在划分模块时注意每个人的模块之间不要重叠。
开发人员在修改文件之前,养成事先update的习惯。
开发人员注意commit的频率,尽量及时commit,最好每天至少提交一次。
6系统集成
系统集成,简称集成。
集成通常在编码阶段存在,其基本的使命就是把产品的各个部分捏在一起,并保证产品作为整体是可以运转的,而不仅是每个模块,每个单元能在特定的开发调试环境、特定的数据和参数下运转。
集成由配置管理工程师来做有以下好处:
1.避免开发人员在集成过程中加入私有操作;
2.保证每次集成环境相同、构建方式相同;
3.由配置管理来控制集成周期,能保证产品质量以及测试质量;
4.集成流程图
图4
6.1集成步骤
1.确保开发人员都提交了相关的源代码。
2.冻结或者标识将要集成的源代码。
3.取出要集成的源代码(比如放入集成区)。
4.编译、链接和打安装包。
(通常称为构建)如有问题则打回开发修改代码
5.安装并粗略测试,即测试安装包是否能够成功部署。
6.标识和存储集成成果。
7.通知相关人员本次集成完成。
构建是集成的核心部分,其输入为源代码或相关文档,输出通常是产品包。
构建分为全量构建和增量构建,具体如何执行需按计划或同项目经理商议。
6.2集成结果存放位置
1.如果本次集成仅用于开发组内部测试(Integration)
则用于集成的源代码还放在集成区的源码区域内,作为开发人员今后开发的基础;集成后的产品包放入集成区的产品区域里,开发人员可从该区域获取测试。
2.如果本次集成用于发布测试组测试(Migration)
则将用于集成的源码放入基线区的源码区域内,作为开发人员今后开发的基础;集成后的产品放入测试区供测试组测试。
当测试完毕后将测试结果连同产品包放入基线区的产品区域内,如果有发布需要可用其对外发布。
6.3说明
对于开发人员:
由于目前部门配置管理工程师人手有限,所以集成的方案、环境和工具均由开发人员提供,由配置管理工程师执行。
即使这样配置管理工程师也需要有一定的开发能力。
对于测试人员:
测试人员只能从配置管理工程师处获取产品包。
测试人员跟开发人员没有直接的产品接口。
7配置变更控制
5.
7.1软件及其相关文档的变更
6.
7.
7.1
7.1.1变更的分类
软件及其相关文档的变更按照变更的影响范围进行分类:
1)A级:
变更会影响系统级的需求、外部接口、产品价格或者交付期;这类变更必须经过配置管理委员会审核并有客户批准和确认。
2)B级:
变更会影响配置项间的功能接口、内部功能的设计、组件;这类变更必须由项目经理或配置管理委员会的批准和认可。
3)C级:
变更只会影响配置项内部或对BUG问题的处理;这类变更可以由配置项的管理人员负责批准。
7.1.2变更请求的提出
a. 变更申请人汇集客户意见,填写《配置项变更申请表》,并提交给配置管理工程师。
b. 配置管理工程师对申请表是否清晰、明确和完整性进行审查,若发现变更不明确或不完整,应返回申请者。
对通过审查的变更申请分配变更ID,以便跟踪和记录变更信息。
7.1.3评估变更
a. 配置管理工程师将《配置项变更申请表》发送给CCB(或者其他授权人员),由CCB负责对变更进行评估。
b. CCB对变更进行分解,一般的BUG修正不需要审批直接由项目经理决定是否需要变更。
新增功能或对整个项目影响重大的变更必须由研发部总经理审批通过后方可变更。
变更评估文档在完成变更评估后发送给配置管理工程师。
7.1.4变更实施和确认
a. 变更被批准后,项目经理提交变更实施进度计划,开发人员开始实施变更,并详细记录变更的内容;配置管理对变更的实施状态进行跟踪,项目经理跟踪变更实施进度。
b. 对于代码变更,必须进行回归测试,以确保变更没有引入新的Bug。
另外与变更相关的文档必须修订,以反映变更。
当变更以及测试完成后,进行提交。
c. 通过测试后,PM需对变更进行审核,审核的范围一般涉及以下方面:
测试记录;变更请求;配置项的检入及检出;文件的命名;版本的编号。
d. 审核后,由配置管理工程师更新到基线库中,并发送《配置项变更通知单》给项目组全体。
7.1.5变更图示
图5
7.2配置库权限变更管理
若在使用配置库的过程中需要变更配置库管理权限,可以由项目管理员或项目经理以邮件方式通知配置管理工程师,配置管理工程师变更之后,将变更结果以电子邮件方式通知受影响的人员、项目经理、项目管理员及其相关人员。
配置管理工程师根据配置库权限变更频率,决定每隔一段时间将配置库权限清单与各项目经理进行审核确认,各项目经理审核后,若有权限需要进行变更,应及时通知配置管理工程师。
8配置状态报告
8.
8.1目的
记录和报告整个软件生命周期演化状态。
8.2记录内容
配置状态报告记录的内容包括:
1)软件和文档的标识;
2)目前状态;
3)基线演化状态;
4)变更状态;
5)版本交付信息等。
8.3生成报告
配置管理报告自第一个基线创建时建立,由配置管理工程师编写,及时反映当前基线区配置项状态,对于基线区的变更和基线的建立需实时在配置状态报告中反应。
9CM阶段报告
9.1目的
定量记录和报告每个阶段工作内容
9.2记录内容
CM阶段报告记录的内容包括:
1)工作成果;
如:
本周期内制定SCMP,标识配置项,创建配置库,辅导项目组使用配置管理工具,新建的基线,纳入基线的配置项清单,发出几份状态报告;
2)问题与风险;
如:
SCM相关的问题及解决情况,风险及措施,跟踪情况等等信息,提请其他人重点关注的事务
3)变更;
如:
各阶段变更申请的数量、状态,工作量合计等等信息
4)下个周期的计划;
如:
安排基线审计的对象、时间,将要建立的基线,状态报告等等
5)度量数据
9.3生成报告
CM周期以一周为准,在每周结束时配置管理工程师根据【CM阶段报告】汇报本周的工作进展。
10配置审核
9.
10.1类别
配置审核分为:
1)功能配置审核(FunctionalConfigurationAudit,FCA):
审核软件功能是否与需求一致,并符合基线文档要求,通常要审查测试文档等。
2)物理配置审核(PhysicalConfigurationAudit,PCA):
审核要交付的组成项是否存在,是否包含所有必需的项目,如正确版本的源代码、资源、文档、安装说明等等。
10.2执行时机
通常选择以下几种情况由质量保证人员负责实施配置审核:
1)软件产品交付或是软件产品正式发行前;
2)软件开发的阶段工作结束后;
3)在产品维护工作中,定期地进行。
如果不清楚审核周期,则按照QA的要求进行每2周一次。
10.3不符合项处理
对配置审核中发现的不符合现象,配置管理工程师进行记录,并交由责任部门限期进行纠正,配置管理工程师负责纠正措施的验证。
所有的不符合项报告均关闭后,才能发布新版本。
11发布管理
通过配置审核后,经项目经理批准,由配置管理工程师负责发布新版本。
10.
11.
12.
11.1交付管理
这里“交付”是指从配置库中提取配置项,交付给
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMDEV301 配置管理应用指南 配置管理 应用 指南