第 11 章 软件配置管理

教学目的：掌握配置管理的概念、任务， 了解配置管理的标准和 CASE 工

具。教学重点：配置管理的概念、任务。教学难点： 访问和同步控制。

第第 1111 章章 软件配置管理软件配置管理 即： Software Configuration Management ，简称 SCM

软件配置管理——对正在被某个项目组建造的软件的修改进行标识、组织和控制的技术，用来协调和控制整个系统过程。目标——通过最大限度地减少错误来最大限度

地提高软件生产率。软件配置管理是包括从软件项目计划到软件退役为止——贯穿整个软件工程过程活动中的所有追踪和控制软件变动的保护性活动。

11.111.1 软件配置管理概念软件配置管理概念 软件开发过程的最终结果包括三类信息：

计算机程序（源程序和目标程序）； 描述程序的文档（面向技术人员和面向用户）； 数据结构（包括程序内部和外部定义两部分）。

组成上述信息的所有项目构成一个软件配置，其中每一项称为一个软件配置项（ Software Configuration Item ，简称 SCI ），它是配置管理的基本单位。一个 SC 中最早的 SCI 是系统规格说明书。SCM 要解决的主要问题就是保证软件的质量。

11.1.1 11.1.1 基线技术基线技术 基线（ baseline ）的原意是棒球场的边线，在软件开发过程中，为了有效地控制变动，软件配置管理引入基线的概念。IEEE 组织对于基线的定义——“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。根据这个定义，基线标志软件开发过程的各个里程碑，任一 SCI （例如，设计说明书），一旦形成文档并复审通过，即成为一个基线，它标志开发过程中一个阶段的结束。对于已成为基线的 SCI ，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。相反，对于未成为基线的 SCI ，可以进行非正式修改。

图 11-1-1 基线

系统工程

需求分析

软件设计

编 码

测 试

系统规格说明书

软件需求规格说明书

设计规格说明书

源代码

测试计划 /过 程 / 数据可操作的系统

发 布

11.1.1 11.1.1 基线技术基线技术

某个 SCI 一旦成为基线，随即被放入项目数据库（ project database ）。此后，若开发小组中某位成员希望改动 SCI ，首先要将它拷贝到私有工作区并在项目数据库中锁住，不允许他人使用。在私有工作区中完成修改控制过程并复审通过之后，再把修改后的 SCI推出并回送到项目数据库，同时解锁。

11.1.2 11.1.2 软件配置项软件配置项

一般软件配置需包括下列 SCI ：1．系统规格说明书2．软件项目规划3．需求分析结果 1 ）软件需求规格说明书 2 ）可执行的或“纸样”原型4．初步用户手册

11.1.2 11.1.2 软件配置项软件配置项5．设计规格说明书 1 ）数据设计描述 2 ）总体结构设计描述 3 ）模块设计描述 4 ）界面设计描述 5 ）对象描述（若采用面向对象技术）6．源代码清单7．测试规格说明书 1 ）测试计划和过程 2 ）测试用例和实验结果

11.1.2 11.1.2 软件配置项软件配置项8．操作和安装手册9．可执行程序 1 ）每个模块的可执行代码 2 ）连接到一起的代码10．数据库描述 1 ）数据模型和文件结构 2 ）初始化映象11．联机用户手册12．维护文档 1 ）软件问题报告单 2 ）维护申请单 3 ）预计变动的顺序13．软件工程的标准和过程

11.1.2 11.1.2 软件配置项软件配置项有时把 SCM 活动也列入配置管理的范畴。还应当建立组织的过程基线和软件财富基线，以便在整个组织中共享过程和软件财富。作为过程基线，应当将组织的质量体系、过程文件、工程操作指南、文档模板、工作样表、历史度量数据等进行统一管理、集中维护、控制发放和深入分析。软件财富基线主要包括各类可复用的软件构件。同时，把软件开发中选用的编辑器、编译器和CASE 工具等作为软件配置的一部分，当配置中其他 SCI 发生变化时，同时考虑这些软件工具是否与之适应和匹配。

11.1.2 11.1.2 软件配置项软件配置项用面向对象的方法组织项目数据库，将每个 SCI看作一个配置对象，有自己的名字和一组属性，各 SCI之间的联系用对象间的关系表示。以图 11-1-2 为例，五个配置对象，对象之间的关系用有向连线表示。有向曲线——对象的部分—整体关系。

