软件配置管理

软件配置管理第一页，共三十八页，编辑于2023年，星期一17.1软件配置管理的任务随着软件工程过程的进展，软件配置项(SCI，SoftwareConfigurationItems)的层次、数量迅速增加。考虑到因为市场原因、客户原因、组织原因和预算与进度原因的影响，软件工程过程随时都可能发生变化。这就不可避免地会影响到配置项发生变化。SCM的任务就是在计算机软件的整个生命周期内管理变化。我们可以将SCM看作是应用于整个软件过程的一类质量保证活动。17.1.1基线变化是软件开发过程中必然发生的事情。客户要变更需求，开发者希望修改技术方法，管理者要调整预算等等第二页，共三十八页，编辑于2023年，星期一都属于合理的变化要求。遗憾的是如果完全随意地进行变化的话，软件工程将变成一场灾难。变化不可避免，变化必须得到管理，已经成为业界的共识。引入基线的概念，正是为了实现对变化的管理。

基线(BaseLine)的原意是棒球场的边线，在软件工程中将其引申成为软件配置管理中的一个专用名词。基线用来在不对合理变化造成严重阻碍的前提下控制变化。IEEE组织对于基线的定义是：“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。这里的规约(Specification)可以解释为“详细说明”或“规格说明”。第三页，共三十八页，编辑于2023年，星期一根据这个定义，可以认为基线是一组已经经过正式技术复审而被认可、发布并且可供使用，只能遵循一定规程进行变化的软件工作产品。SCI被纳入基线之前，生产者可以为了顺应某种要求，对其进行迅速而非正式的变更，但是如果该项已经纳入基线，那么针对它的每一个变化，必须按照特定的、正式的规程进行评估、实施、验证和发布。虽然基线可以在任意的细节层次上定义，但为了避免过于繁琐，最常见的软件基线如图17.1所示。第四页，共三十八页，编辑于2023年，星期一图17.1基线第五页，共三十八页，编辑于2023年，星期一

在软件工程的范围内，基线是软件开发过程中的里程碑，其标志是有一个或多个软件配置项(SCI)的交付。而且这些配置项已经经过正式技术复审并获得认可。例如：某设计规约的要素已经形成文档并通过复审，错误已被发现并且得到了纠正。一旦规约的所有部分均通过复审、纠正，然后认可，则该设计规约就变成了一个基线。此后任何对包含在此设计规约中的程序体系结构的变化都只能在被评估并得到批准之后方可进行。产生基线的事件进展如图17.2所示。

第六页，共三十八页，编辑于2023年，星期一图17.2作为基线的SCI和项目的配置数据库第七页，共三十八页，编辑于2023年，星期一

软件工程产生一个或多个SCI，在SCI被复审并得到认可后，它们被放进项目的配置管理数据库中。当软件工程项目组中的某个成员希望修改某个基线SCI时，该SCI被从项目的配置管理数据库拷贝到工程师的私有工作区中，然而，这个提取出来的SCI只有在遵循SCM控制的情况下才可以被修改。图17.2中的虚线说明了对某一个SCI进行修改的事件路径。

第八页，共三十八页，编辑于2023年，星期一

软件财富基线主要包括各类可复用的软件构件。对这些构件进行标识、维护、管理，提供给所有需要重用它们的项目组，无疑将会极大地提高生产率，改进未来产品的质量并提供更多可供选择的解决方案和设计方案。项目中形成的可复用构件，应当及时纳入财富基线，尽快发挥它们的作用，扩大财富的积累。17.1.2软件配置项软件配置项已经定义为在部分软件工程过程中创建的信息。一般地说，一个SCI可以是一个文档、一套测试用例或者一个已经命名的程序构件。下面的SCI成为配置管理技术的目标并形成一组基线。第九页，共三十八页，编辑于2023年，星期一1：系统规约2：软件项目计划3：软件需求规约a:图形分析模型b:处理规约c:原型d:数学规约4：初步的设计手册5：设计规约a:数据设计描述b:体系结构设计描述c:模块设计描述d:界面设计描述e:对象描述(如果采用了面向对象技术)第十页，共三十八页，编辑于2023年，星期一6：源代码清单7：测试规约a:测试计划和过程b:测试用例和结果记录8：操作和安装手册9：可执行程序a:模块的可执行代码b:链接的模块10：数据库描述a:模式和文件结构b:初始内容11：联机用户手册12：维护文档a:软件问题报告b:维护请求c:工程变化命令13：软件工程的标准和规程第十一页，共三十八页，编辑于2023年，星期一

