|
|
|
配置管理包括六项主要活动，分别为：制定配置管理计划，配置标识，配置控制，配置状态报告，配置审计，发布管理和交付。
|
|
|
|
|
|
配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。
|
|
|
|
|
|
.配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。
|
|
|
|
|
|
|
|
.负责实施这些活动的人员或组织，以及他们和其他组织的关系。
|
|
|
|
|
|
配置标识也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置控制即配置项和基线的变更控制，配置控制包括如下活动：
|
|
|
|
.变更申请：相关人员如项目经理填写变更申请表，说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，并提交给CCB。
|
|
|
|
.变更评估：CCB对变更申请进行评估并确定变更对项目的影响、变更的内容是否必要、变更的范围是否考虑周全、变更的实施方案是否可行、变更工作量估计是否合理。CCB对变更申请作出决定。
|
|
|
|
.通告评估结果：CCB把关于变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。
|
|
|
|
.变更实施：项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息。
|
|
|
|
.变更验证与确认：项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交CCB，由其确认变更是否已经按要求完成。
|
|
|
|
.变更的发布：配置管理员将变更后的配置项纳入基线并将变更内容和结果通知相关人员，并做好记录。
|
|
|
|
为了解决一个文档的变更引起多个相关文档的变更时文档修改不全面，以及多个开发人员对同一部件进行修改引起版本混乱等问题，可以基于配置库进行变更控制。
|
|
|
|
|
|
|
|
|
|
下面以某软件产品的升级为例，说明基于配置库变更的流程：
|
|
|
|
（1）将待升级的基线（假设版本号为V1.0）从产品库中复制到受控库。
|
|
|
|
（2）程序员甲将欲修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。代码被检出后即被“锁定”，其他程序员无法检出，以保证同一段代码只能同时被一个程序员修改。
|
|
|
|
（3）程序员甲将开发库中修改好的代码段检入（Check in）受控库。检入后，代码的“锁定”被解除，其他程序员可以检出该段代码了。
|
|
|
|
（4）软件产品的升级修改工作全部完成后，将受控库中的新基线更新到产品库中（软件产品的版本号更新为V1.1，旧的V1.0版并不删除，继续在产品库中保存）。
|
|
|
|
|
|
配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
|
|
|
|
|
|
|
|
|
|
.每个基线的当前和过去版本的状态以及各版本的比较。
|
|
|
|
|
|
配置状态报告应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。配置状态报告应定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况。
|
|
|
|
配置状态报告还可供项目经理和CCB追踪变更的情况，通过配置状态报告可以了解如下内容：变更请求的批准情况、已批准的变更请求的当前状态、已完成的变更投入时间和工作量、某个配置项与哪几个变更请求有关等。
|
|
|
|
|
|
配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求——不允许出现任何混乱现象。
|
|
|
|
|
|
.功能配置审计：审计配置项的一致性（配置项的实际功效是否与其需求一致），具体需要验证配置项的开发已圆满完成、配置项已达到配置标识中规定的性能和功能特征、配置项的操作和支持文档已完成并且是符合要求的。
|
|
|
|
.物理配置审计：审计配置项的完整性（配置项的物理存在是否与预期一致），具体需要验证要交付的配置项是否存在以及配置项中是否包含了所有必需的项目。
|
|
|
|
|
|
发布管理和交付活动的主要任务是有效控制软件产品和文档的发行和交付，在软件产品的生存期内妥善保存代码和文档的母拷贝。
|
|
|
|
|
|
.存储：可通过一些方式确保存储的配置项的完整性，如选择存储介质使再生差错或损坏降至最低限度、根据媒体的存储期以一定频次运行或刷新已存档的配置项、将副本存储在不同的受控场所以减少丢失的风险等。
|
|
|
|
.复制：复制是用拷贝方式制造软件的阶段，应建立规程以确保复制的一致性和完整性，应确保发布用的介质不含无关项（如软件病毒或不适合演示的测试数据），应使用适合的介质以确保软件产品符合复制要求，确保其在整个交付期中内容的完整性。
|
|
|
|
.打包：应确保按批准的规程制备交付的介质，应在需方容易辨认的地方清楚地标出发布标识。
|
|
|
|
|
|
.重建：应能重建软件环境，以确保发布的配置项在所保留的先前版本要求的未来一段时间里是可重新配置的。
|
|
|
