内容


异地分布式开发:IBM 统一生命周期方法

Comments

插图您不可能没有读到过或听说过“外包”。外包,曾开始于制造业和零售产品,现在在 IT 行业获得了动力,并且每个人都在谈论它。它甚至成为在美国 2004 年总统选举中的热门话题之一。本文的目的不是要解决外包所引起的所有问题 —— 也成为异地分布式开发(geographically distributed development,GDD) ,而是要着眼于一些 GDD 所需要的业务要求,并说明这些需求如何推动创新的业务变更。

在本文中,我们将着眼于一些业务需求、它们为什么对业务策略是重要的、GDD 如何影响这些业务动力以及如何有效地为成功的 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 接口访问数据
  • 终端服务器技术的使用
  • 产品部件的数据复制。

摘要

现今,许多公司正求助于异地分布式开发以实现更好的灵活性及成本控制,同时提升他们在日益全球化的市场中的竞争能力。然而,将 GDD 模型引入到 IT 策略中会带来风险:围绕项目团队能够准确、精确并明确地在所有成员间沟通的能力的不确定性。在并非每个团队成员都使用同一主要语言的环境中进行沟通是困难的,由于距离和时区的障碍,人们不能够实时地沟通,在内部流程、知识和工作转移问题和项目工件所属权问题上存在着冲突。通用的流程、工具及报告是克服这些风险的关键。

利用 GDD 模型达到预期结果需要对人、流程和工具的预先投资。最初公司必须彻底地评估他们的开发团队及支持的基础架构,以实现支持分布团队的开发流程和工具。IBM 软件开发平台提供一个生命周期解决方案,它可以在所有领域内对 GDD 的成功起到关键作用。利用它,分布团队可以更加有效并高效地沟通、开发并管理软件项目。

注释

1 Versioned Object Base —— 一种用于存储开发过程中项目工件的多重连续版本的 IBM Rational ClearCase 数据库资料库。


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=161912
ArticleTitle=异地分布式开发:IBM 统一生命周期方法
publish-date=05312005