UML软件工程组织

分布式异地开发是一种能够使业务在位于不同地区、国家或时区的项目团队之间进行合作的软件开发模式。本文通过一个普通的场景举例说明了GDD 模式是如何在 24 小时周期中运行，这使得假定在印度班加罗尔和美国丹佛的团队协同工作成为一体。

分布式异地开发（GDD）是一种快速的 IT 策略转换以及横跨或大或小的企业之间软件和系统的开发过程。GDD 包括广泛多样的场景，其中，与软件和系统开发项目有关的人员被扩展至超越常规的单一建筑物或校园环境。典型的 GDD 场景包括分布在不同地理位置的公司――全市范围的、地区的、全国的以及国际间的――同样包括合作伙伴关系以及各种外包关系。成功的 GDD 允许团队以更快的速度、更低的成本开发高质量的软件及系统，并能够得到增强的业务灵活性以及更强的处理全球化竞争压力的能力。

然而，认识到这些竞争优势的挑战是十分重要的。这其中主要的是需要在由防火墙、距离、时区、国界线、语言及文化－－或是上述所有因素所带来的障碍之间进行准确而清晰的通信。由于管理所有软件开发生命周期多个纬度的需要，在一个分布式环境中通过一个可重复的过程，同时维护有效的安全性，这些问题被进一步地合并在一起－－例如软件需求、变更及资产、测试、编码等等。

本文第一部分介绍了GDD以及其业务需求，并展示了 IBM 软件开发平台是如何能够对一个成功的 GDD 策略提供支持得。第一部分同时还论述了核心战略的考虑，例如什么样的项目最适合于一个 GDD 解决方案。

现在，在第二部分，我用一个示例场景举例展示了关于应用 IBM Rational 工具以支持 GDD 的一些可能性。

GDD 的布局基础
正如我在第一部分所讨论的，团队跨越时间以及空间的分布给整个软件和系统开发的周期内带来了挑战并增加了复杂性。而比协同位置团队（也就是，位于下一层或附件建筑物中的团队）的 GDD 场景更大复杂的问题是标准、方法、过程以及最佳实践的实现；组合管理；有效的需求管理；高效的知识及工作传递方法；以及健壮的软件变更管理。日益明显地，开发组织正在转向使用软件工具来帮助他们进行标准化并指导他们的过程，提高团队的协作；考虑到 GDD 场景的复杂性，这些工具的潜在价值就更加重要了。

每个 GDD 项目中都包含着独特的业务以及涉众需求。这些需求依次定义了工作目标以及子任务职责所处的工作模式。例如，对于一个新系统项目而言，你在GDD环境中所选择的管理需求变更的方法，与关联于第三方的遗留维护合同的管理需求变更方的法将有很大的不同。这就是为什么GDD工具的实施不同于“一种尺寸适合所有需求”的解决方式。为了最优化地支持不同的业务需求，定制产品下层基础平台以及灵活的集成相关工作是必须的，因此GDD场景的支持工具需要是可配置的。

但是虽然每个GDD项目是不同的，仍然存在着一些公共的部分。在许多GDD场景中，同时关联着本地以及远程开发资源。那些在本地能够最有效运行的规则以及任务有着高度的“面向客户”的活动，例如业务建模、需求定义以及可配置性。而能够高效地在远程执行的工作包括代码开发及测试－－规则主要与开发团队相关而不是应用客户。本地以及远程站点也许都需要他们自己的测试或集成以及变更管理规划。同时虽然总体的项目管理责任处于本地级别，但某些级别的项目管理也许场需要在远程进行。

网络性能以及服务器基础结构也在很大程度上决定了是否能够良好的对一个GDD项目进行组织。GDD项目经理需要考虑：

远程站点对数据库服务器的维护、数据存储复制以及类似工作的需求及能力。
远程用户范围，例如在分开地点的小团队或是在家工作的个体开发者将需要建立、显示、更改以及删除各种不同的项目资产，从需求文档到用例模型，从代码到测试计划。
远程站点及用户使用“瘦客户端”的潜力，例如 Citrix、Windows Terminal Server（WTS），或是网络客户端。精简客户端可以给分布式团队更大的灵活性及可移动性，但是也许不能支持工具所有的本地接口特性。

另外，例如网络拓扑以及安全策略会进一步使得配置及开发GDD工具变得更复杂。业务需求及基础结构性能将联合起来帮助对一个特定的GDD环境进行最优化的工具配置。

一个GDD场景
在这里所描述的GDD配置场景举例说明了今天 IBM Rational 工具对分布式团队支持方法中的一种。我们假定的用户是 Alcrohm 公司，一个财富1000 强的铝合金供应商。

