软件配置管理vss.ppt

《软件配置管理vss.ppt》由会员分享，可在线阅读，更多相关《软件配置管理vss.ppt（119页珍藏版）》请在三一办公上搜索。

1、2007-12-11,Software Engineering 1/1191/119,Software Project Management 2007 软件配置管理,Solonhi GaoSchool of Computer,2007-12-11,Software Engineering 1/1192/119,前面章节的回顾,2007-12-11,Software Engineering 1/1193/119,Outline,头脑风暴什么是软件配置管理(SCM)软件配置管理最佳实践概述软件配置工具的功能和比较基于VSS的案例说明,2007-12-11,Software Engineering

2、1/1194/119,软件开发的发展历程,2007-12-11,Software Engineering 1/1195/119,多操作系统多开发工具网络化团队方式异地开发,Oracle,Sybase,APPC,MVS,WINDOWS,SQL,OS/2,TCP/IP,UNIX,OO,PM,DB2,NT,C+,INTERNET,INTRANET,开发环境的复杂性,2007-12-11,Software Engineering 1/1196/119,软件项目中是否遇到如下的问题,找不到某个文件的历史版本；开发人员使用错误的版本修改程序开发人员未经授权修改代码或文档；人员流动，交接工作不彻底；已修复的

3、Bug在新版本中出现；无法重新编译某个历史版本；因协同开发中，或者异地开发，版本变更混乱导致整个项目失败；,2007-12-11,Software Engineering 1/1197/119,What cause of the problem,著名的软件大师Brooks曾经说导致软件开发困难的一个原因就是就是软件可变性。导致变化的原因功能变更新的商业或市场条件，引起产品需求和业务规则的变化。新的客户需要，要求修改信息系统产生的数据、产品提供的功能、或基于计算机的系统提供的服务。改组和/或企业规模减小，导致项目优先级或软件工程队伍结构的变化。预算或进度的限制，导致系统或产品的重定义。缺陷修补,

4、2007-12-11,Software Engineering 1/1198/119,What should be done to void them,曾经有一个很好的配置管理工具在我面前，我没有理睬，直到版本混乱的时候才后悔莫及，工作中最大的痛苦莫过于此，如果上天再给我一次机会的话，我向对它说三个字：我要你。如果非得加一个期限的话，我希望是一辈子。软件配置管理+软件过程管理,2007-12-11,Software Engineering 1/1199/119,微软工作人员的一天,开发人员的一天 测试人员的一天 程序经理的一天,2007-12-11,Software Engineering 1

5、/11910/119,开发人员的一天,1,2007-12-11,Software Engineering 1/11911/119,开发人员的一天从哪里开始？,2007-12-11,Software Engineering 1/11912/119,开发人员的一天从哪里开始？,答案：开发人员的一天从Daily Build开始开发人员上班的第一件事儿就是查看Daily Build的结果，担心由于自己昨天的代码Check-in，造成Build Broken,2007-12-11,Software Engineering 1/11913/119,2007-12-11,Software Engineeri

6、ng 1/11914/119,经历对Build的提心吊胆之后，第一件事做什么？,2007-12-11,Software Engineering 1/11915/119,经历对Build的提心吊胆之后，第一件事做什么？,答案：打开Bug管理工具，查看指定给自己的Bug，解决高优先度的Bug。因为质量重于新功能,2007-12-11,Software Engineering 1/11916/119,2007-12-11,Software Engineering 1/11917/119,接下来，开发人员会,从源代码管理工具中Check out代码修改代码（解决Bug或实现新功能）取得源代码管理工具中

7、最新变化，在本机Build和单元测试请开发组同事作Code ReviewCheck in代码在Bug管理工具中修改Bug的状态开发人员以一封Daily Report结束一天的工作,2007-12-11,Software Engineering 1/11918/119,2007-12-11,Software Engineering 1/11919/119,测试人员的一天,2,2007-12-11,Software Engineering 1/11920/119,测试人员第一件事做什么？,2007-12-11,Software Engineering 1/11921/119,测试人员第一件事做什么

