173软件配置中对象的标识.PPT

* 第17章 软件配置管理 第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.1.1 基线 变化是软件开发过程中必然发生的事情。客户要变更需求，开发者希望修改技术方法，管理者要调整预算等等都属于合理的变化要求。遗憾的是，如果完全随意地进行变化的话，软件工程将变成一场灾难。变化不可避免，变化必须得到管理，已经成为业界的共识。引入基线的概念，正是为了实现对变化的管理。 基线(Base Line)的原意是棒球场的边线，在软件工程中将其引申成为软件配置管理中的一个专用名词。基线用来在不对合理变化造成严重阻碍的前提下控制变化。IEEE组织对于基线的定义是：“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。这里的规约(Specification)可以解释为“详细说明”或“规格说明”。 根据这个定义，可以认为基线是一组已经经过正式技术复审而被认可、发布并且可供使用，只能遵循一定规程进行变化的软件工作产品。SCI被纳入基线之前，生产者可以为了顺应某种要求，对其进行迅速而非正式的变更，但是如果该项已经纳入基线，那么针对它的每一个变化，必须按照特定的、正式的规程进行评估、实施、验证和发布。虽然基线可以在任意的细节层次上定义，但为了避免过于繁琐，最常见的软件基线如图17.1所示。 图17.1 基线 在软件工程的范围内，基线是软件开发过程中的里程碑，其标志是有一个或多个软件配置项(SCI)的交付。而且这些配置项已经经过正式技术复审并获得认可。例如，某设计规约的要素已经形成文档并通过复审，错误已被发现并且得到了纠正。一旦规约的所有部分均通过复审、纠正，然后认可，则该设计规约就变成了一个基线。此后任何对包含在此设计规约中的程序体系结构的变化都只能在被评估并得到批准之后方可进行。 产生基线的事件进展如图17.2所示。 软件工程产生一个或多个SCI，在SCI被复审并得到认可后，它们被放进项目的配置管理数据库中。当软件工程项目组中的某个成员希望修改某个基线SCI时，该SCI被从项目的配置管理数据库拷贝到工程师的私有工作区中，然而，这个提取出来的SCI只有在遵循SCM控制的情况下才可以被修改。图17.2中的虚线说明了对某一个SCI进行修改的事件路径。 图17.2 作为基线的SCI和项目的配置数据库 在基线管理活动中，除了对项目基线进行管理之外，为了提高整个开发组织的过程能力，SCM活动也必须进行必要的扩充。一般来说，还应当建立组织的过程基线和软件财富基线，以便在整个组织中共享过程和软件财富。 作为过程基线，应当将组织的质量体系、过程文件、工程操作指南、文档模板、工作样表、历史度量数据等进行统一管理、集中维护、控制发放和深入分析。将这些来自于本组织工作实践的财富提供给各个项目组，用作具体项目的工作指导。同时，通过对项目的监控和度量，不断地充实过程基线；在深入分析当前基线数据的基础上，找出限制组织提升过程能力的主要因素和存在的关键问题，有针对性地引入更先进的过程模型和技术手段，不断地提高本组织的过程能力。 软件财富基线主要包括各类可复用的软件构件。对这些构件进行标识、维护、管理，提供给所有需要重用它们的项目组，无疑将会极大地提高生产率，改进未来产品的质量并提供更多可供选择的解决方案和设计方案。项目中形成的可复用构件，应当及时纳入财富基线，尽快发挥它们的作用，扩大财富的积累。 17.1.2 软件配置项 软件配置项已经定义为在部分软件工程过程中创建的信息。一般地说，一个SCI可以是一个文档、一套测试用例或者一个已经命名的程序构件。下面的SCI成为配置管理技术的目标并形成一组基线。 1：系统规约 2：软件项目计划 3：软件需求规约 a: 图形分析模型 b: 处理规约 c: 原型 d: 数学规约 4：初步的设计手册 5：设计规约