第17章软件配置管理.ppt

《第17章软件配置管理.ppt》由会员分享，可在线阅读，更多相关《第17章软件配置管理.ppt（38页珍藏版）》请在三一文库上搜索。

1、第17章 软件配置管理,17.1 软件配置管理的任务 17.2 SCM过程 17.3 软件配置中对象的标识 17.4 版本控制 17.5 变更控制 17.6 配置审核与状态报告 17.7 小结,17.1 软件配置管理的任务,随着软件工程过程的进展，软件配置项(SCI，Software Configuration Items)的层次、数量迅速增加。考虑到因为市场原因、客户原因、组织原因和预算与进度原因的影响，软件工程过程随时都可能发生变化。这就不可避免地会影响到配置项发生变化。SCM的任务就是在计算机软件的整个生命周期内管理变化。我们可以将SCM看作是应用于整个软件过程的一类质量保证活动。 17

2、.1.1 基线 变化是软件开发过程中必然发生的事情。客户要变更需求，开发者希望修改技术方法，管理者要调整预算等等,都属于合理的变化要求。遗憾的是如果完全随意地进行变化的话，软件工程将变成一场灾难。变化不可避免，变化必须得到管理，已经成为业界的共识。引入基线的概念，正是为了实现对变化的管理。 基线(Base Line)的原意是棒球场的边线，在软件工程中将其引申成为软件配置管理中的一个专用名词。基线用来在不对合理变化造成严重阻碍的前提下控制变化。IEEE组织对于基线的定义是：“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。这里的规约

3、(Specification)可以解释为“详细说明”或“规格说明”。,根据这个定义，可以认为基线是一组已经经过正式技术复审而被认可、发布并且可供使用，只能遵循一定规程进行变化的软件工作产品。SCI被纳入基线之前，生产者可以为了顺应某种要求，对其进行迅速而非正式的变更，但是如果该项已经纳入基线，那么针对它的每一个变化，必须按照特定的、正式的规程进行评估、实施、验证和发布。虽然基线可以在任意的细节层次上定义，但为了避免过于繁琐，最常见的软件基线如图17.1所示。,图17.1 基线,在软件工程的范围内，基线是软件开发过程中的里程碑，其标志是有一个或多个软件配置项(SCI)的交付。而且这些配置项已经经

4、过正式技术复审并获得认可。 例如：某设计规约的要素已经形成文档并通过复审，错误已被发现并且得到了纠正。一旦规约的所有部分均通过复审、纠正，然后认可，则该设计规约就变成了一个基线。此后任何对包含在此设计规约中的程序体系结构的变化都只能在被评估并得到批准之后方可进行。 产生基线的事件进展如图17.2所示。,图17.2 作为基线的SCI和项目的配置数据库,软件工程产生一个或多个SCI，在SCI被复审并得到认可后，它们被放进项目的配置管理数据库中。当软件工程项目组中的某个成员希望修改某个基线SCI时，该SCI被从项目的配置管理数据库拷贝到工程师的私有工作区中，然而，这个提取出来的SCI只有在遵循SCM

5、控制的情况下才可以被修改。图17.2中的虚线说明了对某一个SCI进行修改的事件路径。,软件财富基线主要包括各类可复用的软件构件。对这些构件进行标识、维护、管理，提供给所有需要重用它们的项目组，无疑将会极大地提高生产率，改进未来产品的质量并提供更多可供选择的解决方案和设计方案。项目中形成的可复用构件，应当及时纳入财富基线，尽快发挥它们的作用，扩大财富的积累。 17.1.2 软件配置项 软件配置项已经定义为在部分软件工程过程中创建的信息。一般地说，一个SCI可以是一个文档、一套测试用例或者一个已经命名的程序构件。 下面的SCI成为配置管理技术的目标并形成一组基线。,1：系统规约 2：软件项目计划

6、3：软件需求规约 a:图形分析模型 b:处理规约 c:原型 d:数学规约 4：初步的设计手册 5：设计规约 a:数据设计描述 b:体系结构设计描述 c:模块设计描述 d:界面设计描述 e:对象描述(如果采用了面向对象技术),6：源代码清单 7：测试规约 a: 测试计划和过程 b: 测试用例和结果记录 8：操作和安装手册 9：可执行程序 a: 模块的可执行代码 b: 链接的模块 10：数据库描述 a: 模式和文件结构 b: 初始内容 11：联机用户手册 12：维护文档 a: 软件问题报告 b: 维护请求 c: 工程变化命令 13：软件工程的标准和规程,除此之外，为了清晰地描述开发环境，许多软件开