除此之外，为了清晰地描述开发环境，许多软件开发组织也将使用的工具和开发环境内容纳入配置管理库中。工具，就像利用它们生产的产品一样，可以被基线化，并作为综合配置管理工作的一部分，一般称之为“环境基线”。SCI被组织成配置对象、被命名并被归类到项目的配置管理数据库中。一个配置对象有名字、属性，并通过“关系”和其他的对象连接。第十二页，共三十八页，编辑于2023年，星期一图17.3配置对象在图17.3中，配置对象“设计规约、“测试规约”、“数据模块”、“模块N”、“源代码”分别被定义。但每个对象都和其他对象存在着一定的关联。曲线表示的关系是组装关系，说明数据模块和模块N都是设计规约的组成部分。直线双箭头连接指明关联关系。如果一个对象(比如源代码对象)发生变化，关联关系使得软件工程师能够据此判定还有哪些对象会被影响。第十三页，共三十八页，编辑于2023年，星期一17.2SCM过程

软件配置管理过程是软件工程中的重要环节，它的直接目标是管理变更。在管理过程中，配置管理活动还要关注个体SCI的标识和软件产品的版本控制，负责软件配置库的审核和配置变更情况并及时提出配置变更报告。概括地说，SCM过程的任务主要有下面五项。

(1)组织如何标识和管理程序及文档的很多现存版本，以保证能够高效率地进行必要的变更。(2)如何在软件发布之前和之后控制变更。(3)明确由什么角色负责批准变更，并给变更确定优先级别。(4)如何保证变更已经被恰当地执行。(5)采用什么机制去告诉相关人员目前已经发生的变更。

第十四页，共三十八页，编辑于2023年，星期一简单地说，SCM任务是标识配置项、控制产品版本、控制变化、配置审计和发布配置报告。在软件能力成熟度模型中，将配置管理作为达到二级成熟度的一个关键活动域，提出了四项必须达到的目标。

目标1：软件配置管理活动是有计划的。目标2：所选定的软件工作产品是已标识的、受控的和适用的。目标3：对已标识的软件工作产品的更改是受控的。目标4：受影响的组和个人得到软件基线的状态和内容的通知。

第十五页，共三十八页，编辑于2023年，星期一17.3软件配置中对象的标识

为了控制和管理软件配置项，每一个配置项必须被独立命名，然后用面向对象的方法加以组织。对象命名是为了能够根据名称提取对象；而通过组织对象并描述其间的关系则是着眼于在对象变更时能够清楚地了解变更的影响范围。能够被标识的对象分为基本对象和聚集对象两大类。基本对象是软件工程师在工作中创建的诸如需求规约的一个段落、一组测试用例、模块的源代码清单之类的“文本单元”(unitoftext)。而一个聚集对象是基本对象和其他聚集对象的集合，是一个递归的概念。例如图17.3中的“设计规约”。在概念上，聚集对象可以被认为是已经被标识命名的“指针表”。指针指向基本对象“模块N”和“数据模块”。第十六页，共三十八页，编辑于2023年，星期一

配置对象具有一组惟一标识它的特征数据：(对象名、描述、资源表、实体)。各项特征的含义如下：

