软件工程讲义_第十七章软件配置管理.pptxVIP

软件工程第17章 软件配置管理主要内容软件配置管理概述SCM中心存储库SCM过程小结软件配置管理软件配置管理（SCM），也称为变更管理，是一组管理变更的活动。它通过下面的方式来管理变更：识别可能发生变更的工作产品，建立这些工作产品之间的关系，制定管理这些工作产品的不同版本的机制，控制所施加的变更，审核和报告所发生的变更。参与软件过程的每个人在某种程度上都参与变更管理，但是有时候也设专人来管理SCM过程。软件配置管理如果不控制变更，将被变更所控制。一个未受控制的变更流可以很容易地将一个运行良好的软件项目带入混乱。结果会影响软件质量并且会推迟软件交付。为此，变更管理是质量管理的重要部分。因为在构建软件时会创建很多工作产品，因此每个工作产品都需要唯一标识。一旦成功完成标识，则可以建立版本和变更控制机制。为保证变更发生时维护质量，变更过程需要审核；为了通知那些需要知道变更的人员，需要进行变更报告。软件配置管理软件配置管理计划定义变更管理的项目策略。另外，当启动正式的SCM时，变更控制过程将产生软件变更请求、报告和工程变更工单。当每个工作产品都可以标识、跟踪和控制时，当每个变更可以跟踪和分析时，当每个需要知道变更的人都通知到时，变更管理的目的就达到了。软件配置管理软件配置管理（SCM或CM），是贯穿于整个软件过程的普适性活动。因为变更可能随时发生，所以SCM活动的目标就是为了：(1)标识变更；(2)控制变更；(3)保证正确地实现变更；(4)向其他可能的相关人员报告变更。软件配置管理明确地区分软件支持和软件配置管理是很重要的。软件支持是一组发生在软件已经交付给客户并投入运行后的软件工程活动。而软件配置管理则是在软件项目开始时就启动，并且只有当软件被淘汰时才终止的一组跟踪和控制活动。软件工程的主要目标是当发生变更时，使变更更容易地被接受，并减少变更发生时所花费的工作量。软件配置管理概述软件过程的输出信息主要分为三类：(1)计算机程序（源代码和可执行程序）；(2)描述计算机程序的文档(针对不同的软件开发人员和用户);(3)数据或内容（包含在程序内部的数据，或程序外部的数据）。在软件过程中产生的所有信息项总称为软件配置。如果一个软件配置项只是简单地推导出其他一些软件配置项，则几乎不会产生混乱。但不幸的是，在这个过程中还有另一个变量——变更。变更可能毫无理由地随时发生。正如系统工程第一定律所述：不管你处在系统生存周期的什么阶段，系统都可能发生变更，并且在整个生存周期中将会持续不断地提出变更的要求。软件配置管理 变更有四个基本的原因：新的业务或市场条件导致产品需求或业务规则的变更。新的客户需求，要求修改信息系统产生的数据、产品提供的功能或系统提供的服务。企业改组或扩大/缩小规模，导致项目优先级或软件工程团队结构的变更。预算或进度安排的限制，导致系统或产品的重新定义。软件配置项管理是一组用于在计算机软件的整个生命周期内管理变更的活动。SCM可被视为应用于整个软件过程的软件质量保证活动。SCM场景 典型的CM工作场景包括：负责软件小组的项目经理、负责CM规程和方针的配置管理员、负责开发和维护软件产品的软件工程师以及使用软件产品的客户。在下述场景中，假定由6个人组成的团队正在开发一个约15000行代码的小型软件。在操作级别上，SCM场景包括多种角色和任务。项目经理的职责是保证在确定的时间框架内开发出产品。因此，项目经理必须对软件的开发进展情况进行监控，找出问题，并对问题做出反应。这可通过建立和分析软件系统状态报告，并执行对系统的评审来完成。SCM场景 配置管理员的职责不仅是要保证代码的创建、变更和测试要遵循相应的规程和方针，还要使项目的相关信息容易得到。为了实现维护代码变更控制的技术，配置管理员可以引入正式的变更请求机制、变更评估机制和变更批准机制。配置管理员要为工程师们创建和分发任务单，并且还要创建项目的基本环境，而且，还要收集软件系统各个构件的统计信息。SCM场景 软件工程师的目标是高效地工作。即软件工程师在代码的创建和测试以及编写支持文档时不做不必要的相互交流；但同时，软件工程师们又尽可能地进行有效的沟通和协调。特别是，软件工程师可以使用相应的工具来协助开发一致的软件产品；软件工程师之间可以通过相互通报任务要求和任务完成情况来进行沟通和协调；通过合并文件，可以使变更在彼此的工作中传播。对于同时有多个变更的构件，要用机制来保证具有某种解决冲突和合并变更的方法。依据系统变更原因日志和究竟如何变更的记录，历史资料应该保持对系统中所有构件的演化过程的记录。软件工程师有他们自己创建、变更、测试和集成代码的工作空间。在特定点，可以将代码转变成基线，并从基线做进一步的开发。SCM场景 客户只是使用产品。由于产品处于CM控制之下，因此，客户要遵守请求变更和指出产品