配置管理规范.docx

配置管理规范.docx

《配置管理规范.docx》由会员分享，可在线阅读，更多相关《配置管理规范.docx（12页珍藏版）》请在冰点文库上搜索。

配置管理规范

UNISP_CM

配置管理

文档信息

文档编号：

UNISP_CM

文档名称：

配置管理

文档类别：

支持管理文档

文件密级：

机密

版本信息：

版本号

日期

作者或变更者

审核者

说明

V1.0

2010-4-15

EPG

EPGLeader

新建

V1.1

2010-11-11

EPG

EPGLeader

增加版本命名规范

V1.2

2010-12-9

EPG

EPGLeader

增加版本修订记录

目录

UNISP_CM0

配置管理0

文档信息1

1介绍（Introduction）4

1.1目的（Purpose）4

1.2过程总体概述（ProcessOverview）4

1.3相关过程（RelationalProcess）5

2过程活动描述（ProcessActivityDescription）5

2.1制定配置管理计划5

2.1.1目的（Purpose）5

2.1.2角色和职责（RolesandResponsibility）5

2.1.3启动准则（EntryCriteria）5

2.1.4输入（Inputs）5

2.1.5任务描述（TaskDescription）5

2.1.6输出（Outputs）7

2.1.7结束准则（ExitCriteria）7

2.1.8度量（Measure）7

2.2配置库管理7

2.2.1目的（Purpose）7

2.2.2角色和职责（RolesandResponsibility）7

2.2.3启动准则（EntryCriteria）7

2.2.4输入（Inputs）7

2.2.5任务描述（TaskDescription）7

2.2.6输出（Outputs）8

2.2.7结束准则（ExitCriteria）8

2.2.8度量（Measure）8

2.3配置项变更管理8

2.3.1目的（Purpose）8

2.3.2角色和职责（RolesandResponsibility）9

2.3.3启动准则（EntryCriteria）9

2.3.4输入（Inputs）9

2.3.5任务描述（TaskDescription）9

2.3.6输出（Outputs）10

2.3.7结束准则（ExitCriteria）10

2.3.8度量（Measure）10

2.4配置审计10

2.4.1目的（Purpose）10

2.4.2角色和职责（RolesandResponsibility）10

2.4.3启动准则（EntryCriteria）10

2.4.4输入（Inputs）10

2.4.5任务描述（TaskDescription）10

2.4.6输出（Outputs）11

2.4.7结束准则（ExitCriteria）11

2.4.8度量（Measure）11

3工作产品一览（WorkProductsList）11

4附录11

1介绍（Introduction）

1.1目的（Purpose）

配置管理（ConfigurationManagement,CM）的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。

配置管理是对工作成果的一种有效保护。

配置管理过程域的三个主要活动：

✧制定配置管理计划

✧配置库管理

✧配置项变更管理

1.2过程总体概述（ProcessOverview）

项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被保存起来，以便查阅和修改。

如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。

毫无疑问，人们应当将文件分门别类、有条理地保存起来。

凡是纳入配置管理范畴的工作成果统称为配置项（ConfigurationItem,CI），配置项主要有两大类：

（1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。

（2）项目管理和机构支撑过程域产生的文档。

这些文档虽然不是产品的组成部分，但是值得保存。

每个配置项的主要属性有：

名称、标识符、文件状态、版本、作者、日期等。

所有配置项都被保存在配置库里，确保不会混淆、丢失。

配置项及其历史记录反映了软件的演化过程。

基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。

基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。

基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。

基线的主要属性有：

名称、标识符、版本、日期等。

通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。

所有的项目成员都要使用配置管理软件来保护自己的工作成果。

机构应当采用统一的配置管理软件，常见的配置管理软件有Microsoft的VisualSourceSafe和Rational的ClearCase等。

为了提高配置管理的效率和安全性，机构应当有专门的配置管理员（角色）。

配置管理员为每个项目制定《配置管理计划》，创建和维护配置库。

鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（ConfigurationControlBoard,CCB）。