(1)对象名：无二义的表示对象的一个字符串。(2)描述：一组数据项的列表，具体标识：该对象所表示的SCI类型；项目标识符、变更信息和(或)版本信息。(3)资源：由对象提供、处理、引用或需要的实体，如数据类型、特定的函数、变量名称等等。(4)实体：是一个指针。对于基本对象，它指向特定的“文本单元”；对于聚合对象，它指向null。第十七页，共三十八页，编辑于2023年，星期一在标识配置对象时，应当能够反映它们之间的关系。通过制定命名规则，一个对象可以被标识为某个聚集对象的局部(part-of...)。(part-of...)定义了一个对象层次，例如：E-Rdigram1.4(part-of)datamodeldatamodel(part-of)DesignSpecification使用这样的对象标识方法，能够创建SCI之间的层次结构。实际上，在层次结构中也存在有交叉关连(interrelated)关系：datamodel(interrelated)dataflowmodel(数据模块和数据流程图关联)datamodel(interrelated)testcaseclassm(数据模块和测试用例类m之间关联)第十八页，共三十八页，编辑于2023年，星期一对于配置项的标识，除了上面的基本原则必须满足之外，各个软件开发组织也可制定自己的配置项标识规范。例如，某组织的配置项标识方法规定：配置项标识：要求对每一配置项进行惟一性标识。命名规范：1位基线库编码+“_”+2位配置对象编码+“_”+最多五个汉字或10个英文/拼音的配置项标识(一般为功能/模块名称，但要求有易懂且惟一)+‘_’+5位版本号(最多5位——q.m.n)一个对象在被纳入基线之前，它可能变化了许多次。在被纳入基线之后，也允许继续发生受控的变化。对象的标识必须能够反映对象在整个软件过程中的演化情况。对象演化图能够满足这一要求，直观地反映对象的演化过程和演化路径。第十九页，共三十八页，编辑于2023年，星期一

图17.4中，反映出对象1.0经历了四次一般变化，演化出对象1.1、1.2、1.3、1.4；演化对象1.1经历了两次小的变化，演化出对象1.1.1和1.1.2；对象1.2经历了一次大的变化，形成了对象2.0；对象2.0发生一般变化后，形成对象2.1对象的变化有可能针对它当前存在的任意版本，但一般不会针对所有版本。经过恰当的标识使得对象被选中进行变化时，可以借助于标识符的引导找到本对象及其相关联的所有对象，实施联带变化，保证配置管理数据库的完整性。目前许多用于SCM的自动工具已经被开发出来，提高了配置管理的工作效率和准确程度。第二十页，共三十八页，编辑于2023年，星期一图17.4配置对象演化图第二十一页，共三十八页，编辑于2023年，星期一17.4版本控制

为适应不同的环境特点和用户的个性化需求，同一个软件可能会推出不同的版本。为方便用户的使用，软件的若干功能可以是“可选件”，即使同一版本的软件，选件的不同也将导致它们成为同一版本的不同“变体”。如何利用配置项装配成不同版本的产品进行产品发布，也是SCM工作必须完成的任务。如果图17.4中的每个节点都是包括软件所有组成部分的聚集对象，那么，每个对象节点也就代表了软件的一个版本(一组SCI的集合，包括源代码、文档、数据、可执行程序)。每个版本可以由许多不同的变体(Variant)组成。这第二十二页，共三十八页，编辑于2023年，星期一种情况在我们使用工具软件时也经常会遇到。比如在工具软件的安装过程中我们可以进行裁剪，得到同一版本软件的不同变体。图17.5软件版本变化及其变体第二十三页，共三十八页，编辑于2023年，星期一图17.5是实现变体的示意图。对版本2.1来说，可以定义由构件(1、2、3、4)和构件(1、2、3、5)构成的相同版本的两种变体。当软件使用彩色显示器实现时选择使用构件4，构件5只在使用单色显示器时才被选中。为了构造某程序的给定版本的适当变体，可以为每一个构件赋予一个“属性元组”，即构件特征表。当要构造某软件版本的特殊变体时，只要规定了应当使用具有什么特征属性的构件，就能够很方便地完成构件的选择和组装。目前已经有许多不同的、能够自动进行版本控制的方法与工具，并得到了广泛的使用。使用这样的SCM工具，第二十四页，共三十八页，编辑于2023年，星期一能够进行增量式的版本生成与管理，能够根据当前版本对早期版本进行追溯，同时具有基线管理能力，完全排除了对特定版本进行无控制修改、删除的可能性。第二十五页，共三十八页，编辑于2023年，星期一17.5变更控制

软件工程活动中，变更不可避免，重要的是对变更进行管理。无控制的变化将迅速地导致过程的混乱。合理的组织保证，人为的规程限制和自动化的工具相结合，能够实现良好的变更控制机制。变更控制过程流程如图17.6所示，当修改(变更)请求被提出后，首先要从技术指标，潜在的副作用，对其他配置对象和系统功能的整体影响和变更成本几方面评估变更的可行性。评估结果形成变更报告。该报告交由变更控制审核小组(CCA，ChangeControlAuthority)使用。第二十六页，共三十八页，编辑于2023年，星期一

