软件项目的配置管理 2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测与报告 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测与报告 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

8.1 软件配置及其管理的概念 8.1.1 CMM2的配置管理概念 8.1.2 IEEE的配置管理定义 8.1.3 配置管理概述 8.1.4 配置管理活动的作用 2019/5/1

配置的概念 配置的概念来自硬件 软件工程师是如何处理接口的？ 广而言之： 软件的变化可以发生在一秒钟内 软件的变化可以发生在每一秒钟 软件开发过程下一秒钟是不确定的 情况将会怎样？怎么办？ 2019/5/1

软件项目开发管理的新需求 你在一家小公司做软件工程师，开始的时候，你只有一个人，配了2个助手。你们研究了一种算法（例如：图象压缩、数据加密等），编写了一个实现模块。有一天老板看到了你的演示，认为很有市场潜力，可以结合进公司正在给某行业用户正在准备开发的系统中，成为该系统的核心技术或一个别人没有的卖点。 下一周，你的队伍增加到14（你的老板准备就此豪赌一把了），与你3个人的小组不同的是，公司从其他部门为你配备了系统分析师，还有文档编制员、测试员。你的核心模块已经被大量的用户功能所包装，成为一个行业应用系统，并开始给用户试用，这是你的系统的第一版。 3个月后，公司决定把系统升级到第二版，除增加了许多新的功能外，公司决定支持多平台，同时，为了提高系统的性能和效率，准备采用第三方厂家的中间件，取代自己做的接口。第一版的缺陷修改，也要反映到第二版中。 第2版经过2个多月的开发，最终推向了市场。公司的这个产品不但被用户所欢迎，也被一家大公司所看中（就像IBM收购了Lotus和Rational、Informix一样），你们的产品，正好可以填补这家大公司产品线的空缺，你所在的公司被这家公司买去了。 2019/5/1

与软件的第1版、第2版相比，你的项目管理有什么不同？ 随着这个产品的演变，项目发生了四个变化： （1）系统的复杂性发生了很大变化； 公司为你的项目组派来了产品经理、项目经理。公司决定这个产品的测试，由公司总部独立的测试部门承担。同时，公司决定把项目组增加到50人，其中有20多人并不在你所在的城市。在新公司里，产品管理、项目管理、测试、质量等等，都与你过去的环境和做法不同，特别不同的是，公司准备开发的第3版系统与公司原有的产品要进行融合，使他们看上去是一家出来的不同的兄弟和姐妹。 与软件的第1版、第2版相比，你的项目管理有什么不同？ 随着这个产品的演变，项目发生了四个变化： （1）系统的复杂性发生了很大变化； （2） 用于开发该系统的项目环境发生了很大变化； （3）在不同的项目生命周期内，项目控制本身的要求和力度发生了很大变化； （4）由于组织的变化，管理流程、人员、方式发生了很大变化。 前二类变化要求项目的组织和管理适应系统扩展的需要，后二种变化则要求项目管理具有适应性和灵活性。 2019/5/1

缺乏管理所造成的问题 软件开发人员之间缺乏必要的交流 产品升级和维护所必需的程序和文档非常混乱 开发过程中的人员流动经常发生 因管理不善致使未经测试的软件加入到产品中 项目开发状态不清楚 软件生产达不到规模化 2019/5/1

软件配置管理 SCM（Software Configuration Management） 计算机程序演变的学科，它作为软件工程的关键元素，已经成为软件开发和维护的重要组成部分…… SCM提供了结构化的，有序化的，产品化的管理软件工程的方法。它涵盖了软件生命周期的所有领域并影响所有数据和过程。 配置管理是指用于控制系统一系列变化的学科。 通过一系列技术，方法和手段来维护产品的历史，鉴 别和定位产品独有的版本，并在产品的开发和发布阶段 控制变化。 通过有序管理和减少重复性工作，配置管理保证了生 产的质量和效率。 2019/5/1

因此，从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。 （1）提供用于识别和控制文档、代码、接口、数据库的结构框架，适用于软件开发生命周期的所有阶段； （2）全面支撑某一特定开发及维护工作方法，能够适应各种类型的需求、标准、政策、组织机构以及相关的管理策略； （3）针对特定的基线状态、变更控制、测试、发布版本或审查活动，生成相应的管理信息和产品信息。 因此，从某种意义上讲，SCM本质上是变更的管理。 SCM使软件产品和过程的变更变为受控的和可预见的，它要求并在适当的工具支持下能够做到这样几点： （1）谁做的变更？ （2）软件有什么变更？ （3）什么时间做的变更？ （4）为何要变更？ 2019/5/1

软件项目的配置管理 不懂软件项目的配置管理，就不懂软件开发管理 不对软件项目进行配置管理，就没有进行软件项目开发管理 随着计算机软件的发展，软件开发已由最初的“程序设计阶段”经历了“软件系统阶段”进而演变为后来的“软件工程阶段”，软件的复杂性日益增大。此时，如果仍然把软件看成一个单一的个体，就无法解决所面临的问题，于是配置的概念逐渐引入软件领域，人们越来越重视软件配置的管理工作。 不懂软件项目的配置管理，就不懂软件开发管理 不对软件项目进行配置管理，就没有进行软件项目开发管理 2019/5/1

8.1.1 CMM2的配置管理概念 对软件产品配置的标志和识别 系统地控制对处于配置管理下的各种软件制品的修改和更新 软件配置管理是CMM2中6个关键过程域的第6个关键域。CMM2认为，SCM 的目的是为了建立和维护软件开发过程中各种制品的完整性和一致性，包括以下内容： 对软件产品配置的标志和识别 系统地控制对处于配置管理下的各种软件制品的修改和更新 维护软件开发过程中的各种制品的一致性和可跟踪性 2019/5/1

