《软件项目管理原理与实践》 课件 第6章 软件项目配置管理.pdf

第6章软件项目配置管理 6.1概述o 6.1.1 起源与发展O 6.1.2 解决哪些问题 6.2软件配置管理的任务和活动O 6.2.1 软件和配置项O 6.2.2 标识o 6.2.3 变更控制o 6.2.4 状态报告o 6.2.5 配置审计 6.3软件配置管理的核心要素O 6.3.1 版本和版本树O 6.3.2 软件配置库o 6.3.3 工作空间o 6.3.4 变更请求与变更集o 6.3.5 软件配置管理工具2e 6.4软件配置管理的主要过程O 6.4.1 配置项标识与存储过程o 6.4.2 版本管理过程o 6.4.3 变更控制过程o 6.4.4 基线管理过程6.5软件配置管理中的角色O 6.5.1 配置管理专职人员o 6.5.2 机构运营管理人员o 6.5.3 项目开发人员6.6常用软件配置管理工具O 6.6.1 软件配置管理工具的发展历程o 6.6.2 版本控制工具及功能o 6.6.4 面向开发流程的配置管理工具及功能 6.7案例研究 6.8小结3软件配置管理软件配置管理(Software Configuration Management,SCM)是软件工程领域的重 要课题，也是软件产品开发过程中的核心控 制过程。O与传统产品开发生产相比，软件产品的开发生产具有较 强的复杂性和不确定性。O主要体现在开发进度难以控制、开发结果难以预计。O所幸的是，软件配置管理通过一整套可视化可跟踪和可 控制管理方法为软件开发项目提供了保护伞。InitiationAnalysisPlanningSupportBuildDevelopmentBaseline ManagementDeliveryTestingDeploymentSof tw are Conf iguration ManagementRequirementDesign5软件配置管理软件配置管理在开发过程中各阶段，管理计 算机程序演变的学科，作为软件工程的关键 元素，已经成为软件开发和维护的重要组成 部分。O软件配置管理提供了结构化的、有序化的、产品化的管 理软件工程的方法，涵盖了软件生命周期的所有领域并 影响所有数据和过程。配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学 科。7Configuration Manger DeveloperUserSCM Operational Scenario软件配置管理计算机软件产品的总体发展趋势，就是系统 自身的复杂化与系统使用的简单化。O如何控制日益复杂化的系统，管理系统开发和维护过程,始终是软件从业者头痛的难题。软件配置管理正是在软件产品与软件开发产 业进化过程中不断演练出来的解决这一难题 的主要方法。O遗憾的是，由于软件配置管理本身也是在软件产业发展 过程中逐步形成和完善的，即使是资深软件从业人员，也经常混淆其概念和方法。9软件配置管理概览6,1什么是软件配置管理O 1.软件配置管理 软件配置管理(Software Configuration Management,SCM)就 是在软件开发过程中管理软件的配置。这里的配置，是指构成软件产品的各种原始部件，包括源程序、数据文件、设计文档、用户文档，及其组织关系(如目录结 构)。相应的管理包括管理这些部件的产生、修改、提取与发布，以 保证整个产品的正确性、完整性，产品部件的一致性。软件配置管理的正式定义,在不同的标准规 范中有不同的表述。，10软件配置管理的内容配置（C onfiguration）一词来源于拉丁语的“C om（“与”或者“一起”）和“figure（“形成”）,意为 多个部件集合在一起形成一个整体。O由此，配置管理可以理解为使事物的各个部件或元素组合成整体的管理过程。软件部件分解图.软件配置管理(Software Configuration Management,SCM)就是在软件开发过程_ _ I可执行I I可执行 模块C 模块D|程序A|程序B文档软件规格计划 需求规格说明 设计说明质量保证计划 测试计划 测试程序 测试报告12软件配置管理标准的目标Objectives of SCM StandardsRemote System Administration-Reduced User Down-time-Reliable Data Backups-Easy Workstation setup-Multiuser Support-Remote Software Installation13在不同的标准规范中有不同的表述(1)USO/IEC 12207(1995)信息技术软件生存周期 过程标准O配置管理过程是在整个软件生命周期中实施管理和技术规程的过程，它标 识、定义系统中软件项素，并定制基线(Baseline)。O控制软件项素的修改和发行，记录和报告软件项素的状态和修改请求，保 证软件项素的完整性、协调性和正确性，以及控制软件项素的存储、装载 和交付。(2)toB/T 11457(1995)软件工程术语o软件配置管理是标识和确定系统中配置项的过程，在系统整个生命周期内 控制这些项的投放和变动，记录并报告配置的状况和变动要求，验证配置 项的完整性和正确性。(3)集成化成熟度模型(C M M I)O配置管理是通过配置标识、配置控制、配置状况统计与配置审计来建立与 维持工作产品的完整性的管理过程。O CMMI中的定义概括了软件配置管理的主要任务和方法。15C hange in RequirementsI C hange inTeam/Organizationotwr Docurmnts丁4stsvaXa.08或16Software Configuration Management Process61起源与发展配置管理的概念，最早来源于制造工业，尤 其是在国防工业中。O这些工业产品往往相当复杂，包含数万种部件，经历几 代人多年的开发，每种部件都在不断地改进、演化。O这就需要有一套机制去管理产品部件的变更、版次，保 存完整的产品开发信息，以保持不同阶段产品开发的连 续性。O 1962年，美国空军在进行喷气式飞机设计时，制订了 一个标准规范配置管理，这被视为第一个配置管理标准,该标准被美国国防部和军方其他标准广泛引用。186.1.1 起源与发展单一产品需要的开发人员不断增多，开发人 员之间的信息沟通、进度协调和交付管理等 方面的矛盾日益突出。,软件配置管理已经作为一种重要的软件开发管理,被大多数软件标准化组织所采纳，作为衡量软件 组织成熟程度的基本标准。O用于软件配置管理的工具也在不断地丰富和完善。O这些工具有力地帮助软件开发机构实现软件配置管理自 动化。在节发 现环开19，配置管理的概念，最早来源于制造工业，尤其是 在国防工业中。19 62年，美国空军在进行喷气式飞机设计时，制订 了一个标准规范配置管理，这被视为第一个配置管 理标准，该标准被美国国防部和军方其他标准广泛 引用。口从20世纪80年代起，美国国防部、美国电气和电子工程师协会、美国国家标准协会和国际标准化组织 都开始关注软件开发过程中的配置管理并陆续制订6J.2 解决哪些问题没有配置管理的“手工作坊”式的软件开发 项目，经常会遇到许多问题。例如，一个严重的错误被修正了，却在一段时间后又重 现了；O 一个己经开发并经过测试的功能在手工集成后完全消失 了；O系统崩溃了，却很难查出是什么修改造成的；用于测试 的执行程序与源代码严重不一致；O新的开发人员对现有代码难以理解，不知其前因后果无 法判断单个功能的实现进度和整个项目的完成程度；O无法确知整个产品的代码修改频度和每个版本的代码修 改量。21配置管理的原则 完善的软件配置管理系统有助于规范开发人员的工作流程，明确角色分工，清 楚记录代码的任何修改，同时又能加强代码修改时的沟通协作；完善的配置关联系统也有助于项目经理更好地了解项目的进度、开发人员的负 荷、工作效率与产品质量状况、交付日期等关键信息；配置管理系统中的完整配置信息和修改历史使新的成员可以快速实现任务交接,尽量减少因人员流动而造成的损失。226J.2 解决哪些问题完善的软件配置管理系统有助于规范开发人 员的工作流程，明确角色分工，清楚记录代 码的任何修改，同时又能加强代码修改时的 沟通协作完善的配置关联系统也有助于项目经理更好 地了解项目的进度、开发人员的负荷、工作 效率与产品质量状况、交付日期等关键信息:23SCM Operational ScenarioProj ec tManagerConf igruation MangerDeveloperUser软件配置管理的功能软件配置管理通过对软件产品各个部件的管理控制，协调软件开发项目中不同角色的活动，能够有效地帮助软件开发团队避免上述问题。25 621软件和配置项O软件的脆弱性和易变性的根源在于软件的复杂性，大型 软件通常由数以千万个文件组成，这些文件包括以下内 容：定义产品功能、描述设计实现细节的设计文档。规定产品开发过程、进度计划和交付合同等项目管理文档。口各种语言的源程序文件，这是数量最多、最关键的文件。各种格式的数据文件，包括数字、文字、图片、视频等。构造生成的中间文件、可执行文件和可安装文件。实现源程序文件到可执行文件和可安装文件转换的构造、包装 脚本。该软件所依赖的其他文件：包括开发运行工具、硬件环境说明 或相关软件说明。26软件配置项（Cl）树软件配置是指一个软件产品在软件生命周期各阶 段产生的各种形式（机器可读或人工可读）和各 种版本的文档、程序及数据的集合。O该集合中的每个元素称为该软件产品软件配置中的一个配置项“The proj ec t:Models J/1 ifObj ec t Model Dynamic Model _ iDatabase_*Tho proj ec t”|Codie developmentDates The due date wjs replanned due to external dependenc iesPeople37软件配置I软件配置状态报告,通常用来回答如下问题;O配置项当前有何属性，处于什么状态?O配置项的每一版本是如何生成的?O配置项的新旧版本有何区别？O变更请求何时被谁批准，如何实现？O近期有哪些配置项发生了改变？O近期批准了多少变更请求，完成了多少?O哪些开发人员最近对配置项进行了修改?38完成状态报告任务的主要活动(1)确定报告范围O不同组织、同一组织在不同阶段关注的侧重点不同，对状态报告内容的需 求也不同，应根据实际需要选定报告的内容范围，有选择性地回答上述几 个问题。(2)定义报告模板O格式化的报告通常便于阅读者迅速、准确地抓住关键信息。(3)提取配置数据O根据确定的报告范围定期(每天、每周、每月)从配置库中把相关配置数 据提取出来，按模板整理成便于阅读的文档。(4)发布状态报告O配置状态报告应该发布给项目的所有开发与管理人员，同时必须归档以备 日后查考。(5)定制特定信息查找途径O为满足不同用户的专门需求，必须在周期性的报告之外定制灵活的配置数 据查找方式，并提供便捷、友好的界面。396.2.5 配置审计软件配置审计的任务，是确认整个软件在生命周期中各个部件在技术 上和管理上的正确性与完整性。O审计过程通过审查软件配置项的状况和修改历史寻求以下两个问题的答案，软件的 演化过程是否符合既定的流程，软件实现的功能是否与需求保持一致。配置审计的主要活动，是评审与测试。O前者，确保软件配置变更和软件开发流程的正确执行，后者，确保软件产品功能的 正确性。O测试任务主要由软件质量保证人员完成，具体过程将在后续章节中详细阐述。CONFIGURATIONAUDIT TOOLSC AUDITBOARDWdeskOnsprmgGalvanizeWolters Kluw er REFINITIV 氏40配置评审活动，主要包括如下环节(1)项目经理和配置经理确定审计的人员。(2)配置审计人员准备配置审核检查单，并制订 审计计划。(3)配置审计人员按照计划安排时间对配置数据 进行审计，与相关人员面谈。(4)配置审计人员将在审计中发现的不符合现象 做记录，并发送给项目经理。(5)项目经理和配置经理对上报的问题进行解决 跟踪。6.3软件配置管理的核心要素软件配置管理的主要任务是管理软件产品的 演变，确保产品在演变过程中仍保持正确性、完整性与一致性。O显然，这是一个不容易完成的任务，必须借助于一些特 别的机制，专门的过程才能实现。下面，看看有哪些核心要素支撑配置管理活 动，以实现配置管理任务。426.3.1 版本和版本树版本i是软件配置项在演化过程中的每一个实例O软件产品由许多文件（即配置项）组成，其中的每一个文件在软件 的开发、演化过程中都会不断地被修改，每次修改都形成不同的文 件内容。如果检取出同一文件任何一次修改后形成的内容，）都可看做作该文件的一个实例2即该文件的一 个成aO对同一文件的每次修改总是有先后顺序的。因此文件的每一个版本 也是有先后顺序的。后一版本总是在前一版本的基础上形成的。O止匕外，同一个版本还能根据不同的需要同时衍生出多个后续版本。O如果我们把一个文件的所有版本按衍生顺序描绘出来，通常会出现 为一种树形图，称为该文件的版本树。43IVersion controlProgrammers A and 0 done the remote p)os枪_!_.PPOGAAMMt9 PMXWTCmY I 2 OKMCM or n cca am IMMUlt npowTomreProgramneer A befira her wort from the commit represenftmj by the blue nMH.“w finfthM her ctunoes arvi now has a commit the oranot node,that dotsnft wiHM ZIMMI tfunte in Z remote reposMory.So.she pushes her ctwifes upslrwam.oroQTBnvncr B tchcSownliMd s the new vtnion of the iamiK wfWch l(xiud CCIVWVWt,，Hu*or8nc ooS into hs curtBrt bcsHdi-forminQ|h tcoJ nod#.版本树中分叉处的版本大 多是重要修改的开始、如 新功能的开发、产品新发 布的开始,或是新开发小 组的介入。1文件版本管理是软件配置 管理的基础。O只有对每个文件的每个版本实现 了严格有序的管理，保证每个文 件的版本树能自由而又稳健地成 也。.能随时方便地提取版本树 中任意一个版本,这才能 构建更为复杂的软件配置 管理功能O某一文件的版本树45Wihdwo家谱Microsoft Windowsf amily tree1985 1987 1989 1991 1993 1995 1997 1999 2001 2003 2005 2007 2009 2011 2013 2015 2017 2019 20211588 1990 19啦 1994 1996 1998 2000 2002 2004 2口口B 2口Qfi 2010 2012 2014 201B 2018 2020 202246JDK 1.0Very f irst version w as released on January 23.1996.The princ ipal stable variant.JDK 1.0.2.Is c alled Java 1.JDK 1.1 w as released onFebruary 19.1997J2SE 1.2 Play area-w as the c odename w hic h w as given to this f orm and w as released on 8th Dec ember,1998.lts real expansion Inc luded:strlc tf p keyw ord,the Sw ing graphic al API1996JAVA SE 8Was released on date 18th Marc h.2014 Language level support f or lambda expressions and def ault methods and a new date and time API inspired by Joda Time.J2SE 1.3Was given a c odename KESTREL-and w as released date 8th May,2000 and c ontains additions like HolSpot.JVM Inc luded,Java Naming and Direc tory Interf ac e19982000JAVA SE 9Was released on date:21st September 2017Proj ec t Jigsaw:designing and Implementing a standard,module system f or the Java SE platf orm,and to apply that system to the platf orm itself and the JDK.2017JAVA SE 7Was given the c odename Dolphin and w as released on date 7th July 2011 Added small language c hanges Inc luding strings In sw itc h.The JVM w as extended w ith support f or dynamic languages.JAVA SE 6 Was gtven the c odename-Mustang and w as released on date 11th Dec ember.2006 Pac kaged w ith a database supervisor and enc ourages the utilization of sc riptmg32002J2SE 1.4Was given the c odename Merlin and w as released on date 6th February,2002 and c ontains additions like Library improvements,Regular expressions modelled af ter Perl regular expressions2014201120062004J2SE 5.0Was given the c odename-Tiger and w as released on 30th September,2004 originally numbered as 1.5 w hic h Is still used as Its Internal version.Added several new language f eatures suc h as f or-eac h loopJAVA SE 11Released Date-25th September.2018 c ontains additions like Dynamic c lass-f ile c onstants.Epsilon:a no-op garbage c ollec tor.Loc al-variable syntax f or lambda parameters.Low-overhead heap prof MIngJAVA SE 12Released Date-19th Mac rh.2019 c ontains additions like Shenandoah:A Low-Pause-Time Garbage Collec tor(Experimental).Mic robenc hmark Suite,Sw itc h Expressions(Preview).JVM Constants API9G2018JAVA SE10Released Data-20th Marc h c ontains additions like Additional Unic ode language-tag extensions.Root c ertif ic ates,T nread-loc al handshakes,Heap alloc ation on alternative memory devic es2018201947做本AlphaAndroid 1.0Cupc akeAndroid 1.5工：DonutAndroid 1.6Ec lairAndroid 2.02.1FroyoAndroid 2.2GingerbreadAndroid 2.3ANDROID VERSIONSAndrotd 30AndroKl 4.0Andc od 4,1Android 4.4Android 5.0Android 6.0486.3.2 软件配置库软件配置库，又称软件受控库，是指用来存 放软件配置项的存储池，保存软件产品配置 项的所有版本与每个版本相关的控制信息。最原始的软件配置库，是以笔书形式登记的软件项目中 所有文件及其版本的手工清单。O软件配置管理自动化以后，软件配置库的存储一般采用 数据库的形式，可以是通用的商业数据库，也有些是软 件配置管理系统私有数据库。496.3.2 软件配置库e早期的软件配置库通常只在软件生命周期的某一 阶段结束时存放软件产品和与软件产品开发工作 有关的计算机或人工可读信息，仅用做作软件产 品资产库，不要求实时在线存取，只要求安全性、完整性与可维护性9O现代软件配置库是软件开发项目的核心基础设施，是项目开发人员 随时需要访问的软件代码库。最新、常用的软件开发工具通常都具有与软件配 置库直接连接访问的功能。O因此，现代化的软件配置库应该具有较高的实时性和容错性，同时 有较强的可扩展性、可分布性和可复制性，以满足不断增长的开发 团队对配置项的巨大访问量。50633 工作空间 工作空间，是每个开发人员访问软件配置库、存 取文件版本并进行产品开发的主要渠道。O它为开发人员提供了一个具有稳定性与一致性的工作环境。工作空间首先是一个相对稳定的私有文件区，在 该区域里开发人员可以相对独立地编码、修改和 测试，不受其他开发人员的代码的影响。O其次，工作空间内的代码本身必须是一致的，即所选取的各个文件（配置项）的版本必须是相互兼容的，在进行任何修改之前工作空 间内的文件应该是可编译、可运行的。O由此，工作空间一般初始化为产品的某一稳定基线（Baseline）所 标识的配置项集合，以保证不同开发人员可以获得相同的工作空间51633 工作空间 同时，每个开发人员的工作空间必须及时更新到 最新的产品基线才能保证工作空间的实效性，避 免在旧版本上做无用的开发。O“刻舟求剑”的寓言在软件开发过程中时有上演。O工作空间通常提供相应的机制为开发人员方便进行修改的合并和基 线的刷新。总之，软件配置管理中的工作空间为开发人员提 供了一个相对稳定一致的开发环境，使得开发人 员既可以独自分离地进行开发，又可以方便、快 捷地合并开发结果。O软件开发中的“分”与“合”的基本逻辑在工作空间中得以实现。526.3.4 变更请求与变更集如前所述，软件产品总是处在不断变化、演 进过程中的，软件配置管理的核心任务，就 是管理软件产品的变化，使其在变化过程中 保持正确性、完整性和一致性。O实现这一任务的关键，是对软件的变更进行管理，确保 产品的任何变化都有凭有据。O变更请求就是开发人员对软件产品进行修改的凭据，对 产品的每一点改动都应该通过变更请求详细登记，并取 得相关人员的批准。536.3.4 变更请求与变更集变更请求通常被分为两大类，增强请求和缺 陷。增强请求，是指系统的新增特征或对系 统现有功能的有计划的修改。O缺陷，是指存在于一个已交付产品中的与所设计功能不 一致的异常现象，这里的交付对象可以是最终客户。O也可以是同产品的开发或测试人员。O例如，每个里程碑或基线的交付。变更集，是记录一个变更请求实施后生成的 配置项新版本的集合，是该变更请求完成后 的结果。546.3.5 软件配置管理工具软件配置管理工具是一些软件工具，其自动化软 件配置管理最佳实践并提供方便的操作接口以便 于开发人员日常使用。O同编辑器、编译器和调试一样，软件配置管理工具是今天的软件工 程师工具箱中必要的组成部分。O没有工具很难实现有效的软件配置管理。在早期软件开发项目中，配置管理由配置库管理 员手工完成，记录每个开发人员取出和生成的每 个配置项版本，烦琐、缓慢而又容易出错。O现代化的软件配置管理工具能精确、有效地管理软件配置管理中的 各种要素，尽可能地自动化软件开发过程中用于配置管理相关的过 程，同时保持对软件产品的有力控制。556.4软件配置管理的主要过程 6.4.1 配置项标识与存储过程O标识过程的关键，是如何给每个配置项赋予一个唯一而 又有意义的标识。在普通的文件系统中，文件名及其目录路径可以作为一 个文件的唯一标识，但在配置管理系统中同一个文件（配置项）有许多版本，必须把每个版本也标识出来。O给版本赋予标识首先要确定版本的命名规则，版本命名 规则经确定就在整个配置管理系统或过程中保持不变（在自动化配置管理系统中，版本命名规则一般是固化在 配置管理工具中的）。O同一配置项的前后版本之间存在传递关系，相邻版本之 间存在分支关系。56两种常用的版本标识方式版本命名规则，应该体现这些关系。常用配置管理工具，通常采用两级制版本 命名规则，前一级标识版本分支、后一级标识同一分支中的特定版本，多个前 后级标识串联起来可以表示任何复杂的版本。不同配置管理工具可能用不同的符号连接每级标识（常用的连接符号有 和/）,而且也可能采用字符或数字来标识分支，但其本质构成是相同的Verl1.1 2 1.1.0Hotfix 11.1.1.0576.4.2 版本管理过程版本管理过程，是实现完整的配置管理功能 的基础。O版本管理的主要内容，是管理产品配置项的每一个版本 的生成和使用O主要方法包括版本访问与修改控制、版本分支和合并、版本历史记录，以及历史版本检取。软件开发人员不能直接访问配置库对源文件（配置项）进行修改，所有修改必须在开发 人员各自的工作空间中进行。586.4.2 版本管理过程 一般说来，工作空间是开发人员本地文件系 统中的一个文件夹，具有文件系统提供的访 问控制机制。O开发人员可以按特定方法选取所需要的并且授予访问权 的文件版本，从配置库中加载到工作空间内。O由于产品源代码是产品开发中最重要的信息，项目管理 人员通常会在配置库中设置额外的访问权限控制，以确 保只有授权的人员才可以访问相应产品或模块的代码版 本。596.4.2 版本管理过程 尽管软件配置项经过不断的修改、分支合并形成 复杂的版本关系，版本管理系统总是能清晰、完 整地记录各个配置项的版本历史的。O版本历史记录中，通常包括每个版本的版本标识、修改时间、修改 人员、修改说明等基本信息。O这些信息可以被项目开发人员查找浏览，用于问题追溯、影响分析、版本重构或项目审计等活动。版本管理的另一重要功能，是历史版本检取。O配置管理工具大多可以根据配置项版本标识或基线名称检取出一个 或多个配置项的指定历史版本。O也可通过调整工作空间的版本选取条件，加载整个产品的某一历史 版本。606.4.3 变更控制过程 软件产品在开发过程中进行变更是不可避免 的，但不对变更加以控制是万万不可的。变更和变更控制，是矛盾的统一体。O变更控制过程就是通过一系列方法、手段对变更进行引 导约束，使变更的结果有利于改进产品、满足客户需要,同时使变更的实施对项目影响较小。O变更控制过程主要包括提出变更请求、分析变更请求、变更决策、实施变更和验证变更等步骤。O这些步骤需要有不同的软件开发人员参与，每个步骤主 要由不同角色负责。61基本的变更控制流程通过自动、手工的分配方式，提交的每一个变更请求将被 分配给相关的开发人员进行初步的分析。拒绝或推退变更626.4.3 变更控制过程变更都是有原因的，任何人提出变更请求都 是受相关事件的触发造成的。O这些事件可以是用户使用产品过程中遇到的产品故障或 需要产品新功能的愿望，也可以是开发人员在开发环节 发现的各种错误，如测试时发现的功能错误、审查文档 时发现的描述与实际操作不符、浏览代码时发现某行代 码逻辑有误等。O发生这些事件后，相关人员可自行提出变更请求或通过 各种渠道委托项目开发人员提出变更请求。636.4.3 变更控制过程 变更分析，主要从客观的角度验证变更请求的正确性和合 理性，提出初步的修改可行性判断、修改方案和工时，并 预测可能对项目和产品带来的影响。O变更分析一般由开发小组负责人或有经验的开发人员完成。O变更分析的结果，必须附加到该变更请求在配置管理库的记录中。经过初步分析的变更请求将被变更控制组(C hange C ontrol B oard,C C B)统一评审决策，以确定是否实施变更。O CCB根据变更请求的相关信息和变更分析的结果，结合项目当前状况决定 每个变更请求实施与否。O决定实施的变更将被分配给相应开发人员去实施；决定实施的变更将被终 止，并告知变更提交者。CCB通常也为待实施的变更分配优先级或重新指 定其他开发人员去实施。646.4.3 变更控制过程 开发人员实施变更并提交修改后必须经过质量保 证人员进行变更验证，确保所做的修改不多不少 地实现了相应的变更请求。O验证通过的变更将反映在产品的下个版本中，并告知相应的变更请 求提出者。验证未通过的变更将被要求返工或回滚。从理论上说，配置项的所有修改都必须经过上述 的变更控制过程。O这对许多开发人员来说或许是难以忍受的繁文缗节和官僚主义。O优秀的配置管理工具能根据项目的需要对变更控制流程加以定制，四个项目可通过合并或自动化某些步骤使得变更控制过程更为灵活 Wj 效。O相反，大型项目可通过扩充变更控制步骤，以实现更严格的控制过 程。656.4.4 基线管理过程 基线(Base Line),是由软件产品所有配置 项的特定版本构成的一个固定的产品版本，它是一定阶段变更请求实施后的累加效果。O基线标志产品开发前一个阶段的结果，又作为下一阶段 开发的基础。O基线管理和产品开发模式、开发阶段划分，以及产品发 布过程紧密相关。66基线管理过程基线管理过程，主要解决基线的创建、发布、使用、维护等方面的问题Baseline_ ComponentsWmMfwc/Baseline；Preliminary p&盘内黑盥 却:J Desiqn J?Design BaselineBaseline ConceptBaseline ProgressionTime6.4.4 基线管理过程基线一旦创建，就成为整个产品的一个正式标准，随后的 开发都基于此标准进行，直到下一个基线被创建。O因此，每一个新创建的基线都需要以正式的方式发布给项目中所有人员，发布内容包括基线的名称、包含的版本、可执行代码，以及初步验证结果O基线发布后，代码开发人员可以将基线内的配置项版本更 新到他的工作空间中，使个人的工作环境与项目中的整体 变更保持同步。O项目测试人员可以取得基线对应的可执行代码，进行进一步的测试验证，根据发现的问题提出新的变更请求，推动下一个基线的生成。O在项目的进展过程中，也可以利用旧的基线重新建立基于某个特定发布版 本的配置，用来重现已报告的错误或定位重复发生的问题。696.4,4 基线管理过程此外，基线也可作为新项目的起点，由此生 成一个单独的分支进行新项目的开发，新项 目将与随后对原始项目（在主要分支上）所 进行的变更相互隔离，必要时再进行台并。O基线反映的是配置项已经发生的变更，是固化的版本，因此基线的内容本身不需要什么维护工作。基线的维护,主要是保存基线记录，并结合产品开发过程标识基线 状态。70产品配置项的不同基线测试失败基线测试成功基线Beta版本基线716.5软件配置管理中的角色软件配置管理涉及了软件开发过程中几乎所 有的环节，需要项目所有人员的参与。O确实，对软件产品的开发和维护人员来说，配置管理是 不可避免的日常工作。O不管担任的是什么样的开发过程中的角色，都会涉及软 件配置管理活动。O区别在于同一种角色在软件开发过程中和在配置管理过 程中的角色主次不同。O从另一方面看，配置管理中有些任务是需要专门的配置 管理人员来完成的。如配置管理规划、配置库和配置管理工具的维护、配置审计。726.5.1 配置管理专职人员1.配)管理负责人 哥配置管理负责人的职责，是在开发机构管理层提供的框架 内实施、维护并改进软件配置管理流程与设施。O有些机构的配置管理负责人需要全面负责整个机构的配置管理，有些机构按项目或 组织单元设置配置管理负责人。配置管理负责人的工作，包括以下内容。O(1)为组织机构规划配置管理方案，将机构或组织对配置管理的需求转 换为实际的生产过程、工具和操作规范。O(2)部署和更新配置管理工具。O(3)跟踪机构或组织的配置管理执行情况，确保所定的流程被严格地执 行。O(4)为管理层提供配置管理状态报告、数据分析结果和相关改进建议。732.配置库管理员配置库管理员负责建立产品配置库，并维护 每个配置库的内部完整性与存储空间的安全 雇。配置库管理员的工作范围，主要有以下几方 面：O(1)建立配置库。O(2)创建并维护组成配置库的元数据(非配置项数据)OO(3)对配置库的使用者进行日常支持。O(4)从配置库中提取配置项状态信息与其他过程度量 信息，以供配置报告和审计。743.配置控制委员会配置控制委员会全面负责配置项的变更控制，因 此又称为变更控制委员会。O配置控制委员会有一位专职的主席，负责协调和决策，委员会的成 员则由项目经理、产品经理、客户代表、以及质量保证负责人等项 目中的重要人员担当。配置控制委员会的主要工作，有以下几点：O(1)评估变更请求，批准或否决所请求的变更。O(2)协调变更请求的执行过程，安排合理的优先级。O(3)跟踪变更请求的执行状况，并向变更请求的提出者及相关人 员提供反馈。O(4)决定产品基线的创建和使用策略，确定对外发布的基线。75652 机构运营管理人员 配置管理专职人员，是一个机构或项目中配置管 理过程的构造者和推广者，但他们只有获得了机 构或项目管理层的支持与认可后才能有效地完成 其职责任务。O因此，机构运营和管理人员是配置管理的有力支持者。在此，我们 把一个机构的组织管理人员和负责日常运营工作人员都划归为配置 管理的重要支持力量。O这些人员主要包括机构管理层、资产负责人、工程管理负责人、环 境与工具负责人，这些角色对配置管理有不同的支持作用。机构管理层对配置管理的支持主要体现在两个方 面：O为配置管理的实施和改进提供资本和对实施相关人员授予所需的特 权。为配置管理专职的人员明晰岗位职责，并提供职业晋升途径。76652 机构运营管理人员 过程管理负责人制订组织或机构的各种过程，保 证这些过程满足生产和发展的需求，能够正确地 得到实施。O配置管理过程是其中的一种过程。O因此，过程管理负责人会参与配置管理策略和过程的编制。使其与 其他过程相互衔接兼容。同时确保同一机构中不同项目的配置管理 过程基本一致。环境与工具负责人，为开发机构提供环境和工具 的支持，例如网络、数据存储、开发工具等方面 的支持。O配置管理活动同样离不开这些环境和工具。O环境与工具负责人为配置管理活动提供所依环境和工具的安装和培 训支持，同时协助配置管理负责人定制配置管理工具，以实现与其 他开发工具的集成。776.5.3 项目开发人员 项目开发人员，是配置管理活动中的重要参与者 和执行者。O