8、？,答案：打开Bug管理工具，查看指定给自己的Bug，验证已解决的Bug,2007-12-11,Software Engineering 1/11922/119,接下来，测试人员会,从发布服务器上取得当天的Build版本，根据测试用例检验当天的Build在Bug管理工具中登记新发现的Bug，等待开发人员解决,2007-12-11,Software Engineering 1/11923/119,2007-12-11,Software Engineering 1/11924/119,2007-12-11,Software Engineering 1/11925/119,下班前，测试人员会,发送当

9、天或者一周的Bug报告和测试用例报告,2007-12-11,Software Engineering 1/11926/119,2007-12-11,Software Engineering 1/11927/119,程序经理的一天,3,2007-12-11,Software Engineering 1/11928/119,程序经理的工作,主持Bug专家会诊更新项目的计划、日程表、产品规格书、风险控制列表发送Status Report,PM is the communication hub!,2007-12-11,Software Engineering 1/11929/119,程序经理的工作,主

10、持Bug专家会诊更新项目的计划、日程表、产品规格书、风险控制列表提交Status Report,2007-12-11,Software Engineering 1/11930/119,2007-12-11,Software Engineering 1/11931/119,程序经理的工作,主持Bug专家会诊更新项目的计划、日程表、产品规格书、风险控制列表提交Status Report,2007-12-11,Software Engineering 1/11932/119,2007-12-11,Software Engineering 1/11933/119,Outline,头脑风暴什么是软件配置

11、管理(SCM)软件配置管理最佳实践概述软件配置工具的功能和比较基于VSS的案例说明,2007-12-11,Software Engineering 1/11934/119,什么是软件配置管理(SCM),软件配置管理的定义为什么需要软件配置管理软件配置管理的基本概念,2007-12-11,Software Engineering 1/11935/119,软件配置管理的定义,软件配置管理（Software configuration management，SCM）是软件工程中用来管理软件资产变更的一项规程，包括它所使用的相关工具和应用技术（流程和方法）。-IEEE“配置管理技术标准”IEEE 82

12、8-1998“协调软件开发使得混乱减到最小的技术叫做软件配置管理，它是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生产效率。”-Wayne Babich,SCM Coordination for Team Productivity软件配置管理是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。,2007-12-11,Software Engineering 1/11936/119,软件配置管理的定义,GB/T 11457:1995软件工程术语国家标准 A.表示和确定系统中配置项的过程，在

13、系统整个生存期内控制这些配置项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。B.对下列工作进行技术和行动指导与监督的一套规范：对配置项的功能特性和物理特性进行标识和文件编制工作；控制这些特性的更动情况；记录并报告这些更动进行的处理和实现的状态。,2007-12-11,Software Engineering 1/11937/119,为什么需要软件配置管理,51job上能检索到188个职位Google输入“软件配置管理”检索到6,180,000 条记录软件配置管理能解决的问题程序员的问题项目经理的问题公司的老板的问题,2007-12-11,Software Engin

14、eering 1/11938/119,程序员的问题,问题1：我要更改源代码，但不知道哪个是最新的。原因：源文件混乱失控。解决方法：把所有与工作有关的文件放在配置库中。使用时从配置库中取出来。使用完毕再放回配置库中，这样每次修改的文件就成为文件的最新版本，同时还可以跟踪文件的所有修改。本项目中的其他人都可以从配置库中取出文件的最新版本,2007-12-11,Software Engineering 1/11939/119,程序员的问题,问题2：如果能知道最后修改了那几行以及原因，对我帮助很大。原因：没有对文件的修改的历史记录。解决方法：记录谁最近修改了文件。在什么时间修改了软件。修改请求是什么（

15、即为什么要修改该文件？）更改的内容是什么那一行被修改了。改正了什么问题和新增了什么功能其他修改与之有什么关联。,2007-12-11,Software Engineering 1/11940/119,程序员的问题,问题3：经常在构造（MAKE）时，会用错文件的版本原因：文件版本之间的关系紊乱。解决方法：给出版本之间的关系每个版本有明确的标识，如时间戳、版本的创建人、版本的描述，版本的大小等具体的信息。,2007-12-11,Software Engineering 1/11941/119,程序员的问题,问题4：多人修改同一文件时，有些人的修改被冲掉了。原因：开发没有得到有效的控制，处于一种各自

