clearcaselt配置

bmccbj

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

bmccbj

62
阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人
员开放只读权限。该分支的管理工作由系统集成员负责。
上面定义的3 类工作空间（分支）由配置管理员统一管理，根据各
开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常
运作。在变更发生时，应及时做好基线的推进。
3．变更控制
对于大型的软件开发项目，无控制的变更将迅速导致混乱，变更控
制就是通过结合人的规程和自动化工具，以提供一个变化控制的的机
制。本文所涉及的变更控制的对象主要指配置库中的各基线配置项。变
更管理的一般流程是：
A) 由开发人员或系统集成员提出变更需求；
B) 由SCCB（软件变更控制委员会）审核并决定是否批准；
C) 配置管理员根据SCCB 的决定临时开放相应的权限，并备案；
D) 系统集成员执行相应的变更。
在这里，将要涉及的变更控制分为两类：一类是基线的变更控制，
另一类是软件版本的变更控制。 l 基线的变更控制
基线的变更是指在一个软件版本的开发周期内对基线配置项的变
更，主要包括基线的应用和更新等活动。

bmccbj

63
基线变更所涉及的操作主要包括基线标签的定义和标签的使用。基
线标签属于严格受控的配置项，它的命名必须严格按照相关的命名规范
来进行。基线在建立时，按照角色职责的分工，须经SCCB同意并以正
式的将该基线的标识和作用范围通知系统集成员，由后者负责执行；基
线一旦划定，由该基线控制的各配置项的历史版本均处于锁定或严格受
控状态，任何对基线位置的变更请求都必须按变更控制流程，提交SCCB
批准，然后由系统集成员执行。
l 软件版本的变更
软件版本的命名规范应事先制定，并按照开发计划予以发布使用。
在软件版本的演进过程中既需要从以前的版本中继承，又需要相对的独
立性。所以在对于一个子版本（例如某特定用户的定制版本）就需要对
一系列配置项从统一的开发起始基线所确定的版本上建立新的分支，然
后在此分支上开发新的版本。因此在这样的变更控制流程中，受控的对
象还应包括特定的分支类型，以及工作视图的选取规则，同时配置管理
员将在这一过程中担负更多的操作职责

bmccbj

64
第三章 基于CMM 的SCM
CMM（软件能力成熟度模型）与SCM（软件配置管理）
在COCOMO 模型中，对一个项目团队的软件开发能力作了如下定义：
软件项目的开发能力= （团队技能）（工具）（规模）（过程）
其中：
团队技能：开发团队的技能、经验，以及精神
工具：开发团队使用各种工具的自动化程度
规模：开发团队的人员规模，以及人为因素造成的复杂程度
过程：团队软件开发的方法、标记及成熟度
基于此模型，我们可以看出要提高团队的开发能力，可以从以下四
个方面入手：
降低问题的复杂性，减少开发团队规模:
尽可能多采用第三方现成的组件，多采用软件复用规范标记法，
基于模型的工件， 或由工具直接产生工件
改进过程的效率和成熟度:
吸纳新技术、新工具、新经验
提高团队技能的技术熟练程度:
培训、指导、顾问咨询
扩展工具的自动化程度:
双向工程分析、评估自动化
在这四个方面中，软件开发过程的改进最为重要，目前国际上有多
种改善或评估软件开发过程的方法和工具，其中以卡耐基梅隆大学的软

bmccbj