CCB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。

对于配置管理而言，CCB是决策者，而配置管理员是执行者。

如果机构的各个项目紧密相关（例如一个产品线下的多个项目），建议机构设立公共的CCB，这个公共的CCB对所有项目的配置管理拥有决策权。

如果机构的各个项目相对独立，那么每个项目可以设立各自的CCB。

CCB的决策采用“少数服从多数”原则。

1.3相关过程（RelationalProcess）

2过程活动描述（ProcessActivityDescription）

2.1制定配置管理计划

2.1.1目的（Purpose）

制定配置管理计划，以便有计划地开展配置管理工作。

2.1.2角色和职责（RolesandResponsibility）

角色

职责

CMO

制定《配置管理计划》

CCB

审批《配置管理计划》

CCB的组成为部门经理和项目经理。

2.1.3启动准则（EntryCriteria）

《项目集成计划》已经制定。

人员角色已经确定。

2.1.4输入（Inputs）

《项目集成计划》

2.1.5任务描述（TaskDescription）

2.1.5.1确定配置管理的软硬件资源

确定配置管理工具和用于存放配置库的服务器。

2.1.5.2制定配置项计划

考虑需要进行配置的配置项。

分别确定类型、配置项、标识符和预计正式发布时间。

识别配置项：

●识别配置项通常是在WBS完成后才进行的，按WBS结果识别需纳入配置管理的工作产品，即配置项。

●配置项的最小集合是：

客户需求、测试计划和测试用例、软件需求、设计文档、源代码

●识别配置项后，将识别出的每种不同的配置项进行标识。

●标识时使用统一的命名规则。

2.1.5.3制定基线计划

确定基线发布计划。

分别确定基线、每个基线包含的配置项和预计发布时间。

识别基线：

●根据标识的工作产品，进一步确定哪些列为基线

●确定基线的不同变更控制权限

●确定基线纳人配置管理库的时机

●一般的，这些基线内容及建立时机、变更控制权限如下：

I.需求基线：

①客户需求批准时建立；②软件需求批准时更新；③由配置控制委员会控制

II.设计基线：

①概要设计和详细设计批准时建立；②由项目经理控制；

III.代码基线：

①最初的建立是在对原始软件单元编码、检查和单元测试时；②由项目经理控制

IV.测试基线：

①为测试而发布软件时建立；②由测试经理控制

V.产品发布基线：

①为运行而发布系统时建立；②由配置控制委员会控制

2.1.5.4制定配置库备份计划

制定配置库备份计划。

2.1.5.5审批《配置管理计划》

CCB审批《配置管理计划》，填写《配置管理计划评审报告》。

2.1.6输出（Outputs）

《配置管理计划》《配置管理计划评审报告》

2.1.7结束准则（ExitCriteria）

《配置管理计划》已经制定并评审通过，产生《配置管理计划评审报告》。

2.1.8度量（Measure）

统计《配置管理计划》工作量以及《配置管理计划》文档的规模，汇报给项目经理。

2.2配置库管理

2.2.1目的（Purpose）

所有人员依照配置管理规范和《配置管理计划》操作配置库。

2.2.2角色和职责（RolesandResponsibility）

角色

职责

CMO

创建并维护配置库

Developer

项目成员在权限之内操作配置库

2.2.3启动准则（EntryCriteria）

《配置管理计划》已经制定。

配置管理的软件硬件已经存在。

2.2.4输入（Inputs）

《配置管理计划》《配置管理计划评审报告》

2.2.5任务描述（TaskDescription）

2.2.5.1创建配置库

配置管理员创建配置库，并根据《公司标准配置库目录》初始化配置库目录。

2.2.5.2分配权限

配置管理员根据项目组成员创建配置库用户，并赋予权限。

初始的权限为Read、Checkin\Checkout、ADD\Rename\Delete、Destroy。

2.2.5.3基于配置库工作

项目成员在权限许可的范围内，严格按照checkout\checkin进行工作。

