clearcaselt配置

bmccbj

93
建立
剪辑
优化 更新
更改影响分析
历史纪录
追溯
日志 版本 库
配置 元素种类
配置版本
基线
项目环境
系统模型
界面
关系
选择 一致性
创 建 结 构
审核
生命周期支持
事务管理
沟通
文档
团队
工作区间 家族
冲突解决

bmccbj

94
图1：CM 功能要求
功能区域有：
l 构件：标识、分类、存取构成产品的组件。
l 结构：表示产品的架构。
l 创建：支持产品的构建及其产品的附件。
l 审核：对产品及其过程的审核予以保留。
l 统计：采集与产品、过程相关的数据。
l 控制：控制产品变更的方式及时间。
l 过程：支持产品演变的管理。
l 团队协作：促进项目组开发及产品维护。
以下将对这些功能区域的进一步探讨。
u 对于元素的要求，用户要：记录元素的版本及其差异，差
异的原因；确定构成配置及配置版本的组件群；标识出产品的基
获取控制
变更请求
错误查找
变更告知
分割
统计
现状
报告
构 件
统计 控制
程
过

bmccbj

95
线及其外延产品，确定表示项目组件群及附件项目环境。而且，
用户需要数据库来存取组件及CM 信息，同时还有资源和对象编
码、执行情况、图表、文档和基线。
u 对于机构的要求而言，用户要：通过表示产品组件库的系
统模型来模拟产品的结构；标明组件、版本、配置的界面使之可
以重用；确定及维护组件间的关系；选择兼容的组件使之形成有
效的、一致的产品版本。
u 对构建的要求而言，用户要：容易创建产品的手段；能随
时静态分析产品的现状；通过减少组件的堆积和节省区间来优化
系统创建的机制；进行更改分析以预测因更改而导致的细小分化
的手段；随时都能对产品的任何部分、在任何阶段容易得到更新。
u 对于审核的要求而言，用户要：所有更改的历史记录；所
有与产品相关的组件与其演变的追溯性；完成任务的所有细节的
日志。
u 对于统计的要求而言， 用户要：统计记录的机制，产品
现状的检验，有关产品和过程的所有方面的报告能较易产生。
u 对于控制要求而言，用户要：为避免不必要的变更或变更
冲突对系统中的组件的获取应予以控制，对于更改要求的表格及
问题报告形成在线支持；错误查找的手段及何时对何人会产生什
么影响；在不同但相关的产品版本之间以受控的方式进行更改告
知；将产品进行分割的手段以限制更改影响。
u 对于过程要求而言，用户要：对生命周期模型及组织方针
予以支持；确定要完成的任务及如何完成、何时完成的能力；将
相干的事务的讯息在适当的人员之间进行沟通的能力；将产品的

bmccbj

96
经验文档化的手段。
u 对于团队协作的要求而言， 用户要：个人和小组的工作
区间；在汇合时产生冲突的解决办法；对产品的创建及其维护予
以支持的手段。
注意：图中过程方框与团队方框代表功能区域极为重要的部分。这
是因为它们影响所有其它区域或受到所有其它区域的影响。对于用户来
讲，理想的CM 系统随团队协作和过程的完全融合应当能支持所有的功
能区域。但目前还没有此类系统。
B. CM系统的集成
任何CM 系统在某种程度上都能与它的环境融合。CM 系统可与其它
工具并存或完全融合。适合与不同环境方面融合的有：过程、工具组和
数据库。过程集成是将CM 系统的使用模式（指CM 过程）同环境的使用
模式（指软件生命周期过程）的结合；工具组的集成是将CM 系统安装
在环境中使之至少能环境中其它所有工具共存。譬如，在编辑过程中，
每当用户发出“SAVE”命令时，用户就会要求CM 功能能建立一新的版
本。数据集成指的是CM 数据库的逻辑定位——它是否能与现存环境的
数据库能做某种方式的合并，或它的数据库是否独立存在的，或它能否
利用其它数据库中的信息。所有此类集成都是普通的工具集成和技术的
转换问题。但，由于CM 将影响到环境中的绝大部分物件并贯穿每一物
件生命周期的所有阶段，CM 系统的集成势必对环境中的很多工具有重要
影响。大多数CM 系统能与其它工具共存，有些环境把CM看成其必不可
少的一部分。

bmccbj

