随着软件开发不断发展,敏捷开发模式越来越为更多的开发团队所采用。IBM 最近两年推出的 Rational
Team Concert 是一款适合多种开发模式,尤其是敏捷开发模式的软件开发管理软件。该产品有诸多优点,它可以在同一平台实现需求管理,软件开发管理和代码管理等多项管理任务。而对于那些长期使用
Rational ClearCase 和 Rational ClearQuest 做为配置变更管理解决方案的企业来说,成功的关键在于如何将现有的
Rational 软件交付平台与 Rational Team Concert 无缝集成,从而实现高效的团队协作开发管理。
Rational Team Concert 的最新版本 2.0 里面通过增加 ClearQuest
Bridge 组件,引入了一种新的 Rational Team Concert 与 ClearQuest
轻量级无缝集成的方式。该组件以链接的方式将 Rational Team Concert 里面的工作项与
ClearQuest 里面的变更记录连接起来,帮助客户在同一平台上进行企业级变更管理,以及实现敏捷开发计划的制定,和项目状态追踪。而因为不需要进行繁杂的数据同步操作,集成的部署、配置与维护工作也十分轻松。这样方便、快捷又强大的功能非常适合敏捷开发模式。
本文首先简单介绍了 Rational Team Concert 及其功能部件 ClearQuest
bridge。然后阐述了基于 ClearQuest Bridge 的敏捷开发生命周期管理解决方案。最后介绍了
ClearQuest Bridge 的部署和配置。
Rational Team Concert 是一个可是满足需求管理、开发管理、变更管理等多项需求的软件开发管理产品。自动化的数据收集和报告降低了管理开销并提供了高效管控软件项目所需的实时洞察。动态项目管理支持更高的生产力,同时实时协作帮助极大地减少浪费和返工。Rational
Team Concert 通过集成的工作项、构建、软件配置管理(SCM)和协作的 Jazz Team Server
基础设施扩展团队的能力。
Rational ClearQuest 是一款经典的,已经被广大客户所接受的变更管理工具。目前已经被多家企业部署在企业环境中,用作项目流程管理,变更管理。由于其高度的可定制化,不少企业已经按照其自身发展的需要,定制了想关的流程管理规约。
如果能将这两款功能强大的产品结合起来使用,就可以满足更多新老客户的需求。对于只使用过 ClearQuest
的老客户来说,他们希望引进 RTC 这款功能强大的新型管理软件。但是他们会担心数据“转移”的问题。因为他们可能已经对
ClearQuest 做了许多的定制工作,如果想要将这些被定制的数据转移到另外一个软件中去,一定是非常复杂、繁琐,并且具有很大的风险。而对于只使用过
RTC 的用户来说,要引进强大的 ClearQuest 也存在类似的问题。对于这两类用户来说,急需一个产品或者部件来实现
RTC 和 CQ 的简单无缝集成。Rational Team Concert 2.0 中 ClearQuest
Bridge 就实现了这一的功能。
为了叙述方便,本文使用了表 1 所示的缩写,并且如不特别提示,指代表 1 中相应的版本。
表 1. 缩写及版本号表
缩写 |
全称 |
版本号(本文中默认使用的版本号) |
RTC |
IBM Rational Team Concert |
2.0 |
CQ |
IBM Rational ClearQuest |
7.1 |
RQM |
IBM Rational Quality Manager |
2.0 |
CQ Bridge |
IBM Rational Team Concert ClearQuest Bridge |
|
CQ Bridge
在 RTC 2.0 版本中,提供了一个新的工具,CQ Bridge,实现了 RTC 和 CQ 之间的简单无缝集成。该工具最突出的功能就是以链接的方式将
RTC 记录与 CQ 记录单间的关联起来。比如需求和变更都存储在 CQ 里面,而项目故事、工作内容都存储在
RTC 里面。那么可以通过 CQ Bridge 链接,将需求和项目故事连接起来,表示项目故事实现需求。通过
CQ Bridge 链接,将工作内容和变更链接起来,表示工作内容具体实现了变更。这些链接意义可根据实际的企业或者项目需求来定义。图
1 以简单示意图的形式描述了 RTC 记录与 CQ 记录之间的关联方式。
图 1. RTC 记录与 CQ 记录的关联方式
CQ Bridge 下链接方式的集成,是基于 Jazz 的产品所特有的一种集成方式。它通过简单的配置,可以在
RTC 的客户端同时操控来自 RTC 和 CQ 的实时记录,并且将两者关联起来。这种新一代的集成方式,能够带来诸多好处:
- 减少时间和网路数据传输上的损耗 : 不再依赖于数据的同步,因此用户访问到的数据,都将是实时数据。
- 降低管理员的维护成本 : 由于管理员在配置的时候,仅需要在 RTC 服务器端打开相关的功能,并不需要对
CQ 的模式进行任何修改,订制,也不需要订制相关的记录同步规则。因此对于管理员来说,降低了维护的成本。
- 更易管理的数据池 : 在 RTC-CQ Bridge 方式下,数据仅仅保存在 CQ 的数据库以及
RTC 的数据库中,没有中间同步的步骤。数据备份,数据管理起来更加简单。
- 整合用户终端,降低培训成本 : 用户如果已经熟悉 RTC 和 CQ Web 客户端,那么对于这个桥接的使用,将会十分容易上手。另外在新的界面中,由于整合了
CQ Web 客户端的绝大部分功能。因此用户无需来回切换客户端,就可以完成相关记录的提交,修改,关联操作。
前面的章节介绍了 CQ Bridge 的安装配置,本章节将详细介绍 CQ Bridge 的功能。CQ
Bridge 的功能包含以下三项:
- CQ Records 页:该页面类似于 CQ Web 客户端,实现了大部分 CQ Web 客户端的功能,另外包含
CQ Bridge 的功能。详细请参见
CQ Records 页。
- 创建链接、显示链接:即创建和显示 RTC 记录与 CQ 记录之间的链接。详细请参见
链接的创建和显示。
- CQ Viewlet:RTC Dashboard 中包含四种 CQ Viewlet,这些 Viewlet
为用户提供了管理项目、查询当前状态的轻便视图。详细请参见
CQ Viewlet。
CQ
Records 页
在 RTC 2.0 版本中,经过适当的配置(请参见
部署 RTC,配置 CQ Bridge 章节),RTC 的 Web 客户端就有一个 CQ Records
页,如图 2 所示。
图 2. CQ Records 页(查看大图)
由图中可以看到,这个页面共分为 5 个区域,其中查询区、记录创建区、工具栏和显示区与 CQ Web 客户端是非常类似的。实际上,RTC
在这个页面下实现了大部分 CQ Web 客户端的功能,包括创建记录、查询记录、修改记录等操作。更重要的是,RTC
将这个页面嵌入到 RTC 的 Web 客户端,使得 RTC 与 CQ 之间的切换非常方便直接。
而链接创建、显示区是专门为 CQ Bridge 设置的。在这个区域,用户可以创建 CQ 记录与 RTC
工作项目之间的链接,并且所建链接会被显示在这个区域。关于如何创建链接及其显示方式我们在下面的章节中会提到。
链接的创建和显示
可以通过 CQ Record 页的记录来创建链接。下面是具体创建步骤。
- 登陆到 RTC 的客户端。
- 打开 CQ Record Tab 页,连接一个 CQ 数据库。
- 打开一个已有的记录。在链接创建、显示区,点击向下的箭头,会出现如图 3 的结果。这里有两项,一个是链接到工作项目,即在当前
CQ 记录与已有的某 RTC 记录之间创建链接;另外一个是创建工作项目,即从当前 CQ 创建一个新的
RTC 工作项目并将建立二者之间的链接。
图 3. 创建链接
- 如果选择链接到工作项目,则出现如图 4 的界面。
图 4. 链接到工作项目
选择一条查询结果,点击 OK 键即可创建链接。
- 如果选择创建新工作项目,则会出现如图 5 所示的界面。
图 5. 创建新工作项目
注意到在创建工作项目之前,需要选择创建的类型。在选择类型之后,界面会自动跳转到 RTC 的工作项目页,并且会显示一个需要新创建的记录(类型是之前选择的)。用户根据自己的需求填写相应的域即可。创建该工作项目之时,它与之前的
CQ 记录之间的链接也会被自动创建。
链接会同时在 RTC 记录和 CQ 记录里面显示 .。图 6 给出了 CQ 记录中显示的链接信息,即被连接的
RTC 记录信息。
图 6. CQ 记录中的链接显示 -RTC 记录信息
另外,在 RTC 的工作项目中,有一个链接页,被连接的 CQ 记录也会被显示在其中。如图 7 所示。
图 7. 工作项目中的链接显示 -CQ 记录信息
我们注意到,链接信息是已超链接形式显示的。点击链接信息,Web 页面会自动在 RTC 和 CQ 页面间切换,非常方便。
其实从工作项目到 CQ 记录的渠道还有更多,下面我们将要介绍通过 RTC 的 Dashboard 中的
CQ Viewlet 的功能。
CQ
Viewlet
在 RTC 中,Dashboard 是一个非常重要的功能。在 Dashboard 中,用户可以通过 Viewlet
以表格或者图形的方式来显示当前工作项目的状态。本节将要介绍 CQ Viewlet。
首先创建 CQ Viewlet。创建界面如图 8 所示。
图 8. 创建 CQ Viewlet
从图中可以看到,总共有四种 CQ Viewlet:
- Favorite Viewlet:显示 CQ 中的 favorite。
- Query Viewlet:显示相应 CQ query 的查询结果。
- Startup Query Viewlet:显示 CQ 中 Startup Query 的查询结果。
- Work Items with CQ Records Viewlet:显示某个 RTC 查询结果并且可以选择是否显示没有连接到
CQ 记录的工作项目。
下面分别介绍这四个 Viewlet。
首先来看 Favorite Viewlet。在没有连接到任何 CQ DB 之前,该 Viewlet 显示如图
9 所示。用户可以通过点击登录按钮登录到 CQ DB。
图 9. 未连接 CQ DB 的 Favorite Viewlet 显示内容
连接到一个 CQ DB 之后,该 Viewlet 显示 CQ Favorite 的内容。如图 10 所示,该
Viewlet 的结果与 CQ 中 Favorite 的结果是一致的。
图 10. Favorite Viewlet 与 CQ Favorite
内容比较
接下介绍 Query Viewlet。该 Viewlet 显示一个 CQ Query 的查询结果。在
Query 没有选定之前,Viewlet 显示如图 11 所示。Viewlet 中有提示信息提示用户需要选择一个
Query。
图 11. 未选择 Query 时 Query Viewlet 的显示
选择修改 Viewlet,会出现对话框供用户选择 Query,其中列出了所有的可以选择的 Query,包括用户私有的以及公共的。选择了
Query 之后,该 Query 的结果集就会被列出来。如图 12 所示。
图 12. Query Viewlet 显示内容
如果 CQ 中没有指定任何 Startup Query,则 Startup Query Viewlet
就提示说没有指定任何 Startup Query。如果有 Startup Query,则该 Viewlet
就显示该 Query 的查询结果。
Work Items with CQ Records Viewlet 则显示某个 RTC 查询结果并且可以选择是否显示没有连接到
CQ 记录的工作项目。所以首先要选择一个 RTC 查询。选择了查询之后,显示结果如图 13 所示。
图 13. Work Items with CQ Records Viewlet
显示结果
不难注意到,所有的被连接到某个 RTC 工作项目的 CQ 记录都被当作子条目显示出来。
通过前面的介绍和截图我们看到,所有 Viewlet 的显示结果都是超链接格式的。点击某个结果,相应的详细信息就会被显示出来。比如在
Favorite Viewlet 里面,点击某个查询或者记录,界面会跳转到 CQ Records 页,查询会被执行并且查询结果会显示出来,记录则会自动显示出来。别的
Viewlet 也具有相同的功能。这里不再赘述。
通过前面介绍的 CQ Bridge 的功能及其优势,我们看到 CQ Bridge 通过轻量级链接的方式将
RTC 工作项与 CQ 变更记录连接起来,从而实现 Rational ClearQuest 交付平台与
Rational Team Concert 之间的无缝集成。
基于这种无缝集成方式,本文推出了一个集需求管理、敏捷开发管理、变更管理与测试管理于一体的解决方案。该方案将帮助客户在统一平台上实现企业级需求管理、敏捷开发管理、变更管理、以及测试管理,从而实现高效的团队协作开发管理。因为不需要进行繁杂的数据同步操作,集成的部署、配置与维护工作也十分轻松,该方案方便、快捷又强大,非常适合敏捷开发模式。我们称之为敏捷开发生命周期管理解决方案。
该方案涉及到四个产品和组件,RTC、CQ Bridge、CQ 和 RQM。RQM 是 IBM 新推出的基于
Jazz 平台的测试管理软件,关于 RQM 的基本概念和使用,请参见
RQM Infocenter。
开发生命周期中的记录及其关系
在敏捷开发模式下,一般在每个开发阶段,开发人员从需求入手开发产品;接下来测试人员测试产品并提出变更;开发人员就测试人员提出的变更来再次开发;如此循环直至所开发产品达到了需求。在这个开发生命周期里,出现了表
2 所列出来的记录类型。
表 2. 敏捷开发生命周期中的记录类型
记录类型 |
作用 |
所属管理类型 |
需求 |
描述了客户的需求。 |
需求管理 |
发布计划描述了产品某个版本的发布计划阶段计划描述了某个开发阶段的计划故事更细致精确的描述了客户的需求。工作项目开发人员、测试人员需要完成的工作。工作项目有以下三种类型:对故事的再次细分,这类工作项目需要开发人员完成。测试工作项目,这类工作项目需要测试人员完成。变更相关,这类工作项目是开发人员解决测试人员提出的变更。
|
开发管理 |
测试计划针对需求所制定的测试计划测试用例结合测试计划,针对需求所制定的测试用例测试记录、结果实际测试的记录、结果。
|
测试管理 |
变更 |
测试人员在测试过程中发现的问题,以变更的形式提交给开发人员 |
变更管理 |
我们知道,CQ 可以实现需求和变更管理,RTC 可以实现开发管理,而 RQM 可实现测试管理。另外,开发生命周期中的各个记录是有一定的关系的。比如故事满足了需求,测试计划覆盖了需求,测试用例则验证了需求,测试结果据测试用例生成,测试用例发现变更,变更又被工作项目解决,工作项目驱动一切实际开发、测试行为。图
14 以更直观详细地描述了这些记录之间的关系。
图 14. 记录之间的关系
解决方案
从前面的介绍可以看到,在敏捷开发生命周期里,CQ 可以负责需求和变更管理,RTC 可以负责开发管理,而
RQM 则可负责测试管理。这三个产品完全覆盖了敏捷开发生命周期的所有管理需求,而他们之间的关联就是通过
CQ Bridge 建立起来的。
那么,现在我们的解决方案就呼之欲出了。在生命周期初期,需要对需求进行管理;接下来开发人员针对需求进行开发,这时需要开发管理;然后测试人员加入进来进行测试,就需要测试管理;因为测试人员会根据测试结果提交变更,那么就需要变更管理;同时,开发人员需要解决变更,此时则需要开发管理。图
15 描述了生命周期各个阶段需要的管理内容。
图 15. 敏捷开发生命周期管理方案
现在解决方案出来了,那么在这个方案中,在每个阶段具体可以做些什么事情呢?下面就来细化这个方案。
在开发生命周期里,当需求被创建以后,相关人员就会开始创建发布计划,并且在创建过程中需要对需求进行修改或者细化。在敏捷开发模式中,需求是按阶段来实现的。所以在创建了发布计划之后,紧接着要创建阶段计划。阶段计划规定了某个开发阶段需要实现的功能,但是这些规定还是比较粗略的,可能只是一两句话概括一个功能部件。阶段计划需要故事来支撑,故事则相对详细的规定了目标。在有了故事之后,测试人员就可以开始创建相应的测试计划以及测试用例,开发人员则可以基于故事来细化工作。在经过一定时间的开发之后,开发人员会推出一些测试版本供测试人员测试。测试人员根据测试计划和测试用例进行测试,并提交变更。开发人员在收到变更之后就会根据实际情况做出反应,或拒绝变更,或立即解决变更,或推迟解决变更,或采取各个团队自己的处理方式。
上面我们大概解说了敏捷开发生命周期里需要做的工作。下面以图形的方式来更明朗的说明。图 16 给出了敏捷开发生命周期里各个阶段的具体工作。
图 16. 敏捷开发生命周期各阶段具体工作
一个客户用例
前面介绍了敏捷开发生命周期管理解决方案,本节将把这个方案运用到一个客户用例中去。
客户用例背景如下。客户产品 Prod_A 的版本 1.0 已经发布,正准备开发版本 1.5。在新版本
1.5 中需要做两件事情,一是解决版本 1.0 遗留下来的变更,二是实现新的需求。版本 1.0 的变更是用
CQ 来管理的。客户想在新的开发过程中引入 RTC 进行开发管理,以及 RQM 进行测试管理。客户的开发模式是敏捷开发。客户团队由表
3 中的成员组成。
表 3. 客户团队成员及其角色
姓名 |
角色 |
责任 |
Alex |
产品经理 |
提交并细化需求 |
Helen |
开发经理 |
创建发布计划、阶段计划以及故事 |
Mark |
开发队长 |
给开发人员创建工作开发工作项目
开发工作
创建测试版本 |
Joy |
开发人员 |
开发 |
Carmen |
测试队长 |
创建测试计划和测试用例
测试
提及变更 |
Tony |
测试人员 |
测试
提及变更 |
根据上面介绍的解决方案以及该客户的实际需要,很容易将上述解决方案运用到该客户环境中。在这个方案中,产品经理
Alex 负责创建需求并提供详细的需求信息。开发经理负责创建覆盖需求的发布计划以及阶段计划,另外,开发经理也负责开发过程的管理,即分配任务给开发和测试人员。开发人员负责开发并发布产品。测试人员负责创建测试计划、测试用例、测试产品并提交变更。图
17 以图形的形式更直观的描述了该解决方案下各个成员的责任。
图 17. 敏捷生命周期管理的一个实例
本节中只是假设了一种客户场景,用户可根据自己的需要和已有资源进行流程、角色以及责任设置。另外,这里只是着重介绍了具有
CQ 使用背景的用户场景。对于那些以前没有使用过 CQ 的用户来,可以直接使用 RTC 和 CQ 并且可以做集成,即也可以使用
CQ Bridge。
本章将介绍如何部署、安装和配置 CQ Bridge。首先来看部署拓扑结构。
RTC 与 CQ
集成环境拓扑结构
RTC 和 CQ 分别需要一台服务器和一台数据库服务器,CQ 需要一台 License 管理服务器。另外,为了方便的统一管理,可搭建一台
LDAP 服务器以进行用户统一管理。在这些资源的基础上就可以搭建 RTC 与 CQ 的集成环境了。图 18
给出了这个环境的拓扑结构。
图 18. RTC 与 CQ 7.1 集成环境拓扑结构
关于该拓扑结构图有两点需要注意。其一是图中的 CQ 服务器上应该至少安装 CQ Web 服务器;其二是图中将
RTC 和 CQ 指向了同一个数据库服务器,这只是为了方便起见,并不表示 RTC 和 CQ 使用同一个数据库。实际上,他们所使用的数据库是相互独立的。
部署拓扑结构图有了,接下来的工作就是要安装和配置。本文主要讲如何安装配置 CQ Bridge,关于
CQ 的相关信息,请参见
CQ 7.1 Inforcenter。
CQ Bridge
安装和配置
目前,CQ Bridge 是作为 RTC 的组件发布的,所以安装 CQ Bridge 也就是安装 RTC。至于
RTC 的安装配置,请参见
RTC 2.0 Inforcenter。
在正确安装配置 RTC 之后,打开 RTC 服务器的 Admin 页面,通过下面几个简单的配置,即可通过
CQ Bridge 集成 RTC 和 CQ。
通过 https://<JazzServer>::9443/jazz/admin(JazzServer
代表 Jazz 服务器名或者服务器 ip,比如 localhost;9443 是 Jazz 服务的默认端口,可修改)打开
Admin 页面,选择 Configuration > Advanced Properties,找到
CQ Bridge 这段,如图 19 所示。
图 19. CQ Bridge 配置
从图中可以看到,有几个属性需要配置:
CQ Schema Repository:即 CQ schema DB,可指定,也可为空。如果指定,应填写
CQ Web 服务器上配置的某个 CQ schema DB 名字,比如 DefectTrack。这种情况下从
RTC Web 客户端登陆 CQ 时不可选择 schema DB,否则可选。默认为空。
CQ User Database:即 CQ User DB,可指定,也可为空。如果 CQ Schema
Repository 项未指定,则本项值被忽略。如果 CQ Schema Repository 项被指定,本项可以填写连接到所填写
schema DB 的 user DB,比如 SAMPL。这种设置下,从 RTC Web 客户端登陆 CQ
时 user DB 被指定,即不可选。如果本项为空,登陆时可选择 user DB。默认为空。
CQ Web remote server:CQ Web 服务器地址或服务器名,比如 localhost。默认为
localhost。
HTTP Port::CQ Web 服务器的 HTTP。默认为 80。
HTTPS Port:CQ Web 服务器的 HTTPS 端口。默认为 443。
Enable CQ Bridge Webui:启动、关闭 CQ Bridge 选项。默认值是 False。如果选择
False, 则在 RTC 的 Web 界面上看不到 ClearQuest Recordst 页。选择
True,则 RTC Web 界面如图 20 所示。
另外还需要设置一个元素,Advanced Properties -> Core Repository
Component -> com.ibm.team.repository.servlet.internal.ServletConfigurationService
-> Host Name,将该变量设为 Jazz 服务器的名字。
图 20. 配置了 CQ Bridge 之后的 RTC 界面
Is Full Text search enabled:是否打开 CQ 中的全文检索。默认值是 False。
SSL enabled on CQ Web remote server:非本地 CQ Web 服务器是否使用了
SSL 加密。默认值是 False。
CQ Bridge 实现了 RTC 和 CQ 的集成,并以链接的形式将 RTC 和 CQ 的记录关联起来。相比
RTC CQ Connector,他有诸多优点,包括:
- 集成配置简单,在本文的
部署 RTC,配置 CQ Bridge 章节,我们详细介绍了如何安装配置 RTC 以及 CQ
Bridge,这个过程是非常简单的。而 RTC CQ Connector 的配置是非常复杂的。具体请参见
RTC 2.0 Inforcenter。
- 数据管理和维护简单。在 CQ Bridge 方式下,关联 RTC 和 CQ 的记录所额外需要的数据只是关联信息,他并不需要在
RTC 和 CQ 之间同步数据。
- 统一的终端。在本文
CQ Bridge 功能简介 章节我们看到,在 CQ Bridge 方式下,CQ 的 Web
端作为一个 tab 页被嵌入到 RTC 的 Wed 端。这大大方便了用户,无需在两个客户端切换。
但是,上述所有优点只是功能上的,CQ Bridge 最大的优势其实在于他使得集需求管理、开发管理、变更管理和测试管理于一体的敏捷开发生命周期解决方案称为可能。本文在
敏捷开发生命周期管理解决方案
部分详细介绍了这一解决方案,并在假设的用户场景下介绍了实际应用情况。
本文档是作者在实际工作中总结的经验,仅仅代表个人观点,请以参考及怀疑的观点阅读。任何由此造成的损失,作者不承担责任。谢谢!
学习
获得产品和技术
讨论
|