配置管理员根据“基线计划”创建与维护基线，“冻结”配置项，记录《配置管理跟踪表》。

2.2.5.4配置库维护

配置管理员定期清除配置库里的垃圾文件。

配置管理员检查配置库备份是否正常。

配置管理员在项目里程碑结束时，形成《配置库管理报告》。

2.2.5.5配置库带出管理

配置库需要带出到客户现场，由配置管理员拷贝配置库给维护人员，并把配置库进行锁定。

维护人员回来时，把配置库交还给配置管理员，由配置管理员替换配置库，并重新开放访问权限。

2.2.6输出（Outputs）

《配置管理跟踪表》《配置库管理报告》

2.2.7结束准则（ExitCriteria）

配置库管理将持续到项目结束。

2.2.8度量（Measure）

配置管理员统计工作量以及《配置管理跟踪表》《配置库管理报告》文档规模。

2.3配置项变更管理

2.3.1目的（Purpose）

对纳入基线的配置项进行变更管理，防止配置项被随意修改而导致混乱，确保配置的完整性。

2.3.2角色和职责（RolesandResponsibility）

角色

职责

CCB

审批配置变更申请

CMO

进行配置变更管理

2.3.3启动准则（EntryCriteria）

基线已经建立。

变更申请被审批通过。

2.3.4输入（Inputs）

待变更的配置项

2.3.5任务描述（TaskDescription）

2.3.5.1变更申请

变更申请人提出变更申请，重点说明“变更原因”和“变更内容”。

2.3.5.2审批变更申请

CCB评审申请，分析此次变更对其他相关造成的影响。

如果同意变更，则安排进行变更。

否则，结束本次变更。

2.3.5.3安排变更

CCB安排变更执行人员，下达变更任务。

2.3.5.4执行变更任务

变更执行人根据CCB安排的任务，修改配置项。

CCB需要对变更进行监控，保证变更按时完成。

2.3.5.5确认变更

CCB对变更后的配置项进行审核，若审核通过，则发布新的基线。

若审批不通过，则退回重新执行变更。

2.3.6输出（Outputs）

《配置管理跟踪表》

2.3.7结束准则（ExitCriteria）

完成变更。

2.3.8度量（Measure）

配置管理员统计工作量以及《配置管理跟踪表》文档规模。

2.4配置审计

2.4.1目的（Purpose）

对配置进行审计，包括物理审计和功能审计，确保配置的正确性和一致性。

2.4.2角色和职责（RolesandResponsibility）

角色

职责

PM

进行功能审计

CMO

进行物理审计

2.4.3启动准则（EntryCriteria）

基线已经建立。

2.4.4输入（Inputs）

基线

2.4.5任务描述（TaskDescription）

2.4.5.1审计准备

1.审计工作的准备由SCM组来完成。

2.认可的变更权威确认审计组成员：

通常SCM经理和SCM人员负责产品审计。

项目经理、技术权威、测试负责人负责功能审计。

3.SQA人员负责对审计过程进行监督。

4.确认审计日程安排。

5.为审计准备材料：

《基线发布报告》、问题及变更日志、基线内容清单、配置状态报告

2.4.5.2配置审计

6.审计按照SCMP中的审计时间表进行

7.SCM根据《基线审计报告》所列内容进行产品审计

8.评估软件基线的完整性和正确性

9.审计各个配置库分区，确保配置标识的完整和正确

10.根据《配置管理计划》中的内容对配置计划的实施进行审计

11.PM和SCM在跨区移动或归并后要检查配置项或基线的正确性

2.4.5.3审计报告

编写审计报告

2.4.5.4跟踪审计问题解决

对审计发现的问题及时跟踪解决。

2.4.6输出（Outputs）

《配置审计报告》

2.4.7结束准则（ExitCriteria）

审计完成。

2.4.8度量（Measure）

配置管理员统计工作量以及《配置审计报告》文档规模。

3工作产品一览（WorkProductsList）

《产品审计报告》

4附录

《版本号命名规范》

《公司标准配置库目录》