吕云翔 编著 13.ppt

13.3.2 软件配置管理过程 每个对象都有一组能唯一地标识它的特征：名字、描述、资源表和“实现”。对象描述是数据项的列表，它标识： ◇ 该对象表示的软件配置项类型（如文档、程序和数据）； ◇ 项目标识符以及变化和（或）版本信息。资源是该对象提供、处理、引用或需要的实体，如数据、函数甚至变量名都可作为对象资源。 13.3.2 软件配置管理过程 实现是一个指针，对于基本对象而言它指向文本单元，对于聚集对象而言它是null。在设计软件对象的标识模式时，必须认识到对象在整个软件过程中都在演化。在一个对象成为基线之前，它可能变化许多次，甚至在已经成为基线之后变化仍然可能相当频繁。 13.3.2 软件配置管理过程 13.3.2 软件配置管理过程 人们已经开发出许多自动化的软件配置管理工具（如CCC、RCS、SCCS），用以辅助完成标识（及其他软件配置管理）工作。在某些情况下，工具被设计为仅仅保持最新版本的完整拷贝，为了得到程序或文档的早期版本，要从最新版本中“减去”变化。这种模式使得当前的配置立即可用，其他版本也容易得到。 13.3.2 软件配置管理过程 2．版本控制 版本控制联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的配置。实现这个目标的方法是，把属性和软件的每个版本关联起来，然后通过描述一组所期望的属性来指定和构造所需要的配置。 13.3.2 软件配置管理过程 为了构造一个程序的给定版本的适当变体，可以赋给每个构件一个“属性元组”。所谓属性元组实际上是一个特征表，当构造软件某版本的特定变体时，该特征表将指出是否应该使用这个构件。为每个变体都赋上一个或多个属性，如为了确定在支持彩色显示器时应该包含哪个构件，可以使用一个“颜色”属性。 13.3.2 软件配置管理过程 13.3.2 软件配置管理过程 3．变化控制 对于大型软件开发项目来说，无控制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。 13.3.2 软件配置管理过程 提交”和“提取”过程实现了变化控制的两个主要功能——访问控制和同步控制。访问控制决定哪个软件工程师有权访问和修改一个特定的配置对象，同步控制有助于保证由两名不同的软件工程师完成的并行修改不会相互覆盖。 13.3.2 软件配置管理过程 13.3.2 软件配置管理过程 在一个软件配置项变成基线之前，仅需应用非正式的变化控制。该配置对象的开发者可以对它进行任何合理的修改（只要修改不会影响到开发者工作范围之外的系统需求）。一旦该对象经过了正式技术复审并获得批准，就创建了一个基线。而一旦一个软件配置项变成了基线，就开始实施项目级的变化控制。 13.3.2 软件配置管理过程 现在，为了进行修改，开发者必须获得项目管理者的批准（如果变化是“局部的”）；如果变化影响到其他软件配置项，则必须得到变化控制审批者的批准。在某些情况下，可以省略正式的变化请求、变化报告和工程变化命令，但是，必须评估每个变化并且跟踪和复审所有变化。 13.3.2 软件配置管理过程 4．配置审计 为确保适当地实现了所需要的变化，我们从两方面采取措施：①正式的技术复审；②软件配置审计。 13.3.2 软件配置管理过程 正式的技术复审（见13.2.2小节）关注被修改后的配置对象的技术正确性。复审者评估该配置对象以确定它与其他软件配置项的一致性，并检查是否有遗漏或副作用。 软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征，而成为对正式技术复审的补充，它询问并回答下述问题。 13.3.2 软件配置管理过程 ◇ 在ECO中指定的变化已经完成了吗？是否做了任何额外的修改？ ◇ 是否已经进行了正式的技术复审？ ◇ 是否遵循了软件工程标准？ ◇ 在该软件配置项中显著地标明了所做的变化了吗？是否说明了变化的日期和作者？ 13.3.2 软件配置管理过程 ◇ 该配置对象的属性反映了所做的变化吗？ ◇ 已经遵循软件配置管理关于标注变化、记录变化和报告变化的规程了吗？ ◇ 是否已经适当地更新了所有相关的软件配置项？ 13.3.2 软件配置管理过程 5．状态报告 配置状态报告是软件配置管理的一项任务，它回答下述问题：①发生了什么事？②谁做的这件事？③这件事是什么时候发生的？④它将影响哪些其他事物？ 13.3.2 软件配置管理过程 每次当一个软件配置项被赋予新的或修改后的标识时，则创建一个配置状态报告条目；每次当一个变化被变化控制审批者批准（即产生一个ECO）时，则创建一个配置状态报告条目；每次进行配置审计时，其结果作为配置状态报告的一部分被报告。 13.3.2 软件配置管理过程 配置状态变化对大