CCA针对被批准的变更生成一个工程变更命令(ECO，EngineeringChangeOrder)。ECO描述将要进行的变更，必须注意的约束，复审和审核的标准。然后，接到ECO的技术人员将指定要被修改的对象从项目配置管理数据库中提取出来(CheckOut)，进行修改，并进行必要的SQA活动和测试活动。接着，将改定的对象提交(CheckIn)回项目配置管理数据库。最后使用合适的版本控制机制去建立软件的下一个版本。第二十七页，共三十八页，编辑于2023年，星期一图17.6变更控制的过程第二十八页，共三十八页，编辑于2023年，星期一

“提取”和“提交”过程实现了两个主要的变更控制因素。“提取”实现了对配置项的“访问控制”，限制了只有被指定的工程师才有权获得和修改特定的配置对象，在对象被提取后自动“加锁”；“提交”提供了一种“同步控制”。特定的配置项一旦被授权人提取进行修改，在修改完毕提交回配置库之前，由于已经加锁，其他人只能够进行浏览性提取，无权进行修改。修改者执行了提交操作后，配置库中原被锁定的修改对象将被更新并被“解锁”。在变更管理流程中，CCA的作用十分重要。他们要从全局的观点来评估变更对SCI之外的事物的影响，包括变更是第二十九页，共三十八页，编辑于2023年，星期一否会影响硬件，如何影响性能，如何影响软件的质量和可靠性等等。最终CCA将根据变更评估的结果就是否实行变更进行决策，并具体安排变更的实施。

第三十页，共三十八页，编辑于2023年，星期一17.6配置审核与状态报告17.6.1配置审核

SCM通过配置项标识、版本控制和变更控制措施，保障了软件工程过程中的工作秩序。对于变更工作，必须通过正式的技术复审和软件配置审核工作来验证被核准进行变更的对象是否进行了必要的、正确的变更，并得到了重新的配置。对变更结果进行的正式复审由技术工程师们进行。它关注的是被修改的配置对象在技术上的正确性。复审者们要评估SCI以确定它和其他SCI的一致性，关注是否有潜在的副作用等问题。第三十一页，共三十八页，编辑于2023年，星期一

作为对变更进行的正式复审的补充，SQA人员还要针对和变更管理相关的SCM工作进行审核。作为正式技术复审的补充环节，这种审核主要关注下列几方面的问题：

(1)ECO中提出的变更是否已经完成，有无进行未经指定的其他附加变更。(2)针对变更工作的技术正确性，是否已经进行了正式的技术复审。(3)变更工作是否遵循了软件工程标准。(4)检查是否针对被变更的SCI进行了强调说明。被变更的SCI的属性是否反映了本次变更，是否记录了变更日期和变更实施者等必要信息。(5)是否遵循了标注变更、记录变更和报告变更的SCM工作规程。(6)所有相关的SCI是否都得到了恰当的修改。第三十二页，共三十八页，编辑于2023年，星期一17.6.2配置状态报告建立并发布配置状态报告(CSR，ConfigurationStatusReporting)是SCM的任务之一。CSR应当说明：配置库发生了什么事情，该事是谁做的，是什么时候发生的，将会造成哪些影响。每当一个SCI被赋予新的或修改后的标识时，就有一个CSR的条目被创建；每当下达一个ECO时，也有一个CSR条目被创建。在每次进行配置审核时，审核的结果也作为CSR的一部分被报告。应当定期地生成配置状态报告并向所有相关人员发布。保证大家始终能够清楚地了解配置管理库的现状和配置管理工作的进展。在大型项目中，离开了配置状态报告有可能导致状态混乱。例如，两个开发者可能试图以不同的或者互相冲突第三十三页，共三十八页，编辑于2023年，星期一的意图去修改一个配置对象；不了解未来的软件运行环境已经发生了变更的工程师们可能还在针对已经不再存在的环境开发软件。有了真实、及时的配置状态报告，就能够防患于未然。第三十四页，共三十八页，编辑于2023年，星期一17.7小结

SCM活动是应用于软件工程全过程中的一种保护性活动。SCM标识、控制、审核和报告在软件开发过程