SCM 的目标 目标1: 软件配置管理活动被定义和计划 目标2: 软件开发过程中的制品被识别、控制和管理 目标3: 对于处于配置管理下的软件制品的修改被控制 目标4: 与软件制品相关的项目组和成员应该被通知制品的目前状态和被修改的信息 从对配置目的的定义可以看出，CMM2的配置管理应包括这样一些活动：标识给定时间点的软件配置（即所选择的工作产品及其描述），系统地控制这些配置的更改，并在软件生命周期中保持这些配置的完整性和可跟踪性。 CMM2认为，受控于配置管理的工作产品，包括交付给用户的软件产品（如：代码等），以及生成软件产品所需要的有关项（如：项目管理文件）。 CMM2的配置管理活动最主要的内容是：建立软件基线库，该库存储开发的软件基线。通过软件配置管理的更改控制和配置审核功能，系统地控制基线变更和由软件基线库生成的软件产品版本。 2019/5/1

要达到 CMM 规定的 SCM要求所需具备的能力 具有对软件基线产品有管理权限的组织已经建立，例如：软件配置管理委员会； 协调和实现软件配置管理的组织已经建立； 为进行软件配置管理所需要的各项资源已经分配； 软件配置管理组织里的成员已经接受了软件配置目标、流程、方法方面的培训； 软件项目组或是其他的相关的部门经过培训，可以执行他们的软件配置管理活动； 2019/5/1

CMM 中对SCM 规定的活动 根据文档化的流程，项目软件配置管理计划已准备完毕； 文档化的已获批准的软件配置管理计划可用作以后软件配置管理活动的基础； 软件配置管理库已经创建，并可用作进入基线的软件制品的存贮库； 处于软件配置管理下的软件制品被标志和识别； 对于配置项的变更请求和问题报告被初始化、计划、评审、批准并根据文化化的流程对其进行跟踪； 2019/5/1

CMM 中对SCM 规定的活动 对于进入基线的制品的修改必须遵循文档化的流程； 发布的产品必须从软件配置库中取出，并且产品发布的流程须依照文档化的流程和规定； 根据文档化的流程和规定，软件配置项的状态被记录和跟踪； 记录软件配置管理活动和软件基线内容的报告被建立，并通知受到影响的项目组和个人； 根据文档化的流程进行软件制品基线的评审； 2019/5/1

组织规定和相关责任 项目级配置管理 项目配置经理(Project Configuration Manager) 与软件配置管理计划 变更控制委员会(Change Control Board) 组织级配置管理 组织配置管理库(Organizational Configuration Management Cell) 负责项目完成后的软件配置管理活动 管理组织级的文档 2019/5/1

8.1.2 IEEE的配置管理定义 IEEE标准729-1983就配置管理的内容进行了规范的定义： （1）标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。 （2）控制：通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。例如，它将解决哪些修改会在该产品的最新版本中实现的问题。 （3）状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。例如，它将解决修改这个错误会影响多少个文件的问题。 （4）审计和审查：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。例如，它将解决目前发布的产品所用的文件的版本是否正确的问题。 （5）生产：对产品的生产进行优化管理。它将解决最新发布的产品应由哪些版本的文件和工具来生成的问题。 （6）过程管理：确保软件组织的规程、方针和软件周期得以正确贯彻执行。它将解决要交付给用户的产品是否经过测试和质量检查的问题。 （7）小组协作：控制开发统一产品的多个开发人员之间的协作。例如，它将解决是否所有本地程序员所做的修改都已被加入到新版本的产品中的问题。 2019/5/1

8.1.3 配置管理功能概述 CMM2的定义比较抽象，IEEE的定义就比较具体。结合各体系的定义和要求，我们下面具体来讨论配置管理的概念。 2019/5/1

SCM的四大功能领域 配置标识或者又称为配置需求，包括标识软件系统的结构，标识独立部件，并使它们是可访问的。配置标识的目的，是在整个生命周期中标识系统各部件并提供对软件过程及其软件产品的跟踪能力。它回答：什么是受控的？ 配置变更控制包括在软件生命周期中控制软件产品的发布和变更，目的是建立确保软件产品质量的机制。它回答：受控产品怎样变更？谁控制变更？何时接受，恢复，验证变更？ 配置状态统计包括记录和报告变更过程，目标是不间断记录所有基线项的状态和历史，并进行维护，它解决以下问题：系统已经做了什么变更？此问题将会对多少个文件产生影响？配置变更控制是针对软件产品，状态统计针对软件过程。因此，二者的统一就是对软件开发（产品、过程）的变更控制。 配置审核将验证软件产品的构造是否符合需求、标准、或合同的要求，目的是根据SCM的过程和程序，验证所有的软件产品已经产生并有正确标识和描述，所有的变更需求都已解决。它回答：系统和需求是否吻合？是否所有变更都是在版本控制下？ 2019/5/1

SCM的三个应用层次 SCM从应用层次上可以从低到高分为三级：版本控制、以开发者为中心、过程驱动。 版本控制主要应用于个人独立开发或小组开发，它可以控制任何文件的版本、实现分支和归并功能、进行文本比较、标记注释和版本报告信息，主要工具有MS的Visual SourceSafe及Intersolv PVCS。 以开发者为中心主要应用于部门级开发，它可用于软件维护、不断增加的开发任务、并行开发、QA及测试，它面向大型团队、利于交流、能最大限度地利用人力资源，主要工具为Rational ClearCase及MKS Source Integrity。 过程驱动主要使用于企业级开发，着重解决新的工具引入、IT审核、管理报告、复杂的生命周期、应用工具包、集成解决方案、资料库等问题，实现真正规范的团队开发，主要工具为Platinum Technology CCC/Harvest。 2019/5/1