例如，“数据模型”和“模块 N”都是“设计规格说明书”的组成部分。双向连线——对象间的关联联系。

例如，一个模块的源代码一旦变动，对应的测试用例亦需修改，随之需要重新执行测试过程。

图 11-1-2 配置对象

设计规格说明书数据设计总体结构设计模块设计界面设计

测试规格说明书测试计划测试过程测试用例

数据模型

源代码

模块 N

11.2 11.2 软件配置管理任务软件配置管理任务

软件配置管理主要任务是控制软件的修改，主要包括：

1．标识软件配置中各种对象；2．管理软件的各种版本；3．控制对软件的修改； 4．审计配置；5．报告配置情况。

11.2.1 11.2.1 标识配置对象标识配置对象 所有 SCI都应按面向对象的方式命名并组织起来。对象命名是为了能够根据名称提取对象；而通过组织对象并描述其间的关系则着眼于在对象变更时能够清楚地了解变更的影响范围。基本对象——在分析、设计、编码或测试阶段由开发人员创建的某个“文本单元”（ unit of text ）。

例如，需求说明书中某一节，某个模块的源代码，或按等价分类法制定的一套测试用例；复合对象——由若干基本对象和复合对象组合而成的对象，是一个递归的概念。

例如，“设计规格说明书”是复合对象，它由“数据模块”和“模块 N”等基本对象组合而成。

11.2.1 11.2.1 标识配置对象标识配置对象每个配置对象都拥有名字、描述、资源列表和实际存在体四个部分：

1. 对象名一般为无二义字符串；2. 对象描述包括若干数据项，它们指明对象的类型（例如，文档、程序还是数据）、所属工程项目的标志及变动和版本的有关信息；

3. 资源列表给出该对象要求、引用、处理和提供的所有实体，如数据类型、特殊函数等，有时变量也被看作资源；

4. 只有基本对象才有实际存在体，它是指向该对象“单元正文描述”的一个指针；对于复合对象，此项取 null值。

11.2.1 11.2.1 标识配置对象标识配置对象

除了标识配置对象外，还必须指明对象之间的关系，一个对象可标识为另一个复合对象的一部分，即此两对象之间存在一个 <part‑of>关系。若干 <part‑of>关系可定义出对象之间的分层结构。例如：

“E‑R 图” <part‑of>“ 数据模型” “数据模型” <part‑of>“ 设计规格说明书”因一个配置对象可能与其他多个对象有关系，所以 SCI 的分层结构不一定是简单的树状结构，而是更一般的网状结构。

11.2.1 11.2.1 标识配置对象标识配置对象

在标识对象时还应考虑对象随着开发过程的深入不断演进的因素。为此，可为每个对象创建一个进化图，它概述某对象演化的历史，图中每个结点都是 SCI 的一个版本。

obj1.0

obj1.1.1

obj1.1

obj1.2

obj1.3

obj2.0

obj2.1

obj1.1.2

obj1.1.3

图 11-2-1 进化图

11.2.2 11.2.2 版本控制版本控制

为了适应不同环境特点和满足不同用户的个性需求，往往一个项目保存多个版本。配置管理的版本控制主要解决下列问题：

1 ）根据不同用户的需要配置不同的系统； 2 ）保存系统老版本，为以后调查问题使用； 3 ）建立一个系统新版本，使它包含某些决策而抛弃另一些；

4 ）支持两位以上工程师同时在一个项目中工作；

5 ）高效存储项目的多个版本。

11.2.2 11.2.2 版本控制版本控制版本控制系统都为配置对象的每个版本设置一组属性，这组属性既可以是简单的版本号，也可以是一串复杂的布尔变量（即开关值），用以说明该版本功能上的变化。进化图也可用于描述一个软件系统的不同版本。

图中每个结点都是软件的一个完整版本，它由所有协调一致的软件配置项组成（源代码，文档和数据）。此外，一个版本还允许有多种变形（ Variant ）。

