配置管理计划

配置管理计划

关于本文档

1前言

1.1 编制目的

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

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

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

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

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

产品是正确的、完整的，同时工作产品的发布过程是有计划的和受控的。

1.2 适用范围

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

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

1.3 岗位与职责

1.4 参考文档

➢《FI-SCM-配置管理规范.doc》。2配置库目录结构

3配置管理规范

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

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

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

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

意见后，定期的遵循以上步骤1、2来予以改进。

3.1 配置库权限管理

3.1.1 VSS权限的划分类型如下

⏹只读型－read：在需要对文档的修改作控制时，可以只给指定人员分配读写权

限，而为其他人分配只读权限；

⏹可修改型－check out/check in；

⏹可增/删型－add/delete/rename：此权限通常分配给项目经理和项目组正式职

工；

⏹永久删除型－destroy：此权限通常只分配给配置管理员；

3.2 配置标识的定义标准

配置项标识=部门标识-Project Name-Type – Name Version。其中，

①部门标识：金融保险部为FI

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

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

③Type：类型划分如下：

SQA－质量保证文档

SCM－配置管理文档

CR－变更请求（代码、数据结构除外）

CODEM－代码变更请求

DBM－数据结构变更请求

MTG－会议文档

SCM－项目计划文档

RM－需求管理文档

SD－系统设计文档

TEST－测试文档

MAN－用户手册

OTH－其它类型文档

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

3.3 权限申请流程

⏹非正式员工：

项目经理同意（需要发送相关邮件），即可开放；

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

流程如下：

2.申请人发邮件给项目经理，在邮件主题中要写清“XXX项目组－XXX姓名申请

XXX配置库权限”，（如“华泰项目组－金波申请华泰配置库权限”）

3.项目经理审批

✧项目经理如果审批通过，转发邮件给配置管理员，在邮件中写清审批结果；

✧如果审批没有通过，项目经理要回复告知申请人没有通过审批。

4.配置管理员处理

✧配置管理员收到项目经理的邮件后，给申请人开通权限；

✧发邮件通知申请人，抄送项目经理。

3.4 配置项操作

配置项以文件为单位。

文件同一次检出的持续时间不能超过5个工作日。

4Build构建后配置约定

在集成测试之后开始，每次build成功，在开发库上建lable标识。

5VSS基线管理

5.1 基线入库

只有源代码进行基线管理。

初次建立的配置项，或经过修改的配置项，必须经过SCCB批准之后由项目经理提交SCME 入库。

项目组提交的配置项需在邮件中说明是否已经过验证。

5.2 基线库的取用

项目组在构造和配送产品时，必须取用软件基线库中的配置项来完成。

只有SCME拥有基线库的管理权限，其他人员只能读取基线库中的内容。

5.3 基线变更

5.3.1 申请

1.发送邮件主题为：XXX项目组XXX基线变更申请yyyymmdd_姓全拼名缩写(大写)，其

中，yyyymmdd为发送日，如PICCALLB工具基线变更申请20050617_ZHANGL；附件文件名同邮件主题名。

2.为便于QA跟踪基线申请的处理情况，请将申请邮件同时抄送给QA。

3.模板统一采用问题跟踪模板，有不需要列时，隐藏，而不要删除，以便后续合并处

理。

4.在附件中，申请者需明确每一变更的计划解决日期。

5.3.2 处理

1.申请者在开发库中进行变更。

2.申请者将变更申请内容粘贴到开发库根目录下的《xxx受控文件汇总清单》中，并

指明复核人，mail告知PM让其审核。

3.PM在接到申请，审核通过后，补充填写记录状态，并告知申请者。

4.申请者在备注字段内标示“已合并”。

5.3.3 合并基线

1.为了保证最终的产品发布进度不受影响，必须在发布提出的“最晚合并完基线变更

内容的日期”前，把与自己相关的基线变更申请合并完成。

2.最终合并时，项目组SCME负责在开发库中打label，

3.项目组SCME基线库中建立版本子目录，并将label对应内容合并到此目录中。

bel之后又发生变更的文件，原则上将体现在下次发布合并中。

5.为了检查基线库内容的正确性，每次在合并完成后，由项目组QA负责检查：基线库

中此版本所包含的变更文件，是否和《受控文件汇总清单》中的所列文件一致。

5.3.4 问题记录

1.对于审核过程中发现的问题，由SCME负责记录统计，并每月向PM、QA发布统计结

果。