没有合适的资源?快使用搜索试试~ 我知道了~
使用 Rational RequisitePro 和 Rational ClearCase 对需求工件进行版本化和并行开发
需积分: 9 108 下载量 171 浏览量
2008-04-04
15:50:31
上传
评论
收藏 520KB DOC 举报
温馨提示
试读
17页
使用 Rational RequisitePro 和 Rational ClearCase 对需求工件进行版本化和并行开发
资源推荐
资源详情
资源评论
使用 Rational RequisitePro 和 Rational ClearCase
对需求工件进行版本化和并行开发
http://www.ibm.com/developerworks/cn/rational/rationaledge/content/
jun05/john/#main
如果你正在使用 Rational
®
RequisitePro
®
中的基于文档的需求,并且你已经在你的
公司里成功地实施了 Rational Uni"ed Process
®
和 Rational 工具,那么你就已经有了一
个“团队组的团队”如何学会在 RUP 的工作流程之下一起工作的第一手经验。当我们的几个
项目经理自告奋勇地按照一个方案,通过并 行的、非重叠的迭代来缩短开发时间,并且更
好地利用他们的开发资源时,我们就处于这个阶段了。他们不断地问,“为什么我们要在分
析师编写用例时让开发人员 无所事事,并且在开发人员编写代码时让分析师无所事事
呢?”这听起来的确像一个合理的问题。但是对于并行地开发需求,还有其它的,甚至更引
人关注的争论。
首先,如果有多个分析师,他们必须对相同的需求工件,或者是相同的迭代和项目中
的,或者是不同的迭代和项目中的,更新些什么吗?在我 们的集成系统中,这个场景是有
可能的。另外,我们经过了创建所有新的用例的阶段,并且已经在 Rational
RequisitePro 中不断开发出用例集和相关的工件。我们如何为了下一个发布包,处理这些
已有工件的变更?
当我们考虑整个变更管理流程以及其如何影响我们已有的业务建模和需求工件集时,我们
看到了几个相互冲突的要求:
我们已经知道,我们需要对我们在 RequisitePro 中已有的用例和相关工件进行变
更,并让业务经理、测试人员和开发人员对他们进行评审--并最终被批准。
尽管我们知道我们想进行的一些变更,但是由于在用例讨论和评审过程中出现的需
求易变性,我们也想延迟直接地编辑现有的用例和相关工件。对需求的变更影响到
已有的标记和追踪,并且我们想要确定我们的变更在我们开始编辑之前是稳定的。
我们想要延迟的另一个原因是已有的用例和相关工件表示的是当前的产品发布版本,
因此我们想要每个人都能访问他们。我们知道如果在生产过程中发现需求缺陷的话,
我们以后可能不得不修改他们。
认识到这些需求都是相互关联的,并且我们将必须找到对他们全部作出响应的方法,我们
要接受这些挑战。我们决定不只是指出如何版本化我们的需求工件,而且还有如何并行地
开发需求工件。
你可能会问,为什么是“需求工件”而不是“需求”呢?Rational RequisitePro 有能力指出你
正在查看一个需求的哪一个版本吗,是通过属性吗?需求可以存在于相同用例的不同级别
中吗?
这两个问题都问得很好。但是坦率地说,我知道从开始,我不想在需求级别进行版本化。
我总是将一个用例认为是一个完整的需求工件,类似于一个组件。相反,我的本能告诉我,
要注意已经有多年并行开发代码经验的编程人员,并以他们为榜样。如果需求通过配置管
理工具和技术来进行管理,我们所发现的就有益于开发组织。
程序人员了解什么是:串行和并行开发
如果你现在或曾经是一个程序员,那么你就已经熟悉串行和并行开发的概念了。串行开发
在开发一个单独的软件发布版本,并且同时只有一个人工作在一个特定文件上时出现。在
软件维护期间修复的缺陷被包含在下一个发布版本中。并行开发在多个个人或团队工作在
不同的发布版本,并对同时对相同的文件进行修改时产生。并行进行的修改随后和维护时
修复的缺陷合并在一起。
®
ClearCase
®
通过支持分支 和 合并管理并行开发的复杂性。
用简单的语言来说,一个分支是一个线性的版本序列。合并是一种技术,通过合并,一个
文件的不同版本被协调和合并在一起,产生文件的一个新版本(参见图 1)。在
ClearCase 中,有一个 di%/merge 工具,其并排显示两个文件,高亮显示差异,并允许
一个开发人员选择哪些变化将被合并到文件的新版本中。
图 1:Rational ClearCase 带有合并的版本树
一个串行例子
现在,我们已经理解了分支和合并的概念,我们可以将他们应用于 Rational
RequisitePro 中的需求工件。比方说,我们的软件的发布版本 5 处于开发中,我们的项目
经理正在计划开发发布版本 6 的迭代。在发布版本 6 中的新功 能将需要对 Create Lead
用例进行变更。为了使讨论简单化,我们将限制我们的场景为此用例的串行开发,并且紧
记在一个实际的开发周期中,我们将必须作出如何管理所有相关工件变更的决策。
基线化用例
当发布版本 6 正式开始时,我们想要进行的第一件事情就是确保 Create Lead 用例已经被
基线化了。依照 RUP,一个基线是项目存储库中某个时间的每一个工件的一个版本的“快
照”。一个基线化的用例表示的是与当前在开发的代码协调一致的需求。
1
它提供了一个正
式的标准,后续的工作就是基于它进行的,并且只有经过审核的变更才能修改它。一旦我
们基线化了我们的用例,我们就可以继续修改它,我们知道这是安全的,因为我们有一个
已存档的原始需求的副本。
要基线化 Create Lead 用例,我们使用我们的一个 Rational 顾问用 Visual Basic 编写的
存档工具。这个存档工具使用 Rational RequisitePro 和 ClearCase COM APIs(组件对
象模型应用程序接口),其提供的功能可以将我们的 RequisitePro 的一些文档存档到
ClearCase 视图中的一个目录下,并且 在它们被加入到视图时可以将标签应用到存档后
的文件上。这些 ClearCase 存档视图允许分析师访问存档后的文件所存放的 ClearCase
的目录结 构。
准备一个用于存档的工件
在我们进入到存档工具之前,必须要在 Rational RequisitePro 中做一些事情以准备要存
档的文档。在 Project Properties 菜单中,我们取消“Save documents in
RequisitePro Format”复选框,这样可以阻止 RequisitePro 中的文档在 RequisitePro
之外被成功地打开(参见图 2)。我们想要将 Create Lead 用例的存档副本用 Microsoft
Word 格式进行存储,因此它可以在任何时候都被检出和查看。在存档工具运行起来之后,
我们应该重新设置 Project Properties,重新选中“Save documents in RequisitePro
Format”复选框。这样做失败的话将会导致 RequisitePro 中的文档的损坏。因此我们鼓
励我们的分析师创建他们自己的存档活动的检查单,以确保此步骤不会被忘掉。(可能此
存档工具以后的版本将会通过 RequisitePro API 来做这件事情。)
图 2:在存档后,记住重新选中“Save documents in RequisitePro Format”复选框
存档 Create Lead Use Case 用例
下一步是启动存档工具的可执行程序,我们可以通过桌面上的一个快捷方式进行。图 3 显
示了在启动存档工具程序后立刻出现的画面。
剩余16页未读,继续阅读
资源评论
zhang_yan_223
- 粉丝: 0
- 资源: 2
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功