clearcaselt配置

bmccbj

91
版本的测试和对某个产品的某种测试及其结果予以记录。将错误报告给
相关人员并通过回归测试进行修补。
质量保证经理的目标是确保产品的高质量。这意味着特定的规程和
方针应当完成并得到相关的批准。错误应得到纠正并应对变化的部分进
行充分测试。客户投诉应予以跟踪。
不同的客户使用的产品版本也是不同的。客户总是遵循规则来做变
更要求、错误显示及产品改进。
理想的CM系统在这种情形下应能够支持所有这些目标、角色和任
务。这也意味着这些角色、任务和目标决定了一CM 系统要求的功能。
本文提出的一些概念就是为了解决这些问题。
D. 本章的结构
在简介中就CM 和CM系统进行了定义，列出一典型的CM 情形，
这样一来也就暗示了CM 体系的要求。第二节描述了CM系统中以用户
为导向的一些问题。这些问题影响用户对CM 系统的期望。第三节描述
了CM 概念谱。第四对CM 体系的未来做了探讨，第五节是结论。附录
是本文CM 体系索引的概览。
2. CM体系用户的有关问题
许多与CM 有关的问题直接影响到CM 系统的用户。现有的CM 体
系从不同的角度解决这些问题。尽管本文是为了就现有CM 体系的特色
进行探讨，但对这些问题的阐述仍然有必要因为它们影响到用户对一
CM 系统的期望。这些问题包括：
用户的角色问题：
不同CM 体系用户对CM 体系的功能的要求也就不同。

bmccbj

92
集成问题：
不同的集成问题影响到CM系统的功效。
启用CM 的时机问题：
一项目组何时启用CM系统取决于该CM 系统的能力。
控制水平问题；
一CM 系统对产品及产品的管理的控制水平可以是不同的。
过程与产品问题：
一理想的CM 系统提供CM 的过程、产品及其附件。
自动化水平问题：
CM 功能的实现总是手工与自动程序的统一。
功能问题：
CM 体系具备实现CM 众多功能的许多特点。
以下将对此做进一步说明。
A. 用户的角色问题
正如1。3 节中的情形表示的一样，CM 体系的用户是多种多样的。
每一个用户都有特定的角色，对CM 也有不同的观点，因此，对CM 系统
的要求也就不同。这种要求是很分明的同时又是互补的。图1 是一功能
组描述了项目经理、配置经理、软件工程人员、质量保证经理及客户对
CM 系统的期望。图1 中的每一个方框代表的是一主要的功能区域。图1
显示在方框外（审核、统计、构件、结构与创建）在任何CM 系统中都
可独立存在的功能区域，但当与团队和过程功能合并时，就得到一个完
整的（或综合的）CM 系统了。

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*