|
|
|
配置控制即配置项和基线的变更控制，配置控制包括如下活动：
|
|
|
|
.变更申请：相关人员如项目经理填写变更申请表，说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，并提交给CCB。
|
|
|
|
.变更评估：CCB对变更申请进行评估并确定变更对项目的影响、变更的内容是否必要、变更的范围是否考虑周全、变更的实施方案是否可行、变更工作量估计是否合理。CCB对变更申请作出决定。
|
|
|
|
.通告评估结果：CCB把关于变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。
|
|
|
|
.变更实施：项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息。
|
|
|
|
.变更验证与确认：项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交CCB，由其确认变更是否已经按要求完成。
|
|
|
|
.变更的发布：配置管理员将变更后的配置项纳入基线并将变更内容和结果通知相关人员，并做好记录。
|
|
|
|
为了解决一个文档的变更引起多个相关文档的变更时文档修改不全面，以及多个开发人员对同一部件进行修改引起版本混乱等问题，可以基于配置库进行变更控制。
|
|
|
|
|
|
|
|
|
|
下面以某软件产品的升级为例，说明基于配置库变更的流程：
|
|
|
|
（1）将待升级的基线（假设版本号为V1.0）从产品库中复制到受控库。
|
|
|
|
（2）程序员甲将欲修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。代码被检出后即被“锁定”，其他程序员无法检出，以保证同一段代码只能同时被一个程序员修改。
|
|
|
|
（3）程序员甲将开发库中修改好的代码段检入（Check in）受控库。检入后，代码的“锁定”被解除，其他程序员可以检出该段代码了。
|
|
|
|
（4）软件产品的升级修改工作全部完成后，将受控库中的新基线更新到产品库中（软件产品的版本号更新为V1.1，旧的V1.0版并不删除，继续在产品库中保存）。
|
|
|
