软件项目管理第12章软件配置管理.ppt

,第12章 软件配置管理,12.1 什么是软件配置管理 12.2 软件配置管理的相关概念 12.3 软件配置管理的活动 12.4 软件配置管理组织 12.5 配置管理工具 12.6 小结, 12.1 什么是软件配置管理 变更是软件过程中的一项基本活动，需求变更驱动设计变更，设计变更驱动代码变更，测试活动也将导致变更，有时甚至是原始需求的变更。对于软件过程中经常遇到的变更问题，如果没有有效的机制进行控制，将会引起巨大的混乱，导致项目失败。 软件配置管理(Software Configuration Management, SCM)就是在项目开发中，标识、控制和管理软件变更的一种管理活动，是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施，用于记录软件产品的演化过程，最大限度地减少错误和混乱，保证软件项目工作,产品在整个生命周期内的完整性。IEEE关于软件配置管理的定义为：软件配置管理是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。 随着软件开发规模的不断扩大，一个项目的中间软件产品的数目越来越多，中间软件产品之间的关系越来越复杂，对中间软件产品的管理也越来越困难，有效的软件配置管理有助于解决这些问题。软件配置管理贯穿于软件生存期的全过程，目的是用于建立和维护软件产品的完整性和可追朔性。,12.1.1 配置管理需求分析 现在的软件开发通常由许多人共同合作完成。在团队开发模式中，软件项目开发管理就显得更加重要，直接影响到软件产品的质量。如果缺乏对软件开发过程的统一管理，就会产生如图12.1所示的问题。,图12.1 缺乏统一管理出现的问题(在实际开发中表现为项目组成员沟通困难、 软件重用率低下、开发人员各自为政、代码冗余度高、文档不健全等),缺乏统一管理出现的问题具体描述为： (1) 由于开发经费及开发时间的限制，不可能一次开发就解决所有问题，许多问题有待维护阶段解决，由此带来软件产品的不断升级，但是维护和升级必需的文档往往非常 混乱。 (2) 开发过程缺乏规范化管理，即使有源程序以及相应的文档，也由于说明不详细而不能对产品进行功能扩充，用户不得不再次投入大量的经费去开发新产品，浪费大量的人力、物力和时间。,(3) 在开发团队中，人员流动在所难免。如果管理不善，有些人员流动将对开发工作产生致命影响。特别是软件开发管理人员或核心成员的流失，可能会导致无法确定软件产品中各模块所处的状态及阶段，使软件产品版本出现混乱，甚至可能泄露公司的核心机密。 (4) 管理不善可能导致未经测试的软件成分加入到产品中，不但会影响产品质量，有时还会导致致命错误，以至造成不可挽回的损失。 (5) 用户利益无法保证，用户与开发商缺乏有效的沟通手段。用户投入了开发费用后，得到的只是可执行文件和一堆杂乱无章的文档。即使是较好的文档，对不熟悉开发过程的非专业人员来说也无从下手，更谈不上日后的维护和升级。,(6) 软件生产达不到规模化，无法形成软件企业的内部标准构件仓库。软件产品总处于一种低水平、重复开发的状态，不但时间得不到保证，而且成本也无法降低，产品也就缺乏市场竞争力。 这些问题在实际开发中表现为项目组成员沟通困难、软件重用率低下、开发人员各自为政、代码冗余度高、文档不健全等。由此造成的后果是数据丢失、开发周期漫长、产品可靠性差、软件维护困难、用户抱怨使用不方便、项目风险增加等。,怎样进行软件开发管理才能生产出高质量的软件产品呢？ISO 9000质量管理和质量保证体系制定了相关标准软件开发、供应和维护使用指南。标准除对软件生命周期的各个阶段做出了严格规定外，还在质量体系中规定了与阶段无关的支持活动，其中软件配置管理被放在了首位。 作为管理软件开发过程的有效方法，SCM的有效性早已被发达国家软件产业的发展实践所证明。SCM可以系统地管理软件系统中的多重版本，全面记载系统开发的历史过程，包括为什么修改、谁做了修改、修改了什么，同时管理和追踪开发过程中危害软件质量、影响开发周期的缺陷和变化。SCM对开发过程进行有效的管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档。SCM是通往ISO 9000和SEI CMM标准的基石。,在软件开发团队中，正确地引入、实施软件配置管理系统，可以提高生产力、增强对项目的控制能力、改善软件产品质量，使企业从容地面对快速上市和产品质量的双重压力。 12.1.2 配置管理的作用 随着软件系统的日益复杂化和用户需求的多样化、软件升级的频繁化，软件配置管理逐渐成为软件生存周期中的重要控制过程，在软件开发过程中扮演着越来越重要的角色。好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开发过程的宏观管理(即项目管理)也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性，使软件系统具有可重复性，使用户和主管部门对软件质量和开发小组有更强的信心。,软件配置管理通过对软件的修改和每个修改生成的软件组成部件进行控制、记录、追踪来实现对软件产品的管理功能。由于软件产品是在用户需求不断变化的驱动下不断变化的，为了保证对产品有效地进行控制和追踪，配置管理过程不能仅对静态的、成型的产品进行管理，还必须对动态的、成长的产品进行管理。由此可见，配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期。通过配置管理过程控制，用户对软件产品的需求如同普通产品的订单一样，遵循严格的流程，经过受控的生产流水线，最后形成产品，发售给相应用户。从另一个角度看，在产品开发的不,同阶段通常有不同的任务，由不同的角色担当，各个角色职责明确、泾渭分明，同时又前后衔接、相互协调。 好的配置管理过程有助于规范各个角色的行为，同时又为角色之间的任务传递提供无缝衔接，使整个开发团队像一个交响乐队一样和谐地进行。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品，这些都是项目主管人员关注的重点，因此，配置管理在软件项目管理中也起着越来越重要的作用。配置管理过程演化出的控制、报告功能可以帮助项目经理更好地了解项目进度、开发人员负荷、工作效率、产品质量状况和交付日期等信息。同时，配置管理过程所规范的工作流程和明确分工有利于管理者应付开发人员流动的困境，使新老成员可以快速实现任务交接，尽量减少因人员流动造成的损失。,配置管理对软件开发项目的具体作用，表现在以下几个方面： (1) 缩短开发周期。通过配置管理工具对程序资源进行版本管理和跟踪，建立公司的代码知识库，保存开发过程中每个过程的版本，可以提高代码重用率，便于同时维护多个版本和进行新版本开发，防止系统崩溃，最大限度地共享代码。同时，项目管理人员通过查看项目开发日志对开发过程进行管理，测试人员可以根据开发日志的不同版本对软件进行测试，工程人员可以得到不同的运行版本。有些配置管理工具还提供Web版本，供外地实施人员存取最新版本，无须开发人员亲临现场。,(2) 减少施工费用。利用配置管理工具，建立开发管理规范，把版本管理档案链接到公司内部的Web服务器上，内部人员可直接通过浏览器访问，工程人员通过远程进入内部网，进而获取所需的最新版本。开发人员无须亲自到现场，现场工程人员通过对方系统管理员收集反馈意见，书面提交到公司内部开发组的项目经理，开发组内部讨论决定是否修改，并做出书面答复。这样可以同时响应多个项目，防止开发人员被分配到各个项目引起力量分散、人员紧缺等问题，避免开发人员将大量的时间和精力浪费在旅途中，同时节约大量的差旅费用。,(3) 代码对象库的建立。软件代码是软件开发人员脑力劳动的结晶，也是软件公司的宝贵财富，长期开发过程中形成的各种代码对象就如同一个个已生产好的标准件一样，是快速生成系统的组成部分。一个长期的事实是：一旦某个开发人员离开工作岗位，其原来所做的代码便基本成为垃圾，无人过问。究其原因，就是没有专门对各个开发人员的有用代码对象进行管理，没有把使用范围扩大到公司一级，没有进行规范化，没有加以说明和普及。配置管理对软件对象管理提供了一个平台和仓库，有利于建立公司级的代码对象库。,(4) 建立业务及经验库。通过配置管理，可以形成完整的开发日志及问题集合，以文档方式伴随开发的全过程，不以某个人的转移而消失，有利于公司积累业务经验，无论对版本修改还是版本升级，都具有重要的指导作用。 (5) 量化工作量考核。传统的开发管理中，工作量一直是难以估量的指标，靠开发人员自己把握，随意性很大；靠管理人员把握，主观性却又太强。采用配置管理工具，开发人员每天下班前将修改的文件上传，记述当天修改的细节，这些描述可以作为工作量的衡量指标。,(6) 规范测试。采用配置管理，测试工作有了实实在在的内容，测试人员根据每天的修改细节描述，对每天的工作做具体测试，对测试人员也具有可考核性，这样环环相扣，减少了工作的随意性。 (7) 加强协调与沟通。采用配置管理，通过文档共享及其特定锁定机制，为项目组成员之间搭建交流的平台，加强项目组成员之间的沟通，做到有问题及时发现、及时修改、及时通知，但又不额外增加太多的工作量。 从这些具体作用可以看出，配置管理确实能够解决困扰软件项目经理的很多问题。,12.2 软件配置管理的相关概念 12.2.1 软件配置项 软件配置管理的对象就是软件配置项(Software Configuration Item, SCI)。软件配置是指一个软件产品在软件生命周期各个阶段产生的各种形式和各种版本的文档、程序及其数据的集合，软件配置项就是该集合中的一个元素。例如，需求规格说明书、设计规格说明书、源代码、可执行程序、安装包、测试计划、测试用例、测试数据、用户手册和项目计划等。另外，构造软件的工具和软件赖以运行的环境也应作为软件配置项来管理，例如操作系统、开发工具、数据库管理系统和编辑器等，这些工具和环境要与特定版本的软件产品相匹配，从而在任何时候都能够构造和运行软件的任一版本。,1. 软件配置项的状态 在软件生命周期中，一般包括制定计划、需求、分析、设计、实现、测试和运行维护等状态。与此相似，软件配置项可划分为设计态、测试态、受控态和运行态4种状态，状态联系如图12.2所示。,图12.2 软件配置项的4种状态(这4种状态之间沿箭头方向进行转换，进入受控态就表示配置项已经过测试，可以进入配置库，受控态需要交付就进入运行态，进入产品库),这4种状态相互之间的联系具有方向性，沿图中实线箭头所指方向的状态变化是允许的，虚线表示为了验证或检测某些功能或性能而重新执行相应的测试，一般不沿虚线变化。 2. 软件配置项的版本 软件配置项也有不同的版本，配置项和配置项的版本类似于面向对象的类和实例。配置项可以看成是类，版本看成是类的实例。例如，图l2.3表示了数据库设计说明的配置项。数据库设计说明的不同版本对应于数据库设计说明的实例。配置项的不同版本是从最原始的配置项(相当于配置项类)逐渐演变而来的，尽管每个都不相同，但是具有相关性。,图12.3 软件配置项类及实例(配置项和配置项的不同版本类似于面向对象的类和实例),3. 软件配置项的分类 在软件开发过程中，最早的软件配置项是系统需求规格说明书。随着软件开发过程的不断深入，需要纳入管理的各种工作产品越来越多，软件配置项的数量也随之上升，而软件配置管理的目的是在软件项目的整个生存周期内建立和标识软件配置项，并对其进行控制管理和跟踪维护，保证其完整性和一致性。这样软件配置管理的作用将清晰可见。通过对软件配置项进行分类，可以加强对软件配置项的管理。软件配置项的分类如表l2-1所示。,表12-1 软件配置项的分类,12.2.2 基线 1. 基线的定义 基线是一个或多个配置项的集合，它们的内容和状态已经通过技术复审，并在生存期的某个阶段被接受了。一旦配置项经过复审并正式成为一个初始基线，那么该基线就可以作为项目生存期开发活动的起始点。 IEEE对基线的定义是这样的：“已经正式通过复审和批准的某规约或产品，可作为进一步开发的基础，只能通过正式的变更控制过程才能改变。”所以，根据这个定义，在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等，非基线配置项可能包括项目的各类计划和报告等。,基线代表了软件开发过程的各个里程碑，标志了一个开发过程阶段的结束。对于已成为基线的配置项，虽然可以修改，但是必须按照一个特殊的、正式的过程进行评估，确认每一处修改，只有批准的修改才能安排资源来实施修改。相反，对于未成为基线的配置项，可以进行非正式修改。在开发过程中，在不同阶段要建立各种基线，因此基线是具有里程碑意义的一个配置。,虽然基线可在任何级别上定义，但是一般最常用的软件基线如图12.4所示。基线提供了软件生存期中各开发阶段的特点，其作用是把开发阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果。在交付项中确定一个一致的子集，作为软件配置基线，这些版本一般不是同一时间产生的，但是具有在开发的某一特定步骤上相互一致的性质，例如系统的一致、状态的一致等。基线可以作为一个检查点，正式发行的系统必须是经过控制的基线产品。,图12.4 软件基线示意图(基线可以作为一个检查点，以便检查与肯定阶段成果),2. 建立基线的原因 建立基线的三大原因是重现性、可追踪性和报告。 (1) 重现性：指及时返回并重新生成软件系统给定发布版本的能力，或者是在项目早期重新生成开发环境的能力。 (2) 可追踪性：指建立项目部件之间的前承后继关系，目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。 (3) 报告：来源于一个基线内容同另一个基线内容的比较，基线比较有助于调试并生成发布说明。,3. 基线的分类 一般来说，对于大多数生存周期模型而言，存在四种基线。每种基线都表示一个参照点，可以作为项目进一步开发的起点。在某些情况下，客户依据这些基线进行评审和支付费用。这四种基线是：功能基线、分配基线、开发基线和产品基线。 (1) 功能基线。功能基线描述系统应该能够执行的功能，是在系统需求评审和系统设计评审之后所建立的配置。通常，功能基线是软件开发项目的初始基线。功能基线中的文档规范了软件配置项的所有必要的功能特性，包括为表示这些特性的实现所要求的系统层的测试、必要的接口特性、性能需求、质量属性及设计约束等，但并不区分哪些是由软件执行的，哪些是由硬件和操作系统完成的。,(2) 分配基线。分配基线有时候称为软件需求基线。它描述了被开发的软件所能执行的功能，是在软件需求评审之后建立起来的配置，是系统分配给软件的需求配置，一般是软件项目组在完成对系统的功能性需求和非功能性需求分析后，经过客户参与评审确定后的软件需求规格说明。 (3) 开发基线。开发基线是一个不断演化和积累的基线，出现于分配基线和产品基线之间。软件开发项目组可以根据项目的需要设置开发基线，也就是说在详细设计完成之后设立一个基线，包括详细设计报告、概要设计报告和数据库设计等设计文档。,(4) 产品基线。产品基线是在经过系统层验证和确认后，确信可交付的产品满足需求基线中的所有需求项所建立起来的配置。因此，产品基线完整地记录了软件的最终版本。对外发布的产品都来源于这一产品基线，并支持产品的发布版本。该基线也是任一后续版本开发的起点。 这四种基线的划分在项目开发周期中对应的位置如图12.5所示。,图12.5 基线规划图(分配基线、开发基线和产品基线主要是针对软件项目的配置基线),4. 建立基线的优点 (1) 基线为开发部件提供了一个定点和快照。 (2) 新项目可以从基线提供的定点处建立。作为一个单独的分支，新项目将与随后对原始项目所进行的变更进行隔离。 (3) 各开发人员可以将建有基线的构件作为在隔离的私有工作区中进行更新的基础。 (4) 当认为更新不稳定或不可信时，基线为团队提供了一种取消变更的方法。 (5) 可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。 (6) 定期建立基线，以确保各开发人员的工作保持同步。,12.2.3 版本 版本是某一配置项已标识了的实例。版本用来定义一个具体实例应该具有什么样的内容和属性。随着软件的开发进展，版本也在不断地演变，这些不同配置项的不同版本构成了一个复杂的版本空间。 一个系统版本就是一个系统实例，在某种程度上有别于其他系统实例。系统新版本可能有不同的功能和性能，可能修改了系统错误。有些版本可能在功能上没有什么不同，只是为不同的硬件或软件配置而设计的。如果版本之间只有细微区别，有时就把其中的一个版本称作另一个版本的变体。,一个系统的发布版本指的是要分发给客户的版本。每个系统发布版本都应该包含新的功能或是针对不同的硬件平台。一个系统的版本要比发布版本多得多，因为机构的内部版本是为内部开发或测试而创建的，有些根本不会发布到客户手中。,版本的演变一般有串行演变和并行演变两种方式。串行演变所形成的每个新版本都是由当前最新版本演变而来的。这样，各个不同版本按演变过程就形成了一个简单链，称为版本链。在这种方式下，版本的演变是按照一对一的映射关系前进的，通常是为了弥补缺陷、提高性能和适应环境。并行演变采用一对多的方式进行。在实际应用中，这两种版本演变形式通常结合在一起，形成更为普通的带分支的版本图，也称为版本树。版本树反映了项目开发演变的历史，版本树示例如图12.6所示。,图12.6 版本树示例(版本树直观地反映了版本的演变过程),在图12.6中，共有3条版本链，分别是“1.01.11.2 1.31.41.5”、“1.01.11.1.11.1.2”和“1.01.11.2 2.02.12.23.03.0.1”。其中，“1.01.11.21.3 1.41.5”是串行演变；从1.1开始，“1.11.2”和“1.11.1.1”是并行演变。 为了建立特定的系统版本，必须确定系统组件的版本。在大型软件系统内，有数以百计的软件组件，其中每种组件都可能有诸多不同的版本。版本管理规程应该规定明确标识每个组件版本演变的方法，这样在需要进一步变更时，可以查找到组件的具体版本。组件版本的变化过程如图12.7所示。,图12.7 组件版本的变化过程(版本管理可以方便地标识每个组件版本演变的过程),12.2.4 配置数据库 配置数据库(Configuration Management Database, CMDB)用于记录与配置有关的所有信息，帮助评估因系统变更带来的影响，并提供有关配置管理过程的管理信息，也称为软件受控库。除了定义配置数据库的模式以外，还要定义记录和检索项目信息的规程，这是配置管理规划过程的一部分。 配置数据库不仅包含有关配置项的信息，可能也包含组件用户、系统用户、可执行平台及计划变更等信息。配置数据库必须能够对各种系统配置查询做出应答。,理想情况下，配置数据库与版本管理系统集成到一起，版本管理系统负责存储和管理正式项目文档。这种方法(某些集成CASE工具支持该方法)使得变更与受变更影响的文档和组件间的直接链接成为可能。例如，设计文档和程序代码之间的链接能得到维护，这样在提出一个变更时，可以较容易地找出所有必须修改的地方。 由于配置管理的集成CASE工具非常昂贵，许多公司在进行配置管理时并不考虑使用，而是把配置数据库作为一个独立的系统加以维护，配置项存储于文件或版本管理系统中，例如CVS、Subversion就是版本管理系统。,配置数据库存储配置项的有关信息并在版本管理系统或文件存储中索引它们的名字。虽然这种做法费用低廉、使用灵活，但是配置项的变更可能不经过配置数据库，因此不能确定配置数据库是否反映了系统的最新状态。 建立构建脚本是软件项目的有效实践，配置数据库不仅要存储各种文档和源代码，还要存储环境配置，甚至是构建脚步。,12.3 软件配置管理的活动 实施软件配置管理就是要在软件的整个生命周期中建立和维护软件的完整性。软件配置管理是组织和管理各种软件产品及文档，控制其变化的一系列活动，这些活动将贯穿软件产品的整个生命周期。 在项目管理过程中，需要解决的问题有很多，例如采用何种方式标识和管理已存在程序的各种版本、在软件交付用户前后如何控制变更、利用什么办法来估计变更引起的各种问题等，这些问题归结到软件配置管理中的活动方面。通常的软件项目配置管理包括以下12项活动：,拟定配置管理计划； 配置标识； 确定配置管理范围； 确认和记录配置项属性； 为配置项定义标识符； 确定配置基线； 确定配置结构； 确定配置项命名规则； 配置项控制； 配置状态报告； 配置审计； 配置管理数据库的备份、存档和保管。,通过上述活动，可以实现软件配置管理，其主要流程如图12.8所示。,图12.8 软件配置管理的主要流程(项目组制定SCM计划，进入配置数据库， 供开发人员 和管理人员使用。其中PTO(Project Tracing and Oversight)即 项目跟踪与监督),根据图12.8，对配置管理流程中各项活动进行分析，可将软件配置管理流程中具体实施的活动归纳为以下5个主要活动： 配置标识：在系统演化过程中标识中间的软件产品； 版本控制：记录每个配置项的发展历史，并控制基线的生成； 变更控制：在整个生命周期中控制中间软件产品的变化； 状态报告：记录和报告软件的变化过程； 配置审计：用于保证软件产品是依照需求、标准和合同开发出来的。,12.3.1 配置标识 在软件开发过程中，随着软件生命周期的推进，产生的配置项越来越多，为了控制和管理方便，所有的软件配置项都应该按照一定的方式来命名和组织，这是进行软件配置管理的基础。 配置标识能唯一地标识软件配置项，并在技术文档中记录其功能特征和物理特征，使它们可以通过某种方式访问。配置标识的目标是在整个系统生命周期中标识系统的构件，提供软件和软件相关产品之间的跟踪能力。软件配置标识是软件配置管理的基础性工作，是管理配置的前提。,每个软件配置项都包括名字、描述、资源列表和实际存在体4个部分。此外，在对配置项进行标识时，还要考虑配置项之间的关系。 配置标识管理是一个配置项的选择、命名和描述的过程。首先，把一个软件系统分成便于进行配置管理的配置项；接着，按照一定的方法对这些配置项命名、编号，便于管理人员和开发人员明确该系统各配置项之间的相互关系，包括各个文档之间以及文档与代码之间的联系；最后，对每个组成部件的功能、性能和物理特性进行必要的描述。,1配置标识的对象 配置标识的对象包括： (1) 各种功能规格说明和技术规格说明，以及软件项目的特殊功能和开发过程中使用的方法； (2) 所有受到功能和技术规格影响的开发工具，这些工具不仅包括用于创建应用程序的开发工具，而且还包括对比、调试和图形化工具； (3) 所有与其他软件项目和硬件的接口； (4) 所有与软件项目相关的文档和计算机文件，例如文本文件、源程序、文档和图形，以及任意的二进制文件。 标识软件项不仅需要处理程序项和需求之间的联系，一般来讲，还需要使用多种方式来标识软件项，以及软件项同软件产品之间的关联。,2. 配置标识的活动 配置标识的主要活动包括选择配置项、制定标识方案和存取方案。 (1) 选择配置项。配置项是配置管理的最小单元，一般由一个或多个文件组成。软件组织可以根据不同的原则选择配置项。 (2) 制定配置项标识方案。选择好配置项后就要为其选择适当的标识方案。配置项的标识使配置项被唯一识别，因此，标识方案应该显示软件演化的层次结构和可追溯性。常用的方案是数字方案，即配置项由名称和数字版本号标识。,一般情况下，配置项的标识以记录该配置项的计算机文件为单位，标识形式由文件名、作者、文件修改日期以及使用配置管理工具检入的时间等标识。与软件有关的文档也应使用配置管理工具进行管理。,(3) 制定存取方案。软件组织需要建立软件配置库，存放软件配置。软件项目组的所有成员都可根据权限存取配置库中的配置项，同时必须协调各成员之间的关系，使每个成员所能执行的权限不超过权限的范围。例如，如果某个程序员只负责一个模块的开发，那么就不能有对其他模块源码的修改权。 有效的配置标识是其他配置管理活动的前提。如果闲置项和相关的配置文档没有被很好地标识，想要控制这些配置的变更、建立准确的记录和报告、审核配置的有效性是不可能的。不准确或不完全的配置项标识和配置文档可能会导致产品延期交付，或花费很高的维护费用。,3. 配置标识框架 配置标识是软件生存周期中产生的所有文档的总称，例如一个函数、一个模块说明、一个等价类的测试数据、一份软件结构图等。配置标识定义配置项的名称、与其他配置项的联系和版本信息等。由于文档之间存在着复杂的关联，一旦要求对配置项进行更改，尤其是当软件需求发生变化时，就不只是更改一个配置项，而且还要修改其他文档。因此，在标识配置项时，应考虑其名称、描述、资源、变化、版本方面的内容。,下面介绍一个典型的配置标识框架模型。,上面的配置标识框架中，供应资源是由本配置产生并能为其他配置项所利用、参考的数据/变量/功能等实体，需求资源则是仅供本配置项所使用、参考的其他配置项供应的资源。 一个配置标识包含该配置项的所有版本。实际上，新版本是在某一旧版本的基础上作一些变化而形成的，这就构成了一条树状的版本链。在一条版本链中各版本存在很多共性，也有一些差异，反映在资源、接口和文档内容等方面。因此，在实际存储时，仅存储配置项的最初版本内容和版本变化信息。,4. 要注意的问题 配置标识功能论述了与基线中包含的软件配置项的标识以及基线本身的标识有关的问题。“标识”用来确定如何识别产品的所有部件和由部件建造的产品基线。在标识过程中，要考虑下面几个关键点： 必须识别出每个软件配置项并赋予它唯一的标记。 识别和标记计划必须反映产品的结构。 必须建立识别和标记软件配置项的标准。 必须建立识别和标记所有形式的测试和测试数据的标准。,必须建立识别建造基线需要的支持工具的标准。工具中需要包括编译程序、连接程序、汇编程序、make文件以及其他用来翻译软件和建造基线的工具，这一点很重要。它确保在基线被变更、替换或更新很长一段时间后，开发人员总能够重新获得由这些工具产生的信息。 要特别关注集成到软件产品中的第三方软件，特别是那些存在版权或版税问题的软件。必须建立第三方软件如何集成到软件产品的标准，从而能够容易地删除、替代或升级这些软件。 要特别关注来自其他产品中正被重新使用的软件或打算重用的软件。 要特别关注打算替换掉的原型软件。,总之，配置标识是配置管理的基础，唯一地标识软件配置项和各种文档，使它们可以通过某种方式访问。配置标识的目标是在整个系统生命周期中标识系统的组件，提供软件和软件相关产品之间的追踪能力。,12.3.2 版本控制 这是典型的由于版本管理混乱带来的麻烦，很大程度上受工作环境的影响，通过版本管理工具就可以有效地解决这类问题，这也是目前流行的软件工程和项目管理实践。 软件配置管理的一个必备功能就是在软件产品开发时及交付后，可靠地建立和重新创建版本。在开发时会建立产品的中间版本，并进行常规测试。因为经常需要回到以前的版本，所以就需要能准确地重建以前的版本。开发完成后，还需要管理交付给用户的软件版本，因而必须对所有必要的信息进行维护，例如编译程序、连接程序以及使用的其他工具，以确保每个已交付的软件产品版本能够重建。常见的版本控制流程如图12.9所示。,图12.9 版本控制流程图(这是版本控制的过程，开发人员先访问当时的最新 版本并下载到本地，修改调试后提交新版本，在此基础上生成最新版本， 并让其进入源代码库),版本控制是所有软件配置管理系统的核心功能，负责为配置库中的所有元素自动分配版本标识，并保证版本命名的唯一性。版本控制的目的是便于对版本变化加以区分、检索和跟踪，以表明各个版本之间的关系。一个版本是软件系统的一个实例，在功能和性能方面与其他版本有所不同，或是修正、补充了前一个版本的某些不足。 1. 版本控制的内容 版本控制包括了对配置项版本的一系列操作控制。一般来说，版本控制包括检入检出控制、分支和合并、历史记录。,1) 检入检出控制 软件开发人员对源文件的修改不能在软件配置管理库中进行，对源文件的修改依赖于基本的文件系统并在各自的工作空间中进行。为了方便软件开发，需要不同的软件开发人员组织各自的工作空间。一般来说，不同的工作空间由不同的目录表示，对工作空间的访问，由文件系统提供的文件访问权限来加以控制。 访问控制需要管理各个人员存取或修改一个特定软件配置对象的权限，例如，软件开发经理一般比软件开发人员具有更高的权限。开发人员能够从库中取出对应项目的配置项，也可以修改，并检入软件配置库中，对配置库中的版本进行“升级”；软件开发经理除了具有开发人员的所有执行权限外，还可以确定多余配置项，而且可以删除多余配置项。,同步控制的实质是版本的检入检出控制。检入就是把软件配置项从用户的工作环境存入软件配置库的过程，检出就是把软件配置项从软件配置库中取出的过程。检入是检出的逆过程。同步控制可用来确保由不同人员并发执行的修改不会产生混乱。,2) 分支和合并 进行版本分支(以一个已有分支的特定版本为起点，但是独立发展的版本序列)的人工方法就是从主版本(又称主干)上复制一份，并做上标记。在实行了版本控制后，版本分支也是一份副本，这时的复制过程和标记动作由版本控制系统完成。进行版本合并(来自不同分支的两个版本合并为其中一个分支的新版本)有两种途径，一种是将版本A的内容附加到版本B中；另一种是合并版本A和版本B的内容，形成新的版本C。 对文件来说，分支与合并的结果就是形成具有图结构的版本历史，即版本图，如图12.10所示。,图12.10 版本的分支与合并(从版本图中可以直观地了解版本的历史),进行版本分支有以下几个目的： 代表独立的开发路径，例如开发过程和维护过程； 代表组件的不同变体； 代表实验性的开发，该分支在以后可能会丢弃，或合 并到主分支中； 适应两个开发人员并发地修改同一组件的情况，此时分支仅暂时存在，一旦两个开发人员修改完毕，将被合并。 合并就是将独立发生在两个版本分支上文件的修改合成到其中一个分支上，从而形成该分支上的一个新版本。合并包含两方面的内容：第一是两个文件版本内容的实际合并；第二是在版本图上作为版本历史的一部分进行反映。,3) 历史记录 版本的历史记录有助于对软件配置项进行审计，有助于追踪问题的来源。历史记录包括版本号、版本修改时间、版本修改者和版本修改描述等最基本的内容，还可以有其他一些辅助性内容，例如版本的文件大小和读写属性等。 2. 版本编号的方法 版本号是配置项的某个版本的唯一标识。源代码文件、文档文件、软件产品整体(源代码整体或安装包)都有版本号，这里主要关注的是软件产品整体的版本编号方法。合理的版本编号策略可以使软件配置管理更为简便和有序。目前，业界尚无统一的软件版本编号方法，但是常用的方法有两种：数字顺序型编号和属性编号。,1) 数字顺序型编号 数字顺序型编号通常会分为几段，不同段上的数字的变化，标志着产品不同类型的变化。例如，一种典型的版本编号策略是：版本号分为3段，形如X.Y.Z，其中X为主版本号，Y为特征版本号，Z为缺陷修复版本号。主版本号的增加表示提供给客户的主要产品功能的增强，特征版本号的增加表示产品新增了一些特征或做了一些重要修改，缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。当某一级版本号增加时，其下级版本号要清零。例如，软件的一个版本是1.3.2，如果该版本新增了一些特性，使特征版本号增加为4，那么缺陷修复版本号要复位为0，所以整个版本,号就变为1.4.0。同样，如果软件做了重大改进，提升了主版本号，那么特征版本号和缺陷修复版本号就都要复位为0，这样就得到了版本2.0.0。 如果要标记软件的测试版和测试版，可在上述3段数字版本编号后面增加一个大写字符A或B来分别表示版本或版本。例如，1.2.4A或1.2.4B。如果存在多次的 发布和发布，可在A或B后面添加一个数字来说明发布的次数，例如，1.2.5A1，1.3.0B2等。,以上版本编号策略是面向用户的，在开发团队内部，对版本号也有要求。例如，测试团队需要区分测试对象的版本，软件的每次对外发布，可能也对应着不止一次内部测试。简单的解决方法是，版本号中再增加一段，说明是新版本软件发布前的第几次送测，或称第几次内部发布。例如，1.0.3.0是发布版本1.0.3在发布前的第1次送测，而1.0.3.1是第2次送测。当然，新增加的这一段数字不必让外部用户看到。,2) 属性编号 数字顺序型版本编号的特点是简单易用，但是包含的信息有限，而且如果段数太多的话，就难以让人识别和理解。因此在有些情况下，开发团队会使用属性版本编号，就是把版本的一些重要属性反映在版本标识中。属性版本编号可以包括的属性有：客户名、开发语言、开发状态、硬件平台、生成日期、技术特征和质量状态等。例如，下面的这个版本号就包含了软件的生成日期和时间，以及技术特征(native threads, jit)。 J2SDK.v.1.2.2: 11/31/2013-18:00, native threads, jit-122 当然，像这样复杂的属性版本号一般只应用于开发团队内部，不显示给用户。,现在的版本控制通常由CASE工具来支持。工具用于管理对每个系统版本的存储，并控制对系统组件的访问。这些组件必须能够从系统中抽取出来进行编辑，当将其重新放入系统的时候，就构成了一个新的系统版本，由版本管理系统给它一个新的名字。 版本控制是全面实行软件配置管理的基础，可以保证软件技术状态的一致性。版本控制是配置管理的基本要求，可以保证在任何时刻恢复任何一个配置项的任何一个版本。版本控制记录了每个配置项的发展历史，这样就保证了版本之间的可追踪性，也为查找错误提供了帮助。版本控制也是支持并行开发的基础。,12.3.3 变更控制 变更是软件开发的固有属性。变更会造成很大的麻烦，例如客户不断提出需求变更，导致重新设计和实现系统，造成大量返工。事实上，软件开发中不可避免地会存在编码错误等问题，这就需要修正错误。在开发过程中，随着用户和开发人员逐步掌握更多的信息，他们也会对已经确定了的设计方案或设计细节进行改进。修改错误或进行改进都是变更。,软件开发过程中的变更以及相应的返工，会对产品的质量造成很大的影响。软件变更的不可避免性并不意味着软件可以任意修改。变更控制是软件配置控制的关键活动，指在整个软件生命周期中控制软件的变化，建立一套对软件配置项的修改进行有意识的控制机制，防止在软件开发过程中因盲目修改造成混乱，主要是进行基线管理以及对基线更改控制过程的处理。配置管理最初就是为了控制变更而提出的，能否解决好变更控制问题是衡量软件组织成熟度的一个标志。,1. 变更的涉及面 变更是不可避免的，也是必不可少的，变更和变更控制是矛盾的统一体。由于变更的内容和变更的幅度都会直接影响到整个项目，所以时刻需要考虑到变更的波及面。在瀑布模型的生命周期中，变更的波及面如图12.11所示。,图12.11 变更的波及面(越早形成的基线发生变更，变更的影响就越大，波及面 就越宽。反之，越晚形成的基线发生变更，变更的影响就越小，波及面就越窄),在图12.11中，如果在系统工程阶段的工作需要发生变化，那么软件生命周期中的各个阶段都有可能受到影响，这些阶段所有相关的软件配置项也都会或多或少地受到影响；如果代码编写阶段的工作需要变化，则软件测试和系统测试阶段的工作都要受到影响；如果在代码编写阶段发现错误，该错误是由需求阶段的工作造成的，则需要需求及以下阶段都要进行相应的修改。,变更控制需要记录每次变化的相关信息，查看这些相关信息，有助于追踪出现的各种问题。记录正在执行的变化信息有助于做出正确的管理决策。软件配置管理对基线管理的任务之一是追踪更改的变化过程，以保证对软件开发过程的可见性和可追踪性。对基线更改变化过程的追踪有两部分内容：一是对基线更改版本的跟踪，另一个是对其更改原因以及更改结果的追踪。,2. 变更的分类 一般来说，软件的变更通常有功能变更和错误修补变更两种类型。 (1) 功能变更。功能变更是为了增加或删除某些功能或者为了改变完成某个功能的方法而进行的变更。这类变更如果代价比较小，对软件系统其他部分没有影响或影响很小，就应该批准这类变更。反之，如果变更的代价比较高，或者对软件系统其他部分影响比较大，就必须权衡利弊，以决定是否进行这类变更。,(2) 错误修补变更。错误修补变更是为了修复漏洞而进行的变更，是必须进行的，通常不需要从管理角度对这类变更进行审查和批准。但是如果在造成错误阶段的后面发现错误，例如在实现阶段发现了设计错误，就必须遵照标准的变更控制过程，把变更正式记入文档，把所有受变更影响的文档都做相应的修改。,3. 变更控制的内容 变更控制作为配置管理的主要内容之一，在操作过程中有严格的控制流程，以保证配置项的一致性和有效性。 一般变更控制的内容如下： 确定变更批准人的责任范围和权限； 建立变更控制流程，实施变更控制； 对配置项变更进行管理； 对基线变更进行管理； 设立两个变更授权机构，变更控制委员会(Change Control Board，CCB)和项目经理； CCB成员为项目级的，可因项目的不同而有所不同，由高级经理在项目任务书中定义。,4. 变更控制的类型 变更控制一般分为两类：一类是基线的变更控制，另一类是软件版本的变更控制。 1) 基线的变更控制 基线的变更是指在一个软件版本的开发周期内对基线配置项的变更，主要包括基线的应用和更新等活动。基线变更所涉及的操作主要包括基线标签的定义和标签的使用。基线标签属于严格受控的配置项，命名必须严格按照相关的规范来进行。基线在建立时，按照角色职责的分工，须经CCB同意并正式地将该基线的标识和作用范围通知系统集成人员，由后者负责执行；基线一旦划定，由该基线控制的各配置项,的历史版本均处于锁定或严格受控状态，任何对基线位置的变更请求都必须按变更控制流程提交CCB批准，然后由系统集成人员执行。 2) 软件版本的变更控制 软件版本的命名规范应事先制定，并按照开发计划予以发布使用。在软件版本的演化过程中既需要从以前的版本中继承，又需要相对的独立性，所以对于子版本(例如某特定用户的定制版本)而言，就需要对一系列配置项从统一的开发起始基线所确定的版本上建立新的分支，然后在此分支上开发新的版本。因此在这样的变更控制流程中，受控的对象还应该包括特定的分支类型，以及工作视图的选取规则，同时配置管理员将在这一过程中担负更多的操作职责。,5. 变更控制的流程 典型的变更管理规程涉及如何提交变更请求、如何对变更请求进行复审以便决定是否实施、由谁实施、如何实施和如何确定变更请求准确实施完成等方面。通常规范的变更管理过程都应包含以下步骤(如图12.12所示)。,图12.12 变更控制流程(泳道图很好地反映了各种不同的人员执行的活动和责任),(1) 变更请求。变更请求是实施变更控制的第一步，也是必不可少的一步。变更请求可以由任何人提出，包括用户和开发人员。典型的变更请求有清除缺陷和适应运行平台的变更，软件扩展提出的要求(例如增加功能、提高性能等)，以及对已有功能的优化和改进等。变更请求有多种形式，而且来自不同的地方，例如来自内部及外部的错误报告，来自市场及工程部门的功能增强请求，需求、设计及文档变更请求等。,(2) 变更请求评审。变更请求评审是根据变更管理规程、项目目标、变更的必要性、变更实现所需的时间、成本利润分析、变更对系统其他部分的影响以及技术可行性(能否实现)等分析评估变更请求的。一般由变更控制委员会(CCB)召开相应的评估会议，并根据变更的影响范围，邀请相关人员参加。 如果有必要，可以设立不同级别的CCB，对不同层次的变更申请进行控制，在这种情况下，项目组可以在配置管理计划中以树状结构说明其从属结构，并在计划中明确说明CCB的授权范围，在变更管理规程中规定由谁来评估变更。一般在大型项目中，对已基线化的配置项的变更，由变更控制委员会评审；在较小型项目中，由项目经理评估。,(3) 批准变更。根据评估决定接受变更或拒绝变更，对接受的变更也会有不同的处理方式，例如立即实现变更，或在下一个版本的产品中或下一期项目中再实现变更。不同的企业会根据项目情况将变更分类，对不同类型的变更采取不同的措施。可以将变更分成下列几种类型： 增强型：变更要求对已批准的项目功能进行增强。 改进型：变更不会造成功能更改，将使配置项的维护更加有效率。 纠错型：变更对错误进行修正。 通常，对纠错型的变更会根据系统的质量标准决定是否批准变更，对增强型和改进型的变更要根据评估结果决定是否批准变更。,(4) 实现变更。如果接受了变更请求，就开始区分变更的优先级，根据优先级计划变更实现方案，包括技术方案、人员安排和任务分配等。不同企业会根据项目情况区分变更优先级，并对不同优先级的变更采取不同的实现方案。变更可分配下述几种优先级： 高：严重地影响一些用户或许多用户。在变更请求提交的5个工作日内要对所做改动的版本进行全面测试。 中：对用户造成不方便或存在主要问题但可以采取相应的变通方法处理。在变更请求提交的20个工作日内要对所做改动的版本进行全面测试。 低：小问题。在变更请求提交的3个月内，在下一个发布版本中进行改动。,(5) 确认变更。实现的变更要经过审计，审计由质量控制小组或负责管理产品的发布人完成。 (6) 发布变更。配置管理人员要记录和追踪变更，采取措施保证变更在受控状态下进行，并发布变更请求的状态。变更请求可具有下列状态： 提交：变更请求提交给配置管理人员。 拒绝：变更评审小组或个人拒绝变更请求。 接受：变更评审小组或个人接受变更请求。 挂起：变更请求被挂起，以后再做决定。 已验证：变更请求要求的更改已执行和验证。 关闭：验证并归档配置项，并将更新的配置项提交给用户(例如通过版本发布)。,12.3.4 状态报告 1. 状态报告 为了清楚、及时地记载软件配置的变化，不至于到后期造成贻误，需要在开发的过程中对每个软件配置项做出系统的记录，以反映开发活动的历史情况。配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况的。记录主要包括软件配置项的