分布式异地开发是一种能够使业务在位于不同地区、国家或时区的项目团队之间进行合作的软件开发模式。本文通过一个普通的场景举例说明了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数据库同时被复制。这保证了资产之间连接的数据更新。图一举例说明了这种安排是如何工作的。
图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模型要求软件开发工具支持整个软件或系统开发生命周期。其它的，例如模块化团队开发也许仅仅需要配置管理以及能够跨越分布式环境工作的开发工具。 重新联合业务与 IT
灵活性、全球化、成本控制、加剧的竞争。这些只是当前挑战许多组织基本业务需求的一些内容。每一种需求都是复杂的，并且在更大的企业里，这些经济因素迫使 CIO 重新评估他们的 IT 策略。问题是，软件开发项目与组织的业务需求很好的结合了吗?
让我们依次考虑一下这些需求。
灵活性。现在，当某人在软件开发环境中使用灵活一词时，大多数人会想到一个灵活的基于组件开发的系统体系架构。虽然灵活是基于组件开发的一个好处，但是“灵活”的范围已经扩展了。许多人越来越相信，商家需要灵活性以快速适应不稳定的市场环境和经济波动，确切地说，就是适应人员配备结构、程序设计、系统体系架构、软件开发流程和系统如何遵照业务调整和预算结构方面的变更。作为这些领域的公共命名，灵活性还可以使组织适应于永无休止的本地、州和联邦政府的强制性的标准，甚至要应付恐怖分子袭击的后果。整个组织不得不准备好即刻适应所有的这些变更。
全球化。全球化是业务增长的新领域。跨国际界限建立或管理业务关系的需要起始于许多现代环境，成功的商家适应全球化的许多需求。例如，一个公司会面临导致团队分散在全世界的合并或收购。或者需要通过在国外建立市场来扩展业务，然后，需要将产品供应本地化(例如，为本地语言和习俗重新设计产品)。总之，成功的关键是理解和工作在不同文化下的能力。
成本控制。从过去的某些意义上讲，学会如何“利用较少的资源做更多的事”对所有商家都是必要的。经济状况总会影响到组织的健康。点 com 的时代已经滚滚而来。世界，如我们今天所了解的，不仅要遵照严谨的预算，组织还要学会如何用更少的人做更多的事。他们必须提高员工的生产率以实现更有效的、更高效的、有更大利益的流程、系统和产品。
加剧的竞争。任何行业的市场引领者必须用客户的眼光看事情，并且作为提供高质量产品和服务的革新者。引领者的产品必须在任何时候都可利用，并且它的支持团队必须提供最高级别的客户服务。这些特性中的大部分都需要能够在竞争中取胜的专门的且高度细分的软件系统。这些包括可以加快内部流程 —— 例如，销售流程、存货跟踪和产品开发 —— 的系统，还有可以增强客户体验 —— 例如，可以推广宣传产品和服务的网站，和允许客户在线定购产品并执行事务的电子商务特性的系统。介绍 GDD
为满足这四种业务需求，许多公司求助于异地分布式开发(GDD)模型，作为他们用于软件开发项目的 IT 策略的一部分。出于本文的目的，异地分布式开发引用了管理软件开发项目的实践，超出了单个建筑物或办公室结构(开发人员的分布令人无法想象)的传统边界。在 GDD 模型中，开发人员配置分布可能是跨城镇的、跨州或省边界的，或是在海外的。一些公司在他们的异地分布式环境之内从事分布式的开发，这种开发可能在一个单独的软件开发项目中涉及到多个地点，及软件开发生命周期一部分的服务提供者(外包公司)。
GDD 不仅能够允许公司加强在全世界范围内的运作，还使公司从削减的劳动力成本、各种人员安置、利用 24 小时工作的人员配备来缩减投入市场的时间中收益。同时为组织提供了具有立即反应能力的多样的和灵活的特性。
但是 GDD 并不是易于采用的模型。该解决方案听起来能够满足您的业务需求，但成功的关键是要依靠策略的执行和实现。异地分布式的风险
随着公司采用了 GDD，风险会迎面而至。最大的风险集中在沟通上：在团队成员讲不同语言的环境中，分散的项目团队需要准确、精确并明白地沟通。然而，沟通常常受到距离和时区、文化差异、知识和工作转移问题、内部流程的冲突及软件工件的所属权的阻碍。在安全的环境中跨地理边界地管理变更和资产使得所有这些障碍更加复杂。
语言和文化的差异影响着 GDD 生命周期的所有方面，并且考验项目经理是否有能力清楚地表述项目需求和系统功能。经理们需要传达总体设计和流程，以便团队成员能够理解项目需求，从而确保开发正确的应用程序。
知识和工作迁移的方法也许在同一地点的工作环境中是很常规的。但是在 GDD 环境中，就不是想当然的了。每个 GDD 团队成员都很清楚地了解项目的范围吗?个人的责任明确吗?团队成员是否都知道如何传达与下一个任务相关的工作状态及详细数据吗?是否存在一个可以提供最佳实践和一致流程指导方针标准的统一流程?管理变更和资产以便团队能够在跨越地理位置的环境中无缝的开发并集成软件的变更变得同样地复杂。
为了解决这些难题，公司开始求助于可以为统一流程方法、沟通、软件开发及项目规格提供基础构架的软件开发工具。无边界的解决方案
IBM 软件开发平台提供了一个无边界的生命周期解决方案。它可以通过优化内部基础架构来帮助分布式团队有效地沟通、开发并管理软件项目。它还可以帮助确保项目的成功，因为它是基于行业证明了的最佳实践和工具。IBM 软件开发平台为从事需求管理、可视化建模、分析与设计、测试、项目管理、配置管理及变更管理的个体从业者提供最好的支持，而所有这些都是基于被证明了的流程之上。
另外，IBM Rational 已经将产品集成到该解决方案中，以将工作流、团队沟通、信息复用、生命周期跟踪及信息共享自动化。这些集成将团队联合到一起并为项目的成功作出贡献。这种自动化可以带来项目可预言性、改进的沟通、更高的质量以及投入市场的时间的缩减。对于分布式团队在部署上的考虑
除了实现了集成的产品集(如 IBM 软件开发平台)的好处之外，还需要考虑并结合新的实现策略。这种策略是将 Citrix 技术合并到业务计划中。该策略提供一个应用程序服务器环境，将应用程序的执行和管理集中到服务器上，并允许多用户在网络上进行访问。该模型本质上是将设备转变为一台只需具有显示和操作用户接口功能的瘦客户机。
在您的分布策略中要考虑的另外的技术包括提供对共享资料库的基于 Web 的访问以及跨越地域的可靠副本及同步资料库。统一流程
统一流程对分式布团队的成功是决定性的，因为它帮助建立起一个高度重复性的过程、一组软件开发的最佳实践及执行的标准方法。这样的流程提供了公共的词汇表以及能够联合分散团队以促成共同视点和文化的清晰责任定义。一旦建立了流程，就可以使用工具将每个规程自动化。
支持统一流程的团队工具和依赖于共享信息资料库的工具会反过来受到物理距离、有限的通信带宽以及不一致的 WAN 可靠性及性能的影响。其他的可能使得工具部署复杂化的因素是公司的网络结构及安全规则。要想确立您的组织可以有效实现 GDD 结构的途径，您就必须首先理解并为每个贯穿开发生命周期的规程定义开发基础架构及工具使用的模型。例如，您应该考虑这些问题：
设置每个软件开发规程 —— 例如，需求、测试、项目管理 —— 的中心信息交换场所。
谁创建项目需求，团队中的哪个人需要使用这些需求?谁需要能修改需求?
团队成员如何访问网络?他们是否受到防火墙问题的限制?是否选择 VPN 技术?
您的开发人员是否用到模型和代码?
开发团队中的什么成员需要访问由测试团队提交的缺陷记录?这些工件位于网络的什么位置?他们是否需要拥有对缺陷记录的读写权限，以便他们可以在缺陷确定时进行记录，还是只需要有读取缺陷位置的能力?
当前 Citrix 是否为您的基础架构的一部分?如果是，团队中哪些成员可以得益于对 Citrix 的工具使用?
您的现有网络配置是什么?
您组织的安全政策如何影响 GDD 工具使用?
当您的团队遍布全球，您如何度量项目的状态?您如何有效地度量突出的最高优先权缺陷的数量?决定性的需求是否得到了满足，并作为应用程序的一部分得到开发?
随着您开始访问团队成员的结构及位置、网络基础架构的布局及定义当前开发工作流的流程，您将开始为如何实现或扩充流程及工具以适应具体需求而建立基础。
让我们更进一步了解这些问题，来看看为什么它们如此重要。并特别注意它们如何影响流程和工具部署，如何影响开发生命周期。流程及工具部署
我们从流程开始。对于贯穿开发生命周期的分布式团队的成功起决定性作用的是高度的可重复的流程及提供公共词汇表及清晰的责任定义的标准执行方式。因为有了通过开发工作流中每个规程来理解并依照流程的决定性需要，所以对流程的方便使用就成为极其重要的事情了。
要满足该需求，我们要求助于 IBM Rational Unified Process 框架，或称 RUP。 RUP 是基于已证实了的最佳实践的软件开发流程框架。它在整个开发生命周期中提供有价值的指导和公共流程。通过将来源于许多规程 —— 例如项目管理、业务建模、需求管理、分析、设计、测试和变更管理 —— 的最佳实践组合成一个一致的、综合的流程，RUP 促成了一种共同的贯穿开发组织的观点和文化。该方法通过提供项目具体流程信息的在线文档来帮助加强分散位置的联系。此共享的流程还改进了沟通、使开发团队有效合作、更加有效地工作，并减少投入市场的时间。
作为基于 Web 的解决方案，RUP 能够很容易地扩展，以支持处于所有位置的开发团队。利用动态生成的 HTML 页面生成 Web 站点，RUP 可以使您以多 RUP Web 站点的形式进行发布，每个站点代表一个配置好的简明的流程定义。RUP 浏览器小应用程序使得可以通过许多标准 Web 浏览器对 RUP Web 站点进行动态访问。要对站点进行简单导航，附加的导航小应用程序便会执行。
要满足您的特定项目需求，RUP 平台提供了一个灵活的流程框架，具有可以帮助您为您的项目非常简洁地选择并部署一组流程组件的强大配置工具。当项目启动时，您的项目领导会利用 RUP Builder 和与您项目相关的流程插件配置基础流程框架。可以为项目大小、具体技术、工具或领域而定制这些资产。一旦您设计好流程，RUP Builder 便会帮助您快速简单地以基于 Web 的项目视图的形式进行部署。团队成员从中央单元将用户流程直接安装到它们自己的机器上。每个团队成员都可以使用整个项目的共享视图(详细说明了工作流图，流程文档和与行业相关的规格文档)。此外团队成员还可以利用 MyRUP对项目进行个别地改进，以便于只有与它们工作相关的活动、部件和文档会显示出来。沟通需求
在分布环境中，对需求不合理的识别及定义常常是项目失败的主要原因。语言沟通或作为项目开发基础的不精确定义的需求会导致不良的设想、错误及最终错误的解决方案。这通常表现在大范围全球性 GDD 情景中，不同文化带来沟通困难，因此除了简明清楚地定义并编制的需求以外都有可能导致意外的代价高昂的结果。
IBM Rational RequisitePro 软件，一个强大的易于使用的需求管理解决方案，提供了一个有效的基于数据库和易于使用的 Microsoft Word 功能组合的需求管理流程。
用于记录需求的 Word 文档提供环境或辅助的需求信息。Rational RequisitePro 利用数据库分配属性，如优先级、难度和状态，同时组织并跟踪需求。能够帮助分析团队确定并分析变更影响的相关需求，换句话说，当已知需求随时间发生变更时，可以很容易地看出变更对其他相关需求的影响在逐渐明显起来。拥有了这种关于变更的实时可视化功能，可以使您查明变更在项目中的效应，这可以帮助您做出关于范围管理或资源再分配的快速、合理的决策。该需求解决方案可以促进团队沟通、增强协作并减小项目风险。
RequisitePro 为分布团队提供了许多配置选项。最好的配置要依赖于团队的基础架构。例如，在您的团队中进行需求定义的中央信息交互的位置将决定在哪里设立 RequistePro 主机服务器是最佳的，寄存有 RequisitePro 的主机服务器一般与中央信息交换或“核心用户”在一起。下一步要确定的是其他哪些成员需要访问项目需求。他们会更新需求吗?或者他们只需要简单地回顾需求?一旦您制定出需求使用模型，您就可以评估用于工具部署的选项了。
本地的 Windows 用户接口提供了对 RequisitePro 的访问，并具有所有特性功能，包含项目管理功能。远程用户可以得益于允许他们创建、显示并删除文档，编辑需求属性，参与讨论，并可以在 RequisitePro 项目数据库中直接创建需求的 RequisiteWeb。若要标记需求，则要删除现存需求，并编辑需求文档，RequisiteWeb 用户可以对来自于 RequisiteWeb 的文档进行脱机访问，在 Word 中进行编辑，并通过 RequisiteWeb 将其放回线上。一旦文档回到线上，其更改部分会与资料库中的内容保持同步，并且对其他项目成员是可见的。
RequisitePro 支持 Citrix/Windows Terminal Support 技术。如果您现存的基础架构已经支持 Citrix 技术或者正考虑将它作为分布部署计划的一部分，那么您应考虑该选项。根据资源需求，应该只对相当小的分布团队考虑该选项。它还有助于选择更大的需要完全本地化 RequisitePro 接口功能的团队，包括对工具到工具集成的访问。可视化建模
语言、文化及时区的多样性要求我们要非常清楚地传达应用程序的视角 —— 从使用模型到类及活动模型，以便可以明确地理解应用程序的功能。您需要确定每个团队成员的头脑中是相同的工作流，在每个电话会议中使用的关键点或词汇都能让人理解，文化或语言的差异不会引起对目标的误解。关键的问题是：您怎样确保所有团队的成员最初想到的是相同的整体设计，而不在部署时发现设计是错误?
统一建模语言(UML)已经成为用于软件体系架构和设计的软件开发行业标准表示法。利用 UML，软件专业人员可以以一种统一一致的方式对他们的分析和设计部件进行可视化建模，这样团队就有了一种处理沟通和项目文档的公共方法。为了使 UML 简单易用，IBM Rational 创造了引领行业的获得嘉奖的 Rational Rose XDE 系列可视化建模和开发工具。Rational Rose XDE 软件提供了用于创建并维护描述项目体系架构、过程流、逻辑组件关系和数据库设计的 UML 模型的工具。该软件还能够由模型直接生成代码，并由代码生成模型，这使您全面掌控了模型何时及如何与代码保持同步。
Rose 和 XDE 利用基于文件的方法存储 UML 模型和相关信息。要提供资料库及团队开发支持，您需要使用优先的配置管理(CM)系统，如 IBM Rational ClearCase MultiSite，以便分布团队可以添加、更新及查看模型，并按照严格一致的进度表合并所有更新。
对于那些只需查看模型的团队成员，Rational Rose/XDE 提供了一种允许用户与涉众共享体系架构和设计的 Web 发布特性，不论他们是否安装过 Rational Rose/XDE 。模型转换成 HTML 并发布在内联网上，所有拥有 Web 浏览器的人都可以查看到模型。缺陷跟踪
在软件开发生命周期的规程之间转移工作时，多个团队、地点、语言和规程会引起大量混乱。出现许多问题：开发团队已经找到缺陷了吗?已经通过了质量保证(QA)检测了吗?谁分配到了由分类会议中引出的最近的变更请求?
暂不回答这些问题，这类的问题会导致项目传送的延迟及糟糕的质量。
IBM Rational ClearQuest MultiSite 软件通过被证实的变更请求管理流程来满足大多数组织的需要。还可以根据特定的需求对其进行定制。它坚固灵活的工作流支持包括电子邮件通告及提交选项的部分，这样您的团队成员可以在变更请求更新时得到通知。您可以为任何类型的变更需求定义独特的工作流。为了满足所有位置的团队成员的需求，自动化的同步为重复的缺陷和变更跟踪信息提供最新的访问，以使整个团队保持同步。
对工具部署的考虑要视使用模型而定。如前面部分“统一流程”中介绍的，您最初的评估应确定：哪些用户需要访问变更请求，如缺陷?变更请求的工作流是什么，在整个工作流中会涉及到哪些用户?工具的管理在哪里执行?
ClearQuest 利用了双重的客户服务器的体系结构。增加、缺陷及其他由 ClearQuest 管理的变更请求记录存储在名为“用户数据库”的关系数据库中。ClearQuest 将有关项目变更管理规则及实践(记录、字段定义、有效状态及事务、数据实体表单等)的信息存储在单独的叫作方案资料库的关系数据库中。ClearQuest MultiSite 可使跨多个地点的方案资料库和用户数据库可复制并保持同步。如同使用 ClearCase MultiSite 一样，对于由分散的子团队组成的团队来说这是一种好的解决方案，可以使每个团队的成员都在中央 LAN 上，像 ClearCase MultiSite 一样，ClearQuest MultiSite 和复制机制提供了服务器运转中断时的安全机制。
像使用 ClearCase MultiSite 一样，复制和同步功能支持在分散的地理位置上的主要用户。因此，无论用户是需要利用错误确定信息更新缺陷或变更请求的开发人员，还是需要创建新的缺陷记录的测试人员，每个用户都可以通过本地接口访问本地的数据副本。
对于那些不拥有到服务器的非常可靠且快捷的连接的远程用户来说，可以使用 Web 接口来添加、更新及查询变更请求记录。换句话说，ClearQuest 为远程用户及可能处于远程的管理员提供 Citrix/Window Terminal Server 的支持，需要使用 Web 接口不支持的 ClearQuest 管理工具。应用程序测试
应用程序测试和持续的质量保证涉及到整个开发团队的协作与沟通。您需要一个覆盖应用程序所有方面的测试计划，以确保应用程序的覆盖达到百分之百。在异地分布式环境中特别关键的是定义需求的团队、测试团队和确定在测试计划中找到的应用程序故障的开发团队之间的完全的沟通。该流程需要严格地遵守。
为了通过此协作规程来协助团队，IBM Rational 提供了全面的系统测试系列产品。其中包括可以帮助您管理包括手工测试工作流、测试日志和测试执行的自动报告的完整测试计划的 IBM Rational TestManager，以及 IBM Rational Performance Tester 和 Rational Functional Tester。
在测试计划的核心位置的是 TestManager 产品。TestManager 利用一个两层的客户服务器的体系结构。有关测试部件及测试执行结果的信息存储在一连串称为“测试数据库”的相关文件中。关联的关系数据库存储着指针并提供对数据库的简单数据访问。对分布团队来说，熟悉的 Internet 协议简化了团队中日常测试的沟通。资产管理
用于管理资产的系统是分布开发的主干。有效的基础架构要按照团队大小和位置数量设定规模。它必须提供地点间自动可靠的软件资产复制，这样便可在全天的软件开发工作循环中提供对所有软件资产的本地访问。
分布开发团队可能由在不同地理位置的多个办公环境组成，每一处都有能力存放存储库及多数据库服务器。IBM Rational ClearCase MultiSite 提供了此情况下有效的资产管理解决方案。作为 ClearCase 的附加产品，ClearCase MultiSite 提供了可靠的存储着所有文件系统对象(无论是二进制的还是文本的)的资料库副本 —— 跨地域。每个中央子团队与本地存储库副本协作以求得最优性能，并因此避开所有与临时 WAN 或 Internet 性能有关的问题。MultiSite 利用了 ClearCase 对分支及合并的支持，因此任何在一个位置发生的变更可以与其他位置的变更同步并合并。同步和复制间隔由 SCM 项目管理员控制。在同步过程中，只有变更在不同地点间迁移，不是整个的 VOB1副本。拥有多个副本也为项目提供了一个安全机制，可以在服务器运行中断过程中减少停机时间及返工。
如果您的拓扑中包含相当数目的在家和小型卫星办公室的远程开发人员，那么 ClearCase 提供支持许多标准 ClearCase 特性的 Web 接口，对于那些需要完整的 ClearCase 功能的人，可使用 Citrix/Windows Terminal Server。项目状态和度量
对分布团队来说，确定项目状态是特别令人头痛的事情。文化差异容易增加复杂性，例如，在某些地区，按照规范，甚至当工程拖后进度几个星期也宣告成功。最好可以快速的得到所有与项目相关的数据，这样您就可以准确地度量所有导致项目成功和失败的因素，例如，最高优先级缺陷的数量和在开发循环中还没有实现的需求的数量。这些类型的详细统计可以使您客观地度量项目的状态和进展，并使您无需解释团队中 10,000 英里远的人所说的“是的，我们几乎达到目标了”的含义。
除了关心项目的状态，确定 GDD 项目过程中预期收益是否实现也是同样重要的。是否实现了所有项目需求?如果没有，整个项目是否需要废弃或大量返工?在部署阶段，是否还存在大量未解决的错误?在项目的结尾，对开发资源的需求是否惊人地增长，还是保持平稳?类似这些问题可以帮助您评估项目的成功与否，并查明如何使得下一个分布项目取得成功。
IBM Rational ProjectConsole 工具，Rational Team Unifying Platform 的一个功能部件，从 IBM 软件开发平台中的产品及第三方产品中收集真实的开发数据，同时以图形方式提供结果，以便您可以简单快速地评估项目的发展及质量。它使您能够客观地度量并更好地预测那些需要特殊关注的领域。Rational ProjectConsole 帮助您解答各种类型的问题：为了保持进度我应该关注哪里的稀缺资源?什么趋势会影响成本?项目是否稳定并可以用于部署?ProjectConsole 可以帮助项目按照进度和预算运作，以至于您可以见到分布团队所带来的好处。
项目经理及所有指定的团队成员可以简单地通过浏览器访问 Project Website Dashboard。可以通过存取控制表来限制报告及视图对某些团队成员的可见性。项目经理可以查看相应的数据以客观地度量项目进展及质量。只有项目管理员和需要设计和修改 ProjectConsole 模板的用户需要安装本地客户端。为了从所有开发地点收集数据以便使项目状态“仪表盘”可以反应出全面的项目状态，您可以从远程站点收集数据并发送到 ProjectConsole 服务器站点处，或者您可以从中央位置(服务器站点)收集数据。分布环境下的产品集成
在 IBM 软件开发平台中的产品集提供了自动集成软件开发的业务流程的功能，这样组织就可以更有针对性、响应性更强且更具弹性。该集成沿着应用程序设计、功能测试、缺陷跟踪及变更管理的项目需求开始。随着您的开发团队扩展到分布环境，您就需要关注集成点。当然，更加健壮的数据资料库和接口所需要的关注要比原来那些为有限的本地访问而设计并部署的东西要少。
本文中所讨论的产品间的集成出现在客户级别。客户交换信息并在他们各自的资料库中存储的数据间建立连接，导致数据在一个产品资料库中同时由不同的资料库引用。因此，当资料库协作定位时，集成会执行的更好。除了产品相关性，当确立基础架构在分布环境下支持的产品时必须要考虑使用 Rational Administrator —— 用于定义一组特别项目的产品资料库的工具。
因此，定义您很可能利用的生命周期中的集成点是重要的。在最初生命周期评估定义使用模型时，拥有对它的完全的理解会帮助您权衡整合选项。影响集成可用性的因素包括：
产品存储库寄存在哪里
通过 Web 接口访问数据
终端服务器技术的使用
产品部件的数据复制。