问题中的项目包括对一个企业级用户应用软件的正在进行中的维护以及重要的特性增强。关键任务应用是统一用于销售的客户关系管理系统、建议系统和合同管理能力，以及支持 Alcrohm 的所有三个部门（工业产品、客户包装以及自动化部分）中的团队。当前的版本是由一个大部分由C++编写的用户界面的传统桌面型客户/服务器应用软件。Alcrohm不得不在短期时间内继续维护代码。但是，与维护工作相比，Alcrohm计划实现一个新的应用软件版本，这个版本能够通过标准网络浏览器访问，加上Java语言的服务器端代码以及业务逻辑。这个新版本的开发将能够更有效的进行配置以及管理，因为它能够减小客户端安装以及升级的需要。它还将能够与Alcrohm跨越整体IT基础结构的包括面向服务的体系架构（SOA）的长期目标更好地进行吻合。

这个项目使用每天24小时、每周7天（7×24）的分布式开发模型，包括两个独立的地理场所：位于美国科罗拉多州丹佛的 Alcrohm 中央办公现场内；以及位于印度班加罗尔的海外开发中心。我们称现场的场所为“Site A”，非现场的场所为“Site B”。

这种GDD场景为 Alcrohm 提供成本以及时间计划上的优势，例如可变化的人员安排、减小国外劳动率，并通过保持项目能够通过“昼夜不停”（也就是说，当位于东半球的开发团队在家或睡觉时，西半球的开发团队是在办公室中工作的）的运作以减小上市时间。但是这些优点的出现同时也增加了风险。这个项目有着很重大的技术困难，这些难题也会检验协同位置的团队有效协作、理解需求、交付高质量成果的能力。Alcrohm 选择了来自 IBM Rational 的强壮的、集成的软件工具以解决这些问题，并支持成功的成果。

建立任务
Site A 的室内开发团队集中于新特性开发和相关的测试，同时也包括构建/部署。Site B 的远程转包商承担维护开发、对现存的客户/服务器应用软件进行单元测试任务。这个高层次的职责分解对于什么角色、任务以及最终工具将在每个地点如何运行具有关键的影响。

在 Site A 执行的任务包括：

捕获需求、创建需求文档和管理需求
系统构架及建模
业务分析及高层次系统设计
新特性开发
对预发布的新应用软件的构造进行组件、功能以及系统测试
对当前应用软件版本的维护版本进行功能及系统测试
所有构造以及部署活动
项目和组合管理

在 Site B 执行的任务包括：

对当前客户/服务器版本的应用软件代码进行维护
对代码维护过程中所修正代码的组件进行单元测试
对维护阶段项目进行构造及修正需求

在进行了成功的单元测试后是在Site B开发下面维护版本的运行，Site B将代码发送给Site A，Site A执行确认、功能以及系统测试。项目规约以及与现有应用软件的维护版本有关的需求变更、模型和图表在Site A及Site B之间进行通信。项目管理是在Site A处理的核心能力，所有Alcrohm应用软件的组件以及资源组合都在这里进行监控。

这些强有力的任务划分允许Alcrohm以相对低的风险得到GDD的常规经验，特别是其非现场的合作伙伴。如果所有这些在次一级项目中都进行的很顺利，Alcrohm也许在未来会选择利用其它分布式开发模型，例如新特性组件开发。

确定资产位置及访问
现在让我们来看什么资产是在两个站点都需要的。Alcrohm的关键目标是能够在两个站点间引用资产。哪些工具要被使用以及他们如何进行配置将很大程度上取决于关键的开发资产在哪里创建以及他们又将在哪里被使用。

对两种版本应用软件的需求在Site A被本地的捕获。Site A因此需要对需求的读/写访问，同时包括业务模型以及用例图。对需求特性的更新以及大部分对需求的更改也都将在Site A发生。Site B也需要对需求的读/写访问。因为他们随着时间对现存的应用软件进行维护，Site B的团队将需要增加需求，对现存需求进行修正，对需求文件添加辅助信息，并分配属性，例如优先级、难度以及状态。Site B的团队成员还将需要在需求间跟踪关系的能力，这样，他们可以测量改变的影响。

虽然两个团队将在不同分支上进行工作，然而两个站点都将需要对共享代码库进行访问。两个站点还需要浏览、创建以及修正变更请求，增加需求以及缺陷报告。

为了达到这种高等级的共享访问，两个站点需要在本地服务器上对关键数据进行复制。