97
C. 何时启用CM 系统
对于在开发和维护产品过程中, 项目组何时启用CM系统是不定的。
有些项目组选择在产品经历开发生命周期并准备发到用户地时开始启
用。有的选择在项目一开始就将一切置于CM 下。二者都有各自的一般
费用。譬如，项目组可能基于变更要求的费用上来决定何时启用。如果
有许多的手工程序（如：将变更申请表归档、寻求CCB的批准与确认可），
项目组会选择在大部分开发完成之后将软件置于CM 的控制之下。但如
果变更要求程序能在线很快地得到处理，CM 将在软件生命周期的早期就
被用上。理论上讲，CM 在产品的整个生命周期都能派上用场 —— 从创
建、开发、产品发放、交付、使用到维护。在理想的情形下，CM 能在较
少的花费下对此予以支持，由此CM 才能在项目中尽可能早地予以应用。
然而，现有的CM 系统只关注生命周期的某一特定的阶段，用户因
此受到限制。
D. CM的控制水平
很多的程序、方针和工具组合一块来支持CM 的应用。它们在对用
户的支持和产品的演变予以不同程度控制水平支持。譬如，它们会要求
开发人员递交正式的书面的更改请求。配置经理则会建立一个工作区间
给软件开发人员。配置经理可从受控库存中抽取所要的文档并将其置于
该开发人员的工作区间里。当然，不同的程序、规定和工具事实上允许
开发人员也可以通过电子邮件的方式将更改请求通知配置经理及CCB的
其他成员。成员之间通过电子邮件予以迅速回应。一经批准，更改请求
将被指派给开发人员，他可以直接从库存中抽取相关的文件并作出更
改。所有这些无需手工介入。由于CM 系统会自动记录所有的登入，更

bmccbj

98
改过程的正式记录就可创建。
前一种情形可被看成对行动具有积极的控制，后者较为松且被动。
在前一种情形中由于手工耗费的原因，经常性的更改不予以主张，而后
者恰恰相反。这种不同的控制水平在产品生命周期的特定阶段有其适用
性。譬如，前者更适合维护而后者适合开发。不管CM 系统这么用，它
对于用户和产品的演变历史都有一定程度的控制。它将驱动用户的过程
并将其加强。现有的CM 系统提供或松或紧的控制水平但很少能灵活地
允许用户选择控制的种类。
E. 过程与产品的区分
CM包括过程和产品。CM过程表示执行CM是所需的一系列工作任务。
从根本上讲，过程是一个计划，它定义要做什么、谁来做及如何做。支
持这过程是管理的功能。过程模型将组织的方针、程序和软件开发生命
周期模型通盘考虑。CM 的产品是工程管理任务的结果。CM 系统的功能
需要为二者予以支持。现有的CM 系统提供一些产品及过程的支持，但
在同一CM 系统中一般不能形成对二者完全支持。
F. CM自动化水平
目前，CM 一般是手工和自动程序二者兼而有之。无需任何在线支持
来实施CM 也是可能的。但这样做的效率很低。我们的目标是将CM 中非
创造性的部分尽量多地自动化。譬如，书面更改表格和对此回应的监控
一般只在组织方针里予以记录，而不能在线获取与加强。
G. CM系统功能
现有的CM 系统提供的只是所有不同种类的用户的部分功能。但随

bmccbj

99
时间的推移和用户的需求和环境结构的能力得到更好理解后，这种情况
将可能得以改进。以下部分描述的是现有CM 系统概念范围。
3. 配置管理系统概念光谱图
以上部分解释了有关配置管理系统需求问题的范围，本部分将细述
配置管理系统的具体功能，并对于支持前文所述某些功能的概念特别加
以考察。这些概念将被组织成一幅光谱图来表示配置管理系统的演化过
程。每个概念都将置于一个特定的配置管理系统中来描述。以下是要讨
论的我们感兴趣的配置管理系统概念中的功能，包括：组件，过程，结
构和特色架构的组合，团队概念。图2 展示了整个概念光谱图和它们对
应的，有代表性的配置管理系统实例，然后给出每个概念的一个简单描
述并着重突出它的优势。在本部分的末尾，将对概念和概念光谱图的作
用和局限性作一个分析总结。
图例：
概念
演化的方向
*系统实例

bmccbj

