UML软件工程组织

 

 

配置管理的主要活动
 
2008-11-06 来源:网络
 
配置管理的主要活动有12个:
一、配置管理计划
二、配置标识
三、确定配置管理范围
四、确认和记录配置项属性
五、为配置项定义标识符
六、确定配置基准线
七、确定配置结构
八、确定配置项命名规则
九、配置项控制
十、配置状态报告
十一、配置审验
十二、CMDB备份,存档和保管

下面详述:

一、配置管理计划:

内容应包括:

1.配置管理的目标和范围
2.与特定的支持小组相关的政策,标准和程序
3.配置管理角色和责任安排
4.配置项命名规则
5.实施配置管理活动的日程安排和程序
6.与第三方(如变更管理,供应商等)的接口控制
7.配置管理系统的设计,包括CMDB,配置管理数据的存放地点,配置项运行的受控环境,与其他服务管理系统的联系和接口,构建和安装等支持工具
8.配置管理的内务工作,包括许可证控制,配置项的存档等
9.计划的配置基准线,重大发布,里程碑,以及针对以后每个期间的工作量计划和资源计划

二、配置标识:

确定CI的范围,属性,标识符,基准线,以及配置结构和命名规范。

三、确定配置管理范围:

包括用于构建、发布、验证、安装、分发、维护、恢复和移除CI的硬件和软件及相关文档(这句话感觉很费解,是否翻译得有问题?)。
我的理解是,配置管理的范围是:所有CI的管理。
这些CI包括被识别为CI的硬件,软件以及相关文档。
而对这些CI的管理则包括构建,发布,验证,安装,发布,维护,删除,恢复等操作。

四、确认和记录CI属性:

一般包括名称,编号,类别,版本号,责任人,来源,提供日期,许可证号,目前状态,父配置项关联,子配置项关联,事故号,问题号,变更请求号,变更号,备注等内容。

五、为配置项定义标识符:

对于硬件CI,可贴上或刻上物理标记或通过条形码。
对于软件CI可将软件拷贝进入DSL(最终软件库)时制作一个包含CI名称和版本号的标签。
对于文档CI,可以通过在文档命名中加入有效日期和更新日期加以标识。

六、确定配置基准线:

配置基准线(Configuration Baseline)是对某个特定时点上一组配置项的描述。
应包括的内容:
1.过去的、当前的和计划中的发布信息
2.过去的、当前的和计划中的变更信息
3.批准和实施变更时系统的状态和有关文档
4.实施发布时系统的状态和有文档
5.按标准规范配置的硬件和软件

七、确定配置结构:

确定IT基础架构的配置结构,由此识别和记录各CI关系。

八、确定CI命名规则:

配置管理应建立所有CI和控制形式(如RFCs)的命名规则。规则应考虑CI名称的延续性,易记性可扩展性。

九、配置项控制:

指在正式建立配置文档后对CI变更进行控制的各种活动,包括对变更的评价、协调、批准或否决等活动。
确保CMDB中只记录那些得到批准和可识别的CI,确保CI的增加,修改,替换,删除是根据适当的控制文档进行的。
具体的活动有:
1.注册新CI及其版本
2.更新CI
3.许可证管理
4.撤消或删除CI时将相关记录存档
5.保护各种CI的完整性
6.定期检查CI以确保CI是否实际存在及是否合规,并更新CMDB。

十、配置状态报告:

针对所有受控CI的当前版本和变更记录定期制作配置状态报告。
通过状态报告,配置管理人员就可以了解CI以前,当前及计划的状态,可以跟踪基准线和发布版本之间的变动情况。
内容:
1.基准线和发布标识符
2.为构建系统或应用所使用的软件的最新版本
3.对系统进行的变更次数
4.基准线和发布版本的数量
5.CI的使用和变动情况
6.对基准线和发布版本的比较结果

十一、配置审验:

配置管理人员对CI和CMDB进行审验,确保CMDB中的配置信息能真实反映IT基础架构中CI的存在和变更情况。
审验的时机:
1.实施新的CMDB后
2.对IT基础架构实施重大变更前后
3.在一项软件发布和安装被导入实际动作环境之前
4.灾难恢复后或事故恢复正常后
5.发现未经授权的CI后
6.任何其他必须的时候(等于没说)

提示:一些常规的配置审验操作可由审计软件完成。但审计软件即使发现不一致,也禁止自动更新CMDB,必须由有关小组调查后再更新。

十二、CMDB备份、存档和保管:

为了应付灾难的发生,建议将CMDB备份到一个较偏远的地方。
备份频率和保管政策需根据IT基础架构的规模和变动情况来确定。

问题:
配置基准线在技术上如何实现呢?《指南》中没有进一步阐述,但这才是很关键的地方。有待进一步的研究。 似乎和CC一类的版本管理工具实现原理类似? 不知道HP有没有这方面的实践?
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号