Rational工具进行软件配置管理方案的研究.doc

同济大学工程硕士学位论文声 明本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果，撰写成硕士学位论文“ Rational工具进行软件配置管理方案的研究 ”。除论文中已经注明引用的内容外，对本研究做出重要贡献的个人和集体，均已在论文中作了明确的说明。尽我所知，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得同济大学或其它教育机构的学位或证书而使用过的材料。签名： 日期： 2004/6/9 摘 要关键词：AbstractKeywords:目 录摘 要IIAbstractIII第1章 引言11.1 研究意义11.2 研究现状11.3本文的几点工作21.4本文的结构2第2章 软件配置管理介绍32.1 VOB32.2 配置规格（config spec）32.3 工作空间32.4 项目管理：项目、工作流和活动42.5 版本对象：元素、分支和版本52.6 构件管理：构件和基线52.7 过程：标签、属性、超链、触发器5第3章 CRM24 Java化项目简介63.1 项目来源63.2 原系统架构简介63.3 项目组人员和职责安排113.3.1 按工作性质来划分113.3.2 按工作任务和项目进度来划分123.4 项目相关资料的目录结构13第4章 软件配置管理计划154.1 组织和职责154.1.1 配置管理组（CM）154.1.2变更控制委员会（CCB）154.1.3组评审委员会（GRB）164.2 配置管理过程描述164.2.1 识别配置项164.2.2 制定配置管理计划184.2.3 版本控制184.2.4 变更控制184.2.5 配置审计194.2.6 发布配置状态报告194.2.7 发布管理204.3 搭建软件环境204.4 搭建硬件环境20第5章 采用Base ClearCase实现配置管理计划215.1 CRM24 Java化项目中的配置项215.2 项目开发流程245.2.1项目经理创建项目环境245.2.2项目经理定义实现开发策略265.2.3 开始进行开发27第6章 采用UCM技术实现配置管理计划286.1 CRM24 Java化项目中的配置项286.2 项目开发流程296.2.1项目经理创建UCM项目并创建基线296.2.2 开发人员加入项目296.2.3 开始进行开发296.2.4发布工程构建产品306.2.5 开发人员更新工作区30第7章 总 结317.1 比较Base ClearCase和UCM的优劣317.2 研究管理license的有效方法317.3 使用配置管理带来的好处327.4 配置管理实施过程中的一些技巧327.4.1 使用perl编程使操作自动化327.4.2 VOB的备份策略34参考文献35致 谢3637第1章 引言1.1 配置管理的重要性随着软件产业的崛起，团队化的工作方式已成为软件开发的主流方式，然而随着软件开发人员的增加和开发环境的日益复杂，使得软件开发越来越难以管理。在实际开发中往往出现团队沟通困难，软件重用率低下，开发人员各自为政，代码冗余度高，文档不健全等问题，造成的结果是数据丢失，开发周期长，产品可靠性差，质量低劣，软件维护困难，项目风险增加等。因此，加强软件开发过程的配置管理是十分重要的。软件配置管理由于直接管理软件资源，对各方面均会产生显著的影响。软件配置管理技术是CMM（capability maturity model，能力成熟度模型）2级（可重复级）的一个关键过程域，ISO/IEC 12207国际标准也把它作为软件生命周期过程中基本过程的重要支持过程。目前用于软件配置管理的工具有很多，IBM的Rational系列软件，无论在稳定性方面还是在性能方面口碑都很好，对于整个的软件开发过程能够提供有效的支持，其中的clearcase和clearquest工具相结合用来进行统一变更管理。（加相关配置管理重要性的例子）1.2 软件配置管理技术及工具现状软件配置管理技术在八十年代初就应运而生了。第一代软件配置管理工具只是处理文件版本控制的工具，它们是基于单一文件的工具，它们将个独立文件改变存储在特殊的文档文件之中，一般支持恢复提交模式，并提供分支。最早的这类工具是SCCS和RCS，其它商用产品有Sun公司开发的TeamWare，以及Intelsoft公司的PVCS等，另外还有自由软件CVS。第二代配置管理工具是基于项目数据库的，所有软件开发项目和文件的原信息与它们的文档文件分离，而储存在一个数据库中。这一代工具有基于变动请求的IBM的CMVC，面向操作的Platium公司的CCC以及SQL公司的PCMS.第三代配置管理工具在保持了第二代工具的优点的基础上加入了“文件透明性”这一特征。最具有代表性的产品是ClearCase，它是通过一个独占的文件系统MVFS（multiversion file system，多版本文件系统）来实现文件透明性的。这些配置管理工具在许多软件工程，如现今的MS Windows，Oracle等的开发过程中发挥了重要的作用。在国内，随着软件工程技术的发展，已经有许多人注意到了配置管理的重要性，也有企业在开发或引进配置管理工具。如果我们要在国际的软件工程业中占有一席之地，配置管理工具的应用将是重要的一环。采用配置管理的工具可以有效地进行项目的并行开发和集成，甚至是地域上分布的开发，降低开发的风险。需要注意的是配置管理工具并不是越复杂越好，而应该选用适合于自己的配置管理工具。1.3本文的几点工作本文将研究借助一个CRM系统Java化项目来研究如何使用Rational工具进行软件配置管理的解决方案，具体工作包括以下几点：1、 简要的介绍配置管理；2、 针对该CRM系统Java化项目制定配置管理计划，设定配置管理委员会的组成和职责；3、 采用Base ClearCase技术实现该配置管理计划，分别从配置管理人员和开发人员方面进行讨论实施方案；4、 采用UCM技术实现该配置管理计划，分别从配置管理人员和开发人员方面进行讨论实施方案；5、 针对项目的具体情况，讨论Base ClearCase和UCM技术的优劣；6、 研究管理license的有效方法；7、 讨论使用配置管理所带来的好处。8、 讨论实施过程中的一些技巧。1.4本文的结构第2章 软件配置管理技术及ClearCase概要2.1 通用的SCM技术2.2 ClearCaseVOB VOB（Versioned Object Base），即版本对象库，这是SCM系统的核心，用来存储文件、目录和元数据的永久数据存储池。它能够管理任何表示为文件或目录的对象。它支持的特征包括：（1） 可扩展的。ClearCase VOB中的元素可以从成百上千的文件演变成成千上万的文件和目录，当VOB变得很大时，一个VOB中的文件和目录可以在多个VOB间移动。一个VOB可以被分成多个VOB，多个VOB也可以相互连接。（2） 容错性。ClearCase VOB使用内部数据库，不需要进行额外的数据库管理。（3） 分布式。ClearCase VOB可以分布在网络的不同服务器上，对于最终用户是透明的。（4） 可复制。这里的复制是指在不同地理位置上进行完全的复制并保持相互间的同步更新。ClearCase VOB可以在两点或多点进行复制。可复制是异地分布开发的关键。ClearCase有两种VOB，一种是标准VOB，另一种是项目VOB（project VOB，简称PVOB），PVOB中包含与项目环境相关的对象。简言之，VOB存储和组织的对象组成了正在开发的系统，而PVOB存储的对象则用来组织和管理正在开发的项目。2.2 配置规格（config spec）定义在一个视图中可以看到哪些元素的哪些版本。对于使用UCM模型的项目，ClearCase自动生成配置规格。对于不使用UCM的项目，可以使用默认配置规格，或手工生成配置规格，还可以使用脚本生成配置规格。2.3 工作空间在ClearCase中，工作空间被称为“视图（view）”，视图的主要目的是为开发者提供一组稳定的、一致的软件内容，在视图中可以进行变更和执行单元测试。视图依据一组配置规格定义从VOB内所有可用版本中选择文件和目录的合适版本。ClearCase提供了两种视图，快照视图（snapshot）和动态视图(dynamic)。快照视图将文件的拷贝从VOB中下载到视图中，使用一个数据库跟踪下载到本地工作目录中的版本，可以使用配置规格中的load语句来限制哪些元素从VOB拷贝到快照视图中。动态视图通过一个称为“多版本的文件系统（Multiversioned File System，简称MVFS）的虚拟文件系统提供对于元素版本的存取操作，不用将元素拷贝到本地目录中，这个虚拟文件系统直接指向VOB中的元素。当在MVFS文件系统中使用编辑器的工具访问文件时，MVFS会中断文件打开命令，判断用户在什么视图中工作，再判断选择文件的哪个版本正确，然后打开文件的那个版本。动态视图是ClearCase所特有的。2.4 项目管理：项目、工作流和活动由于软件开发活动的规模和复杂性，项目管理需要自动化和工具来协助组织和管理大型软件项目。ClearCase UCM拥有辅助管理和组织软件项目的对象和自动化功能，包括：项目、工作流和活动。项目管理研究所（PMI）学院如下定义项目：在有限资源条件下，人们用于规划、执行和控制活动而付出的努力。项目是为了创建“一个”产品或者服务而付出的“临时性”的努力。“临时性”的含义是每个项目都有明确的开始时间和结束时间。“一个”的含义是该产品或者服务在某些方面与其他的产品或者服务有明确的不同之处。在组织机构的各个层次都在进行着各种项目。项目中可能牵涉一个人或者是成百上千的人。项目可能只花费不足100个小时，也许会耗费超过100000000个小时。项目可能涉及一个机构的一个部门，也可能是跨越组织机构边界的合资或合作伙伴。项目通常是贯彻机构业务策略的要件。ClearCase UCM中的项目代表一组独立的个人协作生成新的基线，这个基线由一个系统的一个或多个构件组成。使用ClearCase项目，其属性定义了项目范围和工作的对象以及策略，策略包括：项目分配工作的策略，工作空间（工作流和视图）的策略，还有项目成员执行哪些活动的策略。一个工作流为其关联的一个或多个视图定义了工作配置，它包括为创建视图自动生成配置规格所需要的信息。每个项目有一个集成流（integration stream）和多个开发流（development stream）。工作流主要有两个作用：（1） 配置与工作流相关联的视图。他们配置视图来选择正确的文件版本，在工作流中从事项目工作。（2） 工作流物理地存储开发人员工作在视图中的活动。活动用于跟踪完成一项开发任务的工作。它包括一个文本标题，标题描述了任务和变更集，标题还标识了这个活动中所创建或者修改的所有版本。活动对象的主要任务就是跟踪变更集和结果。2.5 版本对象：元素、分支和版本在ClearCase中，元素（element）就是置于版本控制下的文件和目录。每个元素记录了它所代表的文件或目录的版本。这些元素版本被组织成不同的分支，分支就是版本的序列。2.6 构件管理：构件和基线将被一起开发、集成、基线和发布的文件和目录聚集在一起就形成了构件，构件通过一个根目录来定义。构件的一个版本就是一个基线。构件基线标识了构件中包含的每个元素的零或一个版本。每个基线有一个用户定义质量和晋升级别。一个公司可以使用ClearCase定义不同的测试水平并标识基线，表示每个基线已通过的测试水平。2.7 过程：标签、属性、超链、触发器标签（Label）是一个标签类型的一个实例，并被关联到一个元素的一个版本上。标签类型是一个冠名的标记符，用来标识一组相容的元素版本。在UCM里不需要自己创建和生成标签。属性类型由一对数据/值构成，能够把属性（Attribute）实例关联到几乎所有的ClearCase对象上。超链（Hyperlink）定义对象间的关系。触发器（Trigger）是用户定义的事件，当某些ClearCase操作发生时被激活。触发器有两种不同的类型：事前触发和事后触发。事前触发的触发器在ClearCase事件发生前被激活，可以取消触发的事件，它的典型应用是强制制度；事后触发在ClearCase事件发生后被激活，它的典型应用是通知。以上就是软件配置管理里的一些基本概念，下面将介绍一个CRM的项目，本文就是结合此项目来研究如何制定软件配置管理方案的。第3章 CRM24 Java化项目简介3.1 项目来源本项目是国内某公司承接的一个日本公司的项目，它是将原来用ASP开发的一个客户关系管理（CRM）系统Call Center重新用JSP和目前比较流行的Struts技术里重新实现，这样使该CRM系统更好的应用于多种平台。本项目规模较大，涉及到500多个页面，而且要求新系统不能改变原系统的Oracle数据库的结构，并且要与原系统的数据库连接正常，不丢失数据。3.2 原系统架构简介下面根据不同的功能来划分该Call Center系统的模块结构，如表3-1所示：表3-1 Call Center系统模块结构Table 3-1项目名模块Call Center登录顾客检索社员检索设备检索修理检索入出库检索质量检索检查检索相关资料检索社内体制数据维护管理指标共通子画面共通模块下面依次介绍各模块所包含的功能：登录模块用来使用户进入该Call Center系统，它所包含的功能如表3-2所示。首先显示登录画面，然后用户输入账号和密码，验证正确后进入系统，否则提示用户。表3-2 登录模块包含的功能Table 3-2模块名功能登录登录画面验证账号密码登录后菜单画面顾客检索模块包含的功能如表3-3所示，可以指定条件来检索顾客，可以列出所有的顾客，也可以列出顾客的详细信息并且把这些信息导出成文件。表3-3 顾客检索模块包含的功能Table 3-3模块名功能顾客检索顾客检索顾客一览顾客详细信息将顾客详细信息导出社员检索模块包含的功能如表3-4所示，可以指定条件来检索社员，可以列出所有的社员，也可以列出社员的详细信息并且根据社员的email链接来给社员发送email。表3-4 社员检索模块包含的功能Table 3-4模块名功能社员检索社员检索社员一览社员详细信息、生成email设备检索模块包含的功能如表3-5所示，这个模块包含的内容很多，可以检索设备各方面的信息，还可以将这些信息以多种方式导出。表3-5 设备检索模块所包含的功能Table 3-5模块名功能设备检索设备检索设备一览将设备信息导出设备详细信息设备详细信息画面中的机种选择设备详细信息画面中的顾客选择设备入出库信息一览将设备入出库信息导出设备修理信息一览设备检查信息一览设备品质信息一览设备图片资料设备资料处理设备商谈信息一览设备详细商谈信息将设备详细商谈信息导出入出库详细信息画面故障信息选择上传入出库详细信息附加文件入出库信息输出菜单入出库信息输出成Excel文件入出库信息输出成Html文件将对应的详细信息用邮件发送修理检索模块包含的功能如表3-6所示，其中包括查看详细的修理信息并把这些信息以Excel和Html两种文件格式输出；还可以把修理信息作为附件上传。表3-6 修理检索模块所包含的功能Table 3-6模块名功能修理检索详细修理信息将修理信息输出成EXCEL文件将修理信息输出成HTML文件上传修理信息附加文件pull-down数据简易作成pull-down数据简易删除修理零部件信息处理修理工作信息处理入出库检索模块包含的功能如表3-7所示，包括入出库信息的检索、列举、添加、修改等。表3-7 入出库检索模块所包含的功能Table 3-7模块名功能入出库检索入出库检索入出库一览入出库号码变更将入出库信息输出详细入出库信息（新建）详细入出库信息（更新）附加处理文件质量检索模块包含的功能如表3-8所示，包括检索质量信息以及输出等等。表8 质量检索模块所包含的功能Table 3-8模块名功能质量检索质量检索详细质量信息将质量信息输出检查检索模块包含的功能如表3-9所示，包括检查信息的检索、列举、添加、修改以及输出等等。表3-9 检查检索模块所包含的功能Table 3-9模块名功能检查检索检查信息检索检查装置选择检查信息一览将检查信息输出详细定期检查信息（新建）详细定期检查信息（修改）打印检查信息相关资料检索模块包含的功能如表3-10所示，包括相关资料的检索、列举、编辑以及登录等。表3-10 相关资料检索模块所包含的功能Table 3-10模块名功能相关资料检索相关资料检索相关资料一览相关资料的编辑相关资料的登录社内体制模块包含的功能如表3-11所示，包括社内体制的信息。表3-11 社内体制模块所包含的功能Table 3-11模块名功能社内体制社内体制表検索社内体制表社内体制表输入画面工作岗位设定公司内部工作岗位选择数据维护模块包括数据库中所有信息的登录、更新、修改、删除等操作。管理指标模块用来设定各项管理参数，如表3-12所列举，还可以将这些参数输出。表3-12管理指标模块所包含的功能Table 3-12模块名功能管理指标按地区分类的顾客按缴纳台数分类的顾客每月入出库件数每年入出库件数每月对应时间每年对应时间按对应时间分类的入出库件数按入出库时间分类的入出库件数每月1件对应时间每年1件对应时间共通子画面模块包含了在所有模块中都可能用到的功能，比如数值输入、日期时间设定等，如表3-13所示。表3-13共通子画面模块所包含的功能Table 3-13模块名功能共通子画面数值输入日期設定时间設定共通模块包含了其它模块中都可能使用到的子模块等等。3.3 和配置管理有关的项目组人员及职责安排3.3.1 按工作性质来划分根据本项目的实际需要，如下安排项目组成员：项目经理：A技术经理：B1、B2、B3质量保证经理：C配置经理：D开发人员：范亮、黄季、王小兵、汪峰、杨涛、卢娟、陆世超、王伟、陈国辉、薛杰、刘涛测试人员：朱美、杨兰、何苗、王爱萍配置管理员：李冰喆用图3-1来表示本项目的人员结构：图3-1 CRM24 Java化项目组人员结构图Diagram 3-1 The Structure of the Project Development Group3.3.2 按配置项或工作任务及项目进度来划分图3-1是从人事构成上来大致的展现项目组的人员结构，但是在细节上，针对项目的具体情况以及不同的开发阶段，可以来灵活的安排人员的结构，而不拘泥于上面的框架，下面就是按照工作任务和项目进度来安排项目的开发工作，见表3-14：表3-14 项目的人员和进度安排Table 3-14 The Developers and Process Arrangement of the Project任务或模块名开始日期结束日期负责人备注需求分析8-58-15刘量（组）5人分析原ASP系统8-58-15雷正山（组）5人概要设计8-158-25李文驷（组）5人数据库设计8-158-25周浩军（组）4人登录模块8-258-30刘量包括详细设计、编码和单元测试顾客检索模块8-259-25范亮社员检索模块8-2511-20汪峰设备检索模块8-2511-20薛杰修理检索模块8-2511-20陆世超入出库检索模块9-1811-12李文驷质量检索模块8-2511-20刘涛检查检索模块9-1811-12王小兵相关资料检索模块8-2511-20陈国辉社内体制模块8-2511-20卢娟数据维护模块8-2511-20周浩军管理指标模块8-2511-20杨涛共通子画面模块8-259-18黄季共通模块模块8-259-18王伟数据库连接11-1511-25周浩军（组）4人系统集成11-2511-30刘量（组）、李文驷（组）、周浩军（组）14人集成测试11-3012-29雷正山（组）5人详细设计书整理12-2212-29刘量、李文驷、周浩军系统移交12-2912-31沈华系统维护12-31-王伟、王爱萍、李冰喆配置管理8-5-高祥、李冰喆3.4 项目相关资料的配置目录结构项目的源代码和文档是项目的最终产品，所以其重要性是可想而知的。另外项目开发过程中需要使用到的各种资料对项目的开发也很重要，管理好这些资料能够大大的方便项目的开发工作。在本项目中，将使用ClearCase来管理所有的文档、资料、源代码，所以在项目开始之前，制定项目相关资料的目录结构如表3-15所示，根据这个结构来建好目录，并把相应的一些文档资料放入对应的目录中，作为项目的初始化。表3-15 项目的目录结构Table 3-15 The Directory Structure of the Project根目录一级子目录二级子目录存放的内容CRM24_Java.from_customer.former_asp_system原有的ASP系统的源代码.customer_requirement客户的需求.management.weekly_report每个成员的周报.schedule项目进度记录.meeting会议记录.other其它管理文档.document.analyse需求分析文档.design概要设计和详细设计文档.source_mon_module共通模块的代码.common_form共通子画面的代码.login登陆模块的代码.customer顾客检索模块的代码.employee社员检索模块的代码.device设备检索模块的代码.repairment修理检索模块的代码.circulation入出库检索模块的代码.quality质量检索模块的代码.examine检查检索模块的代码.information相关资料检索模块的代码.manage_system社内体制模块的代码.data_maintenance数据维护模块的代码.manage_parameter管理指标模块的代码.test.unit_test单元测试的计划、用例、报告.integrate_test集成测试的计划、用例、报告.other其它测试相关的文档.release与发布相关的文档.maintenance与维护相关的文档.tools开发工具.useful_doc有用的参考资料第4章 CRM24 JAVA项目软件配置管理计划4.1 CRM24 JAVA项目配置管理计划的内容4.1.1组织和职责4.1.1 配置管理组（CM）配置管理组由配置经理和专职配置管理员组成，配置经理可以由技术经理或其他人员担任。配置经理要熟悉机构的配置和变更管理流程，并且要熟悉所采用的SCM工具。在开发人员开始工作之前，配置管理员一定要确立SCM环境，这有两个关键步骤：建立硬件环境和建立开发环境。配置管理员协同系统管理员评估和分配硬件资源，然后还要在服务器端和客户端安装ClearCase，接下来就可以建立开发环境了。配置管理员要和系统架构师一起确定实施模型、创建存储池、创建产品的目录结构、创建初始的版本化元素。总结后可以列出配置经理的主要工作职能包括以下几点：（1） 负责识别项目配置项，形成项目配置项基线计划；（2） 负责确定项目配置项标识规定；（3） 归并集成；（4） 构建系统；（5） 申请基线变更；（6） 建立发布版本。配置管理员的主要工作职能包括以下几点：（1） 制定与维护项目的配置管理计划；（2） 建立与维护项目配置管理库；（3） 为项目组成员进行配置管理工具与配置库的培训；（4） 对已提交的配置项进行配置审计，并建立相应的基线；（5） 按照配置管理过程、标准、计划等执行配置管理活动，执行基线与其他配置项的变更控制流程。针对本项目，配置经理为：高祥，配置管理员为：李冰喆。4.1.2变更控制委员会（CCB）项目组设立变更控制委员会CCB，成员一般由项目经理（PM）、技术经理（TM）、质量保证经理、配置经理组成，在处理具体配置项变更时，根据具体情况，CCB成员会做相应的变动。本项目的CCB成员包括：沈华、刘量、李文驷、周浩军、雷正山和高祥。CCB成员的主要职能为以下几点：（1） 判断变更申请的级别和有效性，并反馈给配置管理员；（2） 对变更后的配置项审核，将审核结果填写至变更单中；（3） 对评审变更的影响范围、工作量等负责；（4） 对变更申请做出裁决；（5） 跟踪变更状态，验证变更并负责；4.1.3组评审委员会（GRB） 项目组设立变更控制委员会GRB，成员一般由项目经理、技术经理、质量保证经理、配置经理组成。GRB成员在整个开发过程中，对整个开发的产出物进行评审，具体包括：（1） 制定访问控制和开发策略；（2） 审核配置管理计划；评审并批准基线的建立；（3） 评审在开发阶段所有的产出物；（4） 审核发布版本。本项目的GRB成员包括：沈华、刘量、李文驷、周浩军、雷正山和高祥。4.2 基于CRM24的配置管理过程描述下面通过依次介绍配置管理过程中的主要活动来描述配置管理过程。4.2.1 识别配置项在项目开发过程中，程序、数据和文档都可以作为配置管理的对象，下面以图的形式来列举可能的配置项，如图4-1所示，由图可以看出配置项之间是组合关系或者相互关系。 图4-1 可能的配置项Diagram 4-1 The possible Configuration Items识别出所有的配置项后，为了管理的规范化，需要对配置项的标识作出规定，例如，我们可以作出如下的命名规定：（1） 技术文档标识规定：客户名称 - 项目名称 - 文档类型名称（2） 质量记录标识规定：客户名称 - 项目名称 - 文档类型名称 序号（3） 代码标识规定：项目启动阶段，由项目经理或技术经理负责提供，GRB审核。（4） 会议记要：客户名称 - 项目名称 - 文档类型名称 开会日期（5） 项目周报：客户名称 - 项目名称 - 文档类型名称 提交日期（6） 技术讨论记录：客户名称 - 项目名称 - 文档类型名称 讨论日期此过程的工作主要由配置经理和配置管理员来担当，采用二级评审的方式，最终的工作输出主要包括：配置项基线计划、软件版本发布计划、配置项标识规定。其中确定配置项标识规定的工作流程可以是首先由CM来发起，然后经PM确认，最后提交给CCB和GRB审核；而对于标识配置项，任何人都可以来执行，只是最后要交由CM来审查。4.2.3 基于配置项版本控制版本控制是将规程和工具相结合来管理在软件工程过程中所创建的配置对象的不同版本，通过“属性元组”等其它技术来控制完整版本中的“变体”，采用不同的工具不同的技术，版本控制的机制会有一些不同。这部分的工作也是由配置经理和配置管理员来担当，采用二级评审的方式，这一过程的工作还可以进一步细分为：裁减标准配置管理库结构、配置项纳入配置管理、基线化配置项，最终的工作输出是配置管理库的目录结构。其中的裁减标准配置管理库结构的工作流程可以是首先在PM或测试经理的参与下由CM来发起，然后交给CCB和GRB来确认，最后告知开发人员和测试人员；而对于配置项纳入配置管理和基线化配置项，都是首先由PM来发起，然后交给PM来执行，最后仍然是交给CCB和GRB来确认。4.2.4 变更控制变更在软件开发过程中是不可避免的，但过于频繁的变更也会对项目的开发产生负面的影响，如影响项目的进度、浪费人力物力，因此需要对变更进行控制。变更控制可以依照如下的步骤来进行：（1） 提交变更请求，这一操作任何人都可以来执行；（2） 审核变更请求，这是由CCB和GRB来执行的；（3） 分配和确定任务，这一操作是PM在CCB和GRB的授权下来执行；（4） 提取变更项，这一操作CM在CCB和GRB的授权下来执行；（5） 执行变更，此操作任何人都可以作为变更责任人去执行；（6） 审核变更，这自然是由CCB和GRB来执行，但任何人都可能参与本项工作；（7） 更新配置管理库，这是由CM来完成的。整个变更控制的产物主要是变更请求单、变更报告单、工程变更单或变更确认单等。4.2.5 配置审计配置审计一般包括两种，一种是正式的技术评审，另一种是软件配置审计。在正式的技术评审中，将关注已经被修改的配置项的正确性，配置项的评估配置项，以确定它与其他一致性、遗漏及潜在的副作用。正式评审应该针对于所有的变更。而另外一种软件配置审计，是来评估正式评审中没有考虑的那些特征，可以考虑如下方面：（1） 工程变更单（ECO）中的相关内容是否已经完成；（2） 是否已经进行了正式的技术评审；（3） 变更过程中是否遵循了软件工程标准；（4） 在对配置项修改的同时，是否有相关的详细注释（comments）；（5） 在配置管理工具中是否标注了变更后的配置项状态；（6） 所有与该配置项相关的配置项是否进行了相应的更新。这一过程的工作主要由CM来完成，也可以在PM的协助下完成。4.2.6 发布配置状态报告配置状态报告（Configuration State Report, CSR）是SCM的一个任务，它在中大型项目中扮演着重要的角色，内容可以包括：修改了什么、谁修改的、修改是什么时候发生的以及修改有什么影响，一般情况下，是在一个配置项被赋上新的或已经修改的标识时，或者一个变更被批准时，或者产生配置审计结果时产生配置状态报告。还可以将CSR放于一个联机数据库中，使得开发者、维护者和管理者可以通过关键词等方式去访问。本过程是由CM来完成的。4.2.7 发布管理当项目进行到一定的阶段，可能需要发布一个稳定的或相对比较稳定的版本，这个时候就需要首先制定发布实施计划，然后生成发布准备报告，最后发布完成生成发布报告。此过程主要由项目经理、CCB和配置管理员来完成，采用二级评审的方式。4.3 搭建CRM24配置环境软件环境由3.3.1可知本项目的参与人员共有22人，为了方便开发管理，每个人的计算机都安装了Windows 2000 server，并且建立一个名为ss的域，每台计算机都登陆到ss域中。同时为了方便管理代码的安全性，设立一个clearcase_mng组，将项目经理、技术经理、质量保证经理、配置经理和配置管理员添加到clearcase_mng组内，这个组可以拥有较大的权限，本项目中加入到clearcase_mng组的成员有：沈华、刘量、李文驷、周浩军、雷正山、高祥、李冰喆。根据项目的特点，可以确定每位开发人员的计算机需要安装如下软件：（1） Jakarta Tomcat 4.1.27（2） Java 2 SDK, Standard Edition 1.4.2（3） Eclipse2.1.1（4） Jakarta Struts 1.1（5） Oracle9i Release 2（6） Rational ClearCase对于ClearCase，整个团队需要一台专门的服务器clearcase_server作为VOB服务器，因为该项目的规模并不是非常庞大，所以该服务器可以兼作许可证服务器（License Server）和注册服务器（Registry Server）。为了保证ClearCase的效率，我们确保clearcase_server这台服务器是专用的，即只作ClearCase的用途，不安装其它的应用软件。4.4 搭建硬件环境根据软件环境的配置，就可以搭建硬件环境了，其中主要考虑的关键资源是：内存、磁盘I/O、网络带宽和CPU，据此，可以设置每台计算机的最小内存为512M，尽量使每个磁盘有一个专门的控制器和通道，使所有项目组成员处于同一个子网内，采用的CPU可以为P4 1.8G以上。第5章 采用Base ClearCase实现CRM24配置管理根据第4章的配置管理计划就可以来开展项目的开发工作，因为配置管理贯穿于整个项目的开发过程，所以采用什么样的配置管理工具和技术对项目的开发流程有较大影响，本章将研究采用Base ClearCase技术来进行配置管理。5.1 CRM24 Java化项目中的配置项(为什么要这样决定配置项)参照第3章对项目结构的分析以及第4章对配置项的定义，识别出了本项目中可以纳入配置管理库的所有配置项，配置管理库的目录结构参见表5-1：表5-1 CRM24 Java化项目中的配置项Table 5-1 The Configuration Items of the Project文档根目录子目录子目录子目录各目录描述01-开发文档存放项目开发过程中需要纳入配置管理的配置项01-需求阶段01-草稿存放需求阶段中所有文档的草稿02-发布文档存放通过评审的需求规格说明书，该目录仅由配置管理员操作，其他人员具有只读权限03-参照文档存放与该阶段相关的参考资料、规范04-评审记录存放需求规格说明书的评审记录02-设计阶段01-架构设计架构设计说明书02-界面设计系统界面设计说明书03-数据库设计数据库设计相关文档04-详细设计01-草稿详细设计所有文档的草稿02-发布存放通过评审详细设计说明书，该目录仅由配置管理员操作，其他人员具有只读权限05-参照文档存放与该阶段相关的参考资料、规范06-评审记录设计阶段GRB产生的评审报告记录03-编码阶段01-相关文档编码阶段涉及的资料文档、规范文档、技术文档02-单元测试01-测试用例测试单元模块设计的用例02-测试数据测试单元模块所要使用的数据03-测试工具测试单元模块的工具，以及工具的使用文档04-测试报告单元测试结果报告04-测试阶段01-集成测试01-测试用例为集成测试设计的用例文档02-测试数据集成测试所要使用的数据03-测试工具集成测试所需工具，以及工具使用文档04-测试报告集成测试结果报告02-系统测试01-系统测试计划02-系统测试用例为系统测试设计的用例文档03-系统测试报告系统测试结果报告05-实施阶段01-用户手册02-系统操作手册03-系统维护手册06-维护阶段01-维护记录07-技术讨论小结02-项目管理01-售前文档报价标书建议书02-项目计划03-验收文档04-项目报告阶段性提交项目完成情况报告,项目总结报告05-会议纪要06-外来文件07-项目讨论稿03-配置管理01-软件配置管理计划02-变更管理变更申请单，变更单03-配置状态报告04-质量保证01-质量保证计划02-质量保证报告05-测试01-用户测试计划02-用户测试报告用户测试系统的结果报告06-项目过程定义QA和项目组约定的项目过程文档01-项目规范07-参考文件5.2 Base ClearCase的项目开发流程根据Base ClearCase的特点，确定使用Base ClearCase的开发流程如下所述。5.2.1创建CRM24项目环境VOB作为存储文件、目录和原数据的永久数据存储池，显然在整个项目中的作用是至关重要的，而且也是项目能够进行下去的基础，所以项目开始进展前必须要首先创建VOB。可以使用命令行方式cleartool或者在图形用户界面Create VOB下创建VOB，创建时需要指定VOB的tag、类型、存储位置以及注释等信息。对于本项目，项目经理可以指定配置管理员在clearcase_server服务器上创建一个名为CRM24的VOB用来存储项目中的所有资源。当建好一个空的VOB后，将已经建好的CRM24_Java目录导入VOB中，这可以在命令行方式下来完成，例如：c:clearfimport unco E:CRM24_Java M:CRM24_xiang_gao_dvCRM24其中：E:CRM24_Java表示建好的目录CRM24_Java放在E盘； M是clearcase自动映射的一个网络驱动器，用来管理动态视图的； CRM24_xiang_gao_dv是配置经理高祥所建的动态视图； CRM24是本项目对应的VOB。VOB中的数据是以特殊的专有格式来存储的，所以视图是访问VOB中数据的唯一的方式。视图分为动态视图和快照视图，考虑到操作的规范性，规定视图的命名规则为：动态视图：项目名_视图的属主_dv快照视图：项目名_视图的属主_sv由此，CRM24_liang_liu_dv就是刘量的针对本项目的动态视图。因为动态视图是通过虚拟文件系统MVFS来对元素版本进行存取操作，而这个虚拟文件系统直接指向VOB中的元素，提供透明的版本控制机制，所以使用动态视图可以看到VOB中的所有数据，因此，为了代码数据的安全性，必须控制动态视图的创建，所以在安装ClearCase的时候，可以选择只有clearcase_mng组的成员（参见4.3节）可以使用动态视图，其他成员只能使用快照视图。由于开发人员之间是平行开发的，可能会出现两个开发人员对同一个文件进行修改的情况，为了不相互干扰开发，在项目开始的时候需要定义分支策略。在本项目中，规定当每个人的视图里看到的元素都是该元素的一个特有的分支上的版本，而不是主分支上的版本。每个人在这个分支上进行自己的开发工作，当他认为自己所作的修改已经达到一个稳定的版本、可以共享给别人的时候，他就可以把自己分支上的版本合并（merge）到主分支上面去。这样，除了每个开发人员要建立一个视图看到自己分支上的版本外，还要专门建立一个用于合并的分支可以看到主分支上的版本。在本项目中，规定首先由每个技术经理或技术经理指定的人来完成该小组的合并工作，然后再交由项目经理或项目经理指定的人来完成整个项目的合并工作。创建项目环境的最后一步就是制定配置规格（config spec）,每个视图都有其对应的配置规格，只不过动态视图的配置规格中没有load规则。Load规