100
*表示本节点所示概念的系统实例
图2：配置管理概念光谱图
A. 注意事项
值得指出的是要讨论的概念和系统仅仅是现有系统的表示，而不是
现有系统完整的评估和总结。对于每个概念，都用一个配置管理系统实
例来讨论。但是需要注意的是，许多配置管理系统实际上提供了不止一
个光谱图所示概念。既然谈到配置管理系统自然形成的功能时没有通用
的术语，而这些概念是直接从特定配置管理系统中提取——所以每一个
配置管理系统有自己的概念和定义。为了注意力集中，概念的描述都尽
量简化。这样一来，就无法对所有概念的能力（不是它们的系统）面面
俱到。但是，因为要提出概念光谱图和精简出一个配置管理系统概念集
的缘故，简化是必要的。本文参考的每种配置管理系统在附录中都有一
系统建模 对象池 库
文本管理
分布式组件 生命周期模
型
需求变更
属性
工作空间
透明视图
事务
一致性维护
子系统 更改集 约定
LIFESPAN*
PowerFrame*
SherpaDMS*
NSE*
SMS*
Shape*
DSEE*
Adele*
CMA*
Jasmine*
Rational*
ADC* ISTAR*
CCC*
RCS*

bmccbj

101
个简评，它提供了每种系统配置管理能力一个更全面的清单。
B. 组件的概念
组件的概念是与标明和访问软件产品的组件相关。它们包括下文所
描述的库和分布式组件。
a.库
库的概念是配置管理系统的根本。修订控制系统(Revision Control
System（RCS）)[15]提供了ASCII 码文件库的概念。从效果上来说，库
是集中控制的文件库并提供对库中所存储文件的版本控制。任何库中的
文件都被视为在确定的配置管理之下。库中的文件是不会变的——它们
不能被更改。任何更改被视为创建了一个新版本的文件。文件所有的配
置管理信息和文件的内容都存贮在库中。所以，任何配置的管理和控制
都与库中的文件相关联。当工作于一个文件时，用户将某个版本的文件
导入工作目录，然后开始工作，处理完了，然后将文件导回库中。这样
就生成了这个文件的新版本。所以用户不可能导出一个文件并同时在库
中修改源文件。
从库的角度来看，导出的文件自动被锁定直到文件重新被导入，一
个版本号自动与新版本文件相关联。这样一来，用户可以随时根据特定
的版本号来导出任何文件（缺省的是最新的版本）。对最新版本的修改
的结果是产生一个新的，顺序递增的版本；而对更老版本的修改的结果
是产生一个分支版本。在版本编号策略和使用模式共同作用下，产生了
文件版本历史树，用来表示祖先和后代版本。库中不但存储了文件的不
同版本，更改的理由，而且存储谁在什么时候替换了某个版本的文件等
文件历史信息。请注意，对于每个不同版本文件，不是所有的代码都存

bmccbj

102
储起来，而只是不同版本间实际的差异才存储起来：这称为增量。这种
方法有利于节省空间和节省对最新文件版本的访问时间。另外，可以根
据状态给文件加上标签，然后基于状态的值进行导出。它们同样也可以
根据修订版本号，日期和作者进行导出操作。库总是和文件所在的目录
相关联。总而言之，库捕捉配置管理信息并把不同版本的文件存储为不
可修改的对象。
b.分布式组件
Sherpa 设计管理系统（The Sherpa Design System（DMS））[7]提
供一个文件库，其中的文件分散分布在不同的硬件平台上。在逻辑上，
库是集中控制的，但在物理上，库中的数据是分布的。Sherpa 设计管
理系统自己知道数据的分散分布，并把这个因素考虑到配置管理系统中
去，例如，在提供必要的文件格式转换时提供一定的容错能力。这样，
对于用户来说，数据的分布是透明的——用户对库进行的任何工作感觉
上和所有文件放在自己的本地工作站上一样。一组地理上分散分布的用
户可以针对同样配置的文件一起工作。多个文件的副本可以在不同的工
作站上存在。Sherpa 设计管理系统总是知道最新文件版本的位置。任何
对从库中所导出文件的更改会导致所有分散的本地工作站上的副本更
新，因为系统知道所有本地副本放置的位置。更新可以是一步一步交互
式样地发生，也可以是批处理式地完成。有效的，分散分布的用户能够
直接访问集中控制的库。对他们来说，配置管理能力看起来遍布整个异
构网络。
C. 过程的概念
处理与过程相关的功能的概念有以下几个：上下文管理，约定，变