16、为政的状态这里明显的例子是，在UNIX工作环境下，有时为了调试方便，大家使用同一个UNIX用户，使用编辑器，比如VI之类的工具修改同一个文件的问题。即使在vi编辑器的最后一行提示有其他人正在修改文件，但是不少人根本不注意这个，结果是改完就把别人的文件给冲掉了。解决方法：提供各个开发成员的独立工作空间，防止地址冲突提供“锁”控制机制，防止对配置项的修改发生冲突提供对“并发开发”的支持，包括多人开发时能够产生分支、开发完毕能够合并起来,2007-12-11,Software Engineering 1/11942/119,程序员的问题,问题5：我的程序文件被误删了，我曾尝试恢复，但是失败了，这导致

17、我只能重新编写程序。有什么办法可以防止类似的事情发生？原因：没有工作成果保护机制。解决方法：经常使用配置库，只要是有效的更改都要及时地存放到配置库中。配置库中属于某个成员的成果，该成员要注意防止其他成员对该配置项的非法访问防止对所有开发的软件包进行的误操作，减少不必要的损失。,2007-12-11,Software Engineering 1/11943/119,程序员的问题,问题6:我和同事共同开发一个项目，程序出了错，我花了一个星期终于查出来了，结果发现同事上个星期明显修改了其中的一个程序也没有通知我。有什么办法能让我少花点力气在这种事情上面？原因：没有变更信息通知机制解决方法：使用配置管

18、理系统提供的自动通知工具，只要有修改，即自动地将修改信息广播到有关的开发人员，使开发人员能够根据修改信息评估该变动对其所负责的部分所产生的影响，从而防止问题积累和后期调试的难度。提供修改信息的列表，开发人员可以在需要的时候通过查阅这样的列表记录，尽快地查出是什么样的变化导致了问题的出现。,2007-12-11,Software Engineering 1/11944/119,项目经理的问题,问题1：整个项目由若干部分组成，项目初期各人做各人自己那一部分，后期进行合并联调，但是联调的时间很长，往往是数个星期、数月，整个开销比较大。原因：项目各个部分之间缺乏通信，个人不能对全局有一个比较清晰的概念

19、，对其他部分缺乏了解。解决方法:建立通信交流的机制，将配置项信息（各种设计文档）告知到有关人员。充分共享配置资源，使得项目成员能够访问到有关的文档和源代码，以对整个项目有一个充分的理解；同时在信息共享基础上，有利于项目组成员之间对开发、测试、形成产品等过程的监督。从项目一开始就将软件包的创建、开发、发布纳入配置管理。,2007-12-11,Software Engineering 1/11945/119,项目经理的问题,问题2：调试过程中，项目成员经常为一些问题“扯皮”，搞不清楚到底是谁造成的错误。原因：整个组织没有实行有效的版本管理。解决方法：将源代码、文档、最好连目标码也纳入到配置管理。对

20、配置库进行有效的保护，防止被意外或者故意破坏，保证对所有的配置项都有据可查。,2007-12-11,Software Engineering 1/11946/119,项目经理的问题,问题3：我目前项目保存版本的方法是将文件复制一份，从新命名，比如加上人名，时间后缀。但是这样对于一些大文件耗费的磁盘空间太大。原因：没有实行增量的版本管理。解决方法：在项目中使用版本管理工具，因为目前大多数工具支持增量管理，即只保存文件的变化部分，从而节省空间的使用问题4：项目的版本太多，有些版本太旧，查看不方便原因：分支的版本没有合并解决方法：对同一项的并行修改做合并或者将一个环境的所有改变合并到配置库中以减少版

21、本的数量。,2007-12-11,Software Engineering 1/11947/119,项目经理的问题,问题5：估计项目成员的工作成果比较困难原因：不了解项目成员的基本工作解决方法：统计各项目成员对配置项的具体修改情况，将此统计结果作为参考内容之一来衡量工作量。用有效版本的数量作为参考内容之一来衡量工作量。,2007-12-11,Software Engineering 1/11948/119,老板的问题,问题1：交付给用户使用的产品（软件包）“缺斤少两”,用户在安装的时候发现问题原因：公司没有实行有效的配置管理，使得出厂的产品配置不完整。解决方法：使用先进的配置管理系统，建立完善

