基于CMM和CMMI的配置管理一.docVIP

基于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在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步 一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。 　　每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。 　　基线具有以下属性： 　　通过正式的评审过程建立 　　基线存在于基线库中，对基线的变更接受更高权限的控制 　　基线是进一步开发和修改的基准和出发点 　　进入基线前，不对变化进行管理或者较少管理 　　进入基线后，对变化进行有效管理，而且这个基线作为后继续工作的基础 　　不会变化的东西不要纳入基线 　　变化对其他没有影响的可以不纳入基线 　　建立基线的好处： 　　重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。 　　可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。 　　版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。 　　4 基线、配置、配置项的关系 　　基线的组成，以及配置项和配置的关系如下图： 　　基线管理的步骤： 　　1、在开发前确定基线的“配置”