配置IBM Rational工具
当确定了什么资产是在每个站点上都需要的，Alcrohm需要找到一种分配他们的方法。IBM Rational工具为在两个Alcrohm站点间进行通信与协作提供了一个范围广泛的可能。实际上，在这个GDD项目中所使用的产品与很多企业，例如Alcrohm，已经使用的保证在他们更传统的、协同位置开发项目中的高质量产品的工具是相同的：

IBM Rational Unified Process，或称作RUP －支持健壮的、迭代的过程。对很多GDD项目来说，包括本场景，最好的方法是首先在规程间建立工作流程，然后配置工具基础来帮助自动化这个工作流程。RUP包括了最佳实践，并提供了支持标准的、集成的以及迭代过程的指导，所有这些对一个分布式团队的成功来说都是极为关键的。RUP也定义了一个共享的词汇表和一个清晰定义的项目任务与责任，所有这些都促进了一个跨越分布式团队的公共视图。并且由于它是基于网络的，RUP很容易支持分布式工作。于是RUP成为使用其它工具的基础。
IBM Rational ClearCase ―― 用于安全的资产管理以及整体过程控制。没有健壮的、安全的资产管理能力，大部分GDD项目都会承担很大的风险。资产管理保证了只有被授权的人可以浏览或改变项目资产；它还提供了可靠的对被授权用户错误操作事件的恢复能力，例如对源代码文件的意外删除或该写。资产管理进一步为更改控制、审计、重新构建以及从可执行代码或者版本到需求、变更请求等的可回溯追踪性提供了基础。GDD团队需要对资产以及对资产的更改在分布式环境中无缝的协作。同时需要能够在一个项目的不通分支同时工作的能力，通过24×7开发模型加速部署。

在类似于Alcrohm的GDD场景中，每个分布式开发团队拥有一个数据存储，IBM Rational ClearCase MultiSite为分布式资产管理提供了一个健壮的、可扩展的解决方案。Alcrohm 将利用 Rational ClearCase MultiSite 与 Rational ClearCase 的结合以可靠的复制并同步包括二进制或文本对象的数据存储，从需求至代码、可执行应用以及其中的任何东西。每个站点中的团队成员用他们自己本地的数据存储的副本进行工作，因此WAN或企业内部网性能问题被最小化。特性的分支和合并简化了在多于一个位置中对相同文件所作改变的同步，因此有效地支持了24×7的开发工作周期。多个项目资产副本的存在同样帮助最小化停工、返工以及其它服务器的损耗带来的影响或灾难。IBM Rational ClearCase MultiSite还提供了一个基于浏览器的接口，以允许管理员从他们自己的本地站点管理所有的副本。
IBM Rational ClearQuest ―― 用于需求变更管理以及缺陷追踪。无论团队是分布式的或是协同位置的，开发资产都是活动焦点以及对客户来说业务交付日益增加价值的部分。有效的管理以及对开发资产缺陷、增强请求、新需求的响应和其他进行变更的追踪能力在GDD项目中都是极为关键的。关于缺陷状态的未回复问题和混乱是分布式团队所需要解决的最后一件事情，因为不确定总是会导致昂贵的延迟以及滑向崩溃的错误。

为了在GDD环境中提供优化的支持，Alcrohm 了使用 IBM Rational ClearQuest MultiSite，一个已证实的、健壮的、灵活的、能够跨越多个地点对本地数据存储同步化变更请求数据的工具，可以对IBM Rational ClearCase进行补充。这不但使对分布式站点数据更新变得更为容易，而且当服务器变得不可用时为数据存储提供了备份。
IBM Rational RequisitePro ――更有效的通信及管理需求。这个由不良的需求定义及在协同位置开发项目中的沟通所导致的问题在团队变为异地分布时更为明显。确实，不良的定义和不充分的需求沟通是导致GDD项目失败的最常见原因之一。毫不奇怪地是，对创建内容的不正确的假设通常会导致错误的解决方案 ―― 特别是当相关的人甚至不讲同一种语言时。为了减轻这种关系，Alcrohm将使用IBM Rational RequisitePro进行需求管理。RequisitePro使用数据库管理并追踪需求，并为它们分配属性例如优先级、状态以及难度级别等。使用Microsoft Word文件记录需求并提供关键的上下文信息。相关文件可以被链接，这可以使得对项目范围及资源变更影响的分析变得更为容易。

