运转中的工具：Alcrohm GDD项目生命周期中的一天
现在，我们已经决定了任务及资产的划分，配置了工具及跨越我们假设GDD环境的过程，让我们看看各种工具是如何在一个日常的上下文环境中协同工作的。顺便说一下，我们将要描述的工作流程以及状态转换是完全可定制化的。在不同的场景中他们可能完全不同地进行工作，这取决于项目的需求。
在丹佛的 Site A 的拂晓，而在班加罗尔的 Site B 是黄昏。对Alcrohm GDD 项目从这个观点来看 ―― 在许多其他的活动中 ―― 一个对当前应用软件的被计划的维护版本在很好的运行中。将新版本加入到临近的完全产品中的工作正按照预定的日期进行。
在丹佛时间 07：00 ，Site A和Site B中的IBM Rational ClearCase 和 IBM Rational ClearQuest数据存储分别使用IBM Rational ClearCase MultiSite 以及 IBM Rational ClearQuest MultiSite进行同步。当Site A中的SCM管理员吃早饭时，他使用自己家中电脑上的浏览器通过Rational ClearCase MultiSite Administrator Web接口远程访问副本。他确认预定的复制完成时没有错误。
我们将要追踪的活动流程从业务分析开始，在Site A进行工作，输入将要得到的应用软件维护版本至IBM Rational RequisitePro中。
工作于Site A的项目经理负责维护发行，她得到一个发给她的新需求的 email 通知。为了检查这个变更的影响，项目经理检查她在IBM Rational ClearQuest中所创建的“Current Workload”图。这张图向她显示了Site B中所有开发者当前的工作量，这是从每个人当前工作的变更请求数量来看的。
再次使用Rational ClearQuest时，项目经理输入变更请求并将其分配给Site B中的一个开发者。这个新请求会出现在这个开发者下次登陆进入ClearQuest时的“to do”列表中。并且在分配这个变更请求后，它的状态会自动被更改为“Assigned”。
现在，一个新的需求已经被增加了，这对于其能够通过一个新的测试用例来测试来说是极为重要的。项目经理使用Rational RequisitePro 和IBM Rational TestManager之间的集成以在Rational TestManager中对新的需求进行访问。当她创建了新的测试用例时，这个用例会自动的被连接到需求。
维护项目的系统设计师也通过 e-mail 通知获知了新的需求。使用IBM Rational Software Modeler，设计师编辑项目模型来更新用例图以反映新的需求。首先，他检出特定文件进行更新。一旦他将新需求关联到正确的模型元素，更新便被完成，他再检入文件。RSM和IBM Rational RequisitePro之间的集成自动地维护模型元素以及需求之间的联系。为了使更新后的模型对于在两个地点中涉众能够通过网络浏览器进行访问，无论在他们的桌面上是否有Rational Software Modeler，设计师都可以使用IBM Rational Software Modeler的网页发布特性。
另一个通过 e-mail 被通知新需求的团队成员是系统架构师。从她位于丹佛的桌面，她使用IBM Rational Software Modeler以及与IBM Rational ClearCase的集成检出适当的文件。在更新这些系统架构图以及适当的序列图之后，她将这些文件检入。同时，她也使用网页发布特性以使得这些新的图对位于Site B与Site A的团队成员来说都是同等可见的。
现在，我们预测丹佛的夜晚，当然，在班加罗尔是早晨。在丹佛时间的19：00，Site A和Site B中的IBM Rational ClearCase 和 IBM Rational ClearQuest数据存储再一次使用IBM Rational ClearCase MultiSite以及 IBM Rational ClearQuest MultiSite进行同步。正如她的同事在早些时候做的那样，Site B的SCM管理员使用她的膝上电脑的网络浏览器从她家中访问副本，并检查复制是否成功。
当开发者到达Site B开始他们的工作日时，他们使用本地的Windows界面登陆IBM Rational ClearQuest以检查他们的对新变更请求任务的“to do”列表。来自Site B的远程工作开发者可以通过IBM Rational ClearQuest的基于浏览器的接口检查新任务。
被 Site A的项目经理分配新的变更请求的开发者将看到他有一个新的“高优先级”的工作条目。他首先访问更新过的用例图以及序列图来看看这个新变更是如何影响整个应用软件，以及他正在工作的组件的。和任何地点的所有团队成员一样，如果开发者需要核实正确的工作流程或是“下一步骤”，他可以通过他的网页浏览器访问RUP以检查可视化的、显示整个开发生命周期中在各个项目流程之间交互的图表。
下一步，要使用对IBM Rational RequisitePro的基于Web的接口，开发者可以查看新需求的详细内容。他为需求文档添加注释，然后创建一个讨论条目以提出一个问题。Rational RequisitePro自动追踪讨论进程，因此任何有授权的团队成员都可以很容易的看到注释以及后续的回复。
由于新的变更请求有高的优先级，并且将对他正在进行中的其它工作产生影响，开发者决定立即对其进行工作。为了确定哪一部分的代码需要进行更改，以及需要检出哪些文件，他要浏览Site A的系统设计师和架构师所做出的更新。
从他安全的个人IDE工作区，他使用IBM Rational ClearCase检出需要更新的代码，在这一天中，他做出了所需的修正。当开发者准备好时，他使用IBM Rational PurifyPlus更新单元测试。Rational PurifyPlus向他通告任何内存泄漏，确保每一行代码都被测试。一旦测试完成，他将代码检入回IBM Rational ClearCase，并且向一个集成流中交付这个更改而不需要离开他的IDE。他还更新IBM Rational ClearQuest中适当的记录以指示出他的活动状态为“resolved”，以及新代码已经为功能测试准备好。这些内建的工作流程管理特性能够帮助避免工作传递的问题。
下一次项目存储进行复制及同步时（在丹佛时间07：00），开发者的更改随着所有其他对代码库做出的修正一起发送至Site A。
Site A中的构建团队通过创建新的代码基线并使用Rational ClearCase将其提升入构建发布中以开始一天的工作。QA团队然后在新的构建上使用IBM Rational TestManager运行功能、系统以及性能测试。失败的错误导致在Rational ClearQuest中的缺陷记录创建。Rational TestManager 和 Rational ClearQuest之间的集成允许QA经理直接从Rational TestManager中输入缺陷。项目经理可以使用Rational ClearQuest将缺陷分配给Site B中的开发者。对于通过测试的缺陷，相应的变更请求记录状态被自动更新以反映出这个错误已经被修正。Site B中的开发者也可以使用Rational ClearQuest检查分配给他们的变更请求状态。
下面，构建团队使用Rational ClearCase向集成流中交付变更。新的基线与当前基线合并，然后进行比较。当到了对应用软件新版本进行部署的时候，发布工程师可以使用Rational ClearCase创建新的系统“构建”，并将其发送给测试组以在对产品环境进行配置之前进行最终确认。
同时，为了保持项目对于下一个维护版本的快速解决部署日期处于跟踪中，项目经理使用IBM Rational ProjectConsole以监控开发的所有维度，例如不同优先级缺陷的数量，重要需求的数量，以及代码改动量。这些定量的度量能够帮助确保新发布按时准备好，并且完全被测试。如果产生了可能能够危害到进度的问题，项目管理者可以预先进行在各个级别采取减小风险的措施。
许多 GDD 选择
本文中所讨论的GDD场景是各个组织今天正在使用或考虑使用的更加常规的模型。但是，它仅仅是在分布式软件和系统开发环境中使用IBM Rational工具的许多可能场景之中的一个。我们其它的客户经常使用的GDD解决方案包括模块化团队开发以及紧密连接的联合开发。在前一种情形中，分布式团队“拥有”一个或多个对应用软件的分散组件的开发工作。然后团队合作集成组件以得到最终的整个系统。紧密连接的联合开发由地理分散的不同地点团队组成，他们对相同的软件组件进行工作，这样可以得到24×7的开发周期以缩短上市时间。
从建议到部署，在分布式环境中，一些GDD模型要求软件开发工具支持整个软件或系统开发生命周期。其它的，例如模块化团队开发也许仅仅需要配置管理以及能够跨越分布式环境工作的开发工具。
