“计算机系统配置”，是指计算机系统或计算机部件按其组成的零件数量、性质及相互联系所确定的安排。

配置(configuration)一词在计算机领域已有广泛的应用。所谓“计算机系统配置”，是指计算机系统或计算机部件按其组成的零件数量、性质及相互联系所确定的安排。软件配置的含意与此类似，但在管理对象和方法上还是有一些差别。

软件配置管理是软件管理的重要内容。近年来，软件项目的规模越来越大，复杂性越来越高，管理失误给我们的教训也越来越深刻，这使得人们不得不重视配置管理。

软件开发过程中的变更以及相应的返工会对产品的质量造成很大的影响。有统计表明，变更及其返工可能耗费50%的开发工作量，如果不从配置管理方面加以控制，必将导致严重的后果。软件配置管理的一个重要内容就是对变更加以控制，将变更对成本、工期和质量的影响降到最小。

一、软件配置管理的概念

1.软件配置项(software configuration item)

(1)软件开发的过程中，会得到许多工作产品或阶段产品，还会用到许多工具软件，这可能是外购软件，也可能是用户提供的软件。所有这些独立的信息项都要得到妥善的管理，绝不能出现混乱，以便在提出某些特定的要求时，能将其进行约定的组合来满足使用的目的。

这些信息项是配置管理的对象，称为软件配置项。例如，需求规格说明、设计规格说明、用户手册、维护使用手册都属于此。

(2)软件配置

如果说软件配置项是一个独立存在的信息项，我们可以把它看成一个元素。单独的一个元素发挥不了什么作用，但随着工作的进展，出于不同的要求，需要将这些元素进行不同的组合。软件配置是一个软件产品在生存期各个阶段的不同形式(记录特定信息的不同媒体)和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合。

这里以交付给不同用户的某一软件产品为例，进一步说明软件配置的含意。如果我们开发的软件产品是具有一定功能和性能的初始系统，但最终的产品应能满足用户的需求，为此，我们必须认真研究用户的真正需求。经调查，了解到“用户1”代表了一些用户，这个用户群使用的计算机为“机型1”，所用的操作系统是“操作系统1”;而“用户2”所代表的用户群使用着“机型2”和“操作系统2”(参看图1)。就是说，不同用户有不同的工作环境，我们的软件产品必须考虑到这些差异，并且充分地使其满足各个用户的使用要求。为做到这一点，产品的设计可能做成这样的安排(如图2所示)，两类产品分别针对两个用户群，产品内部设计的模块(按上面的说法是配置项)

用户1：A、B、C、D、E和F

用户2：A、B、C、D、E和G、H 两者的差别不仅表现在一个含有F，另一个含有G和H，而且即使两者的A在逻辑上是同一个内容，但在物理上仍然可能因两类用户需求的不同而有差异，例如，两个A分别以不同的媒体出现。

为实现这两种不同的软件配置，在实际工作中，我们完全可以将各个配置项分别开发出来，再根据需要，组合成针对不同用户使用要求的不同产品，正如图3所示。

2.软件配置管理(software configuration management)

(1)什么是软件配置管理

软件配置管理主要是对软件生存期过程中的各种阶段产品和最终产品演化和变更的管理，它是软件质量管理的重要组成部分。如果从变更的意义讲，软件配置管理要解决软件的变更标识、变更控制以及变更发布的问题。

(2)软件配置管理的任务

通常，软件配置管理的实施包括以下几个方面的任务： 制订软件配置管理计划;确定配置标识规则;实施变更控制;报告配置状态;进行配置审核;进行版本管理和发行管理。

3.软件配置管理的意义

(1)软件项目的特点

①软件产品是逻辑实体，是不可见的、抽象的智力产品。 ②软件项目的规模日益庞大和复杂。

③参与项目的人员数量增加，人员间的沟通渠道数量也倍增。若团组中人员数为n，则人员间存在着n*(n-1)/2个需要互相沟通的渠道。

④软件产品易于被拷贝。

⑤软件时时处在演化和变更状态。这包括：技术的快速发展;业务环境的不断演变;不同用户的不同需求;软件需求在开发中的频繁变更;开发人员对阶段产品的灵活、易变更等。

⑥开发人员的离去对项目有较大的影响。

(2)忽视软件配置管理可能导致的混乱现象

举例如下：发给用户的软件产品的用户手册是老版本;某个软件已开发完成，可是安装后就是不工作;在北京能正常工作的软件，到上海就出问题;上个月已解决的缺陷，现在又出现;公司内部发现个别程序员将自己开发的产品拿出去自己出售;最新修改的源程序找不到;上个月用户让做某个变更，这个月又不要了……

二、软件配置标识

软件配置标识是软件配置管理的基础性工作，是管理配置的前提。