为了访问来自Site B或其它远程地点的需求，Alcrohm将采用Rational RequisiteWeb的基于浏览器的接口。这将使位于Site B的团队成员可以浏览、创建并修改存储于Site A的需求，同时对需求之间的关系进行追踪，而无需维护他们各自的数据存储或是在他们的桌面上安装另一个客户端。
IBM Rational TestManager ―― 用于在Site A进行功能及系统测试。在Site A的质量保证团队需要一个能够管理所有测试方面的广泛的解决方案，从初始测试用例计划直至测试开发、执行及测试结果分析。随着与Site A需求数据库的集成，对需求测试用例连接以保证所有需求在开发前被测试，Rational TestManager提供了所有这些能力。
IBM Rational Purify Plus ―― 用于Site A以及Site B开发者的单元测试。Rational Purify Plus是一个能够使设计师写出更加可靠代码的完整的运行时分析解决方案。Rational Purify Plus 通过提供对应用软件瓶颈高的亮化输出来帮助提高性能。
IBM Rational Software Modeler ―― 用于Site A的可视化建模及设计。建模工具可视化的对所有应用软件基础结构各个维度在所有站点的涉众之间进行沟通。Rational Software Modeler支持统一建模语言（UML），工业建模语言标准以及最常见的全球化建模符号 ―― 当包括不同语言及文化时的一个最重要的优势。当需求变更时，相关的结构必须被更新。为了处理这个关系，Rational Software Modeler和Rational RequisitePro 进行集成以更容易关联需求与其相对应的模型元素。更新模型以反映新的需求使得在每个站点的开发者都可以看到更改对需求造成的影响。Site A的开发者同时也可以采用Rational Software Modeler进行模型驱动的UML开发。
IBM Rational Portfolio Manager ―― 用来进行项目组合管理。项目管理需要一种有效的方法进行计划、追踪并对GDD项目所有方面及资源组合进行管理。Rational Portfolio Manager能够捕获关键项目数据，例如成本、质量和完成情况度量，能够帮助进行管理评估、计算，并在所有项目组合的各个方面之间进行沟通。这些能力对评估并平衡GDD工作风险及收益极为重要，同时保证他们与项目优先级相符，并创建业务价值。
IBM Rational ProjectConsole ―― 用于跨越开发周期，对项目从需求定义直至变更请求的统计数据进行自动化的跟踪。Rational ProjectConsole 提供了对项目状态及质量的数据更新视图，因此你可以做出定性的评估以保持项目的健康轨迹并管理风险。

同步数据存储
为了使团队成员在24×7开发模型中跨越分布式环境地共享资产，每个站点所完成地工作必须保持同步，并在另一个站点中进行复制。正如前面所提到过的那样，Alcrohm将分别使用IBM Rational ClearCase MultiSite和IBM Rational ClearQuest MulitSite以保持项目版本化的资产和同步化的变更管理资产。对ClearCase和ClearQuest数据存储的复制及同步将自动每天两次的运行，分别在两个站点对应的每个工作日的结尾（07：00和19：00 丹佛时间）。

IBM Rational ClearCase MultiSite 和 IBM Rational ClearQuest MultiSite内建的复制能力保持了最新的以及简化的同步过程。ClearCase MultiSite 和 ClearQuest MultiSite数据库同时被复制。这保证了资产之间连接的数据更新。图一举例说明了这种安排是如何工作的。

Figure 1: IBM Rational tools and asset repositories

图1：IBM Rational 工具和资产存储

对任何时间或任何地点访问的选择
在一些GDD环境中，也许考虑对共享数据存储提供基于web的访问是可行的，并且/或者可以采用Citrix技术以集中对开发工具的运行和管理。这些种类的“瘦客户端”的可选方法可以使分布式团队成员无论在哪里都可以访问项目资产。

在Alcrohm GDD环境中，Site A和Site B有足够的能力和管理资源以使得在两个站点的IBM Rational工具有最高等级的功能需求时，无论在哪里都可以通过它们内建的接口被访问。但是项目仍然存在极为重要的网络客户端的使用。特别是在Site B中的团队成员需要RequisiteWeb客户端对需求进行访问。

除了RequisitePro外，许多其它的IBM Rational工具支持基于网络的或是基于Citrix的客户端选项。例如：

远程用户可以通过基于Web的接口访问IBM Rational ClearCase变更管理功能。
IBM Rational ClearCase 远程客户端特性使得远程用户可以通过WAN访问目标版本。
管理员可以从任何地点通过网络浏览器，通过IBM Rational ClearCase MultiSite Administrator Web接口管理分布式ClearCase数据存储。
IBM Rational ClearQuest提供了基于 Web 的接口使得远程用户可以访问并更新变更请求。
IBM Rational ProjectConsole使用基于你从Rational Suite以及第三方产品中所选择规格的图形化面板动态创建项目网页站点。

运转中的工具：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模型要求软件开发工具支持整个软件或系统开发生命周期。其它的，例如模块化团队开发也许仅仅需要配置管理以及能够跨越分布式环境工作的开发工具。