SCM 中的专业术语 配置(Configuration)与配置项(Configuration Item) 在软件开发过程中生成各种制品的总和叫做这个项目的软件配置 [Roger S. Pressman, 1997] 计算机程序，包括源代码和可执行程序 与计算机程序相对应的各种文档 计算机数据，包括计算机程序中包含的数据和系统初始化数据 2019/5/1

SCM 中的专业术语 基线 项目开发过程的制品经过正式评审并被相关人员一致同意，可以作为以后项目开发的基础。对已经确定为基线的制品的修改必须要通过正式的变更控制流程。 在软件工程环境中，基线是指在软件开发过程中的里程碑，这些里程碑的标志是一项或多项经过正式的技术评审并一致认同的软件制品的提交。 2019/5/1

SCM 中的专业术语 配置数据库（软件制品基线库） 项目建立和访问软件制品库，这个制品库主要用来对保存配置项和一些与软件配置管理相关的记录。 目前比较好的配置管理工具：Clearcase (Rational), Notes/Domino (Lotus), PVCS (Merant) and VSS (Microsoft). 2019/5/1

配置管理库(1) 基线库的结构(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 Product Software Test Software Product Software Related Test Software Related Source Code Objective Code Executive Code DOC DATA A B Code 2019/5/1

配置管理库 配置管理库的具体实现——项目文件夹 项目文件件是项目开发过程中由项目组创建和维护的制品归档库。 软件配置管理负责管理和控制项目文件夹，并对文件夹中的内容进行评审； 项目经理负责监督项目的软件配置管理执行； 软件质量工程师负责对项目文件夹的内容进行评审； 2019/5/1

配置管理库 项目文件夹的内容 项目开发过程中的所有信息，包括文档、工作制品和各种周报、月报、评审等； 与外部的交流信息，例如与客户、第三方的通讯交流记录等； 其他交流会议记录，例如：重要的Email，传真， 信件等； 2019/5/1

配置管理库 权限管理 项目组内部的权限管理与分配 对其他项目组的开放权限管理与分配 对其他用户或是第三方的权限管理与分配 2019/5/1

8.1.4 配置管理活动的作用 配置管理与质量管理 在质量体系的诸多支持活动中，配置管理处在支持活动的中心位置。质量管理虽然也有过程的验证，但配置管理只要定义的配置项够细，则它可以管理软件开发的全过程，细到每一个模块、每一个文档、每一条工程记录的变化。 因此，配置管理从基础层开始，有机地把其它支持活动结合起来，形成一个整体，相互促进，相互影响，有力地保证了质量体系的实施。  2019/5/1

配置管理给项目组带来的好处 （1）节约费用 缩短开发周期 减少施工费用 （2）有利于知识库的建立 代码对象库 业务及经验库 （1）节约费用  缩短开发周期  减少施工费用  （2）有利于知识库的建立  代码对象库 业务及经验库  （3）规范管理  量化工作量考核  规范测试  （4）加强协调与沟通  2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测与报告 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

8.2 配置管理活动和流程 8.2.1 主要配置管理活动 8.2.2 项目经理的配置管理流程 2019/5/1

8.2.1 主要配置管理活动 标志配置项 变更控制 版本控制 评审 统计 软件编译、连接和发放管理 2019/5/1

RUP描述的配置管理的主要活动如下图所示： 对于一个软件项目组来说，开展一个项目组的配置管理，大致可以分为以下步骤： （1）拟订项目的配置管理计划；（2）创建项目的配置管理环境；（3）进行项目的配置管理活动，包括：标识配置项；管理基线和发布活动；监测与报告配置状态；管理变更请求。 （1）和（2）可以看成配置管理的准备，（3）是配置管理的具体实施。配置管理的具体实施，在RUP定义为四个管理活动。 对于一个软件项目组来说，开展一个项目组的配置管理，大致可以分为以下步骤： 2019/5/1

配置项（Software Configuration Item，SCI）识别 对于配置项，可以给出一个比较简单的定义，既软件过程的输出信息可以分为三个主要类别： （1）计算机程序（源代码和可执行程序） （2）描述计算机程序的文档（针对技术开发者和用户） （3）数据（包含在程序内部或外部）。 这些项包含了所有在软件过程中产生的信息，总称为软件配置项。” 在CMM2中，除上述3个配置项以外，还包括项目管理的有关文件、信息记录等。 由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。 2019/5/1

配置项（Software Configuration Item，SCI）识别 软件配置管理认为软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线（Base Line）”这一概念。 IEEE对基线的定义是这样的：“已经正式通过审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。” 所以，根据这个定义，我们在软件的开发流程中，也可以把所有需要加以控制的配置项分为基线配置项和非基线配置项两类，例如：基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。 有关配置项的内容，我们将在后面，专门花一节的篇幅，进行讨论。 2019/5/1

配置项的标识和控制 所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。 所有配置项的操作权限应由配置管理员严格管理，基本原则是：基线配置项向软件开发人员开放读取权限；非基线配置项向项目经理、配置控制委员会及相关人员开放。 2019/5/1

每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上。 工作空间管理 在引入了软件配置管理工具之后，所有开发人员都会被要求把工作成果存放到由软件配置管理工具所管理的配置库（存储池）中去，或是直接工作在软件配置管理工具提供的环境之下（根据配置管理构架提供的控制方式不同而不同）。 每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上。 比较理想的情况是把整个配置库视为一个统一的工作空间，然后再根据需要把它划分为个人（私有）、团队（集成）和全组（公共）这三类工作空间（分支），从而更好的支持将来可能出现的并行开发的需求。 2019/5/1

版本控制 版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数据来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程改进（Software Process Improvement，SPI）活动的进行。 对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。 2019/5/1

变更控制 变更管理的一般流程是： （1）（获得）提出变更请求； （2）由CCB审核并决定是否批准； （3）（被接受）分配请求，修改人员提取配置项，进行修改； （4）复审变化； （5）提交修改后的配置项； （6）建立测试基线并测试； （7）重建软件的适当版本； （8）复审（审计）所有配置项的变化； （9）发布新版本。 在这样的流程中，配置管理员通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建立在前面所描述的版本控制和分支策略的基础上的。 2019/5/1

状态报告 配置状态报告应该包括下列主要内容： (1)配置库结构和相关说明； (2)开发起始基线的构成； (3)当前基线位置及状态； (4)各基线配置项集成分支的情况； (5)各私有开发分支类型的分布情况； (6)关键元素的版本演进记录； (7)其它应报告的事项。 2019/5/1

配置审计 配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。 总之，软件配置管理的对象是软件研发活动中的全部开发资产。所有这一切都应作为配置项纳入管理计划统一进行管理，从而能够保证及时的对所有软件开发资源进行维护和集成。因此，软件配置管理的主要任务也就归结为以下几条： （1）制定项目的配置计划； （2）对配置项进行标识； （3）对配置项进行版本控制； （4）对配置项进行变更控制； （5）定期进行配置审计； （6）向相关人员报告配置的状态。 2019/5/1

8.2.2 项目经理的配置管理流程 项目经理的工作是： （1）确定项目配置管理策略 （2）确定用于控制产品变更的策略和流程 （3）在配置管理计划（是软件开发计划的一部分）中记录此信息 2019/5/1

软件配置管理计划说明在产品/项目生命周期中要执行的所有与配置管理相关的活动。它记录如何计划、实施、控制和组织与产品相关的配置管理活动。 配置管理策略 软件配置管理策略是指能够确定、保护和报告已经批准用于项目中的工件的能力。通过正确的标注来实现确定操作。对项目工件的保护是通过归档、建立基线和报告等操作而得以实现的。 使用标准的、已记录下来的变更控制流程的目的是：确保项目中所做的变更保持一致，并将产品的状态、对其所做的变更以及这些变更所耗费的成本及对时间表的影响通知给有关的涉众。 软件配置管理计划说明在产品/项目生命周期中要执行的所有与配置管理相关的活动。它记录如何计划、实施、控制和组织与产品相关的配置管理活动。 2019/5/1

配置管理人员的选择和配备，是软件项目经理最主要的工作。在一个比较理想的软件开发团队中，需要哪些角色呢？ 配备人员 配置管理人员的选择和配备，是软件项目经理最主要的工作。在一个比较理想的软件开发团队中，需要哪些角色呢？ 负责软件项目组的项目经理 负责SCM计划和策略的配置经理 负责软件产品开发与维护的软件工程人员 负责验证产品正确性的测试人员 负责确保产品高质量的质量保证经理 使用产品的用户。 2019/5/1

配置经理 配置经理的目标是确保用来建立、变更及编码测试的计划和策略得以贯彻执行，同时使有关项目的信息容易获得。 为了对编码更改形成控制，配置经理引入规范的请求变更的机制，评估更改的机制（通过变更控制机构CCB，由它负责批准对软件系统的变更），和批准变更的机制。 配置经理负责为工程人员创建任务单，交由项目经理对任务进行分配，创建项目的框架。同时，配置经理还收集软件系统中构件的相关数据，比如说用以判断系统中出现问题的构件的信息。 2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测与报告 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

8.3 配置管理需求 8.3.1 配置管理的对象 8.3.2 最基本的配置管理项——文档 8.3.3 UCM目录结构下的配置管理对象 2019/5/1

8.3.1 配置管理对象 配置管理的第一个基本活动是配置标识，通俗地讲，也就是查询、识别和确定配置管理对象——配置项。在生产的软件产品和软件的生产过程中，那些是配置管理的对象呢？ 配置管理对象呈现为一种层次结构，因此，为了标识配置管理的对象，我们需要对软件系统进行分解： 目前，用于分解软件系统的术语有多种多样，没有被标准化。 1989年Humphery定义了5个层次：系统、子系统、产品、构件和模块。 1991年Whitgift定义了3个层次：系统、子系统和元素。 IEEE定义了3个层次：计算机配置项、计算机软件构件和计算机软件单元。 RUP定义了4个层次：系统、实施（或构件）子系统、构件和文件（RUP5.5 1999）。 2019/5/1

配置管理对象 在RUP的概念里，最底层的元素是处于版本控制下的文件和目录，构件的层次要高于元素（文件和目录），构件把元素组织起来。一个版本控制的构件是一个具体的物理的对象，就是一个根目录。这个根目录，以及从根目录下所属的所有目录和文件，是系统的一个子系统。大的系统有多个根目录（子系统），小系统则可能只有一个根目录。 产品目录结构为所有可具有版本号的、与产品相关的工件提供逻辑嵌套的占位符。工件是开发流程生命周期的结果，用于开发整个系统的各组成部分（构件）。 2019/5/1

配置管理对象 首先我们从根目录开始（假设是只有一个根目录的小）系统，讨论软件系统架构：软件项目通过一系列的生命阶段，将建立或者已经建立起一个体系构架。软件的体系构架在软件工程时代被称为系统结构。在UML中，被称为构架。 UML对构架的定义是： （1）一组有关软件系统组织结构的重要决定； （2）结构要素和接口的选取，确保它们的行为能满足这些要素之间的协作关系； （3）结构要素和行为要素以一种渐进的方式被组装成子系统，能够指导这种组织结构的结构风格，要素的内容，它们的接口、它们的协作和它们的组合。 系统或系统构架是由子系统（构件）组成的。 2019/5/1

UML进一步把构件划分成三种构件：部署型构件、工作产品型构件和执行构件。  （1）部署型构件：是指那些被部署到目标机中的元素，例如：可执行程序、库以及其他支持系统运行的文件。 （2）工作型构件：是构成开发环境的元素，例如：源文件、头文件以及其他用于导出或构建部署型构件的文件。 （3）可执行型构件：是指由运行于目标机的系统生成的内容，例如：数据等。 从SCM的角度看系统架构，我们主要关注的是在开发环境中以及将来部署到目标系统中的系统的物理层面的文件和目录结构、分组和版本化。这种关注决定了配置管理的对象以及对象的“粒度”。 现在，有些项目使用高层次的设计文档来描述架构，例如：模型、视图等。在高层架构描述中，逻辑上的“类”，可影射对应为物理层面的文件和目录。 作为软件产品和软件过程，这些文件和目录是SCM控制的对象，即他们是配置项。在我们现在的讨论中，有时，我们说明这些文件是用于管理和设计系统的内容（包括：项目计划、设计模型、测试报告）等，有些是实现系统设计的文件（包括：源代码、库、执行文件等），有时，把它们不加区别地看成为构件。 2019/5/1

CMM2的配置管理对象 CMM2把配置管理对象，称之为软件工作产品，在CMM2配置管理定义中，对应置于配置管理下的软件工作产品，是这样定义的： 可作为配置项/单元标识的软件工作产品实例有： 与过程相关的文档（例如：计划、标准或规程） 软件需求 软件设计 软件代码单元 软件测试规程 为软件测试活动建立的软件系统 交付给客户或最终用户的软件系统 编译程序 其他支持工具 不论各体系是如何定义的，我们基本可以认为，配置管理的对象，主要地可以分为二类：软件产品和文档。软件产品比较容易标识，而文档相对比较复杂。我们将重点进行讨论。    2019/5/1

8.3.2 最基本的配置管理项——文档 文档在软件开发人员、软件管理人员、维护人员、用户以及计算机之间，起到了多种的桥梁作用。软件开发人员在软件生命的各个阶段中，以文档作为前阶段工作成果的体现和后阶段工作的依据，这个作用是显而易见的。这部分文档通常称为开发文档。 软件开发过程中软件开发人员需制定一些工作计划或工作报告，这些计划和报告都要提供给管理人员， 并得到必要的支持。管理人员则可通过这些文档了解软件开发项目安排、进度、资源使用和成果等。这部分文档通常称为管理文档，或称为项目文档。 软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料。这部分文档通常称为用户文档。 2019/5/1

我们把这三种文档所包括的内容列在下图中。其中列举了十三个文档，这里对它们做一些简要说明： 用户文档 用户手册 操作手册 维护修改建议 软件需求（规格）说明书 开发文档 数据要求说明书 概要设计说明书 详细设计说明书 可行性研究报告 项目开发计划 管理文档 测试计划 测试报告 开发进度月报 开发总结报告 2019/5/1

文档的生成阶段 阶段 文档 可行性研究与计划 需求分析 设计 代码编写 测试 运行与维护 可行性研究报告 项目开发计划 软件需求说明 文档     可行性研究与计划 需求分析 设计 代码编写 测试 运行与维护 可行性研究报告   项目开发计划 软件需求说明 数据要求说明 概要设计说明 详细设计说明 测试计划 用户手册 操作手册 测试分析报告 开发进度月报 项目开发总结 维护修改建议 2019/5/1

文档的作用 所提问题 文档 什么 何处 何时 谁 如何 为何 可行性研究报告 √ 项目开发计划 软件需求说明 数据要求说明 概要设计说明 文档  什么 何处 何时 谁 如何 为何 可行性研究报告 √   项目开发计划 软件需求说明 数据要求说明 概要设计说明 详细设计说明 测试计划 用户手册 操作手册 测试分析报告 开发进度月报 项目开发总结 维护修改建议 2019/5/1

UCM（统一变更管理）的发展沿革 第一代UCM： 第二代UCM： 第三代UCM： 第三代UCM引进了一些新的概念： （1）活动（Activity）： （2）构件（Component）： （3）工作流（Stream）： （4）项目（Project）： 2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测与报告 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

8.4 版本管理 8.4.1 版本管理的必要性 8.4.2 此前的版本管理 8.4.3 元素、分支与版本 8.4.4 构件、基线与存储池 8.4.5 现代版本管理活动 2019/5/1

8.4.1 版本管理的必要性 在软件开发过程中，由于软件开发所固有的特征，可能会形成众多的软件版本，而且我们并不能保证不出现错误的修改，而这样的一个困难局面却又非常现实地摆在项目开发管理者的面前，他/她该如何有效地解决这些问题，具体地说就是如下一些问题： （1）怎样对研发项目进行整体管理； （2）项目开发小组的成员之间如何以一种有效的机制进行协调； （3）如何进行对小组成员各自承担的子项目的统一管理； （4）如何对研发小组各成员所作的修改进行统一汇总； （5）如何保留修改的轨迹，以便撤销错误的改动； （6）对在研发过程中形成的软件的各个版本如何进行标识，管理及差异识辨等等。 一个非常直接的反应是，我们必须要引进一种管理机制，一个版本管理机制，而且是广义上的版本管理，它不仅需要对源代码的版本进行管理，而且还要对整个项目进行管理。 2019/5/1

8.4.2早前的版本管理 基于共享文件目录的版本管理 在软件工程时代，面对这样的问题，我们通过以往的那种被誉建立具有良好的编程风格的做法，诸如在编程或对他人的源程序进行修改时，注释修改原因，修改人和日期。如果是多个成员同时进行了修改，那么可能出现一个库管理员，由他来控制什么人在访问哪个源代码，修改的人向他报告做了什么改动。如果有几个人同时改动，库管理员或者限定同时只能有一个人做修改，他记住这人是谁，或者他自己来做同时修改的人工的差异比较和综合，以便形成一个统一的新版本。在3-5人小组，这个库管理员还能胜任，但这种做法在当前的大型软件的开发中已经越来越困难了，因为靠人工的操作、靠个人的自觉、靠库管理员的维护，充其量是一种以小作坊的形式来面对软件的社会化大生产，再也不可能行得通了。 基于共享文件目录的版本管理 在版本控制工具出现之前，或者，现在国内很多的软件企业，并不用什么版本控制工具。他们也做一些简单的版本控制工作。他们是怎么做的？ 最简单的办法是使用文件拷贝支持不同的版本。具体地讲，就是项目组在项目组的文件共享服务器上，建立一个项目组文件系统，在文件系统下，对涉及到的文件，建立不同的版本目录，从个人工作区到系统发布版，包括中间结果，甚至可能是所有文件。库管理员不断地增加目录的标签，以标识历史前进的步伐。 2019/5/1

早期的版本管理工具 （1）通过存储池机制来维护文件库； 8.4.2早前的版本管理 早期的版本管理工具 （1）通过存储池机制来维护文件库； （2）创建和存放文件的多个版本； （3）提供一种或几种锁定装置，强制对文件的修改顺序； （4）标识文件的版本； （5）从历史目录中找回旧版本。 这些工具基本上能帮助库管理员从手工的管理中解脱出来，开发人员不需要库管理员的介入，可以自己从库中检入和检出文件，当文件被检出后，其他人暂时不能再检出此文件。同时，在必要的时候，文件的一个新版本被创立。 2019/5/1

8.4.2早前的版本管理 例如：MS的VSS版本控制是通过以下方式实现的： VSS用日期/时间戳来记录文件是何时被Check-out或是何时被修改的，它主要有三种方法来跟踪文件和项目的版本： （1）版本号：这是由VSS维护的内部数码，用户对它没有控制权。每个文件和项目的每个版本都有一个版本号，这些版本号总是一个整数且是递增的。 （2）标签：这些是用户赋给某个项目或文件的某个版本的一个字符串，可以是任何格式的长度不超过31字符的字符串。 （3）日期/时间戳：它给出了一个文件何时最后被修改的信息，或者是一个文件何时被Check-in。VSS同时支持 12小时和24小时的时间格式。 2019/5/1

8.4.3 元素、分支与版本 原子对象 在ClearCase的概念中，置于版本控制下的原子对象被称为“元素” （element），元素是文件系统对象：文件和目录。每个元素记录了它所代表的文件和目录的版本。所以，当用户检入文件时，就创建了那个元素的新版本。元素被组织成不同的分支。分支是线形的版本序列，版本序列构成的是并行开发的项目或基于统一基线开始的不同的系统。元素都被保存在存储池（VOB）中。下图是存储池、元素、分支、版本之间的关系： 在ClearCase中，每一个元素都以一个主分支（main branch）和一个不包含任何内容的零版本序列开始，称为“/main/0”。每一次新版本检入，在主分支上创建版本1 2019/5/1

SCM 的版本树 1 1 2 1 3 2 3 2 4 3 Release 1.0 Release 1.1 \main \rel2 左图的版本树中，长方形表示一个分支，圆形表示检入的时间排序的版本号，箭头表示从一个分支到另一个分支的变更回归（归并）。“发布版本1.0/1.1”是这个版本上的标签。目录是元素，也是版本对象。ClearCase对目录与文件一样，也进行版本管理。为了能在前一个版本中修复BUG，或者从新版本退回到就版本，就有必要恢复一个旧的版本。目录被修改，在检入的时候，也要进行记录。对目录进行版本管理的目的，还可以借助目录机制，重建或构造软件系统的前一个版本。 Release 1.1 1 \rel2 1 2 1 3 \rel1_bugfix 2 3 2 4 版本控制的两个功能：控制版本和并行开发 3 2019/5/1

元素类型 在ClearCase中，存放在存储池中的元素都被赋予特定的类型，使之可以用于多种目的。类型可以帮助系统决定对该元素的操作。 包括： 文件（完全备份） 文本文件（同轴增量备份） 压缩文本文件（与文本文件相同，但进行压缩） 压缩文件（完全备份，仅进行压缩） 二进制文件（差异增量保存） 目录（直接保存） 2019/5/1

8.4.4 构件、基线与存储池 构件将把被一起开发、集成和发布的文件和目录聚集在一起。聚集成ClearCase构件的文件和元素通常可以实现系统构架中的一个可重用的部分。 构件通过标识一个根目录来定义，这个目录与所有的文件和子目录都被看作是这个构件的一个部分。 构件的一个版本就是一个基线。构件基线标识了构件中包含的每一个元素或一个版本，构件的基线用来配置工作流，为各种视图提供信息，以便决定文件和目录的什么版本被显示。 就像元素有版本一样，构件有基线。当修改一个元素时，你创建了这个元素的一个版本，当你修改构件中的一个元素时，你也创建了这个构件的一个新基线。工作流把一组构件基线聚集在一起。然而，这不是项目范围的基线概念，更恰当的讲，当你在项目的集成流上完成一个基线操作时，你创建了一组被修改构件的基线。 2019/5/1

项目的VOB包含与项目环境有关的对象，如：项目、构件、活动以及基线，这些构成了一个正在开发的项目的所有信息，包括项目的组织和管理信息。 根据一个产品的质量标准要求和需求的不同，可以定义一个项目的不同基线。也就是说，一个公司可以定义不同的测试、功能、版本基线。另一个项目组可以根据自己的需要，选择某特定构件，确定自己的基线。 下图表明构件和基线之间的关系： 任何UCM的核心最后将归结到存储池，存储池也被称为“Versioned Object Base”，或简称为VOB。VOB是用于存储文件、目录和元数据的永久数据存储池。VOB必须能够支持可扩展的、容错的、分布式的可复制的性能。 项目的VOB包含与项目环境有关的对象，如：项目、构件、活动以及基线，这些构成了一个正在开发的项目的所有信息，包括项目的组织和管理信息。 2019/5/1

8.4.5 现代版本管理活动 现代版本管理活动围绕以下展开： l 支持多人同时修改同一文件； l 支持多个小组在同一时间修改同一个软件系统； 2019/5/1

并行开发的版本控制 2 1 1 2 1 3 1 2 3 3 4 2 4 并行开发 Release 1.0 Telecom 1.0 \main \main \main 1 2 1 3 \Bugfix \Telecom 1 2 3 3 4 2 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 4 Release 1.0 Telecom 1.0 2019/5/1

使混乱的开发状态变得有序！ SCM 的主要技术——版本控制 版本控制的好处 2019/5/1 开发者减少了整理任务的时间，把更多的精力投入到开发 保证发布版的正确 bugfix和coding可在不同的分支同时进行且互不干扰 …… 版本控制给开发者带累了很多好处，但对于项目管理者来说，他更关心项目的进展情况……这不是简单的版本控制能够解决的 2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测与报告 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

8.5 变更管理 8.5.1 基于基线的变更管理 8.5.2 变更请求管理过程 8.5.3变更请求管理活动 8.5.4 变更请求的状态转移 2019/5/1

是团队开发过程中的通讯基础 可以了解谁改了什么、为什么 正确及时的项目状态报告 最大限度的利用你的工程师资源 利于团队交流 2019/5/1 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 是团队开发过程中的通讯基础 2019/5/1

8.5.1 基于基线的变更管理 l 变更管理下的基线概念 l    建立基线的意义 l      建立基线的时机         2019/5/1

8.5.2 变更管理流程 变更管理流程：变更管理流程包括提出请求、对请求进行评估、同意请求和实现对已经进入基线库的配置项进行修改。 CCB (Change Control Board)，由项目经理、系 统分析员、项目配置经理和软件质量工程师组成 ，负责评估变更请求，提出同意或不同意对已进 入基线库的配置项的变更； TAF: test, analyze and fix； 2019/5/1

变更管理流程(1) 与变更管理流程相关的表格 软件问题报告表Software Problem Report Form (SPRF) 软件变更请求表Software Change Request Form (SCRF) 软件问题解决细节Software Problem Resolution Details (SPRD) 2019/5/1

变更管理流程(2) 2019/5/1 由用户提出的变更请求 由项目主提出的变更请求 问题评估 PAT 由用户在产品发布前发现的问题 由项目组自身发现的问题 系统分析员 软件问题报告表 问题处理 NO YES 软件变更请求表 由于升级而进行的变更 对问题不予接受 告知问题提出者问题被拒绝 2019/5/1

变更管理流程(3) 2019/5/1

8.5.3变更请求管理活动 2019/5/1

8.5.4 变更请求的状态转移 2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测、报告与评审 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

8.6 配置状态监测、报告与评审 8.6.1 配置状态监测与报告 8.6.2 配置评审 2019/5/1

8.6.1 配置项状态统计 配置项状态统计，由项目配置经理定期地对项目配置项的状态进行收集和统计，主要包括以下统计信息： 项目制品进入基线库的创建时间 变更请求的详细描述 所有问题(Problem Report)报告的描述 变更请求的状态 Baseline Status Accounting Form (BSAF) Archive Status Accounting Form (ASAF) Change/Problem Status Accounting Form (C/PSAF) 2019/5/1

提供图形化的项目状况 那么怎样衡量我们项目的进展情况呢？CMM中给我们介绍了有关的方法和准则…… 2019/5/1

SCM 提供软件产品的状态统计。统计包括寻找软件开发的瓶颈和解决办法，并据此衡量软件产品的成熟度。 度量准则：平均严重程度，严重程度级的分布，平均关闭时间，严重程度的图示，各配置项或子系统的图示 2019/5/1

SCM的度量和度量准则 软件产品成熟度数据要求： 软件变更（问题）数量 描述 计算机软件配置项标识（CSCI） 严重程度级 打开变更的日期（或发现问题） 关闭变更（问题）和实施日期 其他因素：正确的发布还需要开发者评估测试完成情况，测试率，需求稳 定性。若只完成计划测试的10%，表明此产品还未成熟。如项目开发周期很长那么需求的稳定性也是一个十分重要的问题。 2019/5/1

8.6.2 配置评审 配置评审：配置评审通过对配置管理流程的各种制品进行审核，来判断软件配置管理流程被正确的执行。 配置评审包括功能评审和物理评审。 功能配置评审 (Functional Configuration Audit, FCA)，功能配置评审是通过对软件产品的功能和性能的审核，以及与需求说明的一致性来对软件制品的评估。 由项目经理提出请求 由软件质量工程师计划并实施 对评审过程和标准有专门的文档规定 2019/5/1

功能评审 功能审核的目标是核实软件配置项的实际性能是否符合它的需求。以下各项说明从 配置管理角度来看支持功能审核所需要做的工作。 （1）准备一个验证表，列出所有功能方面的需求，而且对每个需求都引用测试过程、测试行为的实例（时间戳或其他测试实例标识符）、相应的测试结果和/或完整记录需求验证情况的分析和/或演示报告。 （2）核实是否已正确实施了所有变更请求。 （3）核实是否已对软件正确应用了所有更改。 （4）文档差异、建立纠正操作和完成日期。 2019/5/1

物理评审 物理配置评审Physical Configuration Audit (PCA)：物理配置评审主要验证软件的功能是否与其设计一致，是否可以发布。 物理配置评审跟随在功能配置评审之后； 由项目经理提出请求； 由软件质量工程师和项目配置经理计划和实施； 对于物理配置评审过程和标准，有专门的文档规定；  物理评审的主要工作是： （1）创建应该出现在配置管理中的项目列表。 （2）检查在配置管理中维护的项目。 （3）创建一个“差异列表”，表示已在配置管理中维护的项目以及应该在配置管理中维护的项目之间的差异。 2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测与报告 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

8.7 基于配置管理的软件项目管理 8.7.1 角色职责 8.7.2 配置管理计划 8.7.3 项目经理的阶段工作要点 8.7.4 配置管理实施的若干问题 2019/5/1

8.7.1 角色职责 项目经理（Project Manager，PM） 配置控制委员会（Configuration Control Board，CCB） 配置管理员（Configuration Management Officer，CMO） 系统集成员（System Integration Officer，SIO） 开发人员（Developer，DEV） 2019/5/1

8.7.2 配置管理计划 肩负对项目成功负责的重要职责 评估开发团队当前配置管理现状 定义实施的范围 计划资源要素 2019/5/1

8.7.3 项目经理的阶段工作要点 2019/5/1

8.7.4 配置管理实施的若干问题 SCM的启动时机 SCM的控制水平 过程与产品的区分 SCM自动化水平 2019/5/1

SCM 的过程驱动 可以不必去熟悉过程，也不必知道团队开发的模式 可以延续你一贯的工作程序和处理办法 将变更流程化 自动处理业务 PRODUCTION CODING TESTING REPORTING PROJECT U PROJECT V PROJECT Y PROJECT X PROJECT Z PROJECT W APPROVE NOTIFY 更强调管理 整个业务流程应预定义 2019/5/1

SCM 的过程驱动 SCM的过程改进 SCM为变更和过程改进提供基本结构 第一步，了解产品是怎样生产的 第二步，培养一个好的变更环境 “做你总做的，就会获得已经得到的” SCM通过度量当前实际及其相关事物能够帮助你鉴别当前工作过程有哪些地方需要改进。 由于变更将影响到生产效率，完整性，一致性，和客户满意程度，所以所有变更必须附加相应的“值”，否则将不允许变更。 改进要构造的也就是改进怎样构造 -- SEI 1998年主题 2019/5/1

SCM 的过程驱动 过程驱动的好处 真正规范团队开发！ 2019/5/1

第八章 • 目录 8.1 软件配置及其管理的概念 8.2 配置管理活动和流程 8.3 配置管理需求 8.4 版本管理 8.5 变更管理 8.6 配置状态监测与报告 8.7 基于配置管理的软件项目管理 8.8 配置管理的技术手段和工具 2019/5/1

Microsoft VSS6.0介绍 VSS的简单工作原理 VSS中的几个重要概念 VSS6.0的一些新增的特征和功能 VSS6.0解决方案 2019/5/1

PVCS介绍 特点： 功能： 2019/5/1

Rational ClearCase介绍 功能： 1．版本控制 2．工作空间管理 3．建立管理 4．过程控制 特点： 推进并行开发 强有力的版本控制 透明的工作区管理 有效的build管理 有弹性的流程管理 功能： 1．版本控制 2．工作空间管理 3．建立管理 4．过程控制 2019/5/1

评估Client/Server环境的配置管理工具 新代码 源存储库 简单的版本控制 新开发 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 2019/5/1

评估Client/Server环境的配置管理工具 新代码 源存储库 简单的版本控制 新开发 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 PVCS系列 VSS 2019/5/1

评估Client/Server环境的配置管理工具 维护模式 增加的开发人员 当前的开发 QA & 测试 部门级开发 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 新代码 源存储库 简单的版本控制 新开发 PVCS 系列 VSS 2019/5/1

评估Client/Server环境的配置管理工具 维护模式 增加的开发人员 当前的开发 QA & 测试 ClearCase Continuus SourceIntegrity PVCS 部门级开发 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 新代码 源存储库 简单的版本控制 新开发 PVCS 系列 VSS 2019/5/1

评估Client/Server环境的配置管理工具 新开发工具 IT 审核 管理报告 复杂的生命周期 企业级开发 ClearCase Continuus SourceIntegrity PVCS 维护模式 增加的开发人员 当前的开发 QA & 测试 部门级开发 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 新开发 新代码 源存储库 简单的版本控制 PVCS 系列 VSS 2019/5/1

评估Client/Server环境的配置管理工具 新开发工具 IT 审核 管理报告 复杂的生命周期 企业级开发 CCC/Harvest 维护模式 增加的开发人员 当前的开发 QA & 测试 ClearCase Continuus SourceIntegrity PVCS 部门级开发 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 新代码 源存储库 简单的版本控制 新开发 PVCS 系列 VSS 2019/5/1

评估Client/Server环境的配置管理工具 应用工具包 集成解决方案 数据仓库 开放的 企业级开发 CCC/Harvest 新开发工具 IT 审核 管理报告 复杂的生命周期 CCC/Harvest 企业级开发 针对此问题，不同的人有不同的回答，甚至是做同一项目的两个人。如项目经理和开发人员他们的视角不一样…… 所以任何人均能从中得到好处 ClearCase Continuus SourceIntegrity PVCS 维护模式 增加的开发人员 当前的开发 QA & 测试 部门级开发 新代码 源存储库 简单的版本控制 新开发 PVCS 系列 VSS 2019/5/1

问题？ Any Questions? 2019/5/1

Keep Connecting In The Future 谢谢！ Keep Connecting In The Future 2019/5/1