it软件配置管理

it软件配置管理林琳软件技术教研室第5章软件配置管理5.1概述5.2配置项5.3基线5.4版本控制5.5变更控制5.6软件配置管理系统软件项目中是否遇到如下的问题：开发人员使用错误的版本修改程序；开发人员未经授权修改代码或文档,或修改的结果不能及时反映到各个相关部分；人员流动，交接工作不彻底造成软件关键部件遗失；已修复的Bug在新版本中出现；找不到某个文件的历史版本；无法重新编译某个历史版本，使维护工作十分困难；因协同开发中，或者异地开发，版本变更混乱导致整个项目失败；……软件项目进行中面临的一个主要问题是持续不断的变化•有效的项目管理能够控制变化.•以最有效的手段应对变化,不断命中移动的目标。5.1概述软件配置管理的概念SCM简单而言就是管理软件的变化，应用于软件工程过程，通常由相应的工具、过程和方法学组成。在整个软件的开发活动中占有很重要的位置。软件配置管理的目的与益处有效的软件配置管理可以解决一些常见的问题；有效的软件配置管理可以节约用户资金；有效的软件配置管理可以提高软件开发管理的水平；有效的软件配置管理可以保护企业的知识财富。软件配置管理四个活动配置项标识审核状态统计变更控制配置项标识、跟踪配置管理环境建立基线变更管理配置审核配置状态统计5.2配置项5.2.1配置项定义5.2.2软件配置控制5.2.3配置项标识5.2.1配置项的定义所有在软件过程中产生的信息，总称为软件配置项，主要包括：①计算机程序（源代码和可执行程序）；②描述计算机程序的文档（针对技术开发者和用户）；③数据（包含在程序内部或外部）。配置项内容配置项包含内容项目管理过程文档项目任务书；项目计划；项目周报；个人日报和周报；项目会议纪要；培训记录和培训文档；QA过程文档QA不符合报告；QA周报；评审记录；工作产品需求文档；设计文档；代码；测试文档；软件说明书和手册；项目中使用的第三方产品例如：Oracle,Java等5.2.2软件配置控制配置控制是配置管理的核心工作。配置控制主要包括：①存取控制：设定了软件开发人员对软件基准库的存取权限，保证软件开发过程及软件产品的安全性；②版本控制：是配置管理的基本要求，使得组织在任何时刻都可以获得配置项的任何一个版本；③变更控制：为软件产品变更提过了一个明确的流程，要求任何进行配置管理的软件产品变更都要经过相应的授权与批准才能实施；④产品发布：保证了提交给客户的软件产品是完整的、正确的。5.2.3配置项标识软件配置项标识是管理配置的前提。标识包括文件名和版本。确定配置项：软件项目在开发过程中会产生成千上百个配置项，那么确定配置项是很重要的；明确配置项标识的要求：项目组人员按照标识规则对配置项进行标识，最后提交给配置管理员纳入配置库统一管理；配置项命名：(1)唯一性：在一个项目内不能出现重名，以避免混淆；(2)可追溯性：系统的要求，即名字应能体现相邻配置项之间的关系。5.3基线常用软件基线：系统工程需求分析软件设计代码测试系统规格说明书软件需求规格说明书设计规格说明书源代码测试计划过程/数据可操作的系统基线属性与优点基线是软件生存期各开发阶段末尾的特定点，也称里程碑。基线的属性：1.通过正式评审过程建立；2.存在于基线库，对基线的变更接受更高权限的控制；3.基线是进一步开发和修改的基准和出发点；4.进入基线前，不对变化进行管理；进入基线后，对变化进行有效管理；5.不会变化的内容不纳入基线，变化对其它无影响的也不纳入基线；6.基线具有名称、标识符、版本、日期等属性；7.交付给客户的基线成为一个Release，内部开发用的基线为一个Build。基线的优点重现性：当更新不稳定或不可信时，基线提供一种取消变更的方法；可追溯性：建立项目工件之间的前后继承关系；版本隔离：新项目与随后对原始项目所进的变更进行隔离。基线种类功能基线(FunctionalBaseline)指派基线(AllocatedBaseline)产品基线(ProductionBaseline)软件过程中的配置基线需求分析设计编码测试计划基线需求基线设计基线编码基线测试基线计划项目开发计划用户手册需求规格分析详细设计说明书概要设计说明书源代码测试报告5.4版本控制5.4.1版本的访问与同步控制5.4.2版本分支和合并5.4.3版本的历史记录5.4.1版本的控制与同步控制版本的访问控制工作区域中的源文件是从库中恢复得到的一个复制文件，它可以是可“写”的，也可以是可“读”的。一般有两种工作模式：一是在工作区域一旦有“读”请求，就做一次恢复操作，获得复制文件，当“读”操作结束，该复制文件被删除；二是仅当软件库中的内容发生更改时，才发生交互，而不是每次“读”操作都与软件库中的文件发生交互。版本的同步控制同步控制实际上时版本的检入检出控制：检入：将软件配置项从用户的工作环境存入到软件配置库的过程；检出：将软件配置项从软件配置库中取出的过程。访问和同步控制的流程图软件工程师软件配置库检入检出访问控制配置对象（修改版本）配置对象（基线版本）审计信息解锁拥有者信息加锁配置对象（基线版本）配置对象（提取版本）5.4.2版本分支和合并版本分支版本分支人工方法就是从主版本复制一份文件，做上标记；实行版本控制之后，版本的分支是一份复制文件，这时的复制过程和标记动作由版本系统自动完成。版本合并版本合并是通过对文件的比较来进行合并。有两种途径：一种是将版本A的内容附加到版本B中；另一种是合并A和B的内容，形成新的C；后一种途径更容易理解，也符合软件开发的思路。5.4.3版本的历史记录文件和目录的版本演化的历史可以形象的表示为图形化的版本树；版本树由版本依次连接形成，每个结点代表一个版本，根结点是初始版本，叶结点代表最新的版本；典型的软件系统包含多个文件和目录，每个文件和目录都有自己的版本树；版本的历史记录有助于对软件配置项进行审计，有助于追踪问题的来源；版本的历史记录应该包含版本号、修改时间、修改者、修改描述这些最基本的内容。版本树最简单的版本树只有一个分支，就是版本树的枝干；复杂的版本树除了主干外，还可以包含很多的分支，分支可以进一步包含子分支。V1.0V1.1V1.2V1.3V2.0V1.4V2.1V1.1.1V1.1.25.5变更控制5.5.1变更类型5.5.2变更请求管理5.5.3变更管理的实施步骤变更机制变更请求CCB评估修改测试或验证关闭变更请求接受提交拒绝5.5.1变更类型功能变更功能变更是为了增加或者删除某些功能、或者为了完成某个功能的方法而需要的变更；这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和其对软件系统其他部分的影响。缺陷变更缺陷修补是为了修复漏洞需要进行的变更。在项目前期，它是必须进行的，通常不需要从管理角度对这类变更进行审查和批准。在项目后期，如果发现错误的阶段在造成错误的阶段的后面，则必须遵照标准的变更控制过程来进行。5.5.2变更请求管理变更请求通常分为两个大类：①增强请求：增强请求指系统的新增特征或对系统“预定设计”行为的变更。②缺陷：指存在于一个已交付产品中的异常现象或缺陷。③变更请求管理过程：1.变更请求提交2.变更请求接收3.变更请求评估4.变更请求决策5.变更请求实现6.变更请求验证7.变更请求完成变更请求管理流程批准变更请求?拒绝记录变更请求指派给相应的开发人员批准检出变更请求评估评估向SCM提交并验证变更请求验证相关责任人提出变更请求请求变更实现实现验证正确的变更请求检入验证变更请求关闭关闭通知相关责任人关闭变更需求软件增强缺陷5.5.3变更管理的实施步骤变更请求提交缺陷和增强请求通常在请求起源和收集信息类型上不同。变更请求接收项目必须建立接收提交的变更请求并进行跟踪的机制。指定接收和处理变更请求的责任人，确认变更请求。变更请求评估大多数机构根据请求的类型是缺陷还是增强而使用不同的评估过程。变更请求决策决策阶段是当选择实现一个变更请求时所做出的决定，如推迟此次实施或者永远不进行实施等。缺陷和增强请求几乎总是以不同方式进行处理。变更管理的实施步骤变更请求实现增强请求实现较之缺陷实现需要更多的设计工作，这是因为增强请求经常涉及新特性或新功能。另一方面，缺陷修复需要建立一个环境，在该环境中可以对缺陷进行重现并测试相应的解决方案。变更请求验证验证发生在最终测试及文档制作阶段。增强请求的测试通常涉及验证所做变更是否满足该增强请求的需要。缺陷测试则简单的验证开发人员的修复是否真正消除了该缺陷。变更请求完成完成是变更请求的最终阶段，这可能是完成了一项请求或者决定不实现某一请求。在完成阶段的主要步骤是由提交请求的原有请求者中止这一循环过程。5.6软件配置管理系统5.6.1软件配置标准5.6.2配置管理工具介绍5.6.3配置管理工具的选择5.6.4版本控制工具-svn软件配置管理系统功能并行开发系统修订版管理版本控制产品发布管理建立管理过程控制变更请求管理代码共享5.6.1软件配置标准标志和指南简要描述EIAStandardIS-649NationalConsensusStdforConfigurationManagement,Aug.1995给出基本的CM规则，和业界最好的实践经验来指导标识产品配置并进行高效、有条理的软硬件产品管理。IEEEStd1042-1987,GuidetoSoftwareConfigurationManagement(ANSI)描述CM规则在软件工程项目中的应用。包括4个完整的SCM计划的例子。IEEEStd828-1990,StandardforSoftwareConfigurationManagementPlans(ANSI)确定SCM计划最少需要哪些内容，是IEEEStd1042-1987的补充。应用于重要软件的整个生命周期，也适用于非重要软件和已开发的软件。IEEE/EIA12207.0-1996,IndustryImplementationofInternationalStandardISO/IEC12207:1995(ISO/IEC12207)StandardforInformationTechnology–SoftwareLifecycleProcesses,Mar1998用明确的术语定义了软件生命周期的一个公共框架。包括在系统软件、独立软件产品、软件服务的获取过程和软件产品供应、开发、操作、维护中的过程、活动和任务。软件配置标准和指南标志和指南简要描述IEEE/EIA12207.1-1996,Lifecycledata,April1998给出了在IEEE/EIA12207.0－1996中的活动和任务执行过程中哪些数据可以记录的指导。对记录内容、记录位置、格式、和记录介质没有限定。IEEE/EIA12207.2-1996,ImplementationConsiderations,April1998给出了实现IEEE/EIA12207.0过程要求的指导。目的是总结软件业在ISO/IEC12207的过程结构环境方面最好的实践经验。ISO9000-3:1991(E),QualityMgmt&QualityAssuranceStds-Part3:GuidelinesfortheapplicationofISO9001tothedevelopment,supplyandmaintenanceofsoftware为应用ISO9001的开发、供应、维护软件的组织提出的指导方针。目的是在合同双方需要供应方开发、支持和维护软件产品能力的证明时提供指导。MIL-HDBK-61,ConfigurationManagementGuidance提供了DoD采购经理、后勤管理员和其他个人已指派的CM职责方面的指导和信息。为国防系统和其配置项的所有生命周期阶段的实践活动制订计划并有效实现DoDCM活动提供帮助。5.6.2软件配置管理工具对比由于软件配置管理过程十分繁