现代软件工程第12章 软件配置管理.pptxVIP

目 录4321SCM过程概述SCM中心存储库WebApp配置管理第12章 软件配置管理软件在其生存周期的各个阶段中，要产生一些文件、报告、表格和数据，这一切构成了软件配置（Software Configuration），即以多种形式表述软件的信息组。软件配置管理（SCM），又称软件版本管理，是标识、控制、审查和解释软件配置的一组活动，它也是软件维护的一个重要方面。第12章 软件配置管理在开发计算机软件时，变更是不可避免的。并且，对于共同研发项目的软件开发团队来说，变更增加了混乱的程度。如果变更之前没有经过分析，变更实现时没有做相应的记录，没有向需要了解变更的人员报告变更，或没有以一种能够改进质量并减少错误的方式控制变更时，都会产生混乱。软件配置管理是在整个软件过程中应用的一种普适性活动。因为变更可能随时出现，SCM活动用于：①标识变更；②控制变更；③保证恰当地实施变更；④向其他可能的相关人员报告变更。第12章 软件配置管理明确地区分软件支持和软件配置管理是很重要的。软件支持是一组发生在软件已经交付给客户并投入运行后的软件工程活动。而软件配置管理则是在软件项目开始时就启动，并且只有当软件被淘汰时才终止的一组跟踪和控制活动。为此，软件工程的主要目标是当发生变更时，使变更更容易地被接受，并减少变更发生时所花费的工作量。12.1 概 述12.1 概 述软件过程的输出信息可以分成3个主要类别：①计算机程序（源代码和可执行程序）；②描述计算机程序的文档（针对不同的软件开发人员和客户）；③数据或内容（包含在程序的内部和外部），在软件过程中产生的所有这些信息项就是软件配置。随着软件工程工作的进行，软件配置项（Software Configuration Items，SCI）的层次结构就产生了。每一项可以是单个UML图一样小或者和完整的设计文档一样大的命名信息元素。如果每个SCI只是简单地产生了其他的SCI，则几乎不会产生混乱。然而，变更可以因为任意理由随时发生。事实上，正如系统工程第一定律所述：不管你处在系统生存周期的什么阶段，系统都可能发生变更，并且在整个生存周期中将会持续不断地提出变更的要求。12.1 概 述这些变更的起因涉及到4种基本来源：新的业务或市场条件，引起产品需求或者业务规则的变更。新的客户需要，要求修改信息系统产生的数据、产品提供的功能或基于计算机的系统提供的服务。企业改组或扩大/缩小规模，导致项目优先级或软件工程团队结构的变更。预算或进度的限制，导致系统或产品的重定义。12.1.1 SCM场景典型的配置管理工作场景包括：负责软件小组的项目经理、负责配置管理规程和方针的配置管理员、负责开发和维护软件产品的软件工程师以及使用软件产品的客户。在本场景中，我们假定一个由6个人组成的团队正在开发一个约15 000行代码的小型软件。在操作级别上，SCM场景包括多种角色和任务。项目经理的职责是保证在确定的时间框架内开发出产品。因此，项目经理必须对软件的开发进展情况进行监控，找出问题，并对问题做出反应。这可通过建立和分析软件系统状态报告，并执行对系统的评审来完成。12.1.1 SCM场景配置管理员的职责不仅是要保证代码的创建、变更和测试要遵循相应的规程和方针，还要使项目的相关信息容易得到。为了实现维护代码变更控制的技术，配置管理员可以引入正式的变更请求机制、变更评估机制（通过负责批准软件系统变更的变更控制委员会）和变更批准机制。配置管理员要为工程师们创建和分发任务单，并且还要创建项目的基本环境，而且，还要收集软件系统各个构件的统计信息，比如能够决定系统中哪些构件有问题的信息。12.1.1 SCM场景软件工程师的目标是高效地工作。也就是说，软件工程师在代码的创建和测试以及编写支持文档时不做不必要的相互交流；但同时，软件工程师们又尽可能地进行有效的沟通和协调。特别是，软件工程师可以使用相应的工具来协助开发一致的软件产品；软件工程师之间可以通过相互通报任务要求和任务完成情况来进行沟通和协调，通过合并文件，可以使变更在彼此的工作中传播。对于同时有多个变更的构件，要用机制来保证具有某种解决冲突和合并变更的方法。依据系统变更原因日志和究竟如何变更的记录，历史资料应该保持对系统中所有构件的演化过程的记录。软件工程师有他们自己创建、变更、测试和集成代码的工作空间。在特定点，可以将代码转变成基线，并从基线做进一步的开发，或生成针对其他目标机的变体。12.1.1 SCM场景客户只是使用产品。由于产品处于配置管理控制之下，因此，客户要遵守请求变更和指出产品缺陷的正式规程。理想情况下，在本场景中应用的配置管理系统应该支持所有的角色和任务。也就是说，角色决定了配置管理系统所需的功能。项目经理可以把配置管理看作是一个审核机制；配置管理员可以把