clearcaselt配置

bmccbj

71
的跟踪表，例如如下：
[注]：被色块覆盖的表示，此配置项属于对应列的基线
[注]：在色块的栏目填写对应配置项的版本号
5 变更管理
在有效标示了配置并进行了管理之后，如何保证它们在复杂多变
得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复
到任一历史状态就要依赖有下的变更管理。
缺乏有效的变更请求管理会导致的问题：
软件产品质量低下，对一些缺陷的修正被遗漏
项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的
能力
开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一

bmccbj

72
边、而工作在一般优先级任务上的情况
可能错误使用和引用已经变更的产品，引起开发工作混乱
变更管理的流程：
（获得）提出变更请求；
由CCB 审核并决定是否批准；
为（被接受）修改请求分配人员，提取SCI，进行修改；
提交修改后的SCI，并测试（或者评审）；
重建软件的适当版本；
复审（审计）所有SCI 的变化；
发布新版本。
为了更好的指导变更范围的影响分析，可以通过两种表格来帮助
发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依
赖关系表》，分别如下：

bmccbj

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

bmccbj

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

bmccbj

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

bmccbj

76
具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。
配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度
报告的参照。为了说明项目状态对变更的情况也应当进行报告。有时，
对配置库的情况也进行说明，例如备份次数，磁盘占用空间等等。只要
是关心的信息，均可作为状态报告的内容。这些信息进行有效记录，往
往可以作为项目度量的重要数据来源。
8 配置审计
配置审计的主要作用是作为变更控制的补充手段，来确保某一变
更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部
分，但当软件配置管理是一个正式的活动时，该活动由SQA 人员单独
执行。 审计机制保证修改的动作被完整地记录，也就是说，记录了谁
修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及
修改了哪些地方。 在版本控制过程中，如果利用一些配置管理工具（或
者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”
（Who、When、Why、What）。 同时配置审计工作应当可以说明如下
信息。
配置审计应当说明的信息：
1. 变更要求被完成，并且对附加的修改已经执行了
2. 采用了正确的正式验证手段
3. 遵循了标准的要求
4. 变更的4W信息被完整记录，并和相关配置项关联

bmccbj

77
9 项目实施指南
一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段
和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活
动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。
一个项目设立之初项目经理首先需要制定整个项目的计划，它是项目研
发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以
展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件
配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是
造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的
行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的
重要保证。
在“开发阶段和维护阶段”，软件配置管理活动主要分为三个层面，这三
个层面是彼此之间既独立又互相联系的有机的整体。
（1） 主要由配置人员完成的管理和维护工作；
（2） 由系统集成员和开发人员具体执行软件配置管理策略；
（3） 变更流程。
软件阶段 活 动 活动说明
制定软件计
划
一个项目设立之初，项目经理首先需要制
定整个项目的计划
计划阶段
确定配置策
略
配置管理委员会（CCB）根据项目的开发计划
确定各个里程碑和开发策略

bmccbj

78
制定配置计
划
配置人员根据CCB 的规划，制定详细的配
置管理计划，交CCB 审核
批准配置计
划
CCB 通过配置管理计划后交项目经理批
准，发布实施
确定初始基
线
CCB 设定研发活动的初始基线
配置库管理
配置人员根据软件配置管理规划设立配
置库和工作空间，为执行软件配置管理做好准
备；并定期进行备份和清理工作
授权开发
开发人员按照统一的软件配置管理策略，
根据获得的授权的资源进行项目的研发工作
集成
系统集成员按照项目的进度集成组内开
发人员的工作成果，并构建系统，推进版本的
演进
管理基线
CCB 根据项目的进展情况，并适时的建立
基线，批准基线变更，保证开发和维护工作有
序的进行。
开发阶段
和维护阶
段
产品发布
系统集成员进行产品集成，由CCB 批准，
进行发布
其 他 配置会议
CCB 定期举行例会，根据成员所掌握的情
况、配置人员的报告和开发人员的请求，对配
置管理计划作出修改，并向项目经理负责。

bmccbj

79
配置报告和
审计
配置人员定期向项目经理和CCB 提交审
计报告，并在配置管理例会中报告项目在软件
过程中可能存在的问题和改进方案
变更管理
事件触发执行，由CCB 批准、项目组执行，
并执行审计
10 配置管理部署模型
基本过程
序号 阶段 活动 备注
1
获得相应管理
权
1.1 建立相应负责团队
1.2 获得授权和资源 可召开启动会
2
评估配置管理
现状
2.1
绘制和评估当前过程的
控制图
可采用CMM 标准
2.2
了解员工对配置管理的
态度
2.3
了解组织的配置管理技
术水平
2.4 了解领导期望

bmccbj

80
2.5 编制并评审评估报告 获得“现状信息”
3 配置工具选择
3.1
编制、评审《评估评分
表》
3.2 评估配置工具和供货商
3.3
收集其他用户的使用经
验
4 配置过程定义
制定配置管理过程草
案
4.1
利用“现状信息”和收
集的经验
4.2 制定新的过程
4.3
评审新过程，并建立新
的过程基线
5 试点
5.1 选定试点项目
5.2 确定试点负责小组
5.3
定义试点成功标准和进
度
5.4 试点项目人员培训
5.5 试点改进 同时对草案进行改进