例如，一个程序的某个版本由 A 、 B 、 C 、 D 、 E五个部件组成，部件 D仅在系统配有彩色显示器时使用，部件 E则适用于单显，那么该版本就有两种变形，一种由 A 、 B 、 C 、 D四个部件组成，另一种由 A 、B 、 C 、 E四个部件组成。

11.2.3 11.2.3 修改控制修改控制

在大型软件开发过程中，无控制地修改会迅速导致混乱。所谓修改控制，即把人的努力与自动工具结合起来，建立一套机制，有意识地控制软件修改。

图 11-2-2 修改控制过程

用户认识到有修改的必要用户提出“修改申请”

开发者评估

产生“修改报告单”提交修改控制机构决策

修改请求被拒绝

通知申请者 ( 用户)

此修改申请入等待队列排队，同时产生“工程变动命令”

将欲修改的各配置对象明确分工到人

从项目数据库中提出配置对象

图 11-2-2 修改控制过程（续）

实施修改复审修改（审计）

将修改后的配置项放回项目数据库建立基线准备测试

进行所有质量保证和测试活动提示即将推出的下一个版本中已做的修改

构造一个完整的新版本

复审对所有配置项所做修改推出新版本

11.2.3 11.2.3 修改控制修改控制当一个“修改申请”提出后，开发者依据技术指标和潜在的副作用，对其他配置对象和系统功能可能造成的影响以及项目成本等诸多因素进行评估。评估的结果将形成一个“修改报告单”，提交给修改控制机构 CCA 决策。CCA 一旦同意修改，应立即提供一个“工程变动命令” ECO 。它指明修改任务、需遵守的限制和复审标准。然后从项目数据库中“提出”待修改对象，经修改后再“推出”更新版本。这一对动作是项目数据库访问控制和同步控制要求的。访问控制决定哪些人员有权访问或修改某个配置对象；而同步控制则保证并行修改时不因互相重写而造成丢失修改。

11.2.4 11.2.4 保存维护记录保存维护记录访问和同步控制流可用图 11-2-3 说明。软件开发人员根据 ECO 从项目数据库中提出待修改对象，访问控制机构，核实该开发人员是否有此特权，而同步控制机构则及时锁住待修改对象，不允许其他开发人员再做修改，直至该对象的新版本推出。加锁期间，其他工程人员仍可提取该对象的副本（称为提取版本）使用。图 11-2-2 所示的修改控制用于已交给用户的软件产品，称为正式修改控制。若欲修改的 SCI 虽已为基线版本，但尚未交付用户，此时修改控制称为工程级的修改控制，它除了不涉及用户外，其他步骤与正式的修改控制大致相同。若 SCI 并未成为基线版本，只需进行非正式的修改控制，则在不影响系统需求的前提下，该 SCI 的开发者可随意改动 。

图 11‑2‑3 修改过程中的同步和访问控制

提出

访问控制

推出

软件工程师 项目数据库访问请求特权信息

解锁

加锁配置对象

（提取版本）配置对象

（基线版本）

配置对象（基线版本）

配置对象（修改版本）

审计信息

11.2.4 11.2.4 配置审计配置审计

对于变更工作，必须通过正式的技术复审和软件配置审计工作来验证被核准进行变更的对象是否进行了必要的、正确的变更，并得到了重新的配置。正式的技术复审着重考虑所修改对象在技术上的正确性，复审人员应对该对象是否与其他 SCI 协调以及在修改中可能产生的疏忽和副作用进行全面的评估。

11.2.4 11.2.4 配置审计配置审计软件配置审计作为正式复审的一种补充措施，主要考虑下列在正式技术复审中未被考虑的因素：

1． ECO 中指定的修改是否都已完成？有无进行未经指定的其他附加变更？

2．是否做过正式技术复审？3．是否严格遵守软件工程标准？4．是否对修改过的 SCI 进行了强调说明？修改的日期和执行修改的人员是否已经注明？该 SCI 的属性是否能够反映本次修改的结果？

5．是否遵循了标注变更、记录变更和报告变更的 SCM 工作规程？

6．所有相关的 SCI 是否已一并修改？

11.2.5 11.2.5 配置状况报告配置状况报告 建立并发布配置状况报告（ Configuration Status Reporting ，简称 CSR ）是软件配置管理的一项任务 .

CSR 主要概述下列问题：发生了什么事情；谁做的；何时发生的；有什么影响。CSR 的时机与图 11-2-2 所述过程紧密相关 :

