配置管理计划word版本

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

配置管理计划

配置管理计划

关于本文档

1前言

1.1 编制目的

本文旨在规范华泰财产保险项目的配置管理,目的如下:

1.结合配置管理工具,规划华泰财产保险项目的配置库框架,制定配置库

规范。

2.通过版本控制和变更控制的有效执行,确保所有配置项的完整性和可跟

踪性,确保产品内容得到保护,确保产品的修改过程受到控制。

3.控制产品正式发布的时机,规范产品发布的行为方式和工作流程,保证

发布的工作产品是正确的、完整的,同时工作产品的发布过程是有计划

的和受控的。

1.2 适用范围

本文档适用对象:华泰财产保险项目配置库的使用者。

本文档适用范围:华泰财产保险项目的整个生存期中,各阶段的产品。

1.3 岗位与职责

1.4 参考文档

➢《配置管理规范》。2配置库目录结构

3配置管理规范

配置库目录结构的制定需遵循以下步骤:

1.配置管理员提出配置库目录结构的方案初稿;

2.经部门审核通过后成为正式规范,所有的配置库均需按照规范的要

求建立;

3.对配置库目录结构的优化过程可以在配置库管理员广泛收集配置库

使用人员的意见后,定期的遵循以上步骤1、2来予以改进。

3.1 配置库权限管理

3.1.1 权限的划分类型如下

⏹只读型-:在需要对文档的修改作控制时,可以只给指定人员分配

读写权限,而为其他人分配只读权限;

⏹可修改型-;

⏹可增/删型-:此权限通常分配给项目经理和项目组正式职工;

⏹永久删除型-:此权限通常只分配给配置管理员;

3.2 配置标识的定义标准

配置项标识=部门标识–。其中,

①部门标识:金融保险部为

②:项目名称采用约定的缩写规则取长度不超过8位的字符

华泰——华泰系统项目组简称;

③:类型划分如下:

-质量保证文档

-配置管理文档

-变更请求(代码、数据结构除外)

-代码变更请求

-数据结构变更请求

-会议文档

-项目计划文档

-需求管理文档

-系统设计文档

-测试文档

-用户手册

-其它类型文档

④配置项名称为:项目工作产品的名称,如需求规格说明书

3.3 权限申请流程

⏹非正式员工:

项目经理同意(需要发送相关邮件),即可开放;

⏹正式员工/特批非正式员工:

流程如下:

1.申请人在邮件中描述清楚以下内容:

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基线产品控制

基线产品为了防止他人未授权修改,作出以下约定:

生产库中形成基线的文件,为了防止被修改,使用功能锁住文件,不允许被修改。

需要修改时走变更申请流程,这样防止意外或者不规范变更文件。

相关文档
最新文档