UML软件工程组织 |
基于CMM和CMMI的配置管理(一) |
51CMM.COM原创 作者:河清 |
本文主要从CMM和CMMI的要求出发,介绍了标准主要涉及的配置管理内容,并对相应内容进行初步地说明,最后提供了一个配置管理在项目实施的指南和一个在组织中部署配置管理的模型。 1 配置管理内容的逻辑关系 在CMM和CMMI中,将配置管理的目的定义为“建立和维护产品的完整性”,这个目标没有提到对项目管理的支持,也就是说,它定义的配置管理的目标比当前业界对配置管理的认识有些缩小。但是,仔细分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。下面就从这个目标出发进行分析。逻辑关系见下图: 配置完整性(对标准的理解) 1. 产品完整性:就是项目提交的工作成果是“产品集合完整、子产品的正确”的 2. 产品集合完整:产品包含的子产品(配置项)是完整的 3. 子产品的正确:子产品(配置项)达到了需求要求,满足标准、规程的要求 逻辑关系分析 1. “基线管理”支持“产品集合完整”,明确产品的“子产品”(配置项)集合,并进行管理和控制 2. “配置项管理”,提供了了对子产品(配置项)的控制管理,支持“子产品的正确” 3. “变更管理”,同时支持“产品集合完整、子产品的正确”,用于控制子产品(配置项)和产品(基线)的变更 4. “配置标示”,建立对配置项(子产品)的识别、命名,支持“配置项管理” 5. “版本控制”,控制配置项(子产品)生命历程,保留配置项(子产品)演进历史 6. “过程管理”,就是对配置项、基线的建立、变更的状态标示、过程控制,保证产品(或子产品)按照规定的流程进行了操作;例如“配置项”进入“基线”的过程包括:配置项标示、产品验证、进入配置、配置审计等 7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置管理得支持系统。提供了配置管理“可视性”和监督管理 2 配置和配置项 在配置管理中,“配置”和“配置项”是重要的概念,“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性,其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素,相对与硬件类配置,软件产品的“配置”包括更多的内容并具有易变性。 受控软件经常被划分为各类配置项(Configuraion items, CIs),这类划分是进行软件配置管理的基础和前提,CIs是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块,每个程序模块及其相关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项(CSCI)。 现在所有的配置管理工具均提供对配置项的管理工具,包括(Check in和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比较繁琐,一般推荐使用配置管理工具,减少事务性工作。 3 基线 在配置管理系统中,基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素(配置项)的一个版本,且只确定一个版本。一般情况下,基线一般在指定的里程碑处创建,并与项目中的里程碑保持同步 一般地,第一个基线包含了通过评审的软件需求,因此称之为“需求基线”,通过建立这样一个基线,受控的系统需求成为进一步软件开发的出发点,对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。 每个基线都将接受配置管理的严格控制,对其的修改将严格按照变更控制要求的过程进行,在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线,这就是“基线管理”的过程。
基线的组成,以及配置项和配置的关系如下图:
[注]:被色块覆盖的表示,此配置项属于对应列的基线 [注]:在色块的栏目填写对应配置项的版本号 |
版权所有:UML软件工程组织 |