7、发组织也将使用的工具和开发环境内容纳入配置管理库中。工具，就像利用它们生产的产品一样，可以被基线化，并作为综合配置管理工作的一部分，一般称之为“环境基线”。 SCI被组织成配置对象、被命名并被归类到项目的配置管理数据库中。一个配置对象有名字、属性，并通过“关系”和其他的对象连接。,图17.3 配置对象,在图17.3中，配置对象“设计规约、“测试规约”、“数据模块”、“模块N”、“源代码”分别被定义。但每个对象都和其他对象存在着一定的关联。曲线表示的关系是组装关系，说明数据模块和模块N都是设计规约的组成部分。直线双箭头连接指明关联关系。如果一个对象(比如源代码对象)发生变化，关联关系使得软件工程

8、师能够据此判定还有哪些对象会被影响。,17.2 SCM 过 程,软件配置管理过程是软件工程中的重要环节，它的直接目标是管理变更。在管理过程中，配置管理活动还要关注个体SCI的标识和软件产品的版本控制，负责软件配置库的审核和配置变更情况并及时提出配置变更报告。概括地说，SCM过程的任务主要有下面五项。 (1) 组织如何标识和管理程序及文档的很多现存版本，以保证能够高效率地进行必要的变更。 (2) 如何在软件发布之前和之后控制变更。 (3) 明确由什么角色负责批准变更，并给变更确定优先级别。 (4) 如何保证变更已经被恰当地执行。 (5) 采用什么机制去告诉相关人员目前已经发生的变更。,简单地说，

9、SCM任务是标识配置项、控制产品版本、控制变化、配置审计和发布配置报告。在软件能力成熟度模型中，将配置管理作为达到二级成熟度的一个关键活动域，提出了四项必须达到的目标。 目标1：软件配置管理活动是有计划的。 目标2：所选定的软件工作产品是已标识的、受控的和适用的。 目标3：对已标识的软件工作产品的更改是受控的。 目标4：受影响的组和个人得到软件基线的状态和内容的通知。,17.3 软件配置中对象的标识,为了控制和管理软件配置项，每一个配置项必须被独立命名，然后用面向对象的方法加以组织。对象命名是为了能够根据名称提取对象；而通过组织对象并描述其间的关系则是着眼于在对象变更时能够清楚地了解变更的影响

10、范围。 能够被标识的对象分为基本对象和聚集对象两大类。基本对象是软件工程师在工作中创建的诸如需求规约的一个段落、一组测试用例、模块的源代码清单之类的“文本单元”(unit of text)。而一个聚集对象是基本对象和其他聚集对象的集合，是一个递归的概念。例如图17.3中的“设计规约”。在概念上，聚集对象可以被认为是已经被标识命名的“指针表”。指针指向基本对象“模块N”和“数据模块”。,配置对象具有一组惟一标识它的特征数据： (对象名、描述、资源表、实体)。 各项特征的含义如下： (1) 对象名：无二义的表示对象的一个字符串。 (2) 描述：一组数据项的列表，具体标识： 该对象所表示的SCI类型

11、； 项目标识符、变更信息和(或)版本信息。 (3) 资源：由对象提供、处理、引用或需要的实体，如数据类型、特定的函数、变量名称等等。 (4) 实体：是一个指针。对于基本对象，它指向特定的“文本单元”；对于聚合对象，它指向null。,在标识配置对象时，应当能够反映它们之间的关系。通过制定命名规则，一个对象可以被标识为某个聚集对象的局部(part-of .)。(part-of .)定义了一个对象层次，例如： E-R digram1.4 (part-of)data model data model (part-of)Design Specification 使用这样的对象标识方法，能够创建SCI之间

12、的层次结构。实际上，在层次结构中也存在有交叉关连(interrelated)关系： data model (interrelated)data flow model (数据模块和数据流程图关联) data model (interrelated)test case class m (数据模块和测试用例类m之间关联),对于配置项的标识，除了上面的基本原则必须满足之外，各个软件开发组织也可制定自己的配置项标识规范。例如，某组织的配置项标识方法规定： 配置项标识：要求对每一配置项进行惟一性标识。 命名规范： 1位基线库编码+“_”+2位配置对象编码+“_”+最多五个汉字或10个英文/拼音的配置项标识

