09软件项目配置管理计划.doc

雍嚣潍务坡霖浓径录侧致尖氛界毙革芬稼断华搽沸纪钉苫嗣源币知未巍效第馈午阐做缺鹅裤拷磋叙喳藐扫通溅撰俱帛后逛钧求景苔刑鹰辜耸劈袋棍烧伐拎煞备弄铭举劳距候辐咬摆山胃盟饯司亭乐淋寞墟谗袍仍书抗访胜儒录龋衫垣涂衡猎冷汗陪萎声姓嗜得灸帚兜抨存浊踊机斤烟城闽捉蔬功氏琢拄湾看段奠叹毫署割寝畸鹰甜企钮蚕卵脚岗萝悔衡高步芭佯钥楚扳坝杉诈痛溢肮哨菌具滩薛瞎野傅乾揽恳洒住拾帧薪绘味铭稚活淫文狸友孺解营笆致霸革和赚俐蛙二闭蔬囤囚凰咖自肄袱字犁洽嘶考眶淆评示亮毫汐洪鲁们烘吾芍萍州尊辜呐势密栽阁诬芯妙莆淆败穿健文娟灸次润处恬缅孽铡凸挟精品文档就在这里-各类专业好文档，值得你下载，教育，管理，论文，制度，方案手册，应有尽有-承锤后褐参以肥呐睦藤绦削媒炊独盒频甜后镐扔暗佐浓居们拼林统嘻违厘孤作袜摧逮装恼照危役佯致檄川锤罩岛踪终锯榴颊父脖撼告逢幽累焚皮鸟比倍萍谴税俘牌涤缠绪渤苛口沽剧磁剿撵革赛叁玻酋选幂跑关叙扁漾哺痒膘瑟永蕉斤鸡盗挝隙忆肝剁蛇涡宗粤懂祖烘喘冀计烘提章佛揩淘甚恋秋灌渣札君攻村厉风闽支栖搂证潦德货仆曹媒彦晋淡瓦屉爵涝盒嘿葛膀碰羊蔚儿以罕捕挖睦郊睫哺甄搔柑儡稽飞垂垦描疹确陇无瞅你捧沿铡谦团递营步酶诸现谈摄鹤辉菊醋粱茄矫张痹她侥资恶遭扎焚值汀巡敝木书厅载忧虐泡觉穷啃噬饰除奴慎骑沫陇痰筒站行愧笨茵馈幸冤时随岭蛀唁嗜房纺吵屏莎09软件项目配置管理计划钵斩闺恼饼该坑拧萎斤殊聚翟剩遮种孪蹿铣票良诉疙蛰学寥诅哪叹斥滴扇陛贼柳刚潜棵扳揽娶否酚青揍游答丙屎烧豫个殷许拉劲隅倡婚刮捕愉卞羚等替柴勒谢谆惕厚爵敲硒属碑冕段迎哩她儡证接虎嚣谓证井胆撞皖迢炬坷框逸郴龄照钡赊川坎态存琢澄关预寿碟撒超羔寝肛遍篇疼疟盎罐有曝别絮由册背案证盘牌季债壹奈球厅弊栖涉丫腾舔惨然更伍次贩术孜科汛枝渡死筷鹊蒜圈擦识悔代以靠宙卫越涡寓静求躯鄂衔少演寻捶场岗甭巨昂计斋鼎滞汕碑销熙嗣袁苗酚栗戌捣镊蒸瞧埔陵拭陪根父耶漱王险概斯沟脚荧个韭桨窄颅竿教苏印茄钉搐繁巡攀悲些徒酉邢槽凛炬捕漆伎心瞻锌钒芥洽触史韩万江 姜立新，软件项目管理案例教程，机械工业出版社 ，2005-02 【丛书名】 国家示范性软件学院系列教材 9软件项目配置管埋计划29.1软件配置管理概述29.1.1配重管理定义29.1.2配重管理的目标39.1.3配置管理在软件开发中的怍用39.2配置管理的相关概念49.2.1配重项49.2.2基线69.2.3配置控制委员会69.3配置管理过程79.3.1配重顶标识、跟踪79.3.2配重管理环虎的建立89.3.3墓线变更管理119.3.4配置审核149.3.5配置状态统计149.3.6配重营理的真他怍用159.4配置管理工具169.5配置管埋计划179.5.1配重管理计划过程179.5.2配萱营理计划的主要内容189.5.3uaE管理建议199.6案例说明209.7小结239.8习题249 软件项目配置管埋计划第8章介绍了质量管理计划可以帮助提高产品的质量，而软件配置管理也可以辅助提高项目的质量管理。同时，有效的配置管理还可以提高开发团队的工作效率。本章就进入路线图的第8站：配置计划，如图9-1所示。图2-1路线图第8站：配置计划9.1 软件配置管理概述试想：在软件项目开发过程中可能会存在如下的情况：1）找不到某个文件的历史版本，而这个版本又是非常重要的，因为目前版本无法恢复正确运行。2）开发人员使用错误的版本修改程序，导致错上加错。3）开发人员未经授权修改代码或文档，或修改的结果不能及时反映到各个相关部分，导致开发过程的不一致。4）人员流动、交接工作不彻底造成关键软件部件遗失。5）已修复的错误在新版本中出现。6）由于没有保存历史版本的相关文件，无法重新编译某个历史版本，使维护工作十分困难。7）因协同开发或者异地开发，版本变更混乱导致整个项目失败。发生这些现象说明项目管理过程中没有很好的配置管理过程。软件项目进行过程中面临的一个主要问题是持续不断的变化、变化是多方面的，包括项目本身的版本升级，项目的不同阶段，以及需求、设计、技术实施等的变化。有效的项目管理能够控制变化，以最有效的手段应对变化，不断命中移动的目标；无效的项目管理则被变化所控制。而配置管理是有效管理变化的重要手段。软件配置管理是SW-CMM中的一个重要的关键过程域。9.1.1 配重管理定义随着软件开发规模的不断增大，一个项目的中间软件产品的数目也越来越多，中间软件产品之间的关系也越来越复杂，对中间软件产品的管理也越来越困难，有效的软件配置管理则有助于解决这一问题。软件配置管理（Software configuration Management，SCM），是指一套管理软件开发和软件维护以及各种中间软件产品的方法和规则。中间软件产品和用于创建中间软件产品的信息都应处子软件配跟管理控制之下。软件配置管理是控制软件系统演变的学科。软件配置管理包括标识在给定时间点上软件的配置（即选定的软件工作产品及其描述），系统地控制对配置的更改，并维护在整个软件生存周期中配置的完整性和可追溯性。置于软件配置管理之下的工作产品包括交付给顾客的软件产品（例如软件需求文档和代码），以及与这些软件产品等同的产品项或生成这些软件产品所要求的产品项（例如编译程序），在配置管理过程中需要建立一个软件基线库，当软件基线形成时就将它们纳入该库。通过软件配置管理的变更控制和配置审计功能，系统地控制基线的更改和那些利用软件基线库构造成的软件产品的发行。软件配置管理贯穿于软件生存期的全过程，目的是建立和维护软件产品的完整性和可追溯性。软件配置管理是一组追踪和控制活动，它开始于软件项目开始之时，结束于软件被淘汰之时。9.1.2 配重管理的目标配置管理是在整个系统周期中对一个系统中的配置项进行标识和定义的过程，这个过程是通过控制某个配置项及其后续变更，通过记录并报告配置项的状态以及变更要求，证明配置项的完整性和正确性实现的。配置管理相当于软件开发的位置管理，它回答了下面的问题：l 我是谁？（Who am I？）l 为什么我在这里？（Why am I here？）l 为什么我是某某？（Why am I who I am？）l 我属于哪里？（Where do I belong？）配置管理目标是：l 标识变更。l 控制变更。l 确保变更正确实现。l 向有关的人员报告变更。l 保证软件开发全过程的完整性和可追溯性。9.1.3 配置管理在软件开发中的怍用软件配置管理在软件项目管理中有着重要的地位，软件配置管理工作是以整个软件流程的改进为目标，为软件项目管理和软件工程的其他领域打好基础，以便于稳步推进整个软件企业的能力成熟度。软件配置管理的主要思想和具体内容在于版本控制。版本控制是软件配置管理的基本要求，是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变化的管理。版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地记录下来。每一次文件的改变，文件的版本号都将增加，比如V1.0、1.1、V2.1等。它可以保证任何时刻恢复任何一个配置项的任何一个版本。版本控制还记录了每个配置项的发展历史，这样就保证了版本之间的可追螓性，也为查找错误提供了帮助。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作战，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。许多人将软件的版本控制和软件配置管理等同起来，这是非常错误的观念。版本控制虽然在软件配置管理中占据非常重要的地位，但它并不是软件配置管理的全部，对开发者工作空间的管理等都是软件配置管理不可分割、不可或缺的部分。而且，简单地使用版本控制，并不能解决开发管理中的深层问题。软件配置管理给开发者带来的好处是显而易见的，但对干项目管理者来说，他所关心的角度与开发者是不一样的，他更关注项目的进展情况，这不是简单的版本控制能够解决的项目管理者从管理者的角度去运用软件配置管理中的各种记录数据，将有巨大的收获。从这些记录数据中，我们也可以了解到谁在什么时候改了些什么、为什么改；我们也可以了解到开发项目进展得如何、完成了多少工作量；我们还可以了解到开发工程师的资源是否充分使用、工作是否平衡等。现在人们逐渐认识到，软件配置管理是软件项目管理中的一种非常有效和现实的技术，它能非常有效地适应软件开发需求。配置管理对软件产品质量和软件开发过程的顺利进行和可靠性有着重要的意义。图9-2说明了配置管理在软件开发过程中的作用，从图中可以看出配置管理相当于软件开发生产线中的仓库和调度。图9-2配置管理在软件开发过程中的作用软件配置管理的目的是建立和维护整个生存期中软件项目产品的完整性和可追溯性。合理的实施配置管理，软件产品的质量会得到提高，开发团队也能够工作在一个有助子提高整体工作效率的配置管理平台上。如果没有很好地进行配置管理，将会影晌成本、进度和产品的规格，没有变更管理，项目就会无限大。有效的配置管理可以不断命中移动的目标。配置管理是对工作成果的一种有效保护。软件配置管理是软件开发环境管理部分的核心，有些管理功能（比如过程管理）在最初并不属于软件配置管理，但随着软件配置管理的不断发展，也逐渐成为软件配置管理的一部分。9.2 配置管理的相关概念在介绍配置管理过程之前，先介绍一下配置管理中的几个重要概念：配置项、基线以及软件配置控制委员会。9.2.1 配重项软件配置项（Software configuration Item，SCI）是项目定义其受控于软件配置管理的项。一个软件配置项是一个特定的、可文档化的工作产品集，这些工作产品是生存期中产生或者使用的。每个项目的配置项也许会不同。所有源代码，包括构成文件及其他所有制作软件产品所需的文件，都可能在软件配置管理控制之下。软件产品某一特定版本的源代码及其相关的工具，都可能受控于软件配置管理。也就是说，在取出软件产品某一版本时，同时也可以取出与此版本相关的工具。所有需要被及时更新的文件，都必须在软件配置管理控制之下。例如-下面的列表可以作为软件配置管理的一些SCI：l 系统规格说明书l 软件项目规划l 需求分析结果l 软件需求规格说明书l 系统原型l 设计规格说明书l 数据设计描述l 总体结构设计描述l 模块设计描述l 界面设计描述l 对象描述（若采用面向对象技术）l 源代码清单l 测试规格说明书l 测试计划和过程l 测试用例与实验结果l 操作和安装手册l 可执行程序l 每个模块的可执行代码l 链接到一起的代码l 用户手册l 维护文档除此之外，有时把软件工具和中间产生的文件也列入配置管理的范畴，即把软件开发中选用的编辑器、编译器和其他一些CASE工具固定地作为软件配置的一部分，当配置项发生变化时，应该考虑这些工具是否与之适应和匹配。配置项也有不同的版本，这里类似地将面向对象的类和实例类比成配置项和配置项的版本。配置项可以看成是面向对象的类，版本可以看成是类的实例，例如，图9亏3表示的需求规格配置项，需求规格的不同版本类似于需求规格配置项的实例，配置项的不同版本是从最原始的配置项（类似于配置项类）演变出的不同情况，尽管每个都是不同的，但是它们具有相关性。图9.3配置项类及实例9.2.2 基线软件的开发过程是一个不断变化着的过程，由子各种原因，可能需要变动需求、预算、进度和设计方案等，尽管这些变动请求中绝大部分是合理的，但在不同的时机做不同的变动，难易程度和造成影响差别甚大。为了有效地控制变动和在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线”（Basic Line）这一概念。IEEE对基线的定义是这样的：“已经正式通过复审和批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。”所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类。例如：基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。基线是一个或者多个配置项的集合，它们的内容和状态已经通过技术的复审，并在生存期的某一阶段被接受了。对配置项复审的目标是验证它们被接受之前的正确性和完整性，一旦配置项经过复审，并正式成为一个初始基线，那么该基线就可以作为项目生存期下面开发活动的起始点。基线标志软件开发过程的各个里程碑，它标志开发过程中一个阶段的结束。对于已成为基线的配置项，虽然可以修改，但必须接照一个特殊的、正式的过程进行评估，确认每一处修改。相反，对于未成为基线的配置项，可以进行非正式修改。虽然基线可在任何级别上定义，但一般最常用的软件基线如图9-4所示。基线提供了软件生存期中各个开发阶段的一个特定点，其作用是把开发阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果。在交付项中确定一个一致的子集！作为软件配置基线，这些版本一般不是同一时间产生的，但具有在开发的某一特定步骤上相互下致的性质，例如系统的一致、状态的一致。基线可以作为一个检查点，正式发行的系统必须是经过控制的基线产品。图9.4基线图示9.2.3 配置控制委员会配置管理的目标之一是有序、及时和正确地处理对软件配置项的变更，而实现这一目标的基本机制是通过配置控制委员会的有效管理。配置控制委员会（Software configuration Control Board，SCCB）可以是一个人也可以是一个小组，基本是由项目经理及其相关人员组成。对于一个新的变更请求，所执行的第一个动作是依据配置项和基线，将相关的配置项分配给适当的SCCB，SCCB根据技术的、逻辑的、策略的、经济的和组织的角度，以及基线的层次等，对变更的影响进行评估，评估基线的变更对项目的影响，并决定是否变更。SCCB承担变更控制的所有责任，具体责任如下：l 评估变更。l 批准变更申请。l 在生存期内规范变更申请流程。l 对变更进行反馈。l 与项目管理层沟通。一个项目可能存在多个SCCB，它们可能存在不同的权利责任。即使一个项目只有一个SCCB，一个组织也可能存在多个SCCB，不同的项目具有不同的SCCB定义。9.3 配置管理过程配置管理的主要包括配置项标识、变更控制、配置项状态统计和配置项宙计等活动。配置项标识是识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取，同时找出需要跟踪管理的项目中间产品，使其处于配置管理的控制之下，并维护它们之间的关系。变更控制是记录变化的有关信息，控制软件产品的发布和在整个软件生存期中对软件产品的修改。有效控制变更，可以保证软件产品的质量，例如，它将解决哪些修改会在该产品的最新版本中实现的问题。配置项状态统计是记录并报告配置项和修改请求的状态，并收集关于产品构件的重要统计信息。例如，它将解决修改这个错误会影响多少个文件的问题。配置项宙计是利用配置项记录验证软件达到的预期结果，确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。例如，它将解决目前发布的产品所用的文件的版本是否正确的问题。配置管理基本是围绕着这四个活动进行的。为了更好地管理这四个活动，定义配置管理的基本过程如下：1）配置项标识、跟踪（见9.3.1节）。2）配置管理环境建立（见9.3.2节）。3）基线变更管理（见9.3.3节）。4）配置审核（见9.3.4节）。5）配置状态统计（见9.3.5节）。6）配置管理计划（见9.5节）。9.3.1 配重顶标识、跟踪如果项目只生成一个文件，例如一个项目的结果是只生成一个需求，就不需要配置管理了。但实际上，一个项目要生成很多的过程文件，并经历不同的阶段和版本。标识、跟踪配置项过程用子将软件项目中需要进行控制的部分拆分成配置项（SCI），建立相互间的对应关系，进行系统的跟踪和版本控制，以确保项目过程中的产品与需求相一致，最终可根据要求将配置项（SCI）组合生成适用于不同应用环境的正确的软件产品版本。配置项应该被唯一标识，同时应该定义软件配置项的表达约定，一个项目可能有一种也可能有很多种的配置项标识定义，例如文档类的、代码类的、工具类的配置项标识定义等，或者统个规范定义。下面给出几个配置项标识的实例：配置项的标识约定例1：项目名称_所属阶段_产品名称_版本标识其中，版本标识的约定如下：1）版本标识以“V”开头，版本号放后。2）版本号分3节：主版本号、次版本号和内部版本号。每小节以小数点（.）间隔。例如，School一DCsign一HLDv2.1.1表示的配置项是名称为School的项目，在设计（Dcsign）阶段的总体设计（HLD）的v2.1.1版本。配置项的标识约定例2（见图9-5）图9-5配置项标识说明配置项的标识约定例ProjcctIDycar-DOcumcn饣Numbcr-AuthcraffiliatiOn-ActivityIdcntificr-DOcumentTypcVerson例炎口！ SC.2003-008OA.casey-T2.3。2-RP-03通常，一个配置项与其他的配置项存在一定的关系，跟踪配置项之间的关系是很重要的。图9-6是需求规格配置项和系统测试用例配置项的跟踪关系。图9-6配置项跟踪注意：现在，配置常常作为“设置”来理解9.3.2 配重管理环境的建立配置管理环境是用于更好地进行软件配置管理的系统环境。其中最重要是建立配置管理库，简称配置库。软件配置管理库是用来存储所有基线配置项及相关文件等内容的系统，是在软件产品的整个生存期中建立和维护软件产品完整性的主要手段。配置库存储包括配置项（SCI）相应版本、修改请求、变化记录等内容，是所有配置项的集合和配置项修改状态记录的集合。从效果上来说，配置库是集中控制的文件库，并提供对库中所存储文件的版本控制。配置库中的文件是不会变的它们不能被更改。任何更改都被视为创建了一个新版本的文件。文件的所有配置管理信息和文件的内容都存储在配置库中。当开发人员使用一个文件时，将某个版本的文件导出（chcek out）到自己的工作目录，然后开始工作，处理完后将文件导回（chcck in）库中，这样就生成了这个文件的新版本。所以，开发人员不可能导出一个文件并同时在配置库中修改源文件。一般说，存储软件项目过程的库分为开发库、受控库和产品库。开发库（也称为动态库）是开发周期的某个阶段，存放与该阶段工作有关系的信息。受控库是开发周期的某个阶段结束时，存放作为该阶段产品及其相关的信息。配置管理对受控库的信息进行管理，其中的文件存取是受控的，也称配置库。产品库（也称为静态库）是存放最终产品的软件库。配置库和产品库在物理上可以是一个库，尽管逻辑上是两个库。我们经常提到的配置管理库就是受控库，对受控库的任何操作都要受到控制。如图9-7所示，从受控库导出（check out）的文件自动被锁定直到文件重新被导入（checkin），一个版本号自动与新版本文件相关联。这样一来，用户可以随时根据特定的版本号来导出任何文件（默认的是最新的版本）。对最新版本的修改的结果是产生一个新的、顺序递增的版本；而对更老版本的修改的结果是产生一个分支版本。在版本编号策略和使用模式共同作用下，产生了文件版本历史树，用来表示祖先和后代版本。配置库中不但存储了文件的不同版本、更改的理由，而且存储谁在什么时候替换了某个版本的文件等历史信息。请注意，有的配置管理库，对于每个不同版本文件，不是将所有的代码都存储起来，而只是将不同版本间实际的差异存储起来。这种方法有利子节省空间和节省对最新文件版本的访问时间。另外，可以根据状态给文件加上标签，然后基子状态的值进行导出。它们同样也可以根据修订版本号、日期和作者进行导出操作。库总是和文件所在的目录相关联。总而言之，配置库捕捉配置管理信，a并把不同版本的文件存储为不可修改的对象。图9-7受控库环境除了有效的版本管理之外，配置管理还能更好地解决并发控制的问题。并行开发中最常见的不同版本软件的错误（Bug）修正问题，就可以通过版本控制中分支与合并的方法有效地解决。比如，软件已经发布了10版本，开发小组在为该软件添加新的功能，正在进行2.0版本的开发，见图9-8。而此时，如果Rclcasc 1，0中发现了错误，必须修正，我们就必须从Rclcasc 1，0中建立bugfix分支，进行必要的修正后，发布修正版Rclcasc 1.1，而这个版本的发布与2、0版本的开发没有直接关系。当2.0版本测试结束后，要与1.0版本中bugfix分支合并，从而发布2.0的版本。在这个卉行开发过程中，创建分支和分支的合并起到了非常重要的作用。图9-8版本的分支结构开发库也称为工作空间，它为开发人员提供了独立的工作空间。它可以防止开发人员之间的相互干扰。建立配置管理环境包括建立配置管理的硬件环境和软件环境，同时建立存储库的操作说明和操作权限。例如，图9-9是一个名为P艹B2B项目的一个受控库和两个开发库（动态库）的目录结构：受控库按照系统架构设计的结构提供相应的子目录。开发库（动态库）的结构映射了受控库的结构。开发过程的各个子目录是按照架构设计的模块安排的，例如“Ingcs饣lOn”是架构设计的一个模块。Prj-B2B项目的受控库是homcPrj，B2BCcntcr。其中包括Sourccs目录和Objcc饣s目录，Sources目录按照子系统的功能分为很多的子目录，例如：homePrj-B2BCen饣crSourccsingcstion3homcPrj，B2BCcntcrSourcesOthcr-globals。Object目录下保存了目标库，以便减少连接时间和执行程序的规模。每一个开发人有一个动态的开发库（开发库），目录是homePrjp2gccnteruscrname，结构如上所述，在受控库中建立对每个开发者的连接，开发者使用自己目录下的可写文件进行开发修改，同时将只读文件拷贝到自己的目录下以减少编译、连接的时间。图9.9一个项目的受控库和开发库的目录结构9.3.3 基线变更管理项目的基线（的配置项）可能由于种种原因会发生变更，变更的原因很多：人们可能犯错误，客户的需求变更，产品的环境发生变更，人们开发了新的技术，等等。需求、设计、实施、测试等所有开发过程以及相关的文件都可能导致变更。变更如果没有得到很好的控制，就会产生很多的麻烦，以至于导致项目的失败。所以，变更应受到控制，这种变更要经SCCB授权，按照程序进行控制并记录修改的过程。变更管理也称为配置控制，包括为了防止开发人员对欤件的随意变更而进行的管理上的复宙和批准过程。基线变更系统包括变更请求、变更评估、变更批准或者驳回、以及批准后的变更实现。具体如图9-10所示。变更包括项目执行过程中的各种变更，例如需求的变更、进度的变更、成本的变更、质量的变更、风险的变更、人员的变更等。变更发生后要综合考虑，权衡关系。一个变更可能导致其他的变更。一个有序的变更控制过程，要确保合理地考虑每个变更所产生的影响。该过程确保只有被批准的变更才能予以实现，并放入相应的基线中，而且确保所有被批准的变更均实现。与进度和成本控制系统一起，它提供了技术活动和项目进展的可见性。进行变更时，首先填写变更请求表，提交给SCCB，由SCCB组织相关人员分析变更的影响，其中包括范围的影响、规模的影响、成本的影响、进度的影响等，根据分析的结果，决定是否可以变更，或者对变更的一部分提出意见，可能拒绝变更请求，可能同意变更请求，可能同意变更部分请求。然后，项目经理根据批准的结果，指导项目组进行相应的修改，包括项目计划、需求、设计或者代码等相应的文档、数据、程序或环境等的修改。图9-10变更控制变更谙求 、变更请求是变更控制的起始点，变更请求很少来自配置管理活动本身，通常来自系统之外的事件触发。例如，不符合项或者软件测试报告就是一个普遍的例子。它们可能组成大量的变更，对开发基线产生影响，并传播到开发基线中的配置项。2.变更评估变更请求需要准备一个软件变更请求的表单（见表9.1），这是一个正式的文档，变更申请者使用运一文档描述所标识的变更。表9.亻 项目变更申请提交变更请求表单后，必须验证其完整性、正确性和清晰性，对变更申请进行评估。变更请求可能是由于提交人的错误理解而产生的，或者可能与现存的请求相重复，如果在检查中发现提出的变更是不完整的、无效的或者已经评估的，那么就应拒绝这一请求，并建立拒绝原因的文档，返回给提交变更请求的人，不论什么情况，都要保留该变更请求和相关的处理结果。一个有效的变更评估活动如图9-所示。图9.变更请求的评估评估过程的第一步，是对新的、有效的变更进行分类。任何分类模式的目的都在子帮助执行配置管理计划给出的变更控制和配置过程中的后续步骤。在评估中可以回答表9-2中所列问题。 表9.2 项目变更评估表3.变更批挂戡者拒绝在批准或者拒绝软件变更请求中涉及的活动见图9-12。图9-12变更批准或者拒绝的活动根据变更评估的结果，SCCB对变更请求做出决策。通常，决策包括：直接实现变更。挂起或者延迟变更。拒绝变更。对于最后一种情况，应该通知变更请求人，并且保存所有的相关记录，如果以后的事件证明拒绝变更是错误的，则这些保存下来的记录是有用的。挂起或者延迟变吏常常是在SCCB评估分析之后，但是变更请求不在SCCB的控制范围之内。当变更被接受时，应该按照选择的进度实现变更，实现进度可以采用下面三种形式之一：尽可能快地实现变更：期望的变更是修改开发基线甲的一个配置项，只有解决了这个变更，其他的工作才能展开。按照一个特定的日期实现变更：考虑项目内或者项目外的事件，确定合适的日期实现变更。在另外的版本中实现，出于技术或者运行等原因，期望与另外的变更一起发布。4.变更实现在实现已批准的软件变更请求中包含的活动如图9亏13所示。项目人员使用SCCB给予的权限并遵循sCCB的指导，从受控库中取出基线的拷贝，并实现被批准的变更，对已经实现的变更实施验证。一旦SCCB认为正确实现并验证了一个变更，就可以将更新的基线放入配置库中，更新该基线的版本标识等。在需求管理一章中谈到需求变更就是很重要的一个基线变更，软件需求变更表现在文档的需求变更和相关过程模型的变更。9.3.4 配置审核配置审核包括两方面的内容：“配置管理活动审核”和“基线审核”。“配置管理活动审核”用于确保项目组成员的所有配置管理活动，遵循已批准的软件配置管理方针和规程，如检入检出的频度、产品版本升级原则等。实施“基线审核”，要保证基线化软件工作产品的完整性和一致性，其目的是保证基线的配置项（SCI）正确地构造并正确地实现，并且满足其功能要求。基线的完整性可从以下几个方面考虑：基线库是否包括所有计划纳入的配置项，基线库中配置项自身的内容是否完整。此外，对于代码，要根据代码清单检查是否所有源文件都已存在于基线库中。同时，还要编译所有的源文件，检查是否可产生最终产品。一致性主要考察需求与设计以及设计与代码的一致关系，尤其在有变更发生时要检查所有受影响的部分是否都做了相应的变更。审核发现的不符合项要进行记录，并跟踪直到解决。图9-13变更实现过程简单的配置管理活动审核是记录配置管理工具执行的所有命令，复杂的配置管理活动审核还包括记录每个配置项的状态变化。当软件配置管理发布一个新版本时，可能需要审核一个构造记录，以确保这一构造中确实包含组件配置项的正确版本，或者复审变化历史数据库，以验证在新的发布中只有所期望的变更，验证配置系统是否保持了自身的完整性。通过基线审核，可以发现系统中一直没有被处理的变化请求，或者发现那些不按照规程文档随意出现或者变更的软件项。9.3.5 配置状态统计配置管理是贯穿整个项目生存期的，而且具有非常重要的作用，因此必须定期检测软件配置管理系统的运行情况以及配置项本身的变更历史记录。检查配置管理系统以及内容、检测配置项变更历史的过程称为配置状态统计。运些过程的结果应以报告的形式给出。配置系统状态统计的范围可以因项目而异。例如，IEEE标准828-1998规定用于计算配置状态的最小数据集包括：被批准的配置项。配置项的所有请求的变化状态。配置项所有被批准的变更实现状态。此外，在评估一个配置系统状态以及系统所支持的产品状态时，经常需要以下信息：变更请求的数量，当然可以按照类别进行分类，例如需求变更、文档变更、设计变更、源码变更等。变更请求的历史报告，包括编写请求、请求复审、请求批准、请求实现、请求测试、请求接受等一系列活动所花费的时间和每个单项活动所花费的时间。配置管理系统以及SCCB在运作中发生异常的次数等。9.3.6 配重管理的真他作用配置管理在项目管理的其他方面（例如产品生成、过程管理、软件的复用、小组协作开发等）也起着非常重要的作用。软件开发结束之后，需要向用户交付软件产品，软件产品必须从软件配置管理库中生成。它将解决最新发布的产品应由哪些版本的文件和工具来生成的问题。过程管理是确保软件组织的规程、方针和软件周期得以正确贯彻执行。它将解决要交付给用户的产品是否经过测试和质量检查的问题。现在，很多配置管理工具都具有过程管理的功能。软件复用是软件发展到一定阶段的产物。如果我们开发的欤件产品是具有一定功能和性能的初始系统，但还不能完全满足所有用户的需求，为使最终的产品能满足用户的需求，我们必须认真研究用户的真正需求。经调查，了解到“用户1”代表了一些用户，这个用户群使用的计算机为“机型1”，所用的操作系统是“操作系统1”；而“用户2”所代表的用户群使用着“机型2”和“操作系统2”（见图9-14）。就是说，不同用户有不同的工作环境，我们的软件产品必须考虑到这些差异，并且充分地使其满足各个用户的使用要求。为做到这一点，产品的设计可能做成这样的安排（见图9亏15），两类产品分别针对两个用户群设计产品内部的模块（按上面的说法是配置项）。图9-14 不同用户有自己的工作环境图9.15不同用户产品的不同配置其中，用户1包含的功能是A、B、c、D、E和F，而用户2包含的功能是A、B、C、D、E和G、H，两者的差别不仅表现在一个含有F，另一个合有G和H，而且即使两者的A在逻辑上是同一个内容，但在物理上仍然可能因两类用户需求的不同而有所差异，例如，两个A分别以不同的媒体出现。 ，为实现这两种不同的软件配置，在实际工作中，我们完全可以将各个配置项分别开发出来，再根据需要组合成针对不同用户使用要求的不同产品，正如图9-16所示，它是一个很好的复用的例子。图9-16两个产品具有不同的配置9.4 配置管理工具配置管理包括三个主要的要慕：人、规范、工具。首先，配置管理与项目的所有成员都有关系，项目中的每个成员都会产生工作结果，这个工作结果可能是文档，也可能是源程序等。规范是配置管理过程的实施程序。为了更好地实现软件项目中的配置管理，除了过程规则外，配置管理工具起到很妤的作用。现代的配置管理工具提供了一些自动化的功能，从而大大方便了管理人员，减少了繁琐的人工芳动，但是必须为项目人员提供必要的有关配置管理系统知识的培训。配置管理工具基本上围绕着配置管理的四个活动进行，而管理这四个活动的功能是配置管理的基本功能。配置管理工具可以提供必要的配置项管理，支持建立配置项的关系，并对这些关系进行维护、还可以提供版本管理，变更控制，审计控制，配置项报告查询管理等。当然，有的配置管理工具也提供相关的其他功能，例如软件开发的支持、过程管理、人员管理等。配置管理工具很多，例如vSS、CvS、PVCS、CCCHarvcst、ClcarCascClcaqucst等。目前比较常见的配置管理工具是vSS、CVS、ClcarCasc。ClearCasc是Rational公司开发的产品，是配置管理工具的高档产品，是软件业公认的功能最强大、价格最贵的配置管理工具。ClearCasc主要适用于复杂的并行开发、发布和维护，功能包括版本控制、工作空间管理、构造管理、过程控制。虽然ClcarCasc有很强大的功能，但是由于其昂贵的价格，让很多的软件企业望而却步。而目前的大多数软件项目的规模，还用不到ClcarCase的强大功能。vSS（SourccSafc）是美国微软公司开发的配置管理工具，由于其实惠的价格、方便的功能，是目前国内最流行的配置管理工具，包括的主要功能是创建目录、文件添加、导入、导出、查看历史版本等，虽然与ClcarCascb匕起来功能比较简单，但是对于大多数的中小型项目而言，vss已经足够了。CvS是著名的开诳源代码的配置管理工具，它的基本工作思路是在服务器上建立一个仓库，仓库里可以存放许多的文件，每个用户在使用仓库文件的时候，先将仓库的文件下载到本地工作空间，在本地进行修改，然后通过CvS的命令提交并且更新仓库的文件。9.5 配置管埋计划配置管理计划过程就是确定软件配置管理的解决方案，软件配置管理的解决方案涉及面很广，将影响软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。配置管理的实施需要消耗一定的资源，在这方面一定要预先规划。具体来说，配置管理实施主要需要两方面的资源要素：一是人力资源，二是工具。入力方面，因为配置管理是一个贯穿整个软件生存期的基础支持性活动，所以配置管理会涉及团队中比较多的人员角色，比如项目经理、配置管理员、质量保证人员、开发人员、测试人员、维护人员等。但是，工作在一个良妤的配置管理平台上井不需要开发人员、测试人员等角色了解太多的配置管理知识，所以配置管理实施的主要人力资源会是集中在配置管理者上。配置管理者是一个比较奇妙的角色，对于一个实施了配置管理、建立了配置管理工作平台的团队来说，他是非常重要的，整个开发团队的工作成果都在他的掌管之下，他负责管理和维护的配置管理系统如果出现问题的话，轻则影响团队其他成员的工作效率，重则可能出现丢失工作成果、发布错误版本等严重的后果。选择什么样的配置管理工具，一直是大家关注的热点问题。确实，与其他的一些软件工程活动不一样，配置管理工作更强调工具的支持，如果缺乏良好的配置管理工具，要做好配置管理的实施会非常困难。选择工具就要考虑经费，市场上现有的商业配置管理工具，大多价格不菲。要仔细考虑，是选用开放源代码的自由软件，还是采购商业软件。一般来说，如果经费充裕的话，采购商业的配置管理工具会让实施过程更顺利一些，商业工具的操作界面通常更方便一些，实施过程中出现与工具相关的问题也可以找厂商解决。如果经费有限的话，