当某个 SCI 被赋予新标记或更新标记时 ;

或 CCA 批准一项修改申请（产生一个 ECO ）时 ;

或配置审计完成时。CSR 的输出可放在联机数据库中，供开发人员和维护人员随时按关键字查询。

11.3 11.3 软件配置管理标准软件配置管理标准

有若干种 SCM 标准：较早的标准主要用于美国军界：

MIL‑STD‑483 ； DOD‑STD‑480A ； MIL‑STD‑1521A 。后来公布的 ANSI/IEEE 标准，如 828‑1983 ， 1042‑1982 和 1028‑1988等。

11.4 11.4 配置管理的配置管理的 CASECASE 工具工具 一个配置管理工具—— DSEE （ Domain Software Engineering Environment ）的组成：

历史管理程序（ history manager ）； 配置管理程序（ configuration manage

r ）； 任务管理程序（ task manager ）； 监控管理程序（ monitor manager ）。历史管理程序负责在库中存储管理配置项的各个版本；配置管理程序的主要功能是定义和建立配置；任务和监控管理程序则主要负责控制软件修改过程。这里重点讨论配置管理部分。

11.4 11.4 配置管理的配置管理的 CASECASE 工具工具使用 DSEE 建立一个配置（在此泛指系统或某个配置项）需涉及下面三个概念：

1．系统模型（ system model ）——欲导出此配置项所需的源项、工具（ DSEE 中称为翻译器）和过程；

“系统模型”描述组成系统各分量之间的关系，即系统构成。它包括每一个分量的形式（分为原子和聚合的），分量之间的依赖关系，以及每一个分量将被什么翻译器处理等。。

11.4 11.4 配置管理的配置管理的 CASECASE 工具工具2．配置依据（ configuration thread ）——推导配置项版本时所用的一组规则、工具和工具中的选件（ options ）；

“配置依据”主要描述对于一次具体的配置建立，源项的哪些版本和翻译器的哪些选件将被使用。因此涉及到版本和选件的命名与确定。为此， DSEE 引入一套专用语言，描述“系统模型”的“配置依据”。

11.4 11.4 配置管理的配置管理的 CASECASE 工具工具

3．导出项缓冲池（ derived element pool ） 每一配置项建立后都放入缓冲池中，它可以同时存放某配置项的几个版本。因此缓冲池中每项均附一个 BCT （ Bound Configuration Thread ，捆绑配置依据），它列出推导此配置项所用的各源项和工具的版本及工具选件。

首先根据“系统模型”和“配置依据”确定此次欲推导配置项的“ BCT” ，然后在缓冲池中查找那些可直接用于推导新配置项的配置项。通过遍历项目依赖图，确定所有凡是其所依赖的项在其建立之后从未改变过的项，直接使用它们，而不重新建立。如果在“导出缓冲池”中能找到某个配置项，其 BCT与欲推导配置项的 BCT匹配，则 DSEE立即重用它，不再重新推导。 DSEE 的一个优点就是允许各配置尽可能共享已经导出的配置项。

建立规格说明（即为所要求配 置项建立 BC

T ）

源库

翻译器导出项缓冲池

系统模型

配置依据

图 11-4-1 用 DSEE 建立一配置

图 11-4-2 用 DSEE 并行建立某编译器前端

DSEE 建立编译器前端

PARSER.O

计算服务器 B

文件服务器 D

…建立PARSER.C

导出项缓冲池

源库

工作站 A

LEX.O

…建立LEX.ASS

LEX.ASS

PARSER.CCONSTAXTS.LNC…

工作站 E 工作站 C

11.4 11.4 配置管理的配置管理的 CASECASE 工具工具DSEE 可以在网络环境下工作，此时建立配置的工作可在多个 CPU 上并行完成，如图 11-4-2 说明了并行建立机制。假设某用户在工作站 A 上要求 DSEE 建立某编译程序前端（指词法分析与语法分析部分） DSEE 确定需要分别建立彼此独立的 LEX.ASS 和 PARSER.C ，选择结点 B 、 C完成此项任务。这两个结点独立地从结点 D 的库中取所需源项，又将已建立完成的项目送到结点 E 的缓冲池中。