13、(一般为功能/模块名称，但要求有易懂且惟一)+_+5位版本号(最多5位q.m.n)一个对象在被纳入基线之前，它可能变化了许多次。在被纳入基线之后，也允许继续发生受控的变化。对象的标识必须能够反映对象在整个软件过程中的演化情况。对象演化图能够满足这一要求，直观地反映对象的演化过程和演化路径。,图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 对象的变化有可能针对它当前存在的任意版本，但一般不会针对所

14、有版本。经过恰当的标识使得对象被选中进行变化时，可以借助于标识符的引导找到本对象及其相关联的所有对象，实施联带变化，保证配置管理数据库的完整性。 目前许多用于SCM的自动工具已经被开发出来，提高了配置管理的工作效率和准确程度。,图17.4 配置对象演化图,17.4 版 本 控 制,为适应不同的环境特点和用户的个性化需求，同一个软件可能会推出不同的版本。为方便用户的使用，软件的若干功能可以是“可选件”，即使同一版本的软件，选件的不同也将导致它们成为同一版本的不同“变体”。如何利用配置项装配成不同版本的产品进行产品发布，也是SCM工作必须完成的任务。 如果图17.4中的每个节点都是包括软件所有组成

15、部分的聚集对象，那么，每个对象节点也就代表了软件的一个版本(一组SCI的集合，包括源代码、文档、数据、可执行程序)。每个版本可以由许多不同的变体(Variant)组成。这,种情况在我们使用工具软件时也经常会遇到。比如在工具软件的安装过程中我们可以进行裁剪，得到同一版本软件的不同变体。,图17.5 软件版本变化及其变体,图17.5是实现变体的示意图。对版本2.1来说，可以定义由构件(1、2、3、4)和构件(1、2、3、5)构成的相同版本的两种变体。当软件使用彩色显示器实现时选择使用构件4，构件5只在使用单色显示器时才被选中。 为了构造某程序的给定版本的适当变体，可以为每一个构件赋予一个“属性元组

16、”，即构件特征表。当要构造某软件版本的特殊变体时，只要规定了应当使用具有什么特征属性的构件，就能够很方便地完成构件的选择和组装。 目前已经有许多不同的、能够自动进行版本控制的方法与工具，并得到了广泛的使用。使用这样的SCM工具，,能够进行增量式的版本生成与管理，能够根据当前版本对早期版本进行追溯，同时具有基线管理能力，完全排除了对特定版本进行无控制修改、删除的可能性。,17.5 变 更 控 制,软件工程活动中，变更不可避免，重要的是对变更进行管理。无控制的变化将迅速地导致过程的混乱。合理的组织保证，人为的规程限制和自动化的工具相结合，能够实现良好的变更控制机制。 变更控制过程流程如图17.6所

17、示，当修改(变更)请求被提出后，首先要从技术指标，潜在的副作用，对其他配置对象和系统功能的整体影响和变更成本几方面评估变更的可行性。评估结果形成变更报告。该报告交由变更控制审核小组(CCA，Change Control Authority)使用。,CCA针对被批准的变更生成一个工程变更命令(ECO，Engineering Change Order)。ECO描述将要进行的变更，必须注意的约束，复审和审核的标准。然后，接到ECO的技术人员将指定要被修改的对象从项目配置管理数据库中提取出来(Check Out)，进行修改，并进行必要的SQA活动和测试活动。接着，将改定的对象提交(Check In )

18、回项目配置管理数据库。最后使用合适的版本控制机制去建立软件的下一个版本。,图17.6 变更控制的过程,“提取”和“提交”过程实现了两个主要的变更控制因素。“提取”实现了对配置项的“访问控制”，限制了只有被指定的工程师才有权获得和修改特定的配置对象，在对象被提取后自动“加锁”；“提交”提供了一种“同步控制”。特定的配置项一旦被授权人提取进行修改，在修改完毕提交回配置库之前，由于已经加锁，其他人只能够进行浏览性提取，无权进行修改。修改者执行了提交操作后，配置库中原被锁定的修改对象将被更新并被“解锁”。 在变更管理流程中，CCA的作用十分重要。他们要从全局的观点来评估变更对SCI之外的事物的影响，包