22、的配置管理机制。设立配置控制委员会，以控制对公司级配置项（包括出厂的产品）的修改。建立产品的过程模型，通过过程模型的约束机制，保证产品发布之前得到有关人员的批准。,2007-12-11,Software Engineering 1/11949/119,老板的问题,问题2：用户使用时发现的问题不能够得到及时地解决原因：决策机构过程繁杂或者问题跟踪能力不强。解决方法：对用户问题同样进行配置管理，将用户反馈的问题作为项目的一种特殊的配置进行管理并把用户问题作为解决软件问题的驱动源。由配置控制委员会对问题作出评估，决定是否需要立即解决该问题。,2007-12-11,Software Engineeri

23、ng 1/11950/119,老板的问题,问题3：有时公司的运作过程无法控制，即“不按我说的做”原因：公司的过程发生了变化，员工没有理解新过程的含义或者运作过程存在的漏洞解决方法：将公司的过程方法纳入配置管理，当过程发生变化时，依靠已经建立的机制来对员工进行培训。完善过程，不断对过程进行改进。,2007-12-11,Software Engineering 1/11951/119,老板的问题,人员的高流动性和知识和技术的快速更新是软件业的重要特点解决方法：将开发人员个人的成功经验转化为团队的以及整个组织的经验。在这样一个转化过程中，软件配置管理也起着极其重要的作用。因为对于一个大型的软件企业来

24、说，它的配置库有如一个巨大的图书馆，随着产品版本的不断演进，越来越多的配置项会充斥其间，以至于没有任何一个人能了解其中的全部内容。当我们需要在开发组织内部迅速的共享以往的成果时，配置管理就能发挥作用了。它就像常见的图书编目法那样，帮助图书管理员（配置管理员）迅速的找出所需要的资料（配置项），而不必彻底了解其中的确切内容。,2007-12-11,Software Engineering 1/11952/119,小结,We know what we have to produceWe know where it is and which state it is inOnly the right p

25、eople can use or change itWe understand the impact(影响)of the changesNeeded information is availableAgreed procedures are followed,2007-12-11,Software Engineering 1/11953/119,软件配置管理的基本概念,配置项 软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被妥善地保管起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存

26、起来。凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI）。配置项主要有两大类：属于产品组成部分的工作成果，例如源代码、需求文档、设计文档、测试用例等等。在管理过程中产生的文档,例如各种计划、监控报告等等，这些文档虽然不是产品的组成部分，但是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。,2007-12-11,Software Engineering 1/11954/119,软件配置管理的基本概念,基线 基线（Baseline）由一组配置

27、项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。,2007-12-11,Software Engineering 1/11955/119,软件配置管理的基本概念,基线,2007-12-11,Software Engineering 1/11956/119,软件配置管理的基本概念,产生基线的流程,2007-1

28、2-11,Software Engineering 1/11957/119,软件配置管理的基本概念,成为基线的SCIs系统规约软件项目计划软件需求规约图形分析模型；处理规约；原型；数学规约初步的用户手册设计规约 数据设计描述；体系结构设计描述；模块设计描述；界面设计描述；对象描述（如果使用面向对象技术）源代码清单测试规约测试计划和过程；测试用例和结果记录操作和安装手册,2007-12-11,Software Engineering 1/11958/119,软件配置管理的基本概念,成为基线的SCIs可执行程序 模块的可执行代码；链接的模块数据库描述模式和文件结构；初始内容联机用户手册维护文档 软

29、件问题报告；维护请求；工程变化命令软件工程的标准和规约,2007-12-11,Software Engineering 1/11959/119,软件配置管理的基本概念,角色 为了提高配置管理的效率和安全性，项目应当设有配置管理员这个角色。配置管理员的主要工作是为项目制定配置管理计划，创建和维护配置库等。对于大型的项目，鉴于配置管理的重要性和复杂性，机构应当设立配置控制委员会（Configuration Control Board，CCB）。CCB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者。对于普通的小型软件

30、项目而言，CCB这个概念难以落实，我们就不要玩虚的了，让项目经理或者配置管理员做决定就行了。,2007-12-11,Software Engineering 1/11960/119,软件配置管理的基本概念,流程,2007-12-11,Software Engineering 1/11961/119,Outline,头脑风暴什么是软件配置管理(SCM)软件配置管理最佳实践概述软件配置工具的功能和比较基于VSS的案例说明,2007-12-11,Software Engineering 1/11962/119,软件配置管理最佳实践概述,配置计划配置活动配置审计和报告,2007-12-11,Softw

