第15讲 件项目管理.pptVIP

六 软件配置管理 任何软件开发都是迭代过程，也就是说，在设计过程会发现需求说明书中的问题，在实现过程又会暴露出设计中的错 误，……。此外，随着时间推移客户的需求也会或多或少发生变化。因此，在开发软件的过程中，变化（或称为变动）既是必要的，又是不可避免的。但是，变化也 很容易失去控制，如果不能适当地控制和管理变化，势必造成混乱并产生许多严重的错误。 软件配置管理是在软件的整个生命期内管理变化的一组活动。具体地说，这组活动用来： ①标识变化； ②控制变化； ③确保适当地实现了变化； ④向需要知道这类信息的人报告变化。 软件配置 1. 软件配置项 软件过程的输出信息可以分为3类： ①计算机程序（源代码和可执行程序）； ②描述计算机程序的文档（供技术人员或用户使用）； ③数据（程序内包含的或在程序外的）。 上述这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是软件配置项。 2. 基线 基线是一个软件配置管理概念，它有助于我们在不严重妨碍合理变化的前提下来控制变化。IEEE把基线定义为： 已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。 简而言之，基线就是通过了正式复审的软件配置项。在软件配置项变成基线之前，可以迅速而非正式地修改它。一旦建立了基线之后，虽然仍然可以实现变化，但是，必须应用特定的、正式的过程（称为规程）来评估、实现和验证每个变化。 除了软件配置项之外，许多软件工程组织也把软件工具置于配置管理之下，也就是说，把特定版本的编辑器、编译器和其 他CASE工具，作为软件配置的一部分“固定”下来。因为当修改软件配置项时必然要用到这些工具，为防止不同版本的工具产生的结果不同，应该把软件工具也 基线化，并且列入到综合的配置管理过程之中。 软件配置管理过程 软件配置管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。 具体来说，软件配置管理主要有5项任务： 标识、版本控制、变化控制、配置审计和报告。 1. 标识软件配置中的对象 可以标识出两类对象： 基本对象和聚集对象（可以把聚集对象作为代表软件配置完整版本的一种机制）。基本对象是软件工程师在分析、设计、编码或测试过程中创建出来的“文本单 元”，例如，需求规格说明的一个段落、一个模块的源程序清单或一组测试用例。聚集对象是基本对象和其他聚集对象的集合。 每个对象都有一组能惟一地标识它的特征： 名字、描述、资源表和“实现”。其中，对象名是无二义性地标识该对象的一个字符串。 在设计标识软件对象的模式时，必须认识到对象在整个生命周期中一直都在演化，因此，所设计的标识模式必须能无歧义地标识每个对象的不同版本。 2. 版本控制 版本控制联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的配置。实现这个目标的方法是，把属性和软件的每个版本关联起来，然后通过描述一组所期望的属性来指定和构造所需要的配置。 上面提到的“属性”，既可以简单到仅是赋给每个配置对象的具体版本号，也可以复杂到是一个布尔变量串，其指明了施加到系统上的功能变化的具体类型。 3. 变化控制 对于大型软件开发项目来说，无控制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。 典型的变化控制过程如下： 接到变化请求之后，首先评估该变化在技术方面的得失、可能产生的副作用、对其他配置对象和系统功能的整体影响以及估算出的修改成本。 评估的结果形成“变化 报告”，该报告供“变化控制审批者”审阅。所谓变化控制审批者既可以是一个人也可以由一组人组成，其对变化的状态和优先级做最终决策。 为每个被批准的变化都生成一个“工程变化命令”，其描述将要实现的变化，必须遵守的约束以及复审和审计的标准。把要修改的对象从项目数据库中“提取 （check out）”出来，进行修改并应用适当的SQA活动。最后，把修改后的对象“提交（check in）”进数据库，并用适当的版本控制机制创建该软件的下一个版本。 3. 变化控制 “提交”和“提取”过程实现了变化控制的两个主要功能——访问控制和同步控制。访问控制决定哪个软件工程师有权访问和修改一个特定的配置对象，同步控制有助于保证由两名不同的软件工程师完成的并行修改不会相互覆盖。 在一个软件配置项变成基线之前，仅需应用非正式的变化控制。该配置对象的开发者可以对它进行任何合理的修改（只要修改不会影响到开发者工作范围之外的系统 需求）。一旦该对象经过了正式技术复审并获得批准，就创建了一个基线。而一旦一个软件配置项变