配置项管理规范.doc

UF/QP/3-01/QI/002
配置项管理规范

一、 配置项管理要求

在产品/项目的整个生存周期中，由SCM人员使用配置管理库系统对配置管理计划中确立的配置项进行统一的管理，控制它们的变更、存取和投放，记录并报告它们的状态和变更;SCM组和SQA需分别定期对有关SCM的活动和工作产品进行审计。各产品开发经理定期且事件驱动地参加SCM活动的评审。研发中心主管经理定期参加SCM活动的评审。

二、 配置项变更管理规范

1.非基线化配置项变更管理规范
非基线化配置项由相应SCM人员存放在软件配置数据库中。SCM人员根据各产品/项目组的《配置管理计划》，来确立各个工程师提交配置项的权限。
在非基线化配置项变成基线前，它(们)的变更可以迅速而非正式地进行。

1.1在配置项通过评审、审核和确认前，各配置项的负责人可根据配置项计划提交时间以及自身需要，事件驱动地向SCM人员提交经过合适修改的配置项，并由SCM 人员标识后放置到软件配置数据库。
1.2当配置项通过相应评审、审核和确认后，在其待基线化的过程中，如需发生必要的变化，则需对变更的内容进行再次评审、审核和确认。在再次评审前，需提交配置项变更记录（UF/QP/3－01/QR/006）。
1.3 一旦配置项已经经过正式的技术评审且已被认可，并得到SCCB基线控制委员会的批准，则此配置项将被基线化，并转入到相应软件基线库中。

2.基线化配置项变更管理规范
基线是软件开发过程中的里程碑。当配置项被基线化后，它(们)的变更需通过正式的变更控制过程，以确保其它基线未受到此变更的影响或完成相应的适当变更。

2.1基线的建立
由软件配置控制委员会批准软件基线库的建立，且只有被软件配置控制委员会批准的配置项才能进入软件基线库。
2.2基线变更控制
2.2.1变更控制的目的
变更控制的目的是不允许跨越里程碑去任意修改前一（或几）阶段的软件工作产品，以保证变更不会对基线造成不可预料的影响。
2.2.2变更控制过程
基线库中的某个配置项被提出需要修改时，需遵循以下变更控制过程：

提交变更请求表CRF、产品/项目经理确认
变更申请人组织变更请求评审
变更请求评审决定
生成工程变化命令
实施变更
记录变更
将变更项提交评审和/或回归测试
评审和/或回归测试
创建并发布新版本
拒绝变更请求
通过
通过
不通过
不通过

2.2.2.1由变更申请人填写并提交变更请求表（CRF），并经由相关产品经理确认。
2.2.2.2 变更申请人将经确认的变更请求表提交相关SCM人员。SCM人员则组织由相关部门、小组组成的软件配置控制委员会（SCCB基线控制委员会）对变更请求进行评审。评审通过后，生成工程变更命令，并由相关小组签字，以再次确认变更已通知到各相关小组（保证受变更影响的配置项能得到及时的相应变更），方可实施变更。
2.2.2.3实施变更时，变更实施人及受变更影响的其他配置项的负责人将要变更的配置项从软件基线库中检出到自己的工作区并通知SCM人员；在实施变更的同时在《配置项变更记录表》（UF/QP/3－01/QR/006）中记录变更。SCM人员则立即封锁并特殊标识软件基线库中的相关对象，以保证当前检出的版本在没有被置换前不能再更新它；同时建立变更记录。
2.2.2.4 变更申请人组织软件配置控制委员会对变更后的所有配置项进行评审和/或回归测试，直到评审和/或回归测试通过为止，以确保变更没有对基线造成意外的影响。
2.2.2.5 SCM人员对经修改并得到认可的配置项重新标识新版本号后，经由SCCB基线控制委员会的批准，解除对基线库中原版本封锁，将新版本置于软件基线库中；同时记录变更。

3.特殊基线化配置项变更管理规范

3.1特殊变更处理对象
为改正小错误而需要进行变更的基线化配置项。
配置项已经基线化，而变更是必须的，但这些变更不会给其他配置项带来影响。例如，以此配置项为输入点的下一阶段工作还未开始；改正错别字等等情况。

3.2特殊变更处理方式
变更申请人填写变更请求表（CRF），并说明申请特殊处理的理由。由SCCB基线控制委员会考核此变更是否会给别的配置项带来影响。如SCCB基线控制委员会同意变更申请人的特殊处理申请，则SCCB基线控制委员会需给出相应的特殊处理流程，并由SCM人员协助执行此简化流程。

三、 配置审计

1.配置审计的目的
配置审计作为正式技术审计的补充，是用来保证整个软件生命周期中各项工作产品在技术上和管理上的完整性。

2.配置审计的内容
2.1SCM标准和规程的执行情况
审计SCM组、SCCB基线控制委员会和产品组对SCM标准和规程的执行情况。
2.2基线审计
（1）评估软件基线的完整性。
（2）评审配置管理库系统的结构和设施。
（3）验证软件基线库内容的完备性和正确性。
（4）验证与配置管理规范、配置项标识和版本控制规则的符合性：
a.验证在工程变更命令表中说明的变化是否已经完成；
b.验证是否任意加入附加的修改；
c.验证修改后的配置项中是否强调了变更；有没有单独指出变化的内容、日期、作者；
d.验证是否记录了变更并形成配置状态报告；
e.验证受影响的配置项是否被适当的修改。

3.配置审计的执行
SCM组内部定期对软件基线进行配置审计，并形成配置审计报告。
SQA定期对SCM的活动和工作产品进行审计，并形成配置审计报告，同时向相关产品经理、SCM人员提交此报告。
各产品开发经理定期且事件驱动地参加SCM活动的评审。研发中心主管经理定期参加SCM活动的评审。
SQA对配置审计发现的问题进行跟踪解决。

四、 配置状态报告规范

1.配置状态报告的意义
各产品部SCM角色详细记录的相应产品/项目配置状态报告，可以使相关部门和人员能够及时且清楚地了解软件配置的内容和状态（包括每一配置项的当前状态和历史情况）；这样，也保证了每一配置项都能恢复到以前的任意版本。

2.配置状态报告的内容

配置状态报告的信息流图：

配置确定
配置控制
配置审计
软件配置项及其标识
变更
缺陷
状态报告
配置
状态
报告
配置状态报告
联机数据库

由配置管理过程，可以得到以下配置状态报告内容：
（1）配置项标识和版本历史状况；
（2）软件基线状态；
（3）变更申请一览表和状态；
（4）工程变更命令一览表和状态；
（5）配置审计结果；
（6）缺陷报告一览表和状态(包含fixes）;
其中部分信息由SCM人员在配置状态报告联机数据库中填写，以便相关人员可以对它进行查询。
配置管理库中每次新增加一个软件配置项或更新一个已有软件配置项的标识，或者一项变更申请被相关任意评审通过，并给出了一个工程变更命令时，在配置状态报告中就要增加一条变更记录条目。一旦进行了配置审计，其结果也应该写入报告之中。
在配置状态报告中新登记的变更由SCM人员及时通知给相关人员。

五、产品/项目创建规范

1.SCM人员在发版时从软件基线库中收集、整理产品/项目发版所必备的配置项，以创建产品/项目。
2.SCM人员从软件基线库中创建产品/项目时，严格填写《产品创建记录》。
3.《产品创建记录》需经由相关产品经理确认。
4. SCCB基线控制委员会对SCM人员从软件基线库中创建的产品/项目进行最终的审定。