31、are Engineering 1/11963/119,配置计划,根据项目的规模和时间周期等，定义相应的配置管理活动、配置审计和报告。配置管理员根据本项目的特征，起草配置管理计划，由CCB负责人（通常是项目经理）审批。配置管理计划的主要内容：1.人员与职责 2.软件硬件资源 3.配置项计划 4.基线计划 5.配置库备份计划 6.版本控制规则7.变更控制规则 8.审批 相关支持 培训 工具和流程的培训配置相关工具模板见word文档,2007-12-11,Software Engineering 1/11964/119,配置活动,安全、统一的存储库清晰规范的目录规划统一标识工件记录和跟踪变更请求通

32、过活动组织和集成一致的版本集合控制和审计工件的变更将工件构件化版本化开发与集成隔离,在项目里程碑建立基线基线的控制和管理维护稳定而一致的工作空间支持并行开发高性能的分布式开发环境统一一致的集成方法及早与经常集成重现软件的构造过程,2007-12-11,Software Engineering 1/11965/119,安全统一的存储库,存储库应具备容错能力、可扩展能力、可分布能力和可复制能力。应有相应的流程对存储池做备份和灾难恢复。,2007-12-11,Software Engineering 1/11966/119,清晰规范的目录规划,2007-12-11,Software Engineer

33、ing 1/11967/119,统一标识工件,进行配置管理必须要统一标识处于版本控制下的工件。查找正确文件的正确版本避免丢失工件版本。,2007-12-11,Software Engineering 1/11968/119,记录和跟踪变更请求,对软件系统进行变更的请求来源很多：测试部门、需求分析部门、用户、市场部、项目组内部等。通过制度、流程和工具用于记录、控制和跟踪各类原因造成的变更。,2007-12-11,Software Engineering 1/11969/119,控制和审计工件的变更,工件经过标识存入受控库后，需要定义相应的变更流程控制什么人获准修改哪些工件（配置控制）保存修改的相

34、关信息：何人做的修改、何时做的修改、哪里做的修改、为何要修改等。（配置状态审计）,2007-12-11,Software Engineering 1/11970/119,通过活动组织和集成一致的版本集合,基于活动的SCM关键思想：从处理文件和版本提升为处理活动。活动具有不同类型：一个缺陷、一个扩展请求、一个问题活动与变更请求的管理和流程直接相关,2007-12-11,Software Engineering 1/11971/119,将工件构件化版本化,一个SCM构件由一组相关的文件和目录组成，这些内容作为一个独立单元被标识版本、被共享、被构建以及形成基线。它是逻辑层面设计构件在物理层面的具体内

35、容。SCM构件在Rational统一流程中称“构件子系统”一个项目由某些构件的某个版本构成。,2007-12-11,Software Engineering 1/11972/119,续：将工件构件化版本化,基于构件方法的SCM带来的益处:构件简化了复杂性。识别特定构件基线的质量水平高于识别众多单个文件版本的质量水平。有助于共享和复用构件。有助于保持软件体系构架的完整性。,2007-12-11,Software Engineering 1/11973/119,开发与集成隔离,有助于保证提交到集成空间的代码是经过测试通过且相对稳定。,2007-12-11,Software Engineering

36、1/11974/119,在项目里程碑建立基线,在项目进展到每个特定时间点，记录组成系统的所有工件（项目计划、需求设计文档、代码等）及构件版本信息。至少应在项目的每个迭代末尾创建基线。定基线原因：再生能力、可追溯能力、报告能力,2007-12-11,Software Engineering 1/11975/119,基线的控制和管理,基线定义和修改应由专人负责。基线要有建立原因。应对基线的修改跟踪其变更，便于比较基线间的差异。代码测试中形成的基线可以定义不同的阶段或级别。,2007-12-11,Software Engineering 1/11976/119,维护稳定而一致的工作空间,定期同步变更

