[工程科技]配置管理.ppt

软件项目的配置管理 Date1 软件配置及其管理的概念 配置管理活动和流程 配置管理需求 版本管理 变更管理 配置状态监测与报告 基于配置管理的软件项目管理 配置管理的技术手段和工具 配置管理 Date2 软件配置及其管理的概念 配置管理活动和流程 配置管理需求 版本管理 变更管理 配置状态监测与报告 基于配置管理的软件项目管理 配置管理的技术手段和工具 配置管理 Date3 CMM2的配置管理概念 IEEE的配置管理定义 配置管理概述 配置管理活动的作用 软件配置及其管理的概念 Date4 配置的概念 l l 配置的概念来自硬件配置的概念来自硬件 l l 软件工程师是如何处理接口的？软件工程师是如何处理接口的？ l l 广而言之：广而言之： l l 软件的变化可以发生在一秒钟内软件的变化可以发生在一秒钟内 l l 软件的变化可以发生在每一秒钟软件的变化可以发生在每一秒钟 l l 软件开发过程下一秒钟是不确定的软件开发过程下一秒钟是不确定的 l l 情况将会怎样？怎么办？情况将会怎样？怎么办？ Date5 软件项目开发管理的新需求 你在一家小公司做软件工程师，开始的时候，你只有一个人，配了 2个助手。你们研究了一种算法（例如：图象压缩、数据加密等），编 写了一个实现模块。有一天老板看到了你的演示，认为很有市场潜力 ，可以结合进公司正在给某行业用户正在准备开发的系统中，成为该 系统的核心技术或一个别人没有的卖点。 下一周，你的队伍增加到14（你的老板准备就此豪赌一把了），与 你3个人的小组不同的是，公司从其他部门为你配备了系统分析师，还 有文档编制员、测试员。你的核心模块已经被大量的用户功能所包装 ，成为一个行业应用系统，并开始给用户试用，这是你的系统的第一 版。 3个月后，公司决定把系统升级到第二版，除增加了许多新的功能 外，公司决定支持多平台，同时，为了提高系统的性能和效率，准备 采用第三方厂家的中间件，取代自己做的接口。第一版的缺陷修改， 也要反映到第二版中。 第2版经过2个多月的开发，最终推向了市场。公司的这个产品不但 被用户所欢迎，也被一家大公司所看中（就像IBM收购了Lotus和 Rational、Informix一样），你们的产品，正好可以填补这家大公司 产品线的空缺，你所在的公司被这家公司买去了。 Date6 公司为你的项目组派来了产品经理、项目经理。公司决定这个产品的测试 ，由公司总部独立的测试部门承担。同时，公司决定把项目组增加到50人， 其中有20多人并不在你所在的城市。在新公司里，产品管理、项目管理、测 试、质量等等，都与你过去的环境和做法不同，特别不同的是，公司准备开 发的第3版系统与公司原有的产品要进行融合，使他们看上去是一家出来的不 同的兄弟和姐妹。 与软件的第1版、第2版相比，你的项目管理有什么不同？ 随着这个产品的演变，项目发生了四个变化： （1）系统的复杂性发生了很大变化； （2） 用于开发该系统的项目环境发生了很大变化； （3）在不同的项目生命周期内，项目控制本身的要求和力度发生了很大 变化； （4）由于组织的变化，管理流程、人员、方式发生了很大变化。 前二类变化要求项目的组织和管理适应系统扩展的需要，后二种变化 则要求项目管理具有适应性和灵活性。 Date7 缺乏管理所造成的问题 l l 软件开发人员之间缺乏必要的交流软件开发人员之间缺乏必要的交流 l l 产品升级和维护所必需的程序和文档非常混乱产品升级和维护所必需的程序和文档非常混乱 l l 开发过程中的人员流动经常发生开发过程中的人员流动经常发生 l l 因管理不善致使未经测试的软件加入到产品中因管理不善致使未经测试的软件加入到产品中 l l 项目开发状态不清楚项目开发状态不清楚 l l 软件生产达不到规模化软件生产达不到规模化 Date8 软件配置管理 SCM（Software Configuration Management） 软件配置管理（软件配置管理（SCMSCM）是指在开发过程中各阶段，管理是指在开发过程中各阶段，管理 计算机程序演变的学科，它计算机程序演变的学科，它作为软件工程的关键元素，作为软件工程的关键元素， 已经成为软件开发和维护的重要组成部分已经成为软件开发和维护的重要组成部分 SCMSCM提供了结构化的，有序化的，产品化的管理软件工提供了结构化的，有序化的，产品化的管理软件工 程的方法。它涵盖了软件生命周期的所有领域并影响所程的方法。它涵盖了软件生命周期的所有领域并影响所 有数据和过程。有数据和过程。 l l 配置管理配置管理是指用于控制系统一系列变化的学科。是指用于控制系统一系列变化的学科。 l l 通过一系列技术，方法和手段来维护产品的历史，鉴通过一系列技术，方法和手段来维护产品的历史，鉴 别和定位产品独有的版本，并在产品的开发和发布阶段别和定位产品独有的版本，并在产品的开发和发布阶段 控制变化。控制变化。 l l 通过有序管理和减少重复性工作，配置管理保证了生通过有序管理和减少重复性工作，配置管理保证了生 产的质量和效率。产的质量和效率。 Date9 我们知道，在软件建立时，变更是不可避免的，而变更加剧了项目中软我们知道，在软件建立时，变更是不可避免的，而变更加剧了项目中软 件开发者之间的混乱。件开发者之间的混乱。SCMSCM活动的目标就是为了标识变更、控制变更、确保活动的目标就是为了标识变更、控制变更、确保 变更正确实现并向其他有关人员报告变更。变更正确实现并向其他有关人员报告变更。 因此，从某种角度讲，因此，从某种角度讲，SCMSCM是一种标识、组织和控制修改的技术，目的是是一种标识、组织和控制修改的技术，目的是 使错误降为最小并最有效地提高生产效率。使错误降为最小并最有效地提高生产效率。 SCMSCM通过以下方法，强化软件的可靠性和质量：通过以下方法，强化软件的可靠性和质量： （1 1）提供用于识别和控制文档、代码、接口、数据库的结构框架，适用于提供用于识别和控制文档、代码、接口、数据库的结构框架，适用于 软件开发生命周期的所有阶段；软件开发生命周期的所有阶段； （2 2）全面支撑某一特定开发及维护工作方法，能够适应各种类型的需求、）全面支撑某一特定开发及维护工作方法，能够适应各种类型的需求、 标准、政策、组织机构以及相关的管理策略；标准、政策、组织机构以及相关的管理策略； （3 3）针对特定的基线状态、变更控制、测试、发布版本或审查活动，生成）针对特定的基线状态、变更控制、测试、发布版本或审查活动，生成 相应的管理信息和产品信息。相应的管理信息和产品信息。 因此，从某种意义上讲，因此，从某种意义上讲，SCMSCM本质上是变更的管理。本质上是变更的管理。 SCMSCM使软件产品和过程的变更变为受控的和可预见的，它要求并在适当的使软件产品和过程的变更变为受控的和可预见的，它要求并在适当的 工具支持下能够做到这样几点：工具支持下能够做到这样几点： （1 1）谁做的变更？）谁做的变更？ （2 2）软件有什么变更？）软件有什么变更？ （3 3）什么时间做的变更？）什么时间做的变更？ （4）为何要变更？ Date10 软件项目的配置管理 l l 随着计算机软件的发展，软件开发已由最初的随着计算机软件的发展，软件开发已由最初的“程序设计阶段程序设计阶段 ”经历了经历了“软件系统阶段软件系统阶段”进而演变为后来的进而演变为后来的“软件工程阶段软件工程阶段 ”，软件的复杂性日益增大。此时，如果仍然把软件看成一个，软件的复杂性日益增大。此时，如果仍然把软件看成一个 单一的个体，就无法解决所面临的问题，于是配置的概念逐渐单一的个体，就无法解决所面临的问题，于是配置的概念逐渐 引入软件领域，人们越来越重视软件配置的管理工作。引入软件领域，人们越来越重视软件配置的管理工作。 l l 不懂软件项目的配置管理，就不懂软件开发管理不懂软件项目的配置管理，就不懂软件开发管理 l l 不对软件项目进行配置管理，就没有进行软件项目开不对软件项目进行配置管理，就没有进行软件项目开 发管理发管理 Date11 软件配置管理是CMM2中6个关键过程域的第6个 关键域。CMM2认为，SCM 的目的是为了建立和 维护软件开发过程中各种制品的完整性和一致性， 包括以下内容： 对软件产品配置的标志和识别 系统地控制对处于配置管理下的各种软 件制品的修改和更新 维护软件开发过程中的各种制品的一致 性和可跟踪性 CMM2的配置管理概念 Date12 SCM 的目标 v目标1: 软件配置管理活动被定义和计划 v目标2: 软件开发过程中的制品被识别、控制和管理 v目标3: 对于处于配置管理下的软件制品的修改被控制 v目标4: 与软件制品相关的项目组和成员应该被通知制品的目前 状态和被修改的信息 从对配置目的的定义可以看出，从对配置目的的定义可以看出，CMM2CMM2的配置管理应包括这样一些的配置管理应包括这样一些 活动：标识给定时间点的软件配置（即所选择的工作产品及其描活动：标识给定时间点的软件配置（即所选择的工作产品及其描 述），系统地控制这些配置的更改，并在软件生命周期中保持这述），系统地控制这些配置的更改，并在软件生命周期中保持这 些配置的完整性和可跟踪性。些配置的完整性和可跟踪性。 CMM2CMM2认为，受控于配置管理的工作产品，包括交付给用户的软认为，受控于配置管理的工作产品，包括交付给用户的软 件产品（如：代码等），以及生成软件产品所需要的有关项（如件产品（如：代码等），以及生成软件产品所需要的有关项（如 ：项目管理文件）。：项目管理文件）。 CMM2CMM2的配置管理活动最主要的内容是：建立软件基线库，该库的配置管理活动最主要的内容是：建立软件基线库，该库 存储开发的软件基线。通过软件配置管理的更改控制和配置审核存储开发的软件基线。通过软件配置管理的更改控制和配置审核 功能，系统地控制基线变更和由软件基线库生成的软件产品版本功能，系统地控制基线变更和由软件基线库生成的软件产品版本 。 Date13 要达到 CMM 规定的 SCM要求所需具备的能 力 具有对软件基线产品有管理权限的组织已经建立， 例如：软件配置管理委员会； 协调和实现软件配置管理的组织已经建立； 为进行软件配置管理所需要的各项资源已经分配； 软件配置管理组织里的成员已经接受了软件配置目 标、流程、方法方面的培训； 软件项目组或是其他的相关的部门经过培训，可以 执行他们的软件配置管理活动； Date14 CMM 中对SCM 规定的活动 根据文档化的流程，项目软件配置管理计划已准 备完毕； 文档化的已获批准的软件配置管理计划可用作以 后软件配置管理活动的基础； 软件配置管理库已经创建，并可用作进入基线的 软件制品的存贮库； 处于软件配置管理下的软件制品被标志和识别； 对于配置项的变更请求和问题报告被初始化、计 划、评审、批准并根据文化化的流程对其进行跟踪 ； Date15 对于进入基线的制品的修改必须遵循文档化的流程； 发布的产品必须从软件配置库中取出，并且产品发布 的流程须依照文档化的流程和规定； 根据文档化的流程和规定，软件配置项的状态被记录 和跟踪； 记录软件配置管理活动和软件基线内容的报告被建立 ，并通知受到影响的项目组和个人； 根据文档化的流程进行软件制品基线的评审； CMM 中对SCM 规定的活动 Date16 组织规定和相关责任 v项目级配置管理 项目配置经理(Project Configuration Manager) 与软件配置管理计划 变更控制委员会(Change Control Board) v组织级配置管理 组织配置管理库(Organizational Configuration Management Cell) 负责项目完成后的软件配置管理 活动 管理组织级的文档 Date17 IEEE标准729-1983就配置管理的内容进行了规范的定义： （1）标识：识别产品的结构、产品的构件及其类型，为其分配唯一 的标识符，并以某种形式提供对它们的存取。 （2）控制：通过建立产品基线，控制软件产品的发布和在整个软件 生命周期中对软件产品的修改。例如，它将解决哪些修改会在该产 品的最新版本中实现的问题。 （3）状态统计：记录并报告构件和修改请求的状态，并收集关于产 品构件的重要统计信息。例如，它将解决修改这个错误会影响多少 个文件的问题。 （4）审计和审查：确认产品的完整性并维护构件间的一致性，即确 保产品是一个严格定义的构件集合。例如，它将解决目前发布的产 品所用的文件的版本是否正确的问题。 （5）生产：对产品的生产进行优化管理。它将解决最新发布的产品 应由哪些版本的文件和工具来生成的问题。 （6）过程管理：确保软件组织的规程、方针和软件周期得以正确贯 彻执行。它将解决要交付给用户的产品是否经过测试和质量检查的 问题。 （7）小组协作：控制开发统一产品的多个开发人员之间的协作。例 如，它将解决是否所有本地程序员所做的修改都已被加入到新版本 的产品中的问题。 IEEE的配置管理定义 Date18 CMM2的定义比较抽象，IEEE的定义就比较具体。结 合各体系的定义和要求，我们下面具体来讨论配置管理 的概念。 配置管理功能概述 Date19 配置标识或者又称为配置需求，包括标识软件系统的结构， 标识独立部件，并使它们是可访问的。配置标识的目的，是在 整个生命周期中标识系统各部件并提供对软件过程及其软件产 品的跟踪能力。它回答：什么是受控的？ 配置变更控制包括在软件生命周期中控制软件产品的发布 和变更，目的是建立确保软件产品质量的机制。它回答：受控 产品怎样变更？谁控制变更？何时接受，恢复，验证变更？ 配置状态统计包括记录和报告变更过程，目标是不间断记录 所有基线项的状态和历史，并进行维护，它解决以下问题：系 统已经做了什么变更？此问题将会对多少个文件产生影响？配 置变更控制是针对软件产品，状态统计针对软件过程。因此， 二者的统一就是对软件开发（产品、过程）的变更控制。 配置审核将验证软件产品的构造是否符合需求、标准、或合 同的要求，目的是根据SCM的过程和程序，验证所有的软件产 品已经产生并有正确标识和描述，所有的变更需求都已解决。 它回答：系统和需求是否吻合？是否所有变更都是在版本控制 下？ SCM的四大功能领域 Date20 SCM从应用层次上可以从低到高分为三级：版本控制、以开发者为中 心、过程驱动。 版本控制主要应用于个人独立开发或小组开发，它可以控制任何文件 的版本、实现分支和归并功能、进行文本比较、标记注释和版本报告信 息，主要工具有MS的Visual SourceSafe及Intersolv PVCS。 以开发者为中心主要应用于部门级开发，它可用于软件维护、不断增 加的开发任务、并行开发、QA及测试，它面向大型团队、利于交流、能 最大限度地利用人力资源，主要工具为Rational ClearCase及MKS Source Integrity。 过程驱动主要使用于企业级开发，着重解决新的工具引入、IT审核、 管理报告、复杂的生命周期、应用工具包、集成解决方案、资料库等问 题，实现真正规范的团队开发，主要工具为Platinum Technology CCC/Harvest。 SCM的三个应用层次 Date21 SCM 中的专业术语 v 配置(Configuration)与配置项(Configuration Item) v 在软件开发过程中生成各种制品的总和叫做这 个项目的软件配置 Roger S. Pressman, 1997 计算机程序，包括源代码和可执行程 序 与计算机程序相对应的各种文档 计算机数据，包括计算机程序中包含 的数据和系统初始化数据 Date22 SCM 中的专业术语 v基线 项目开发过程的制品经过正式评审并被相关人员 一致同意，可以作为以后项目开发的基础。对已 经确定为基线的制品的修改必须要通过正式的变 更控制流程。 在软件工程环境中，基线是指在软件开发过程中 的里程碑，这些里程碑的标志是一项或多项经过 正式的技术评审并一致认同的软件制品的提交。 Date23 SCM 中的专业术语 v配置数据库（软件制品基线库） 项目建立和访问软件制品库，这个制品库主 要用来对保存配置项和一些与软件配置管理相 关的记录。 目前比较好的配置管理工具：Clearcase (Rational), Notes/Domino (Lotus), PVCS (Merant) and VSS (Microsoft). Date24 配置管理库(1) v基线库的结构(VOB) Project Root Directory Project Planning Phase Documents Requirements Analysis Phase Documents Design Phase Documents Code, Unit Test & Integration Phase Documents System Test Phase Documents Phase Deliverables Phase Deliverables Product Software Test Software Product Software Related Test Software Related Source Code Objective Code Executive Code DOC DATA A B B B B Code Date25 配置管理库的具体实现项目文件夹 项目文件件是项目开发过程中由项目组 创建和维护的制品归档库。 v软件配置管理负责管理和控制 项目文件夹，并对文件夹中的内容进 行评审； v项目经理负责监督项目的软件 配置管理执行； v软件质量工程师负责对项目文 件夹的内容进行评审； 配置管理库 Date26 配置管理库 项目文件夹的内容 v项目开发过程中的所有信息， 包括文档、工作制品和各种周报、月 报、评审等； v与外部的交流信息，例如与客 户、第三方的通讯交流记录等； v其他交流会议记录，例如：重 要的Email，传真， 信件等； Date27 配置管理库 权限管理 项目组内部的权限管理与分配 对其他项目组的开放权限管理与分配 对其他用户或是第三方的权限管理与 分配 Date28 配置管理活动的作用 v配置管理与质量管理 在质量体系的诸多支持活动中，配置管理处在支 持活动的中心位置。质量管理虽然也有过程的验证， 但配置管理只要定义的配置项够细，则它可以管理软 件开发的全过程，细到每一个模块、每一个文档、每 一条工程记录的变化。 因此，配置管理从基础层开始，有机地把其它支 持活动结合起来，形成一个整体，相互促进，相互影 响，有力地保证了质量体系的实施。 Date29 配置管理给项目组带来的好处 （1）节约费用 缩短开发周期 减少施工费用 （2）有利于知识库的建立 代码对象库 业务及经验库 （3）规范管理 量化工作量考核 规范测试 （4）加强协调与沟通 Date30 软件配置及其管理的概念 配置管理活动和流程 配置管理需求 版本管理 变更管理 配置状态监测与报告 基于配置管理的软件项目管理 配置管理的技术手段和工具 配置管理 Date31 主要配置管理活动 项目经理的配置管理流程 配置管理活动和流程 Date32 主要配置管理活动 v标志配置项 v变更控制 v版本控制 v评审 v统计 v软件编译、连接和发放管理 Date33 RUP描述的配置管理的主要活动如下 图所示： 对于一个软件项目组来说，开展一个项目组的配置管理，大致可以分为以下步骤： 对于一个软件项目组来说对于一个软件项目组来说 ，开展一个项目组的配置，开展一个项目组的配置 管理，大致可以分为以下管理，大致可以分为以下 步骤：步骤： （1 1）拟订项目的配置）拟订项目的配置 管理计划；（管理计划；（2 2）创建项）创建项 目的配置管理环境；（目的配置管理环境；（3 3 ）进行项目的配置管理活）进行项目的配置管理活 动，包括：标识配置项；动，包括：标识配置项； 管理基线和发布活动；监管理基线和发布活动；监 测与报告配置状态；管理测与报告配置状态；管理 变更请求。变更请求。 （1 1）和（）和（2 2）可以看成配）可以看成配 置管理的准备，（置管理的准备，（3 3）是）是 配置管理的具体实施。配配置管理的具体实施。配 置管理的具体实施，在置管理的具体实施，在 RUPRUP定义为四个管理活动定义为四个管理活动 。 Date34 配置项（Software Configuration Item，SCI）识 别 对于配置项，可以给出一个比较简单的定义，既软件过程的输 出信息可以分为三个主要类别： （1）计算机程序（源代码和可执行程序） （2）描述计算机程序的文档（针对技术开发者和用户） （3）数据（包含在程序内部或外部）。 这些项包含了所有在软件过程中产生的信息，总称为软件配置项 。” 在CMM2中，除上述3个配置项以外，还包括项目管理的有关文件、信息 记录等。 由此可见，配置项的识别是配置管理活动的基础，也是制定配 置管理计划的重要内容。 Date35 配置项（Software Configuration Item，SCI）识 别 软件配置管理认为软件的开发过程是一个不断变化着的过程， 为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入 了“基线（Base Line）”这一概念。 IEEE对基线的定义是这样的：“已经正式通过审核批准的某规 约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变 化控制过程改变。” 所以，根据这个定义，我们在软件的开发流程中，也可以把所有需要 加以控制的配置项分为基线配置项和非基线配置项两类，例如：基线 配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括 项目的各类计划和报告等。 有关配置项的内容，我们将在后面，专门花一节的篇幅，进行 讨论。 Date36 配置项项的标识标识 和控制 所有配置项都应按照相关规定统一编号，按照相应 的模板生成，并在文档中的规定章节（部分）记录对 象的 标识信息。在引入软件配置管理工具进行管理后，这些配 置项都应以一定的目录结构保存在配置库中。 所有配置项的操作权限应由配置管理员严格管理，基本原 则是：基线配置项向软件开发人员开放读取权限；非基 线配置项向项目经理、配置控制委员会及相关人员开放。 Date37 工作空间间管理 在引入了软件配置管理工具之后，所有开发人员都会被要求 把工作成果存放到由软件配置管理工具所管理的配置库（存储池） 中去，或是直接工作在软件配置管理工具提供的环境之下（根据配 置管理构架提供的控制方式不同而不同）。 每个开发人员按照任务的要求，在不同的开发阶 段，工作 在不同的工作空间上。 比较理想的情况是把整个配置库视为 一个统一的工作空间， 然后再根据需要把它划分为个人（私有）、团队 （集成）和全组 （公共）这三类工作空间（分支），从而更好的支持将来可能出 现的并行开发的需求。 Date38 版本控制 版本控制是软件配置管理的核心功能。所有置于配 置库中的元素都应自动予以版本的标识，并保证版本命名 的唯一性。版本在生成过程中，自动依照设定的使用模型 自动分支、演进。除了系统自动记录 的版本信息以外，为 了配合软件开发流程的各个阶段，我们还需要定义、收集 一些元数据来记录版本的辅助信息和规范开发流程，并为 今后对软件过程的度量做好准备。当然如果选用的工具支 持的话，这些辅助数据将能直接统计出过程数据，从而方 便我们软件过程改进（Software Process Improvement， SPI）活动的进行。 对于配置库中的各个基线控制项，应该根据其基 线的位置和状态来设置相应的访问权 限。一般来说，对 于基线版本之前的各个版本都应处于被锁定的状态，如需 要对它们进行变更，则应按照变更控制的流程来进行操 作。 Date39 变变更控制 变更管理的一般流程是： （1）（获得）提出变更请求； （2）由CCB审核并决定是否批准； （3）（被接受）分配请求，修改人员提取配置项，进行修改； （4）复审变化； （5）提交修改后的配置项； （6）建立测试基线并测试； （7）重建软件的适当版本； （8）复审（审计）所有配置项的变化； （9）发布新版本。 在这样的流程中，配置管理员通过软件配置管理工具来进行访问 控制和同步控制，而这两种控制则是建立在前面所描述的版本控制和 分支策略的基础上的。 Date40 状态报态报 告 配置状态报告应该包括下列主要内容： (1)配置库结构和相关说明； (2)开发起始基线的构成； (3)当前基线位置及状态； (4)各基线配置项集成分支的情况； (5)各私有开发分支类型的分布情况； (6)关键元素的版本演进记录； (7)其它应报告的事项。 Date41 配置审计审计 配置审计 的主要作用是作为变 更控制的补充手段，来确保某 一变更需求已被切实实现 。在某些情况下，它被作为正式的技术复审 的一部分，但当软件配置管理是一个正式的活动时 ，该活动由SQA人 员单 独执行。 总之，软件配置管理的对象是软件研发活动中的全部开发资产。所有 这一切都应作为配置项纳入管理计划统一进行管理，从而能够保证及 时的对所有软件开发资源进行维护和集成。因此，软件配置管理的主 要任务也就归结为以下几条： （1）制定项目的配置计划； （2）对配置项进行标识； （3）对配置项进行版本控制； （4）对配置项进行变更控制； （5）定期进行配置审计； （6）向相关人员报告配置的状态。 Date42 项目经理的配置管理流程 项目经理的工作 是： （1）确定项目 配置管理策略 （2）确定用于 控制产品变更的 策略和流程 （3）在配置管 理计划（是软件 开发计划的一部 分）中记录此信 息 Date43 配置管理策略 软件配置管理策略是指能够确定、保护和报告已经批准用于项目 中的工件的能力。通过正确的标注来实现确定操作。对项目工件的保 护是通过归档、建立基线和报告等操作而得以实现的。 使用标准的、已记录下来的变更控制流程的目的是：确保项目中 所做的变更保持一致，并将产品的状态、对其所做的变更以及这些变 更所耗费的成本及对时间表的影响通知给有关的涉众。 软件配置管理计划说明在产品/项目生命周期中要执行的所有与配 置管理相关的活动。它记录如何计划、实施、控制和组织与产品相关 的配置管理活动。 Date44 配备人员 配置管理人员的选择和配备，是软件项目经理最主要 的工作。在一个比较理想的软件开发团队中，需要哪些角 色呢？ 负 责软件项目组的项目经理 负 责SCM计划和策略的配置经理 负 责软件产品开发与维护的软件工程人员 负 责验证产品正确性的测试人员 负 责确保产品高质量的质量保证经理 使 用产品的用户。 Date45 配置经理 配置经理的目标是确保用来建立、变更及编码测试的 计划和策略得以贯彻执行，同时使有关项目的信息容易获 得。 为了对编码更改形成控制，配置经理引入规范的请求 变更的机制，评估更改的机制（通过变更控制机构CCB， 由它负责批准对软件系统的变更），和批准变更的机制。 配置经理负责为工程人员创建任务单，交由项目经理 对任务进行分配，创建项目的框架。同时，配置经理还收 集软件系统中构件的相关数据，比如说用以判断系统中出 现问题的构件的信息。 Date46 软件配置及其管理的概念 配置管理活动和流程 配置管理需求 版本管理 变更管理 配置状态监测与报告 基于配置管理的软件项目管理 配置管理的技术手段和工具 配置管理 Date47 配置管理的对象 最基本的配置管理项文档 UCM目录结构下的配置管理对象 配置管理需求 Date48 配置管理对象 配置管理的第一个基本活动是配置标识，通俗地讲，也就是查询、 识别和确定配置管理对象配置项。在生产的软件产品和软件的生 产过程中，那些是配置管理的对象呢？ 配置管理对象呈现为一种层次结构，因此，为了标识配置管理的对 象，我们需要对软件系统进行分解： 目前，用于分解软件系统的术语有多种多样，没有被标准化。 v1989年Humphery定义了5个层次：系统、子系统、产品、构件和模 块。 v1991年Whitgift定义了3个层次：系统、子系统和元素。 vIEEE定义了3个层次：计算机配置项、计算机软件构件和计算机软 件单元。 vRUP定义了4个层次：系统、实施（或构件）子系统、构件和文件（ RUP5.5 1999）。 Date49 配置管理对象 在RUP的概念里，最底层的元 素是处于版本控制下的文件和目 录，构件的层次要高于元素（文 件和目录），构件把元素组织起 来。一个版本控制的构件是一个 具体的物理的对象，就是一个根 目录。这个根目录，以及从根目 录下所属的所有目录和文件，是 系统的一个子系统。大的系统有 多个根目录（子系统），小系统 则可能只有一个根目录。 产品目录结构为所有可具有版本号的、与产品相关的工件提供逻辑产品目录结构为所有可具有版本号的、与产品相关的工件提供逻辑 嵌套的占位符。工件是开发流程生命周期的结果，用于开发整个系统嵌套的占位符。工件是开发流程生命周期的结果，用于开发整个系统 的各组成部分（构件）。的各组成部分（构件）。 Date50 配置管理对象 首先我们从根目录开始（假设是只有一个根目录的小）系统，讨论 软件系统架构：软件项目通过一系列的生命阶段，将建立或者已经建 立起一个体系构架。软件的体系构架在软件工程时代被称为系统结构 。在UML中，被称为构架。 vUML对构架的定义是： （1）一组有关软件系统组织结构的重要决定； （2）结构要素和接口的选取，确保它们的行为能满足这些要素之 间的协作关系； （3）结构要素和行为要素以一种渐进的方式被组装成子系统，能 够指导这种组织结构的结构风格，要素的内容，它们的接口、它们的 协作和它们的组合。 v系统或系统构架是由子系统（构件）组成的。 Date51 UML进一步把构件划分成三种构件：部署型构件、工作产品型构件 和执行构件。 （1）部署型构件：是指那些被部署到目标机中的元素，例如： 可执行程序、库以及其他支持系统运行的文件。 （2）工作型构件：是构成开发环境的元素，例如：源文件、头文 件以及其他用于导出或构建部署型构件的文件。 （3）可执行型构件：是指由运行于目标机的系统生成的内容，例 如：数据等。 v从SCM的角度看系统架构，我们主要关注的是在开发环境中以及将 来部署到目标系统中的系统的物理层面的文件和目录结构、分组和版 本化。这种关注决定了配置管理的对象以及对象的“粒度”。 v现在，有些项目使用高层次的设计文档来描述架构，例如：模型、 视图等。在高层架构描述中，逻辑上的“类”，可影射对应为物理层 面的文件和目录。 v作为软件产品和软件过程，这些文件和目录是SCM控制的对象，即 他们是配置项。在我们现在的讨论中，有时，我们说明这些文件是用 于管理和设计系统的内容（包括：项目计划、设计模型、测试报告） 等，有些是实现系统设计的文件（包括：源代码、库、执行文件等） ，有时，把它们不加区别地看成为构件。 Date52 CMM2的配置管理对象 CMM2把配置管理对象，称之为软件工作产品，在CMM2配置管理定义 中，对应置于配置管理下的软件工作产品，是这样定义的： v可作为配置项/单元标识的软件工作产品实例有： 与过程相关的文档（例如：计划、标准或规程） 软 件需求 软 件设计 软 件代码单元 软 件测试规程 为 软件测试活动建立的软件系统 交 付给客户或最终用户的软件系统 编 译程序 其 他支持工具 不 论各体系是如何定义的，我们基本可以认为，配置管理的对象，主要 地可以分为二类：软件产品和文档。软件产品比较容易标识，而文档 相对比较复杂。我们将重点进行讨论。 v Date53 最基本的配置管理项文档 文档在软件开发人员、软件管理人员、维护人员、用户以及计算机 之间，起到了多种的桥梁作用。软件开发人员在软件生命的各个阶段 中，以文档作为前阶段工作成果的体现和后阶段工作的依据，这个作 用是显而易见的。这部分文档通常称为开发文档。 软件开发过程中软件开发人员需制定一些工作计划或工作报告，这 些计划和报告都要提供给管理人员， 并得到必要的支持。管理人员则 可通过这些文档了解软件开发项目安排、进度、资源使用和成果等。 这部分文档通常称为管理文档，或称为项目文档。 软件开发人员需为用户了解软件的使用、操作和维护提供详细的资 料。这部分文档通常称为用户文档。 Date54 我们把这三种文档所包括的内容列在下图中。其中列 举了十三个文档，这里对它们做一些简要说明： 文档 用户文档 用户手册 操作手册 维护修改建议 软件需求（规格）说明书 开发文档 软件需求（规格）说明书 数据要求说明书 概要设计说明书 详细设计说明书 可行性研究报告 项目开发计划 管理文档 项目开发计划 测试计划 测试报告 开发进度月报 开发总结报告 Date55 文档的生成阶段 阶段阶段 文档文档 可行性研究与计可行性研究与计 划划 需求分析需求分析设计设计代码编写代码编写测试测试 运行与维运行与维 护护 可行性研究报告可行性研究报告 项目开发计划项目开发计划 软件需求说明软件需求说明 数据要求说明数据要求说明 概要设计说明概要设计说明 详细设计说明详细设计说明 测试计划测试计划 用户手册用户手册 操作手册操作手册 测试分析报告测试分析报告 开发进度月报开发进度月报 项目开发总结项目开发总结 维护修改建议维护修改建议 Date56 文档的作用 所提问题所提问题 文档文档 什么什么何处何处何时何时谁谁如何如何为何为何 可行性研究报告可行性研究报告 项目开发计划项目开发计划 软件需求说明软件需求说明 数据要求说明数据要求说明 概要设计说明概要设计说明 详细设计说明详细设计说明 测试计划测试计划 用户手册用户手册 操作手册操作手册 测试分析报告测试分析报告 开发进度月报开发进度月报 项目开发总结项目开发总结 维护修改建议维护修改建议 Date57 UCM目录结构下的配置管理 UCM（统一变更管理）的发展沿革 第一代UCM： 第二代UCM： 第三代UCM： v第三代UCM引进了一些新的概念： （1）活动（Activity）： （2）构件（Component）： （3）工作流（Stream）： （4）项目（Project）： Date58 软件配置及其管理的概念 配置管理活动和流程 配置管理需求 版本管理 变更管理 配置状态监测与报告 基于配置管理的软件项目管理 配置管理的技术手段和工具 配置管理 Date59 版本管理的必要性 此前的版本管理 元素、分支与版本 构件、基线与存储池 现代版本管理活动 版本管理 Date60 版本管理的必要性 在软件开发过程中，由于软件开发所固有的特征，可能会形成众 多的软件版本，而且我们并不能保证不出现错误的修改，而这样的一 个困难局面却又非常现实地摆在项目开发管理者的面前，他/她该如何 有效地解决这些问题，具体地说就是如下一些问题： （1）怎样对研发项目进行整体管理； （2）项目开发小组的成员之间如何以一种有效的机制进行协调； （3）如何进行对小组成员各自承担的子项目的统一管理； （4）如何对研发小组各成员所作的修改进行统一汇总； （5）如何保留修改的轨迹，以便撤销错误的改动； （6）对在研发过程中形成的软件的各个版本如何进行标识，管理 及差异识辨等等。 一个非常直接的反应是，我们必须要引进一种管理机制，一个版本 管理机制，而且是广义上的版本管理，它不仅需要对源代码的版本进 行管理，而且还要对整个项目进行管理。 Date61 早前的版本管理 在软件工程时代，面对这样的问题，我们通过以往的那种被誉建立具有良好的编 程风格的做法，诸如在编程或对他人的源程序进行修改时，注释修改原因，修改人 和日期。如果是多个成员同时进行了修改，那么可能出现一个库管理员，由他来控 制什么人在访问哪个源代码，修改的人向他报告做了什么改动。如果有几个人同时 改动，库管理员或者限定同时只能有一个人做修改，他记住这人是谁，或者他自己 来做同时修改的人工的差异比较和综合，以便形成一个统一的新版本。在3-5人小 组，这个库管理员还能胜任，但这种做法在当前的大型软件的开发中已经越来越困 难了，因为靠人工的操作、靠个人的自觉、靠库管理员的维护，充其量是一种以小 作坊的形式来面对软件的社会化大生产，再也不可能行得通了。 基于共享文件目录的版本管理 在版本控制工具出现之前，或者，现在国内很多的软件企业，并不用什么版本 控制工具。他们也做一些简单的版本控制工作。他们是怎么做的？ 最简单的办法是使用文件拷贝支持不同的版本。具体地讲，就是项目组在项目 组的文件共享服务器上，建立一个项目组文件系统，在文件系统下，对涉及到的文件， 建立不同的版本目录，从个人工作区到系统发布版，包括中间结果，甚至可能是所有文 件。库管理员不断地增加目录的标签，以标识历史前进的步伐。 Date62 早前的版本管理 早期的版本管理工具 （1）通过存储池机制来维护文件库； （2）创建和存放文件的多个版本； （3）提供一种或几种锁定装置，强制对文件的修改顺序； （4）标识文件的版本； （5）从历史目录中找回旧版本。 这些工具基本上能帮助库管理员从手工的管理中解脱出 来，开发人员不需要库管理员的介入，可以自己从库中检 入和检出文件，当文件被检出后，其他人暂时不能再检出 此文件。同时，在必要的时候，文件的一个新版本被创立 。 Date63 早前的版本管理 例如：MS的VSS版本控制是通过以下方式实现的： VSS提供版本控制和历史服务，以保证一个文件的每个版本都是可 恢复的。 VSS用日期/时间戳来记录文件是何时被Check-out或是何时被修改 的，它主要有三种方法来跟踪文件和项目的版本： （1）版本号：这是由VSS维护的内部数码，用户对它没有控制权。 每个文件和项目的每个版本都有一个版本号，这些版本号总是一个整 数且是递增的。 （2）标签标签 ：这这些是用户赋给户赋给 某个项项目或文件的某个版本的一个字 符串，可以是任何格式的长长度不超过过31字符的字符串。 （3）日期/时间戳：它给出了一个文件何时最后被修改的信息，或 者是一个文件何时被Check-in。VSS同时支持 12小时和24小时的时间 格式。 Date64 元素、分支与版本 原子对象 在 ClearCase的概念中，置于版本控制下的原子对象被称为“元素” （element），元素是文件系统对象：文件和目录。每个元素记录了它所 代表的文件和目录的版本。所以，当用户检入文件时，就创建了那个元素的 新版本。元素被组织成不同的分支。分支是线形的版本序列，版本序列构成 的是并行开发的项目或基于统一基线开始的不同的系统。元素都被保存在存 储池（VOB）中。下图是存储池、元素、分支、版本之间的关系： 在ClearCase中，每一个元素都以一个主分支（main branch）和一个不包 含任何内容的零版本序列开始，称为“/main/0”。每一次新版本检入，在主 分支上创建版本1 Date65 SCMSCM 的版本树的版本树 左图的版本树中，长方形表示 一个分支，圆形表示检入的时 间排序的版本号，箭头表示从 一个分支到另一个分支的变更 回归（归并）。“发布版本 1.0/1.1”是这个版本上的标签 。目录是元素，也是版本对象 。ClearCase对目录与文件一样 ，也进行版本管理。为了能在 前一个版本中修复BUG，或者从 新版本退回到就版本，就有必 要恢复一个旧的版本。目录被 修改，在检入的时候，也要进 行记录。对目录进行版本管理 的目的，还可以借助目录机制 ，重建或构造软件系统的前一 个版本。 3 4 3 2 1 0Release 1.0 main 2 1 0 3 rel1_bugfix 2 rel2 1 0 Release 1.1 Date66 元素类型 在ClearCase中，存放在存储池中的元素都被赋予特定的类型，使之可 以用于多种目的。类型可以帮助系统决定对该元素的操作。 包括： l 确定 元素可以使用的存储/增量机制 l 决定 版本选择的范围，例如：设计文档版本、项目管理文档版本等 l 适用 于不同的配置管理策略 l 决定 比较、归并等的机制 ClearCase已经预先定义了的元素类型，它们主要和存储机制有关。 文件 （完全备份） 文本 文件（同轴增量备份） 压缩 文本文件（与文本文件相同，但进行压缩） 压缩 文件（完全备份，仅进行压缩） 二进 制文件（差异增量保存） 目录 （直接保存） Date67 构件、基线与存储池 构件将把被一起开发、集成和发布的文件和目录聚集在一起。聚 集成ClearCase构件的文件和元素通常可以实现系统构架中的一个可重 用的部分。 构件通过标识一个根目录来定义，这个目录与所有的文件和子目 录都被看作是这个构件的一个部分。 构件的一个版本就是一个基线。构件基线标识了构件中包含的每 一个元素或一个版本，构件的基线用来配置工作流，为各种视图提供 信息，以便决定文件和目录的什么版本被显示。 就像元素有版本一样，构件有基线。当修改一个元素时，你创建 了这个元素的一个版本，当你修改构件中的一个元素时，你也创建了 这个构件的一个新基线。工作流把一组构件基线聚集在一起。然而， 这不是项目范围的基线概念，更恰当的讲，当你在项目的集成流上完 成一个基线操作时，你创建了一组被修改构件的基线。 Date68 根据一个产品的质量标准要求和需求的不同，可以定义一个项目的不同基线。也就 是说，一个公司可以定义不同的测试、功能、版本基线。另一个项目组可以根据自己的 需要，选择某特定构件，确定自己的基线。 下图 表明构件和基线之间的关系： 任何UCM的核心最后将归结到存储池，存储池也被称为“Versioned Object Base”，或简称为VOB。VOB是用于存储文件、目录和元数据的永久数 据存储池。VOB必须能够支持可扩展的、容错的、分布式的可复制的性能。 项目的VOB包含与项目环境有关的对象，如：项目、构件、活动以及基线 ，这些构成了一个正在开发的项目的所有信息，包括项目的组织和管理信息 。 Date69 现代版本管理活动 现代版本管理活动围绕以下展开： l 支 持多人同时修改同一文件； l 支 持多个小组在同一时间修改同一个软件系统； l 现 代的工作空间管理； l 现 代的构建和发布管理。 Date70 并行开发的版本控制并行开发的版本控制 并行开发 3 2 1 0 main 2 1 0 3 Bugfix 4 2 1 0 main 3 4 3 2 Telecom 1 0 Release 1.0 Te