基于CMM和CMMI的配置管理(1)

　本文主要从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、在开发前确定基线的“配置”
  2、基线批准前，根据“配置”检查配置项是否齐备
  3、对各个配置项，确认其版本的正确性
  4、对每个配置项建立基线标志，
  例如上图为：测试基线=（配置项A=1，配置项B=1，配置项C=1）
  alpha版=（配置项A=2，配置项B=1，配置项C=1）
  beta版=（配置项A=3，配置项B=3，配置项C=2）
  产品基线=（配置项A=4，配置项B=4，配置项C=4）
  5、基线变更管理
  6、基线的各类报告和审计信息

  针对某个具体得项目，可以根据基线的内容，建立一个基线信息的跟踪表，例如如下：

  [注]：被色块覆盖的表示，此配置项属于对应列的基线
  [注]：在色块的栏目填写对应配置项的版本号

 5 变更管理
  在有效标示了配置并进行了管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就要依赖有下的变更管理。

• 缺乏有效的变更请求管理会导致的问题：
  软件产品质量低下，对一些缺陷的修正被遗漏
  项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力
  开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况
  可能错误使用和引用已经变更的产品，引起开发工作混乱
• 变更管理的流程：
  （获得）提出变更请求；
  由CCB审核并决定是否批准；
  为（被接受）修改请求分配人员，提取SCI，进行修改；
  提交修改后的SCI，并测试（或者评审）；
  重建软件的适当版本；
  复审（审计）所有SCI的变化；
  发布新版本。
  

  为了更好的指导变更范围的影响分析，可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》，分别如下：

  6 配置库管理
 在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，必须规划好工作空间的管理。主要的手段是设置配置库（即文件夹设置），和设置版本的分支，来实现对配置项权限管理。

• 设置版本分支
    基本上要为每个配置项从建立开始就划分成3个不同的分支：私有分支、集成分支、公共（主干）分支。让它们分别对应3类工作空间。
  • 私有分支：
    私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。
  • 集成分支：
    集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。
  • 公共（主干）分支：
    公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。

  上面定义的3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

•   配置库的设置
    决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。
    按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
   而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。
•   配置库的日常工作
   配置库的日常工作是一些事务性的工作，主要保证配置库的安全性，包括：
    对配置库的定期备份
    清除无用的文件和版本
    检测并改进配置库的性能等 

  7 配置报告
 配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。
  配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。为了说明项目状态对变更的情况也应当进行报告。有时，对配置库的情况也进行说明，例如备份次数，磁盘占用空间等等。只要是关心的信息，均可作为状态报告的内容。这些信息进行有效记录，往往可以作为项目度量的重要数据来源。

  8 配置审计

 配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。 审计机制保证修改的动作被完整地记录，也就是说，记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、 What）。 同时配置审计工作应当可以说明如下信息。

• 配置审计应当说明的信息：
  1. 变更要求被完成，并且对附加的修改已经执行了
  2. 采用了正确的正式验证手段
  3. 遵循了标准的要求
  4. 变更的4W信息被完整记录，并和相关配置项关联