第7章软件配置管理.pptxVIP

17.1 软件配置管理的任务 随着软件工程过程的进展，软件配置项(SCI，Software Configuration Items)的层次、数量迅速增加。考虑到因为市场原因、客户原因、组织原因和预算与进度原因的影响，软件工程过程随时都可能发生变化。这就不可避免地会影响到配置项发生变化。SCM的任务就是在计算机软件的整个生命周期内管理变化。我们可以将SCM看作是应用于整个软件过程的一类质量保证活动。 17.1.1 基线 变化是软件开发过程中必然发生的事情。客户要变更需求，开发者希望修改技术方法，管理者要调整预算等等都属于合理的变化要求。遗憾的是如果完全随意地进行变化的话，软件工程将变成一场灾难。变化不可避免，变化必须得到管理，已经成为业界的共识。引入基线的概念，正是为了实现对变化的管理。 基线(Base Line)的原意是棒球场的边线，在软件工程中将其引申成为软件配置管理中的一个专用名词。基线用来在不对合理变化造成严重阻碍的前提下控制变化。IEEE组织对于基线的定义是：“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。这里的规约(Specification)可以解释为“详细说明”或“规格说明”。 根据这个定义，可以认为基线是一组已经经过正式技术复审而被认可、发布并且可供使用，只能遵循一定规程进行变化的软件工作产品。SCI被纳入基线之前，生产者可以为了顺应某种要求，对其进行迅速而非正式的变更，但是如果该项已经纳入基线，那么针对它的每一个变化，必须按照特定的、正式的规程进行评估、实施、验证和发布。虽然基线可以在任意的细节层次上定义，但为了避免过于繁琐，最常见的软件基线如图17.1所示。图17.1 基线 在软件工程的范围内，基线是软件开发过程中的里程碑，其标志是有一个或多个软件配置项(SCI)的交付。而且这些配置项已经经过正式技术复审并获得认可。 例如：某设计规约的要素已经形成文档并通过复审，错误已被发现并且得到了纠正。一旦规约的所有部分均通过复审、纠正，然后认可，则该设计规约就变成了一个基线。此后任何对包含在此设计规约中的程序体系结构的变化都只能在被评估并得到批准之后方可进行。 产生基线的事件进展如图17.2所示。 图17.2 作为基线的SCI和项目的配置数据库 软件工程产生一个或多个SCI，在SCI被复审并得到认可后，它们被放进项目的配置管理数据库中。当软件工程项目组中的某个成员希望修改某个基线SCI时，该SCI被从项目的配置管理数据库拷贝到工程师的私有工作区中，然而，这个提取出来的SCI只有在遵循SCM控制的情况下才可以被修改。图17.2中的虚线说明了对某一个SCI进行修改的事件路径。 软件财富基线主要包括各类可复用的软件构件。对这些构件进行标识、维护、管理，提供给所有需要重用它们的项目组，无疑将会极大地提高生产率，改进未来产品的质量并提供更多可供选择的解决方案和设计方案。项目中形成的可复用构件，应当及时纳入财富基线，尽快发挥它们的作用，扩大财富的积累。17.1.2 软件配置项 软件配置项已经定义为在部分软件工程过程中创建的信息。一般地说，一个SCI可以是一个文档、一套测试用例或者一个已经命名的程序构件。 下面的SCI成为配置管理技术的目标并形成一组基线。 1：系统规约 2：软件项目计划 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：软件工程的标准和规程 除此之外，为了清晰地描述开发环境，许多软件开发组织也将使用的工具和开发环境内容纳入配置管理库中。工具，就像利用它们生产的产品一样，可以被基线化，并作为综合配置管理工作的一部分，一般称之为“环境基线”。 SCI被组织成配置对象、被命名并被归类到项目的配置管理数据库中。一个配置对象有名字、属性，并通过“关系”和其他的对象连接。 在图17.3中，配置对象“设计规约、“测试规约”、“数据模块”、“模块N”、“源代码”分别被定义。但每个对象都和其他对象存在着一定的关联。曲线表示的关系是组装关系，说明数据模块和模块N都是设计规约的组成部分。直线双箭头连接指明关联关系。如果一个对象(比如源代码对象)发生变化，关联关系使得软件工程师能够