clearcaselt配置

bmccbj

83
建立一个CHECKLIST，来进行调研，如下
序
号
调查内容 调查结果
1
工具可以解决当前问题，满足当前需
求吗？
2 产品的市场地位
3 产品价格
4 与现有环境的兼容程度
5
运行能力（峰值情况、成熟性、稳定
性）
6 是否支持未来需求
7 是否具备：工作空间管理
8 是否具备：版本控制
9 是否具备：配置报告
10 是否具备：过程支持
11 是否具备：安全和保护
12 是否具备：工具集成
13 是否具备：构造支持
14 是否具备：图形界面
15 是否具备：自定义支持

bmccbj

84
16 是否具备：发行管理
17 是否具备： WEB 支持
对应过程：3.2 评估配置工具供应商
建立一个CHECKLIST，来进行调研，如下
序
号
调查内容 调查结果
1 配置管理服务从业时间
2 成功案例数量和质量
3 培训、技术支持队伍
4 提供的培训和指导，以及其他服务
5
近期关于配置服务的商誉、资产、销
售额
6 地理位置、服务及时性
对应过程：4.2 制定新的过程
1. 配置管理过程至少应当包括的内容：配置标示、配置控制、报告、
审计
2. 在考虑工具纳入配置过程中应当考虑下表内容
序号 考虑内容
1 从配置过程中分解出那些是事务性、那些是创造性的工作
2
考虑事务性工作的繁重程度和精度要求程度，理出一个“自
动化优先级”

bmccbj

85
3 根据过程，确定工具可以运用的地方
4 根据“自动化优先级”选择那些工具功能进行自动化
5 考虑使用工具功能自动化的前提和结果
6 划分出“自动化”和“人工”的接口，并清晰描述
7
调整过程要素，适应工具，从而形成一个纳入了工具的配置
管理过程
8 考虑这个过程的适用性和效益
对应过程：6.1 组建相应部门和团队
负责配置管理部署和实施的团队必须包括
序
号
团队成员 职责和要求
1 组长 负责管理小组，并负责配置管理的部署和实施
2 技术人员
负责考虑将要和配置工具集成的各类工具之间的
接口
3 配置专家 配置工具精通、配置管理理论知识熟悉
4 过程专家 负责过程建模和主要的过程分析工作
5
配置管理
人员
负责评审新过程，并提供原来配置管理的经验
6 项目经理
负责评审新过程，并提供配置管理适应于项目的
参考
对应过程：6.2 制定各个项目的实施计划

bmccbj

86
计划应当包括的内容：
序号 计划内容
1 目标和完成标准
2 投资和收益分析
3 阶段划分和进度安排
4 资源投入安排
5 人员分工和组织
6 风险管理
第四章 配置管理系统中的概念
摘要：现在，软件配置管理的环境及其工具越来越得到人们的重视。
本文尝试就现存的CM 体系中的以用户为主体的一些概念作详细说明。
就如一个光谱，某些概念可能是另一些概念的延伸或总结。由于在整个
软件工程家族中对于CM 的功能性没有共通的术语,且许多CM 系统在概
念的应用上也是千差万别，因此要从CM 系统中抽象出一些概念是难乎
其难的事了。正因为这样，本文陈述的每一概念是其在某一具体的CM
系统中的概念。有一部分的概念陈述是针对CM 体系的用户极为重要的
问题。没有哪一个CM系统能提供CM体系不同用户要求的所有功能。而
且，每一CM 系统解决的问题只是所有概念的一部分。为了完成本报告，
对CM 体系的功能以举例的形式作了简短的说明。

bmccbj

87
1. 简介
现在，软件配置管理的环境及其工具越来越得到人们的重视，
这一点从CM体系中提供的概念谱中就显而易见。本文对这些概念
进行了阐明。首先，在一典型的CM 情形中，我们 对CM 和CM
体系做了更为广泛的定义。
A. 配置管理的定义
软件配置管理是一控制软件系统演变的学科。关于CM 的经典讨论
在条文[3]、[4]中进行了阐述。IEEE 标准729-1983 就CM 以下的内容进
行了规范的定义。
在IEEE 标准729-1983 中，软件配置管理的定义包括：
标识——识别产品的结构、产品的构件及其类型，为其分配唯一的
标识符，并以某种形式提供对它们的存取。
控制——通过建立产品基线，控制软件产品的发布和在整个软件生
命周期中对软件产品的修改。例如，它将解决哪些修改会在该产品的最
新版本中实现的问题。
状态统计——记录并报告构件和修改请求的状态，并收集关于产品
构件的重要统计信息。例如，它将解决修改这个错误会影响多少个文件
的问题。

bmccbj