1.确定配置项

大中型软件项目在开发过程中可能会产生数十个、上百个甚至上千个文档，其中许多是技术性的，也有不少是管理性的。技术性文档随着开发的进程，每个阶段都在演化，它们之间互相衔接，后期版本是对前期的修正和扩展，两者间具有继承关系;而管理性文档如计划书、报告书、建议书、备忘录等等，也有类似的变化和变更。

确定配置项就是要决定哪些文档需要被保存、被管理。

2.配置项命名及其相关信息

(1)配置项命名是配置标识的重要工作。所谓标识，其实质就是区分，在众多的配置项中合理、科学地命名是最为有效的区分方法。为配置项命名时切忌任意和随机。命名的基本要求是：

唯一性：在一个项目内不能出现重名，以避免混淆。

可追溯性：也是系统的要求，即名字应能体现相邻配置项之间的关系。

一个典型的实例是采用层次式命名规则来反映树状结构。例如CODE是根结点为PCL_TOOLS的树结构第六层结点，对其命名为：

PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE

三、变更管理

软件配置管理的一个重要任务是对变更加以有效的控制和管理。

1.软件变更 (1)软件变更的不可避免性

软件变更的来源有两个方面。一是用户，他们是软件项目需求的提出者。十分常见的现象是用户提出需求以后，软件开发过程中用户又改变需求，迫使开发工作返工，甚至丢弃一些无法修正的部分。用户不断变更需求，会造成一定的损失，但这又无法完全避免。我们只能尽力减少需求变更，降低它所造成的影响。(开发人员如何解决好自己的工作产品与变更了的用户需求之间的一致性，是CMM二级“需求管理”这个关键过程域的主要目标。)

另一方面来自于软件开发人员或者项目管理人员。开发过程中，开发人员发现前期工作中有些不妥当的地方，便要修改已经确定了的设计方案或设计细节。更有甚者，项目管理人员提出修订已经确定了的项目方案。

原则上说，提出变更的原因在于：随着工作的进展，用户和开发人员都将掌握更多的信息，对问题本身和设计方案有了更深入的认识，同时也发现原来的设想有不充分、不完善甚至不合理、不可行的成分。这时提出修正是完全合理的，是符合人们认识规律的。

软件变更出现的不可避免性决不意味着软件可以任意修改，也不能以此作为软件产品质量达不到要求的借口。毫无疑问，软件过程中变更管理的责任是重大的，能否解决好变更管理问题是成熟软件组织的一个衡量标志。

(2)软件变更的复杂性

软件在一处变更，可能要涉及一些相关部件和文档，需要将这一变更通知到受影响的相关人员。例如，测试引发了需求修改，很可能要涉及到需求规格说明、概要设计、详细设计和代码等相关文档，甚至会使测试计划随之变更。

(3)变更管理的任务

简单地说，变更管理就是控制修改，使之不出现改错、改乱的现象。变更管理的任务是：

分析变更：研究变更的必要性、经济可行性(成本-效益比，是否合算)和技术可行性(能否实现)。

记录和追踪变更。

采取措施保证变更在受授状态下进行。

2.配置库

配置库也称配置项库,是配置管理的有力工具。

(1)配置库的作用

①记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的的内容。

②利用库中的信息评价变更的后果，这对变更控制有重要的意义。

③从库中提取各种配置管理过程的管理信息，可利用库中的信息查询回答许多配置管理的问题，例如：

哪些客户已提取了某个特定的系统版本?

运行一个给定的系统版本需要什么硬件和系统软件?

一个系统到目前已生成了多少个版本，何时生成的? 如果某一特定的构件变更了，会影响到系统的哪些版本?

一个特定的版本曾提出过哪几个变更请求?

一个特定的版本有多少已报告的错误?

利用配置库实现配置管理是非常有效的。它可以把软件开发过程中的各种工作产品，包括半成品或阶段产品以及最终产品管理得井井有条，使其不致管乱、管混、管丢。一些可能出现的问题，正是要靠对配置库“入库检查”(check-in)和“检查出库”(check-out)加以解决，同时若配合访问权限的措施，就完全可以做到库内存放的产品什么人可以“看”，什么人可以“取”，什么人可以“改”，可以“存入”等等的控制。

(2)三类库

①开发库：存放开发过程中需要保留的各种信息，供开发人员个人专用。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其做任何限制，因为通常不会影响到项目的其它部分。

②受控库：在软件开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的以及人工可读的文档资料。应该对库内信息的读写和修改加以控制。

③产品库：所开发的软件产品完成系统测试后，作为最终产品存入库内。等待交付用户或现场安装。库内的信息也应加以控制。

作为配置管理的重要手段，上述受控库和产品库的规范化运行能够实现对软件配置项的管理。