37、内容，并且同步的结果应是一致的、可共享和稳定的变更集合,2007-12-11,Software Engineering 1/11977/119,支持并行开发,SCM工具必须支持的一个关键功能。避免了开发人员被迫绕过系统或者被系统阻滞。开发人员在修改某个文件前，SCM工具应能提醒什么人什么时间因为什么原因也正在修改中。,2007-12-11,Software Engineering 1/11978/119,高性能的分布式开发环境,安全、方便、快捷的支持在不同办公地点的开发。,2007-12-11,Software Engineering 1/11979/119,统一一致的集成方法,采用统一的方法

38、，确保集成的代码是从一个地方下载和编译。避免编译前的代码无法找到或追寻。,2007-12-11,Software Engineering 1/11980/119,及早与经常集成,早期规划集成工作，并在项目生命周期中持续进行集成。及早发现接口中存在的问题及对设计的误解。通过配置管理的有效手段避免开发人员隔离与项目集成之间的僵局。,2007-12-11,Software Engineering 1/11981/119,有能力重现软件的构造过程,记录某一可执行模块或库文件何人构造的？包括哪些内容？相应的操作系统版本如何？在构建步骤命令里指定了哪些选项和参数？,2007-12-11,Software

39、Engineering 1/11982/119,配置活动,安全、统一的存储库清晰规范的目录规划统一标识工件记录和跟踪变更请求通过活动组织和集成一致的版本集合控制和审计工件的变更将工件构件化版本化开发与集成隔离,在项目里程碑建立基线基线的控制和管理维护稳定而一致的工作空间支持并行开发高性能的分布式开发环境统一一致的集成方法及早与经常集成重现软件的构造过程,回顾,2007-12-11,Software Engineering 1/11983/119,配置审计和报告,2007-12-11,Software Engineering 1/11984/119,SCM最佳实践总结,流程、工具、经验=天时、地

40、利、人和PDCA（戴明 p（plan）表示计划；d（do）表示执行；c（check）表示检查；a（action）表示处理）。流程的定义一定要源于实际需要，流程的执行一定要设监控点定期监控。,2007-12-11,Software Engineering 1/11985/119,Outline,头脑风暴什么是软件配置管理(SCM)软件配置管理最佳实践概述软件配置工具的功能和比较基于VSS的案例说明,2007-12-11,Software Engineering 1/11986/119,常用配置管理工具,SourceSafe SourceSafe是Microsoft公司推出的配置管理工具，是Vis

41、ual Studio的套件之一。SourceSafe是国内最流行的配置管理工具，用户量绝对是第一位。SourceSafe长得很象早先土气的文件管理器，的确难看。但是难看不碍事，SourceSafe的优点可以用8个字来概括“简单易用，一学就会”，这个优点是它老妈Microsoft遗传下来的，是天生的。虽然SourceSafe并不是免费的，但是在国内人们以接近于零的成本得到它，网上到处可以下载啊。当然Microsoft也不在乎这个小不点的软件，它属于“买大件送小件”的角色。如果你合法地得到Visual Studio，你就得到了免费的SourceSafe。SourceSafe的主要局限性：只能在Wi

42、ndows下运行，不能在Unix,Linux下运行。SourceSafe不支持异构环境下的配置管理，对用户而言是个麻烦事。这不是技术问题，是微软公司产品战略决定的。适合于局域网内的用户群，不适合于通过Internet连接的用户群，因为SourceSafe是通过“共享目录”方式存储文件的。人无完人，物不尽美。有些卖配置管理工具的软件供应商经常贬低SoureSafe，讽刺它是Source not Safe。我不想为谁辩护，只是给出一个例证说明SourceSafe的效用。有一个软件事业部（约百名开发人员）的十余个项目全部采用SourceSafe来管理，只用一台PC机作配置管理服务器，运行一年都没有发

43、生异常现象。,2007-12-11,Software Engineering 1/11987/119,常用配置管理工具,CVS CVS 是 Concurrent Version System（并行版本系统）的缩写，它是著名的开放源代码的配置管理工具。CVS的官方网站是http:/。官方提供的是CVS服务器和命令行程序，但是官方并不提供交互式的客户端软件。许多软件机构根据CVS官方提供的编程接口开发了各色各样的CVS客户端软件，最有名的当推Windows环境的CVS客户端软件WinCVS。WinCVS是免费的，但是并不开放源代码。与SourceSafe相比，CVS的主要优点是：SourceSaf

