配置管理计划Word格式文档下载.docx
- 文档编号:22184011
- 上传时间:2023-02-02
- 格式:DOCX
- 页数:17
- 大小:20.32KB
配置管理计划Word格式文档下载.docx
《配置管理计划Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《配置管理计划Word格式文档下载.docx(17页珍藏版)》请在冰豆网上搜索。
本文旨在规范华泰财产保险项目的配置管理,目的如下:
1.结合配置管理工具,规划华泰财产保险项目的配置库框架,制定配置库规范。
2.通过版本控制和变更控制的有效执行,确保所有配置项的完整性和可跟踪性,确保产品内容得到保护,确保产品的修改过程受到控制。
3.控制产品正式发布的时机,规范产品发布的行为方式和工作流程,保证发布的工作产品是正确的、完整的,同时工作产品的发布过程是有计划的和受控的。
1.2适用范围
本文档适用对象:
华泰财产保险项目配置库的使用者。
本文档适用范围:
华泰财产保险项目的整个生存期中,各阶段的产品。
1.3岗位与职责
角色
职责
工程师
-制定计划,负责计划的执行和完善
-建立和维护软件配置管理库、基线库,控制基线的变更、保存所有变更请求
-识别/标识软件配置项,确定哪些内容将纳入基线库
-基线化软件工作产品
-审核待发布的工作产品
-对项目组成员,提供知识、工具的必要培训
-审查、分析变更请求
-做出对变更请求的决定(接受/拒绝),授权变更
-确定变更的责任人、验证手段、审核人
-审查计划
-协助工程师制定计划,并支持计划的执行
-提出变更请求
-提出产品发布请求
-确保只选用基线库的基线来构建工作产品或最终产品
项目组成员
-了解计划,支持工程师的工作
-提交变更请求
-按照过程、规程、约定及工作计划的要求,提交工作产品
-协助计划的制定、参与计划评审
-对于过程活动,实施审核
-产品发布或提交给客户前,实施软件的配置审核
高级经理
-主持评审
-批准产品发布
1.4参考文档
Ø
《配置管理规范》。
2配置库目录结构
一级目录
二级目录
三级目录
目录内容
目录说明
财产
项目组缩写(开发库)
开发文档
存放项目开放方面的文档
如:
问题跟踪文档等
维护文档
存放项目维护方面的文档
用户使用手册、系统维护手册、系统安装手册等
标识:
项目组缩写中文名称
需求文档
项目的系统需求文档,如:
需求规格说明书等
源代码
源代码文件名
支持工作
产品发布期间支持组工作文档
设计文档
系统设计说明书、数据库结构等
测试文档
存放项目的测试文档测试计划、版本发布计划、
系统测试说明书、测试数据、测试申请、测试报告、测试总结等
项目组的常用文档
开发参考、客户联系方式、项目组员联系方式文档;
项目组综合信息等…
项目环境文档
环境搭建手册、保监会验收环境、各种开发测试环境描述、项目组对环境维护的规程等文档
(管理库)
组间沟通文档
存放项目组与其它相关组制订的组间约定内容、组间沟通记录等
项目组缩写-相关组英文简称中文名称
会议纪要
存放本项目进行例会的记录
配置管理文档
项目组配置管理活动文档,如配置管理计划、基线状态报告、变更请求汇总报告、变更请求、会议备忘录等
项目策划
项目策划活动文档,如项目开发计划、项目估计结果、需求分析计划、项目设计计划、项目实现计划等
项目跟踪
项目跟踪活动文档,如项目周报(如上的项目组可不包含项目周报)、项目状态报告等
质量保证文档
项目组质量保证活动文档,如计划、周报、项目问题记录等
模版
存放与项目组工作相关的各文档模版
培训文档
存放本项目进行培训的资料,如等
项目组缩写(基线库)
3配置管理规范
配置库目录结构的制定需遵循以下步骤:
1.配置管理员提出配置库目录结构的方案初稿;
2.经部门审核通过后成为正式规范,所有的配置库均需按照规范的要求建立;
3.对配置库目录结构的优化过程可以在配置库管理员广泛收集配置库使用人员的意见后,定期的遵循以上步骤1、2来予以改进。
项目组配置管理活动文档,如配置管理计划、变更请求
项目策划活动文档,如项目开发计划、阶段计划等
项目跟踪活动文档,如项目周报、里程碑评审报告等
3.1配置库权限管理
3.1.1权限的划分类型如下
⏹只读型-:
在需要对文档的修改作控制时,可以只给指定人员分配读写权限,而为其他人分配只读权限;
⏹可修改型-;
⏹可增/删型-:
此权限通常分配给项目经理和项目组正式职工;
⏹永久删除型-:
此权限通常只分配给配置管理员;
3.2配置标识的定义标准
配置项标识=部门标识–。
其中,
1部门标识:
金融保险部为
2:
项目名称采用约定的缩写规则取长度不超过8位的字符
华泰——华泰系统项目组简称;
3:
类型划分如下:
-质量保证文档
-配置管理文档
-变更请求(代码、数据结构除外)
-代码变更请求
-数据结构变更请求
-会议文档
-项目计划文档
-需求管理文档
-系统设计文档
-测试文档
-用户手册
-其它类型文档
4配置项名称为:
项目工作产品的名称,如需求规格说明书
3.3权限申请流程
⏹非正式员工:
项目经理同意(需要发送相关邮件),即可开放;
⏹正式员工/特批非正式员工:
流程如下:
1.申请人在邮件中描述清楚以下内容:
所在项目组:
项目组
是否分支管理员:
○是⊙否
申请人:
申请时间:
2007-11-23
所需权限说明
请求开通权限
:
—一级目录名称
——二级目录名称:
读写
—一级目录名称:
只读
2.申请人发邮件给项目经理,在邮件主题中要写清“项目组-姓名申请配置库权限”,(如“华泰项目组-金波申请华泰配置库权限”)
3.项目经理审批
✧项目经理如果审批通过,转发邮件给配置管理员,在邮件中写清审批结果;
✧如果审批没有通过,项目经理要回复告知申请人没有通过审批。
4.配置管理员处理
✧配置管理员收到项目经理的邮件后,给申请人开通权限;
✧发邮件通知申请人,抄送项目经理。
3.4配置项操作
配置项以文件为单位。
文件同一次检出的持续时间不能超过5个工作日。
4构建后配置约定
在集成测试之后开始,每次成功,在开发库上建标识。
5基线管理
5.1基线入库
只有源代码进行基线管理。
初次建立的配置项,或经过修改的配置项,必须经过批准之后由项目经理提交入库。
项目组提交的配置项需在邮件中说明是否已经过验证。
5.2基线库的取用
项目组在构造和配送产品时,必须取用软件基线库中的配置项来完成。
只有拥有基线库的管理权限,其他人员只能读取基线库中的内容。
5.3基线变更
5.3.1申请
1.发送邮件主题为:
项目组基线变更申请姓全拼名缩写(大写),其中,为发送日,如工具基线变更申请20050617;
附件文件名同邮件主题名。
2.为便于跟踪基线申请的处理情况,请将申请邮件同时抄送给。
3.模板统一采用问题跟踪模板,有不需要列时,隐藏,而不要删除,以便后续合并处理。
4.在附件中,申请者需明确每一变更的计划解决日期。
5.3.2处理
1.申请者在开发库中进行变更。
2.申请者将变更申请内容粘贴到开发库根目录下的《受控文件汇总清单》中,并指明复核人,告知让其审核。
3.在接到申请,审核通过后,补充填写记录状态,并告知申请者。
4.申请者在备注字段内标示“已合并”。
5.3.3合并基线
1.为了保证最终的产品发布进度不受影响,必须在发布提出的“最晚合并完基线变更内容的日期”前,把与自己相关的基线变更申请合并完成。
2.最终合并时,项目组负责在开发库中打,
3.项目组基线库中建立版本子目录,并将对应内容合并到此目录中。
4.之后又发生变更的文件,原则上将体现在下次发布合并中。
5.为了检查基线库内容的正确性,每次在合并完成后,由项目组负责检查:
基线库中此版本所包含的变更文件,是否和《受控文件汇总清单》中的所列文件一致。
5.3.4问题记录
1.对于审核过程中发现的问题,由负责记录统计,并每月向、发布统计结果。
6配置状态统计
6.1.1配制项状态报告
工程师必须定期(每周)提供变更请求统计月报给项目经理,客户,抄送,高级主管,用以报告和跟踪配制项变更状态。
1.开始条件:
需求基线形成之后;
2.统计级别:
颗粒度为级别,的变更算一次状态改变;
3.报告发送:
发送配置状态报告有两种:
a)正常发送报告,为每周一次
b)以新打驱动,每打一次,发送一次
6.1.2基线状态报告
2.4.1.1报告发送
开始条件:
需求基线形成;
报告发送:
新增加基线;
基线变更发送,要求能够区别两次变更之间功能不同。
2.4.1.2基线产品控制
基线产品为了防止他人未授权修改,作出以下约定:
生产库中形成基线的文件,为了防止被修改,使用功能锁住文件,不允许被修改。
需要修改时走变更申请流程,这样防止意外或者不规范变更文件。
7产品入库
发布的产品要及时提交给部门管理员入部门产品库。
7.1.1入库产品清单
序号
产品名称
备注
1
分版本
2
安装包或升级包
3
用户操作手册
对应版本
4
用户升级手册(升级说明)
5
数据库结构说明文档
对应版本,可以是、或者等格式,但是必须包含正确的数据库构建或变化的:
包括完整的数据库结构和本次版本的变更轨迹
6
需求说明或问题跟踪清单
记录本次版本发布内容的原始需求
8备份
由项目组配置管理员每周进行一次备份,备份后需进行抽查验证并记录。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 配置管理 计划