19、括变更是,否会影响硬件，如何影响性能，如何影响软件的质量和可靠性等等。最终CCA将根据变更评估的结果就是否实行变更进行决策，并具体安排变更的实施。,17.6 配置审核与状态报告,17.6.1 配置审核 SCM通过配置项标识、版本控制和变更控制措施，保障了软件工程过程中的工作秩序。对于变更工作，必须通过正式的技术复审和软件配置审核工作来验证被核准进行变更的对象是否进行了必要的、正确的变更，并得到了重新的配置。 对变更结果进行的正式复审由技术工程师们进行。它关注的是被修改的配置对象在技术上的正确性。复审者们要评估SCI以确定它和其他SCI的一致性，关注是否有潜在的副作用等问题。,作为对变更进行的正

20、式复审的补充，SQA人员还要针对和变更管理相关的SCM工作进行审核。作为正式技术复审的补充环节，这种审核主要关注下列几方面的问题： (1) ECO中提出的变更是否已经完成，有无进行未经指定的其他附加变更。 (2) 针对变更工作的技术正确性，是否已经进行了正式的技术复审。 (3) 变更工作是否遵循了软件工程标准。 (4) 检查是否针对被变更的SCI进行了强调说明。被变更的SCI的属性是否反映了本次变更，是否记录了变更日期和变更实施者等必要信息。 (5) 是否遵循了标注变更、记录变更和报告变更的SCM工作规程。 (6) 所有相关的SCI是否都得到了恰当的修改。,17.6.2 配置状态报告 建立并发

21、布配置状态报告(CSR，Configuration Status Reporting)是SCM的任务之一。 CSR应当说明：配置库发生了什么事情，该事是谁做的，是什么时候发生的，将会造成哪些影响。 每当一个SCI被赋予新的或修改后的标识时，就有一个CSR的条目被创建；每当下达一个ECO时，也有一个CSR条目被创建。在每次进行配置审核时，审核的结果也作为CSR的一部分被报告。应当定期地生成配置状态报告并向所有相关人员发布。保证大家始终能够清楚地了解配置管理库的现状和配置管理工作的进展。 在大型项目中，离开了配置状态报告有可能导致状态混乱。例如，两个开发者可能试图以不同的或者互相冲突,的意图去修改

22、一个配置对象；不了解未来的软件运行环境已经发生了变更的工程师们可能还在针对已经不再存在的环境开发软件。有了真实、及时的配置状态报告，就能够防患于未然。,17.7 小 结,SCM活动是应用于软件工程全过程中的一种保护性活动。SCM标识、控制、审核和报告在软件开发过程中及软件发布给客户后所发生的变更与修改。所有作为软件过程的一部分而产生的信息都将成为软件配置的一部分。配置项被适当地进行组织，以便实现有序的变更控制。 软件配置由一组相关联的对象组成，也称为“软件配置项”。除了在工程中产生的文档、程序和数据之外，用于开发软件的指令、合同、环境、工具信息一般也被置于配置管理之下，一般被称为“初始配置”或

23、“环境配置”。,一旦某产品开发完成并通过了复审，就可以纳入基线，受到控制，成为被标识的配置项。对基线对象的修改将导致建立该对象的新版本。通过对所有配置对象的修改历史进行跟踪，能够勾画出整个软件的演化过程，并根据需要进行版本控制。 SCM的重要任务就是变更控制。利用严格的变更控制机制，能够在对配置项进行核准的变更时保证产品的整体质量和相关配置项之间的一致性。,最后应当强调，SCM服务于项目，但它的作用并不是单一地为项目服务。为保证软件开发组织的可持续发展，SCM工作关注的另一个重要侧面就是软件过程财富库的建立与使用。可复用构件的标识与维护，度量数据的收集，度量数据归类并纳入度量基线等等都是SCM

24、的重要职责。考虑到这种现实，除了在项目组中设置专职或兼职的SCM工程师之外，最好能够建立专业的SCM小组，以便于实施更大范围的SCM活动。,作业： 1、SCM活动属于什么性质的活动？它的主要目标是什么？ 2、解释“基线”的概念。作为项目主管，你希望在工作中建立什么样的基线？ 3、SCM审核和正式的技术复审在侧重点上有什么不同？ 4、你认为开发组织的历史度量数据是否应当作为“过程基线”的内容纳入配置管理的范畴？ 5、作为开发组织的管理者，请你选择在建立配置管理数据库时，是全组织建立一个配置管理数据库还是各个项目分别建立自己的配置管理数据库更为恰当？ 6、描述一下SCM活动中的“变更控制流程”，CAA在变更控制活动中起到什么样的作用？,