44、e有的功能CVS全都有，CVS支持并发的版本管理，SourceSafe没有并发功能。CVS服务器的功能和性能都比SourceSafe高出一筹。CVS服务器是用Java编写的，可以在任何操作系统和网络环境下运行。CVS深受Unix和Linux 的用户喜爱。Borland公司的JBuilder提供了CVS的插件，Java程序员可以在JBuilder集成环境中使用CVS进行版本控制。CVS服务器有自己专用的数据库，文件存储并不采用SourceSafe的“共享目录”方式，所以不受限于局域网，信息安全性很好。CVS的主要缺点在于客户端软件，真可谓五花八门、良莠不齐。Unix和Linux 的软件高手可以直

45、接使用CVS命令行程序，而Windows用户通常使用WinCVS。安装和使用WinCVS显然比SourceSafe麻烦不少，这是令人比较遗憾的。,2007-12-11,Software Engineering 1/11988/119,常用配置管理工具,ClearCaseRational公司的ClearCase是软件行业公认的功能最强大、价格最昂贵的配置管理软件。ClearCase主要应用于复杂产品的并行开发、发布和维护，其功能划分为四个范畴：版本控制、工作空间管理（Workspace Management）、构造管理（Build Management）、过程控制（Process Control

46、）。ClearCase通过TCP/IP来连接客户端和服务器。另外，ClearCase拥有的浮动License可以跨越UNIX和Windows NT平台被共享。ClearCase的功能比CVS、SourceSafe强大得多，但是其用户量却远不如CVS、SourceSafe的多。主要原因是：ClearCase价格昂贵，如果没有批量折扣的话，每个License大约5000美元。对于中国用户而言，这无疑是天价。用户只有经过几天的培训后（费用同样很昂贵），才能正常使用ClearCase。如果不参加培训的话，用户基本上不可能无师自通。,2007-12-11,Software Engineering 1/1

47、1989/119,Outline,头脑风暴什么是软件配置管理(SCM)软件配置管理最佳实践概述软件配置工具的功能和比较基于VSS的案例说明,2007-12-11,Software Engineering 1/11990/119,Microsoft的VSS 将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。开发组的成员不能对该数据库中的文件进行直接的修改，而是由该版本管理器将该项目的源程序或是子项目的源程序拷贝到各个成员自己的工作目录下进行调试和修改，然后将修改后的项目文件作Checkin提交给VSS，由它进行综合更新。,VSS的简单工作原 理,2007-12-11,Software

48、 Engineering 1/11991/119,VSS的简单工作原理,用户可以根据需要随时快速有效地共享文件。文件一旦被添加进VSS，它的每次改动都会被记录下来，用户可以恢复文件的早期版本，项目组的其他成员也可以看到有关文档的最新版本，并对它们进行修改，VSS也同样会将新的改动记录下来。,2007-12-11,Software Engineering 1/11992/119,VSS的解决方案,在一台Windows NT服务器上安装VSS 6.0的服务器端软件，创建一个为该整个项目存放用的数据库，然后在该数据库中创建各个项目和子项目，并由VSS管理员为小组的每个成员创建一个帐号及他们各自的权限

49、；在开发小组其他成员的PC上安装VSS的客户端软件，并创建自己的工作目录，这样在软件的开发过程中，他们只要通过该客户端软件登录到VSS服务器上，Checkout当前要进行工作的项目或文件，如有修改的在工作结束时将其Check in提交给VSS服务器进行统一更新。,2007-12-11,Software Engineering 1/11993/119,服务器安装,第一步，将Visual Studio 6.0 的CD1放入CD-ROM，自动进入安装程序，选择第二项“Server Applications and Tools(Add Only)”，第二步，然后在“Server Setups”的“Se

50、rver Components”中选择“Visual Source Safe Server”,按“Install”按钮后，根据提示放入CD2，第三步，根据Installation Wizard的提示，继续安装过程，选择安装路径，按图4左上角的按钮，系统继续进行安装，直至提示你重启以使新安装的程序生效，重启计算机。,2007-12-11,Software Engineering 1/11994/119,客户端安装,1.服务器端将vss客户端文件夹共享。NetSetup.exe所在位置：192.9.200.127softwareVSS客户端 2.在要安装的客户机上执行服务器上的NETSETUP.E