3.配置基线

(1)基线是软件生存期各开发阶段末尾的特定点，也称为里程碑。在这些特定点上，阶段工作已结束，并且已经取得了正式的阶段产品。

建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被割开，从而更加有利于检验和肯定阶段工作的成果。同时也有利于变更控制。有了基线的规定后，就可以禁止跨越里程碑去修改另一开发阶段“已冻结”的工作成果。

作为阶段的正式产品，基线应该是稳定的，设计基线的规格说明应该是通过评审的。

(2)如果把软件看作是系统的一个组成部分，以下三种基线是最受人们关注的：

①功能基线：是指在系统分析和软件定义阶段结束时，经过正式评审和批准的系统设计规格说明中对被开发软件系统的规格说明：或是协议书或合同中所规定的对被开发软件系统的规格说明：或是项目任务书中所规定的对待开发软件系统的规格说明。

②分配基线：指在软件需求分析阶段结束时，经正式评审和批准的软件需求规格说明。

③产品基线：指软件组装与系统测试阶段结束时，经正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。

4.变更请求与变更控制

(1)利用配置库实现变更控制

一般情况下，处于开发状态中的软件配置项尚未稳定下来，并未受到配置管理的控制，开发人员的变更也并未受到限制。但当开发人员认为工作已告完成，可供其它配置项使用时，它就开始趋于稳定。把它交出评审，就开始进入评审状态，若通过评审作为基线将准许进入配置库(实施check-in),开始“冻结”，此时开发人员不允许对其任意修改，因为它已处于受控状态。通过评审表明，它确已达到质量要求，但若未能通过评审，则将其回归到工作状态，重新进行调整。我们可以通过图4看到上述配置项状态变化的过程。

处于受控状态下的配置项，原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出“变更请求”。在得到批准的情况下，允许配置项从库中检出(实施check-out),待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。此过程即为库管理。当然完全可以借助于工具实现库管理。

(2)变更请求

变更请求是实施变更控制的起始一步，也是必不可少的一步。最为常见的变更理由可能是清除缺陷、适应运行平台的变更，或是软件扩展提出的要求，例如增加功能、提高性能等。

四、配置审核

1.什么是配置审核

配置审核的任务是验证配置项对配置标识的一致性。软件开发的实践表明，尽管对配置项做了标识，实践了变更控制和版本控制，但如果不做检查或验证，仍然会出现混乱。这种验证包括：

对配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象。

配置标识的准则是否得到了遵循。

变更控制规程是否已遵循，变更记录是否可供使用。

在规格说明、软件产品和变更请求之间是否保持了可追溯性。

配置审核工作主要集中在两个方面，即：

功能配置审核：验证配置项的实际功能是否与其软件需求一致。

物理配置审核：确定配置项符合预期的物理特性。这里所说的物理特性是指特定的媒体形式。

2.为什么要实施配置审核

目标是为了确保软件配置管理的有效性，体现配置管理的最根本要求，不允许出现任何混乱现象。

3.如何实施配置审核

(1)实施配置审核的时机：通常为软件产品交付或是软件产品正式发行前;软件开发的阶段工作结束之后;在维护工作中，定期地进行。

(2)实施配置审核的责任人：包括项目组人员及非项目组人员，例如其它项目的配置管理人员，软件组织的内部审核员以及软件组织的软件配置管理人员。

(3)配置审核工作的开展

①由项目经理决定何时进行配置审核工作。

②质量保证组或软件组的配置管理组指定该项目的配置审核人员。

③项目经理和配置审核员决定审核范围。

④配置审核员准备配置审核检查单。

⑤配置审核员安排时间审核文档和记录，审核活动可能涉及到：

项目范围 配置项的入库及出库

评审记录 配置项的变更历史

测试记录 文件的命名

变更请求 版本的编号

⑥配置审核员在审核中发现不符合现象，并做记录。

⑦由项目经理负责消除不符合现象。

⑧配置审核员验证所有发现的不符合现象确已得到解决。

五、配置状态报告

配置状态报告也称配置状态说明与报告，是配置管理的一个组成部分，其任务是有效地记录和报告管理配置所需要的信息。目的是及时、准确地给出软件配置的当前状况，供相关人员了解，以加强配置管理工作。

需要跟踪捕捉的状态报告信息有：配置项的当前标识、已交付软件的配置、变更请求或问题报告的状态、已获准变更的状态。

在软件工程过程中，我们必须注意到它的动态特性。事实上，过程中所有的软件配置项都在不停地演化着，如果没有相应的控制手段，其后果不可想像。配置状态报告就是要在某个特定的时刻观察当时的配置状态，也就是在动态演化着的配置项取个瞬时的“照片”，以便于在分析状态报告信息的基础上更好地进行控制。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号