65
件工程研究所（SEI）提出的软件能力成熟度模型（Capability Maturity
Model, CMM）最具影响力。CMM 将软件过程成熟度划分为5 个级别，从
一级到五级分别为：混乱级、可重复级、定义级、管理级和优化级。CMM
级别越高，就表示软件开发过程越规范。每个成熟级别由一系列关键流
程领域（Key Process Areas，KPA）组成，每个KPA 确定一组相关活动。
当这些相关活动一起开展时，它们完成一系列被认为对在该成熟级别建
立流程能力有重要影响的目标。
在CMM 二级中，有以下六个KPA：需求管理、软件项目规划、软
件项目跟踪与勘察、软件分包管理、软件质量保证、软件配置管理。其
中最后一个KPA 软件配置管理的目的就是在项目的整个软件生命周期
内建立并维护软件项目产品的完整性，更好地管理开发。实际上，软件
配置管理是大多数软件工程和管理流程的一个重要构成部分。
针对配置管理，在CMM 中仅仅定义了一系列的流程，而没有对实施
方法提出任何要求。因此，如果要达到CMM2 的要求，我们需要自己建
立配置管理流程，并选用相关的工具，来贯彻流程的实施。
基于CMM/CMMI的配置管理
本节主要从CMM 和CMMI 的要求出发，介绍了标准主要涉及的配
置管理内容，并对相应内容进行初步地说明，最后提供了一个配置管理
在项目实施的指南和一个在组织中部署配置管理的模型。
1 配置管理内容的逻辑关系
在CMM 和CMMI 中，将配置管理的目的定义为“建立和维护产品
的完整性”，这个目标没有提到对项目管理的支持，也就是说，它定义

bmccbj

66
的配置管理的目标比当前业界对配置管理的认识有些缩小。但是，仔细
分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。
下面就从这个目标出发进行分析。逻辑关系见下图：
配置完整性（对标准的理解）
1. 产品完整性：就是项目提交的工作成果是“产品集合完整、子产品的
正确”的
2. 产品集合完整：产品包含的子产品（配置项）是完整的
3. 子产品的正确：子产品（配置项）达到了需求要求，满足标准、规
程的要求
逻辑关系分析
1. “基线管理”支持“产品集合完整”，明确产品的“子产品”（配置项）集
合，并进行管理和控制
2. “配置项管理”，提供了了对子产品（配置项）的控制管理，支持“子

bmccbj

67
产品的正确”
3. “变更管理”，同时支持“产品集合完整、子产品的正确”，用于控制子
产品（配置项）和产品（基线）的变更
4. “配置标示”，建立对配置项（子产品）的识别、命名，支持“配置项
管理”
5. “版本控制”，控制配置项（子产品）生命历程，保留配置项（子产品）
演进历史
6. “过程管理”，就是对配置项、基线的建立、变更的状态标示、过程控
制，保证产品（或子产品）按照规定的流程进行了操作；例如“配置项”
进入“基线”的过程包括：配置项标示、产品验证、进入配置、配置审计
等
7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置
管理得支持系统。提供了配置管理“可视性”和监督管理
2 配置和配置项
在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术
文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包
括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更文
档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，
相对与硬件类配置，软件产品的“配置”包括更多的内容并具有易变性。
受控软件经常被划分为各类配置项（Configuraion items, CIs），这类划
分是进行软件配置管理的基础和前提，CIs 是逻辑上组成软件系统的各
组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相
关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs 的数目是

bmccbj

68
一个与设计密切相关的问题。一个纯软件的CI 通常也称之为软件配置
项（CSCI）。
现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in
和Check out 机制的 )版本管理和版本标号功能。由于版本和标号管理比
较繁琐，一般推荐使用配置管理工具，减少事务性工作。
3 基线
在配置管理系统中，基线就是一个CI 或一组CIs 在其生命周期的不同
时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为
“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定
了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线
一般在指定的里程碑处创建，并与项目中的里程碑保持同步
一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基
线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的
出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进
行功能评审的基础。
每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更
控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增
加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。
基线具有以下属性：
通过正式的评审过程建立
基线存在于基线库中，对基线的变更接受更高权限的控制
基线是进一步开发和修改的基准和出发点
进入基线前，不对变化进行管理或者较少管理

bmccbj

69
进入基线后，对变化进行有效管理，而且这个基线作为后继续工作的基
础
不会变化的东西不要纳入基线
变化对其他没有影响的可以不纳入基线
建立基线的好处：
重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项
目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信
时，基线为团队提供一种取消变更的方法。
可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要
求、代码实施设计以及用正确代码编译可执行文件。
版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线
提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目
（在主要分支上）所进行的变更进行隔离。
4 基线、配置、配置项的关系
基线的组成，以及配置项和配置的关系如下图：

bmccbj

70
基线管理的步骤：
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、基线的各类报告和审计信息
针对某个具体得项目，可以根据基线的内容，建立一个基线信息