88
审计和审查——确认产品的完整性并维护构件间的一致性，即确保
产品是一个严格定义的构件集合。例如，它将解决目前发布的产品所用
的文件的版本是否正确的问题。
生产——对产品的生产进行优化管理。它将解决最新发布的产品应
由哪些版本的文件和工具来生成的问题。
过程管理——确保软件组织的规程、方针和软件周期得以正确贯彻
执行。它将解决要交付给用户的产品是否经过测试和质量检查的问题。
小组协作——控制开发统一产品的多个开发人员之间的协作。例
如，它将解决是否所有本地程序员所做的修改都已被加入到新版本的产
品中的问题。
软件配置管理的解决方案涉及面很广，将影响软件开发环境、软件
过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。
配置管理解决方案将影响过程模型和模型的使用者，是因为它强行
推行组织的方针政策和工作规程，并对工作过程进行跟踪。它从开发和
维护的及时性方面影响产品的质量。例如，配置管理机制可以保证为每
一个发布的版本提供内容清单，通过一致性维护提高产品的质量。配置
管理解决方案通常在组织范围内推行，实际上配置管理系统是组织内部
信息交换的中心，它影响组织内的每一个成员及组织的业务流程。
总之，一个配置管理解决方案的制定包括配置管理计划、过程的定
义、与使用者的交流、自动化支持和做出管理决定等活动。
软件组织应该提出不同层次的配置管理视角，这些层次包括：公司

bmccbj

89
级、项目级、程序员级和应用级。公司级视角提供组织的全貌图和配置
管理过程的描述；项目级视角是与项目相关的各项目组可以使用不同的
配置管理方案；程序员级视角是专门为程序员提供的且具有某些特定的
配置管理功能；应用级视角关心的是配置管理如何应用到具体的问题中
去。
B. CM系统的定义
至于怎样才算是构成CM 系统的，对此还没有普遍接受的定义。例
如：假如系统有版本控制功能，它是否就是一个CM 系统呢？理想的
CM 系统是基于以上定义提供所有功能的系统。但是， 实际中的系统只
能提供某种程度上实现的版本控制功能、配置识别功能、系统构建功能、
系统建模功能，或某种程度上提供CM 的意识就被软件工程大家族认为
是CM 系统了。应注意的是， 现有的CM 体系提供只是一种功能的综
和而不是一标准的体系。本报告提及15 个CM 系统，目前至少有40 个
系统可以为今所用。
这里，有必要将CM 系统和CM 工具两概念区分一下。CM 系统可
看作是其支持环境的一部分且以这种形式被售出。譬如，在
RATIONAL[14]环境下CM 功能成为该环境必不可少的一部分。CM 工
具可看作是一独立的工具。譬如，版本控制系统（RCS）只是一个工具，
因为它可被安装在一个现有环境中。由于这种区分在本文不是那么重
要，术语CM 系统就被用来表示这两概念。
C. CM以用户为导向的典型情形
在讨论CM 体系之前，我们描述了一个简单、典型的、以用户为导
向的CM 系统来作参考。在此情形下，包含了具有不同职责的人员：负

bmccbj

90
责软件小组的项目经理、负责CM 规程和方针的配置经理、负责软件产
品开发与维护的软件工程人员、负责验证产品正确性的测试人员、负责
确保产品高质量的质量保证经理、使用产品的用户。
每一角色都有他们的目标和任务。对项目经理来讲，其目标是确保
产品在一定的时间框架里得以开发。因此，经理监控开发过程并发现问
题，解决出现的问题。这些又必须通过对软件系统的现状形成报告并予
以分析以及对系统进行审核才能完成。
配置经理的目标是确保用来建立、更改及编码测试的规程和方针得
以贯彻执行，同时使有关项目的信息容易获得。为了对编码更改形成控
制，经理引入对正规请求更改的机制，评估更改的机制[通过更改控制机
构（CCB），由它负责批准对软件系统的更改]，和批准更改的机制。经
理负责为工程人员创建并宣导任务单，基本上创建项目的框架。同时，
经理还收集软件系统中构件的相关数据，比如说用以判断系统中出现问
题的构件的信息。
对于软件工程人员，他们的目标是有效地创造出产品。这就意味着
工程人员在创建产品、编码测试及支持文档的产生中不必相互间干涉。
与此同时，他们能有效地进行沟通与协作。他们利用工具以帮助创建性
能一致的软件产品，通过相互通知要求的任务和完成的任务来进行沟通
与协调。做出的更改通过将它们进行融合、分散和冲击而得知。产品中
的所有元素的演变连同其更改的原因及实际更改的记录都予以保留。工
程人员在创建、变更、测试及编码的汇合上有自己的工作范围。在某一
点上，编码会形成一个基线，它使得进一步开发得以延续，为其它平行
开发得以进行。
测试的目标是确保产品经过测试达到要求。这里包括产品某一特定

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 系统了。