级别： 初级 Alan BrownIBM Rational
Dr. Murray CantorIBM Rational
Geoffrey ClemmIBM
Nathaniel MishkinIBM Rational
James RumbaughIBM Rational
2004 年 4 月 01 日 本文来自 Rational Edge：在这个圆桌讨论中，六位 最近被 IBM 授予 杰出工程师的 IBM Rational 的员工讨论了他们的工作对于 IBM 和 更大的软件开发社区的贡献。
IBM 在创新方面的悠久历史代给 IBM 的员工获得了从诺贝尔奖到国家技术奖章的荣誉。IBM 的科学家和工程师们在简化指令集计算机（RISC） 、数据库管理系统、逻辑与复杂性理论、纳米结构材料、高温超导、激光外科以及很多其他的领域上的发明和创新受到了人们的表彰。
在 1995 年， IBM 启动了一项 IBM 杰出工程师 （DE）的项目作为认可公司顶尖的技术专家的另一种方式，并且提供给他们一种执行者的职业生涯道路。在全世界超过 175,000 名在 IBM 的业务或者研究部门中工作的技术人员中，仅有大约 300 人被授予了此项荣誉。
最近，六位 IBM Rational 品牌的工程师被授予了杰出工程师的称号。作为新技术背后的指导力量，他们正在重要的工业领域中推进着技术的革新，比如模型驱动的体系架构 （model-driven architectures）、企业范围的变更管理、IBM Rational/WebSphere 工具、系统工程的最佳实践和下一代产品接口。
这个的圆桌讨论揭示了这些工程师正在从事什么样的工作，并且揭示了他们的工作将如何影响未来软件开发的方向。
你所从事的工作将如何增加 IBM 为客户提供的价值？
Jim Rumbaugh
我在 IBM Ratioanl 的任务是围绕着 UML 的，或者说是统一建模语言，它是用于指定、可视化、构建和文档化软件系统产物的工业标准。归根结底，我专著在建模上。因此我认为好的工程是开始于理解你要作什么，然后通过系统的方法去做也许并不令人惊讶。在其他的学科，工程师们系统性的进行工作已经受到了认可。他们不仅是一起出去修理飞机和桥梁。他们首先进行建模，因此他们可以在花费了高成本做这些事情之前找出问题所在。建模是非常简单的思想，但在程序员中对建模的阻力却有些令人惊讶。如果你告诉一个建筑工程师使用蓝图对于他来说是浪费时间的，相反应该从金属材料开始工作的话，他将认为你在胡说。但是程序员们无时无刻都在这样做。这种做法是极其不成熟的，并且对于创建更好的软件产品也不是一个好的方法。
建模通过使用业务概念开始，并且以这种方法继续下去。当你做完所有建模的工作时，你就以一个应用作为结束。但是，当你第一次与你的客户交谈时，你不要与客户讨论你们将使用什么样的编程语言。那将必定使你丢到你的客户。好的 UML 模型甚至使根本不懂技术的客户都可以理解他们。不懂技术的项目投资人能够容易的理解建模与生具来的
价值：建模为项目团队提供了工具和技术以确保他们可以做正确的事情 — 也就是说，构建客户实际需要的系统。通过建模，项目团队将确保他们拥有正确的信息、正确的信息流、正确的体系架构、正确的数据结构和正确的算法 — 在他们开始担忧实现的细节之前。
Bran Selic
UML 也在我的职责范围内；实际上我有相当多的时间和精力用在 UML 2.0之上。 象 Jim 一样，我也迷惑为什么软件工程师们都不愿意利用建模的机会。或许原因是他们或者他们的组织更愿意投资在当前的技术上。实际上公司在建模上的投资会很容易的得到回报，因为你不必放弃已有的技术来实践模型驱动的开发。正相反，比如当你为 Web 服务和开放源码的应用进行架构时，UML 特别可以被用来协调和合并你的组织中的使用的传统技术。
在我与客户的工作中，我发现客户通常对建模的关心是基于今天的建模技术是如何工作这样的误解的。但是更大的阻碍也许是来自于个人，人们往往希望保护他们在特定技术上的个人知识投资，比如 EJB、C++ 或者其他别的什么。他们设想采用建模技术将意味着他们必须重新学习每一件事情。但是事情并不是他们想象的那样。在模型驱动的环境中，所有组织的和个人的经验都是可重用的。事实上，建模恰恰需要应用你在抽象的更高层面上的专家经验。
另外，不管什么样的阻力，超过我们的期望，UML 已经被的证明是成功的。在我们的采纳基于 UML 工具的客户中，许多都取得了巨大的成功。他们能够显著的增加他们的开发生产力、软件的可靠性和最终业务的响应能力。就像我们知道的那样，以传统的方式开发软件是劳动强度极大的、效率非常低下和令人沮丧的不可靠的。范围的管理不当处处可见，而模型驱动的开发直接的解决了这个问题。模型驱动开发的其他优点是因为它让架构师通过更高层次的抽象进行工作，因此他们能够设计出完全不同的又不必操心包含每一种特定技术的特质。比如，一些系统仍然在使用被创建于 60 年代和 70 年代的数据库，并使用 COBOL 作为前端的编程语言。但是使用建模技术你可以将精力放在系统的设计上而不是技术的特性上。
甚至更好的，使用模型驱动的开发工具，使业务的设计符合特定的环境可以变成一个自动的步骤。总而言之，模型是一种开发良好体系架构的优秀方法，它可以使架构对于硬件和软件的变化很少的敏感。这使我们当前的客户受益非浅，并且当 UML 和模型驱动的开发得到更广泛的接受时，其他客户也将从中受益。
Alan Brown
我当然同意 IBM Rational 的价值主张的关键部分来自于我们对创建良好架构模型的支持和方案：业务模型、将被部署的应用和基础架构。我们的方法让客户将这些元素以系统投资者能够理解的方式结合在一起，并使我们的客户在软件开发项目中作为全面的合作伙伴与我们进行合作。
然而，从我的角度来讲作为对 IBM Rational 桌面产品的一个技术策略，我认为我们的核心价值不仅仅体现在为应用开发提供更好的方案，同时也包括帮助客户适应创建更好的 IT 基础设施的更加广泛的挑战。商家知道他们需要更加灵活，更加自动化的基础设施 -- 换句话说，他们购买的是 IBM 的随需应变环境的远景。并且很快将有很多企业将要进行整合与巩固他们的基础技术架构的过程，以便他们可以更好的准备部署和管理将来的方案。当然，持续的为 IT 基础架构构建和发展软件方案也是非常重要的。这就是为什么 IBM 要收购 Rational：对于 IBM 来说，开发工具与其他 IT 基础架构领域中大的角色一样也是关键的销售资产。
Murray Cantor
Alan 所说的当然是事实，但是为软件提供更好的基础设施仅仅是蓝图中的一部分；就是说，改进组织的效能也是蓝图中的一部分。在过去的几年中，我一直从事针对系统工程的 Rational 统一过程的工作，
®或者 RUP-SE,
®它尤其注重在大的开发团队中存在的主要问题：不够良好的交流。这是我们从阅读《人月神话》
1
或者 Bran 所指的范围的管理不当中学到的教训。当开发团队的规模不断增长时，对于有效的交流方法的需求就越来越大。交流的需求与人的增长的数量是成非线性增长的，但是很少有组织可以有效的处理这种挑战；那就是范围的不当管理导致的。换句话说，更多的程序员不意味着更高的生产力。越多的人员被分配到一个项目中，项目的进展往往看起来越慢。
目前，最佳生产力战胜了我们一直从事的在业务中分解传统工作分组的“大帽子”结构。但是这实际上也产生了更好的协作的需求；如果一个组织没有注意到这个需求，这个组织将面临范围的管理不当。这是使开发组织具有更高生产力的挑战的根本。比如在一个主要的健康和美容产品的制造企业中，IBM 帮助他们为零售客户实现更加有效的发送系统，并将范围的管理不当转换成
经济的范围管理。在这个大公司中，每一个部门都有自己的运输队，并且每一辆卡车离开仓库是经常不是满载的。因此，首先 IBM 帮助他们找到在不同内部组织之间的协作方式，这是他们过去所没有的。接下来，IBM 帮助他们开发了一个算法来计算最优化的卡车装载量。最后， IBM 帮助他们建立起一套 IT 的基础设施用于收集数据，应用算法，准确的告诉工人卡车中装载什么，哪辆车用于装载货物。然后公司能够使不同的部门在相同的卡车上装载产品，因此每一辆卡车离开仓库时都是满载的。结果，他们需要更少的卡车和司机，并大大的节约了他们的费用。
在这个例子中，打破传统的边缘就增加了队协作的需求，这导致了产生新的交流技术和新的基础设施。这就是 RUP-SE 能够为开发组织做的事情。它为团队之间的交流提供了一个蓝图，这种交流不仅仅为了满足业务目标，同时也是有效的执行工程的需要。因为现在，每个人都在构建更大更加集成的系统。看看在当前的汽车工业发生了什么，在更高的保修成本和甚至是整条产品线的召回方面，仅仅是因为集成的工作没有被正确的完成。商家在获得交流/技术/基础设施发展背后所隐含的利益是巨大的。
Geoffrey Clemm
没有人会反对组织的生产力。但是说道作为一个使用“下一代的”焦点工具产品的架构师和界面设计者，我相信改进整体的生产力需要通过为个体的开发人员提供安全的感觉和他们需要在工作中勇敢的进行控制来实现。因为，让我们换位思考一下，作为一名开发人员你通常被沉入到细节当中，在相同的点上你会觉得非常困惑。你在一个跨越两个国家、三个地点、由数百名成员组成的团队中，同时你需要与其他的团队成员一起构建一个相当复杂的软件系统，但是你没有在其他地点或者其他团队中进行什么工作的任何线索。
一个好的软件配置管理（SCM）系统可以帮助你减少局部性的混乱，因为它提供了一个稳定的环境允许你控制你做了什么样的变更和什么时候做的变更。个体开发人员需要获得对他们同事的工作的可见性，不论他们广泛的分布在哪里。但是你
不需要的是你的工作领域在你的脚下以一种不可预知的方式被改变这种令人不舒服的感觉。这就是为什么 SCM 系统应该在其他人已经做了将影响你工作的变更时通知你，并且给你一个关于如何进行相应处理的选择。你需要能够挑选和选择什么样的变更超越了你想采纳的，并且什么时候发生的变化以及变化的顺序。从我的角度来看，这类系统应该给开发人员使用 SCM 系统适当的控制权限的混合以培养他们的创造力。这就是为什么我把我的工作视为创建一个有趣的、令人兴奋的和安全的软件工程环境。
Nat Mishkin
就像 Geoff 注意到的，开发人员是非常中立的，但是他们也需要对他们的同事正在做的事情进行安全且良好的交流以实现有效的工作。作为 IBM Rational 的下一代企业范围的变更管理产品的开发团队的领导者，我关注于从技术的角度获得事情的利益，同时我也非常频繁且深入的与我们的客户进行沟通。因此当你问我们所提供的价值时，我认为在几乎所有编程的级别上我们为开发团队提供他们需要参与和满足他们客户的发展的期望的工具和支持。这当然要求我们具有关于我们的客户的需要和期望的深入的认识。如果你们是一个小的组织，这是非常容易的。回想我们第一次开发的软件配置管理产品 － 现在是 IBM Rational ClearCase
®，那时的工程团队只有十五个人；当你的团队还很小时，你知道你的客户如何认为你的工作。现在，在一个非常大的组织中，我发现实际上归结为一种思想。你可以通过一个简单的提醒帮助人们做正确的事情：“假设你是你的客户，你刚才所说的将会给他们什么样的感觉？”
这不仅仅是一个技术的锻炼 — 也是一个非常商业化的锻炼。此外，客户的关注点是什么是真正良好工程的本质。在一些组织中的工程师们封闭在自己的世界当中，不去与客户进行交流。相反，IBM 非常严格的确保我们提醒自己谁是我们的服务对象。我们在一个要求严格的工作中，存在大量的时间限期和转移我们注意力的压力。这就是为什么我们这些领导产品开发团队的人每天都要提醒我们的同事帮助客户是我们首要的目标。时刻保持关注我们的业务将如何最好的为我们的客户提供价值。
你们正帮助提供的方案将如何影响软件开发人员和其他开发团队成员的工作生活？
Jim Rumbaugh
建模不仅仅推动了正确的工程实践，而且还促进了工程团队的有效交流。这就是模型帮助开发人员构建更好的软件的主要方法之一。模型可以帮助我们以一种使
所有项目涉众都能理解的方式表达设计和架构，因此他们可以作为一个团队更好的工作以得到“正确”的软件。改进交流的好处能够带来超越单个项目的影响。比如，很多人都感觉到在数据库管理系统和编程语言之间 — 或者在数据建模语言与更多具通用目的的建模语言之间，象 UML，存在着一个大的分水岭。 UML 能够帮助架起在以 SOL 或者其他相似语言表达的数据库计划（schema）和用户模型之间的桥梁。他们不再是分离的部分，但是传统的情况下，将这些观念的框架结合在一起还存在着一定的阻力。编程阵营与数据库阵营由于不好的工程原因隔离他们自己。在很多方面，存在着文化上的差别，并且我们需要得到每一方都可以最好得工作的超越。建模将使他变成现实，并且整个计算社区也将从中受益。以相同的方法，随着对建模方法的接受，在不同背景和领域的角色之间的隔绝也将被软化和打破。
Bran Selic
就像我所看到的，模型驱动的开发将在两个方面影响个体开发人员。我们能够在硬件的世界发现类似发生的事情：在引入 CAD（计算机辅助设计）的情况下，新技术将引起的类似的波动。硬件工程师从抽象的更高层次开始工作，并使用模拟器和其他自动化的形式在电路测试板上进行原料填充。根据个人，这会带来两个影响中的一个。一个对新的设计产品感兴趣的人看到这些变化并且说“好的，这是一个允许我更好的创建我的产品的新技术。” 这种类型的开发人员将在这个新技术环境中茁壮成长。但是由于某种或者其他原因而不愿意向新环境转移的工程师将在他们当前的抽象级别上受骗。随着时间的迁移他们对项目越来越不感兴趣，或者他们仅仅很少甚至没有进行工作。当然，今天软件世界与昨天电子工程的不同之处是存在着大量的遗留软件系统需要被维护、集成等等。COBOL 被认为在三十年前就应该消亡了，但是实际上 COBOL 开发人员仍然能够找到工作。能够流畅的使用更老的技术的人在软件世界的发展中不一定就会失业；他们不被要求使用新的技术，对新技术更加感兴趣，但是我们无疑将越来越被作为趋势的建模而驱动。
我发现在从事软件的人员中，存在一个一个有趣的并唯一的特点。通常他们的主要兴趣是在编写软件上面 — 而不是在产品或者对于产品的商业目的上。他们仅仅关心他们负责软件的那一小块上。因此，当一个可以构建更好的产品的新技术诞生时，他们并不是特别的感兴趣，因为他们的目标主要是写代码。软件开发从它本身来讲是多么令人着迷的实践；但是如果人们丢失了他们真正应该尽力的完成什么时，他们将不能帮助他们的业务获得成功。
Alan Brown
Bran 提出了一个好的观点。对于那些在过去几年中了解了我们的建模工具的概念基础的人来说，软件开发的未来将是他们已经从事工作的方向的确认。并且大的变化将是开发人员所看待的他们的工作环境。这个环境将扩展软件开发相关的事物，不仅仅是技术方案，也包括方案所添加的商业价值。对于我们的客户来说，新的工具和技术将提供给他们甚至更大的可见性来考察和构建的系统是如以符合需求的，同时也提供给客户更好的利用他们正准备应用的最佳实践的能力。
比如，一个正在使用建模的开发组织能够放宽从简单的创建有用的架构模型并转化这些模型成为代码，到关注基于资产开发和重用的范围。团队将可以查看他们已经根据业务背景定义的架构模型，并问：“这个系统将如何解决我们的分析人员近期获取的业务问题？” 与过去相比，在项目的早期会有更多的业务/技术的连接。
Nat Mishkin
我同意建模工具和模型驱动开发的概念将在软件工业当中引起重大的影响（连同其他的进化改变，比如向面向服务的架构的转移）。从我的角度来看，作为一个关注 SCM 的人，这些改变将产生对管理贯穿软件开发周期中的代码和产物的更大的需求。当前，多数的开发团队将 查看 SCM 作为一个构建－运行－管理周期中“构建”阶段一项功能。但是，当你在构建一个系统时，对于变更管理的需求是不应该停止的。理想的情况是贯穿实现的过程，并且应该变成绝对不可缺少的以便充分的实现重用的好处。
同时，从维护的观点上看，拥有关于被部署资产详细的信息是更好的。对此人们已经讨论了多年，但是这仍然没有发生。比如，当 Tivoli （或者运行在你的操作系统上的其他应用管理系统）测定在产品软件的某一部分存在问题时，如果变更请求中包含信息的话，那不是非常有用的吗 “...这个问题出现在模型 X 、 Y 和 Z 中，他们是在这个版本，这个迭代和这个日期等等中被添加的？” 通过使用信息的分类，想要重新创建一个环境来调试一定问题的开发人员将得到更多基于响应的信息，并且他们不必向隔壁屋子的人询问“我们装载系统的时间是什么？我们将用什么分枝返回？”如果我们拥有一个无缝的、端对端的变更管理系统，它使用集成的配置“指纹识别” 系统或者翻译系统，或者你希望的任何其他调用它的系统的话，这是非常好的事情，这样我们就可以自动的重新创建任何预发布的环境。我们还仍然没有实现它，并且这里我不能做任何的产品宣布，但是这当然是客户想要的东西。
Murray Cantor
在工程化的制造企业中的人们更加关心商业是毫不疑问的。在跨越组织的人员的角色的环境中，不仅仅是在 IT 组织中，他们将更加全面的理解他们的角色。我们所提供的可以支持这种更加全面的工作方法的工具将实现两件事情。第一，他们将可以贯穿软件或者系统开发过程实现更加有效的工作、更加有纪律性的沟通和协作，这个过程将增加开发组织的整体生产力。当前，我们一直在不断的将从业者的生产力方面推的越来越高，但是我们在直接解决组织级的生产力问题上仅仅是一个开始。第二，客户将对个体开发人员的生产力提出
更高的要求，甚至是开发人员的工作要朝着更加整体的目标前进。
一位在波音（Boeing）公司和我同样角色的人 — 我和他在这些问题的类别上已经工作了大约五年的时间 — 指出，在很早以前，一个程序员一天只能开发四行代码。这四行代码是用汇编语言开发的；现在，这四行代码就可以生成 WebSphere 的服务。因此我们已经得到了比以前我们使用的四行代码高出很多的生成软件程序的能力。技术的前进使开发人员自然而然的得到了更高的生产效率并且生产效率将不断的发展下去。新的技术和在开发人员效率方面的增长使人们可以更多的思考并构架出更加深思熟虑的应用。这些必然会引发了对更加完善的集成的需求，这种需求要求更好的交流与协作，要求新的基础设施...。换句话说，我们一直在绕圈子，我们通过单个程序员得到的生产力悄悄的被在处理更加复杂问题的更大的团队中交流方面的失败而抵消了。使团队和个人打破这个”无限循环“并实现真实纯粹的生产力的收获是我们今天要做的变化。
Geoffrey Clemm
通过现在开发人员所感觉到的生产力方面的压力，我们坚信他们应该拥有一个可以带来他们需要的每一件事情桌面，并且使用这个桌面可以更加容易的履行他们的承诺。每一个人都应该居住在虚拟的世界中，他或者她能够生活在舒适当中，而没有在令人不高兴方面的惊讶。
你可能不太理解在我们的广告中的措词，但是从个人的角度来说，我认为 IBM Rational 的目标之一是将魔法带回到软件世界中。当你能够将一个笨拙的，手工的，部分实现计算机处理的过程转化成为一个通过与软件的交互，软件就知道你想要什么并且做的比你要好的过程时 — 那就是魔法。我们的目标就是将魔法带到软件开发人员的生活中，使魔法可以蔓延到每个人的身上。因此，你可能会说我们有点象魔法师。
因此，你将如何告诉计算机来做具有魔力的事情呢？首先，你必须真正的理解用户正尝试着做什么，以便你可以让计算机也理解。那就是需求收集和生成模型的地方。其次，你必须使用户与系统之间的交互
非常简单，以便用户能够思考他们将要完成的工作，而不是努力的学会如何与计算机交流。第三，你必须删除所有可能存在的你为用户提供的操作上的约束。因此，如果用户知道他们能做四件事，那用户应该可以在任何顺序和任何时间来做这四件事。并且系统应该有效的说”这是你想要的吗？好的，现在它被完成了。“ 用户不应该围绕着软件的约束工作。如果用户要求软件做一些愚蠢的事情，软件应该将它”理解“为对用户学习的机会，并以一种有目的的方式为用户提供帮助。
这个魔法的中心是撤销和重做的能力。灵活的撤销能力是重要的，它可以帮助用户返回到他们了解的、良好状态的世界中。在多层次的系统中得到这种能力也许需要非常努力的与系统的底层架构进行工作。当用户以一种不可预期的方式将环境搞坏时，使他们回到稳定时的状态通常是明智的。但是，仅仅是当他们有信心他们
能够恢复到这个状态时，人们才会真的有勇气这样做。如果你能过很好的处理遇到的麻烦，那你就可以进行试验。你能够尝试一些事情并能够通过使用系统来了解它，相反你将生活在害怕范错的恐惧中。当你能过理解结果并且如果你不喜欢他们你就能够改变他们时，也就是说对于开发人员这种魔法已经发挥巨大的价值了。
注释
1 阅读 Frederick P. Brooks 所著的
人月神话：软件工程随笔，第二版， Addison-Wesley: 1995。这本经典的软件工程的书中在 1974 年你一次出版，并且现在”使用当今的思想进行了修改“，Brooks 解释了存在于快速演进的技术与在个体开发者和开发团队之间的慢速演进的实践之间的不和谐之处。
作者简介  | 
| | Alan Brown 负责 IBM Rational 桌面产品的技术策略。他也是负责矫正由 IBM 多个产品线组成的 IBM 软件开发平台中的 Rational 工具的领导小组的重要成员。此外，他一直负责为 IBM 的模型驱动开发工具进行远景和策略的定位。
通过对 IBM Rational 桌面产品的贡献，他赢得了 IBM 杰出工程师的称号，同时他对软件工业的未来也作出了显著的贡献。在过去的十多年中，Alan 一直是一位业界思想的领导者，他所著的书籍、论文和大量的与 IBM Rational 的顶尖客户的交互，指导了开发人员经验的发展。想了解更多关于他的工作和思想的话，请访问他的网站 www.jorvik.com/alanbrown/index.html 。
Alan Brown 1998 年从 Newcastle-upon-Tyne 大学获得博士学位。
|
| 
| | 作为 IBM Rational 服务团队的领导者，Murray Cantor 促进并扩展了 Rational 的最佳实践，他并且在革新方法方面与客户紧密的工作以构建和交付更加高效的系统。当前，他领导了为转变软件开发组织的新约定模型的演进，也包括Rational Unified Process for Systems Engineering ® (RUP-SE®). 或者的方法对于领导大范围的软件和软件系统开发的组织的工作来说是十分重要的。他也关注如何将 IBM Rational 的能力与 IBM 的其他品牌产品的能力集成到一起。
通过对 RUP-SE的贡献和他成功的实现了客户企业转变，他赢得了 IBM 杰出工程师的称号。作为一个非常著名的思想的领导者，他是一位在行业的活动中广受欢迎的演讲者，他撰写了两本书和大量的论文，并且在 UML 和 RUP 相关的标准委员会中担当重要的角色。
Murray Cantor 1973 年获得了在 Berkeley 的 California 大学的数学博士学位。
|
| 
| | Geoffrey Clemm 负责定义 IBM 的下一代产品的体系架构和用户模型，他也在定义公司的标准方面担当了主要的角色。同时他也关注于集成变更管理服务和使用IBM 的桌面工具的其他Rational 品牌的方案，他也也与 IBM 的研究机构紧密的工作。
通过在对业务成功的关键识别机会方面被证明的能力，设计方案并推动了他们的实现，Geoffrey Clemm 赢得了 IBM 杰出工程师的称号。作为一名在 SCM 领域广泛被认可的思想领导者，他创作了对 SCM 的互联网标准 (RFC-3253) 并作为 对 SCM 的Java 标准(JSR-147)规范的领导者。
Geoffrey Clemm 于 1986 年获得了位于 Boulder 的 Colorado 大学的计算机学博士学位。
|
| 
| | Nat Mishkin 目前正领导创建 IBM Rational 的下一代的企业范围的变更管理产品的开发团队，同时他也是 ClearTeam 团队的首席架构师，这个团队负责 ClearCase、 ClearQuest 和 RequisitePro 产品的研发。
通过在过去十多年中在开发软件配置管理（SCM）方面和 IBM Rational 的缺陷和变更跟踪技术方面的领导能力，Nat Mishkin 赢得了 IBM 杰出工程师的称号。他也是架构和实现分布式计算系统方面的先锋。除了作为在两本书的联合作者外，他在分布式计算系统的主题方面发表了他的论文，并在 Usenix 大会上的网络计算系统会议部分进行了指导教学。
Nat Mishkin 于 1985 年获得 Yale 大学的计算机科学博士学位。
|
| | | Jim Rumbaugh 当前领导着 IBM Rational 的数据库和转换相关的建模工作，同时也正在支持用户向 UML 2.0 的转化，包括 IBM 自己的软件工程团队。
通过在面向对象建模领域长期的思想领导能力，并拥护对象管理组织（OMG）的技术标准和这些标准的实践性应用，Jim Rumbaugh 获得了 IBM 杰出工程师的称号。作为面向对象建模的奠基人之一，他与其他作者联合撰写了五本最热销书。他同时拥有四向专利，并在建模工具领域使 IBM Rational 的产品处于市场领先地位作出了重大的贡献。
Jim Rumbaugh 于 1975 年获得马萨诸塞州技术学院的计算机科学博士学位。
|
对本文的评价
| 
