配置管理与变更管理.ppt
文本预览下载声明
版本与版本控制——概念、目的 版本与版本控制——软件的每一个版本都是源代码、文档、数据以及相关的系统环境的一个收集,且各个版本都可能由不同的变种组成。 版本控制的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本。 版本控制是SCM的基础,它管理并保护开发者的软件资源。使混乱的开发状态变得有序! 5.2 软件项目配置管理过程 版本与版本控制——版本控制规则 处于“草稿”状态的配置项的版本号格式为:0.YZ YZ数字范围为01-99。 随着草稿的不断完善,“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。 处于“正式发布”状态的配置项的版本号格式为:X.Y X为主版本号,取值范围为1-9。Y为次版本号,取值范围为1-9。 配置项第一次“正式发布”时,版本号为1.0。 如果配置项的版本升级幅度比较小,一般只增大Y值,X值保持不变。只有当配置项版本升级幅度比较大时,才允许增大X值。 处于“正在修改”状态的配置项的版本号格式为:X.YZ 配置项正在修改时,一般只增大Z值,X.Y值保持不变。 当配置项修改完毕,状态重新成为“正式发布”时,将Z值设置为0,增加X.Y值。 5.2 软件项目配置管理过程 版本与版本控制——版本图 版本控制管理在软件工程过程中建立起配置对象的不同版本。使用演变图来表示系统的不同版本。 版本管理可以把一些属性结合到各个软件版本上。 V1.0 V1.2 V1.1 V1.3 V1.4 V2.0 V2.1 V1.1.1 V1.1.2 5.2 软件项目配置管理过程 版本与版本控制——配置项的版本 版本控制工具 Rational ClearCase Microsoft Visual SourceSafe Microsoft Project 2000 Sybase ObjectCycle Manager 需求规格V1.1 需求规格 需求规格V1.2 需求规格V1.3 配置项类 配置项 实例 5.2 软件项目配置管理过程 变更管理 是团队开发过程中的通讯基础 可以了解谁改了什么、为什么 正确及时的项目状态报告 最大限度的利用你的工程师资源 利于团队交流 软件工程过程中某一阶段的变更,均要引起软件配置的变更,这种变更必须严格加以控制和管理,保持修改信息。 变更控制包括建立控制点和建立报告与审查制度。 5.2 软件项目配置管理过程 变更管理——变更控制过程 5.2 软件项目配置管理过程 加强团队间的沟通,真正掌握开发状态! 变更管理——变更的两种情况 为改正小错误需要的变更。 为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。 如果变更的代价比较小且对软件系统其它部分没有影响,或影响很小,通常应批准这个变更。 如果变更的代价比较高,或者影响比较大,则必须权衡利弊,以决定是否进行这种变更。 如果同意这种变更,需要进一步确定由谁来支付变更所需要的费用。如果是用户要求的变更,则用户应支付这笔费用;否则,必须完成某种成本/效益分析,以确定是否值得做这种变更。 5.2 软件项目配置管理过程 基线变更管理——基线的概念 基线(Baseline)——是软件生存期中各开发阶段末尾的特定点,又称里程碑。 基线的作用是把各阶段工作的划分更加明确化,以便于检验和肯定阶段成果。 基线由一组配置项组成,一个(些)配置项形成并通过审核,即形成基线,这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了,不能再被随意修改。 基线标志开发过程一个阶段的结束和里程碑(Milestone),一个产品可以有多个基线,也可以只有一个基线。 5.2 软件项目配置管理过程 基线变更管理——软件项目形成的基线 基线的主要属性有:名称、标识符、版本、日期等。 通常将交付给客户的基线称为一个“Release”;为内部开发用的基线则称为一个“Build”。 5.2 软件项目配置管理过程 基线变更管理——基线变更系统 项目基线(配置项)可能由于种种原因会发生变更,如:客户需求变化、进度变更、成本变更、产品环境变化等。 基线修改(变更)应受到控制,变更管理也称为配置控制,这种变化要经SCCB授权,按正式的程序进行控制并记录基线修改的过程。 配置控制 变更请求 变更评估 变更批准/拒绝 变更实现 5.2 软件项目配置管理过程 基线变更管理——变更请求 项目名称 ? 变更申请人 ? 提交时间 ? 变更题目 ? 紧急程度 ? 变更具体内容 ? 变更影响分析 ? ? ? 变更确认 处理结果 ? 签字 ? ? 5.2 软件项目配置管理过程 基线变更管理——变更评估 变更评估 软件变更分类 技术影响分析 接口影响
显示全部