本文内容包括：

为什么 IBM 创建 RUP for System z RUP for System z 路线图 RUP for System z Web 站点 总结 致谢 注释 参考资料

许多 IBM System z 环境中的软件开发实践者，一直以来都认为，迭代化开发和其它“现代”方法并不适合于他们的项目。 然而，IBM 不认为这样。 本文介绍了 IBM Rational Unified Process for System z （RUP for System z ）－－一个新的过程框架，专门创建用于支持 System z 软件开发项目的迭代化开发，同时适合于检验 System z 的开发工具和原则。

传统上，System z 环境上的应用程序开发一直遵循瀑布式生命周期。 今天，大多数软件实践者仍然相信，现代的软件开发实践，如迭代化开发和敏捷开发实践，并不适合于 System z ¹ 的环境。 为支持 System z 开发社区，以及更好地使用最新的技术，IBM® 将一个任务分派给一个专家团队，他们既代表传统 System z 又代表现代开发实践社区，这项任务是阐述一种方法，将当前在使用的软件开发实践部署到 System z 环境中，同时也包括现代开发原理和工具。 本文介绍了这项工作的精要： IBM Rational® Unified Process® for System z RUP® for System z ） ² 。

RUP for System z 提供了特定软件开发实践的指南，和一个简洁的专用于 System z 环境的端到端的过程。 RUP for System z 包括大量的工作产品范例－－大多数是使用 IBM 工具产生的 －－ 取自于使用 CICS ³ COBOL 创建的一个应用程序，并展示为 Web 服务，使用 CICS Web Services Assistant 和 Enterprise Generation Language (EGL) ⁴ 。

RUP for System z 关注“绿色区域”开发，还有涉及架构变更（例如，包括将一个已有功能转换为一个 Web 服务），或对已有业务过程的重大影响。 但是，纯粹的维护活动在 RUP for System z 的范围之外。有关在维护项目中使用 RUP 的更多信息，请参见 IBM Rational Unified Process for Maintenance Projects ⁵ 。

RUP for System z 面向于整个 System z 应用程序开发社区，包括从项目经理，架构师和设计师，到编程人员和测试人员。 它覆盖了 System z 环境的整个端到端的开发生命周期。

RUP for System z 是迭代化以及风险驱动的。 它着重强调了在每个迭代中增量地开发实际的软件系统，这与产生项目相关文档是相反的。 这促进了反馈和中途纠错，以及支持了整个开发团队之间的协作。 这种方法集中强调对现存资产的评估，以及在项目早期稳定架构和任何高风险的元素，从而避免了可能导致项目失败的问题的出现。 它也通过推荐对运行系统进些早期和持续评估，来强调质量。 用户，顾客，以及其他涉众参与到评估过程众，以确保项目成果是可用的，并将满足涉众的期望。 换句话说，RUP for System z 包含了与敏捷开发社区相关的大多数价值和实践。

按照对为何 IBM 创建了 RUP for System z 的讨论，本文通过一个路线图的方法进行了介绍，指导您贯穿一个典型 System z 开发项目的生命周期。 对 RUP for System z Web 站点的介绍，也包括使您熟悉在将此方法开始应用到您自己的项目时所需要的所有内容。

为什么 IBM 创建 RUP for System z

System z 比任何简单的计算环境存在了更多年，仍然在广泛地使用着。 它的开发社区在创建和遵循应用程序开发方法论方面一直是倡导者，一直认识到过程是持续产生高质量软件的一个必要条件。 然而，尽管自从 1990 年以来，在 System z 应用程序开发环境中所使用的方法论已经进行过几次变化，但是这些改变一直很大程度上与传统的瀑布式开发生命周期模型相关。 到目前为止，一直普遍认为，现代开发方法论，例如 RUP，只适用于面向对象编程的领域。

近些年来，在软件开发的范围和速度，以及相关工具和语言上，已经有了巨大的变化。 在当前随需应变的业务环境中，IT 组织处于巨大的压力之下，需要尽可能敏捷地响应业务需求，以及使用快速、准确和高质量的产品满足用户需求。 最终，运行 System z 的组织面临着将传统的和随需应变的需求进行整合的问题，总结如表 1 所示。

表格 1： 问题陈述
　

整合问题	传统需求： 使用大量关键业务应用程序支持海量的，事务处理环境。 随需应变需求： 维护灵活性，响应度，持续高质量，能够平衡已有资产，能够满足业务和用户需求。
影响	跨 IT 环境影响 System z 的组织。
相关影响	带有缺陷应用程序的开发和不能优先交付关键业务和目标。
一个成功的解决方案将会	改善灵活性，响应度，质量，用户满意度，竞争力和 ROI。

要解决在表 1 所定义的问题，IBM 近来组织了一个专家团队：

• 利用当前在 System z 环境中使用的软件开发实践以及现代开发原则，开发一种方法
• 基于 RUP ⁶ 上的新方法，以及面向服务的扩展（IBM Rational Unified Process for Service Oriented Modeling and Architecture，或 RUP for SOMA ⁷ ）
• 关注于绿色领域开发，以及带有架构变化的系统演进，或者对已有业务过程的重大影响
• 使用一个来自于 CICS COBOL 应用程序的案例研究证实方法
• 显示 EGL 如何用于创建一个 Web 接口
• 显示 IBM 工具如何帮助实现新的方法
• 如果必要，提供如何定制方法的信息
• 交付新的方法，既作为一个 IBM Rational Method Composer ⁸ 插件，也作为一个 IBM 红皮书

成果就是在本文中所描述的 RUP for System z 。 RUP for System z 是基于 RUP 的一个适用于任何软件开发环境的，包含所有现代过程的框架。 RUP for System z 支持了适用于 System z 的 RUP 的一部分子集，同时增加了特定于 System z 开发环境的方法元素。

RUP for System z 路线图

RUP for System z 路线图遍历了一个典型 System z 开发项目的所有阶段（先启，精化，构建和产品化）。 RUP for System z 生命周期如图 1 所示。路线图提供了对途中每个元素的一个概览。

图 1： RUP for System z 路线图

图 1 中每个迭代中的活动可以顺序或者按照任何次序执行。 事实上，在 RUP 中，一次迭代不一定是一个活动序列；它可以是一个活动的多方面组合，包括一些可能并行完成的活动。

先启阶段

先启阶段的主要目标是在项目范围内的所有涉众之间达成一致，以确保项目是值得做并且是可能做的。先启阶段包括了达到生命周期目标里程碑的许多迭代。

在先启阶段的一个典型迭代包括以下活动，如图 1 所示：

• 构思新项目。 这项活动将项目从一个想法的初始雏形带到一个合理的决策点上，以决定继续项目或是废弃项目。
• 准备项目环境。 此项活动为项目准备了开发环境，开发环境既包括过程，也包括工具。
• 定义需求。这项活动涵盖了项目远景的定义。 它驱动了系统范围的一致，并概括出了核心需求。 需求可以使用用例的形式进行描述。 在先启阶段，主要的用例被识别出来，并被简要描述。 不适合放在用例中的需求（功能性和非功能性）应当在补充规约中进行文档化。 一旦确定了一些用例和补充规约，就可以决定它们的开发次序。 例如，描述一些重要功能的用例，包含重要架构覆盖（例如，它们运用了许多架构元素）的用例，以及说明或强调一个特定且重要的架构点的用例，将会被首先开发。
• 执行构架概念论证。 此选项活动关注于通过构建一个架构概念论证来证明解决方案的可行性，并评估架构上重要需求的生存力。
• 计划项目。 此项活动从当前迭代的评估和风险的重新评估开始进行。 它提炼了软件开发计划（覆盖了所有项目阶段和迭代），并创建了一个良好而成熟的迭代计划，用于下一个迭代或以后的迭代。 此项活动也驱动了必要资源（包括人员）的获取，以执行即将到来的一个或多个迭代。

在先启阶段的末尾，生命周期目标里程碑按照以下的标准来评估项目：

• 在范围定义上的涉众协作
• 正确的需求集已经被捕获的协定
• 成本或进度估算，优先级，风险以及开发过程是否合适的协定
• 所有风险已经被识别，并且每个风险都有缓解策略的协定。

在先启阶段里程碑处的一些基本工作产品的状态是：

• 业务用例（100％完成）
• 远景（几乎100％完成）
• 词汇表（大约40％完成）
• 软件开发计划（大约80％完成）
• 首次精化迭代的迭代计划（计划100％完成）
• 风险列表（大约25％完成）
• 用例模型（大约20％完成）
• 补充规约（大约20％完成）
• 测试计划（大约10％完成）
• 软件架构文档（大约10％完成）
• 构架概念证明（一个或多个概念论证原型可以用于处理非常特定的风险）

精化阶段

精化阶段的主要目标是对系统架构进行基线化，为在构建阶段中的大量设计和实现工作提供一个稳定的基础。 这个构架的稳定性是根据一个或者多个构架原型来评估的。 精化阶段包括许多生命周期构架里程碑处的迭代。

在精化阶段的一个典型迭代包括以下活动，如图 1 所示：

• 提炼需求。 此活动以用例的形式详细说明了系统的需求。 只有在当前迭代范围内的用例被详细描述，以达到迭代的目标。 余下的用例将在后续的迭代中被详细描述。 不适合放在用例中的需求（功能性和非功能性）应当在补充规约中进行详细描述。
• 定义架构。 此活动从定义一个备选架构（初始的系统组织结构）开始，识别可重用资产，定义架构模式，识别架构上重要的用例，以及在每个上面执行用例分析（也称作用例实现）。 此活动包括识别必要的概念分析元素，以表示每个用例的行为。 一旦定义了一个备选架构，就可以通过从分析活动转到设计活动，来精炼架构。 概念分析元素被细化成为设计元素，比如模块或者类（例如，图 4 中的模块的例子）。目标也是描述系统运行时的组织结构和部署架构，并维护架构的一致性和完整性。 此活动以最终架构的评审作为结束，在软件架构文档中进行文档化。 注意，架构和设计使用统一建模语言（UML） ⁹ 进行文档化。 UML 图允许您建模面向对象和非面向对象的元素，如模块。
• 设计组件。 此项活动主要关注在迭代计划的识别范围中的一个或多个组件的详细设计。 当包含服务时，此项活动使用服务元素来提炼设计。 当包含数据库时，此项活动识别出要在数据库中保存的设计元素，并设计相应的数据库。 当包含用户界面时，此项活动对用户界面进行模型化和原型化。 此项活动以最终设计的评审作为结束，在设计模型中进行文档化，并且可以选择其它支持模型，如服务模型。
• 编码和单元测试组件。 此项活动完成了一部分实现，可以交付至集成。 它通过编写源代码，采用已有源代码，编译，链接以及执行单元测试，实现设计模型中的元素。 如果发现了设计中的缺陷，设计上的返工反馈将被提交出来。 此活动也包括修复代码缺陷和执行单元测试，以验证变更。 代码将被评审，以评估质量以及对编程指南的遵循性。
• 集成和测试。 此项活动涵盖了产品的集成和测试。 集成子活动集成了来自多个实现的变更，以创建一个实现子系统的新的和一致的版本。 对于在迭代范围内的所有实现子系统，都要完成此活动。 当合适时，此活动也要集成实现子系统，以创建最终系统的一个新的和一致的版本。 测试子活动包括了特定范围内的测试所要求的任务。 范围可以是一个给定的测试级别或测试类型，例如功能验证测试（FVT）或系统验证测试（SVT）。 它可能也受限于组件或部分组件，这些组件已经在迭代中被实现了或被计划要实现。 它包括测试计划的改进，测试用例的定义以及将它们实现为测试脚本（一个测试脚本就是能够执行一个测试用例的一步一步的指南），测试的执行和评估，以及产生的问题的相应报告。 它也包括安装验证过程（IVP）的定义和实现。
• 计划项目。 参见上面的迭代阶段。

在精化阶段的末尾，生命周期架构里程碑按照以下的标准来评估项目：

• 产品需求和架构是稳定的。
• 在测试和评估中所使用的关键方法是被证明的。
• 可执行原型的测试和评估已经被证明，主要的风险元素已经被确定，并且已经实际被解决。
• 构建阶段的迭代计划足够详细，使得工作可以继续开展，并被具体的估算所支持。
• 在当前构架的背景下，如果执行当前的计划能够开发完整的系统，所有的风险承担者们都认为愿景是可以满足的。
• 实际的资源花费相比已计划的花费是可接受的。

在精化阶段里程碑处的一些基本工作产品的状态是：

• 词汇表（大约80％完成）
• 软件开发计划（大约95％完成）
• 构建迭代的迭代计划（几乎100％完成，至少是第一次迭代）
• 风险列表（大约50％完成）
• 用例模型（大约80％完成，取决于迭代目标）
• 补充规约（大约80％完成，取决于迭代目标）
• 软件架构文档（几乎100％完成）
• 设计模型（大约60％完成）
• 服务模型（大约60％完成）
• 测试计划（大约30％完成）
• 测试用例（大约40％完成）
• 测试脚本（大约40％完成）
• 实现元素，包括源代码（大约40％完成）
• 构建是可用的（例如，一个或多个迭代）。
• 一个或多个可执行架构原型是可用的（以查看重要功能和架构上重要的场景）。
• 安装验证过程（IVP）（大约80％完成）

构建阶段

构建阶段的主要目标是完成基于已基线化构架的系统的开发。 构建阶段包括许多初始操作性能里程碑处的迭代。

在构建阶段的一个典型迭代包括以下活动，如图 1 所示：　

• 提炼需求。 此项活动以用例和补充规约的形式，完成了系统的详细需求。
• 设计组件。 此项活动完成了在迭代计划的识别范围中的组件的详细设计。
• 编码和单元测试组件。 此项活动完成了绝大部分实现，它们可以被交付至集成。
• 集成和测试。 此项活动涵盖了产品的集成和测试，如精化阶段所描述的。
• 准备部署。 此项活动定义了部署计划。 其目的是确保系统被成功地送达到用户。 部署计划提供了一个详细的事件进度计划，人员职责，以及必要的事件依赖，以确保对新系统的成功完成。 此活动也包括了用户支持资料的首个草稿版本，以及其它附属资料，包括用户学习、安装、操作、使用和维护系统所需要的全部范围的信息。
• 计划项目。 参见上面的迭代阶段。

在构建阶段的末尾，初始操作里程碑按照以下的标准来评估项目：

• 产品发布是足够稳定和成熟，可以在用户环境中部署吗？
• 是否所有涉众都准备好迁移到用户环境中？
• 是否实际的资源花费相比已计划花费仍然是可接受的？

在构建阶段里程碑处的一些基本工作产品的状态是：

• 词汇表（几乎100％完成）
• 软件开发计划（几乎100％完成）
• 产品化迭代的迭代计划（几乎100％完成，至少是第一次迭代）
• 风险列表（大约75％完成）
• 用例模型（几乎100％完成）
• 补充规约（几乎100％完成）
• 设计模型（几乎100％完成）
• 服务模型（几乎100％完成）
• 测试计划（大约90％完成）
• 测试用例（大约80％完成）
• 测试脚本（大约80％完成）
• 实现元素，包括源代码（大约95％完成）
• 构建是可用的（例如，一个或多个迭代）。
• 可执行系统是可用的。
• 安装验证过程（IVP）（大约90％完成）
• 用户支持资料（大约40％完成）

产品化阶段

产品化阶段的主要目标是确保软件对其用户是可用的。 它包括对准备要发布的产品的测试，以及基于用户反馈对软件进行的较小的调整。 此阶段主要关注在产品，配置，安装和易用性问题的细微调整。 产品化阶段包括许多产品发布里程碑处的迭代。

在产品化阶段的一个典型迭代包括以下活动，如图 1 所示：

• 编码和单元测试组件。 此项活动完成了所有系统实现的剩余部分，它们可以被交付至集成。
• 集成和测试。 此项活动完成了产品的集成和测试。
• 执行 Beta 和 验收测试。 此项活动涵盖了产品的 beta 和验收测试。 Beta 测试需要在产品仍处于开发状况下时，来自那些有意愿的用户提出的反馈。 Beta 测试为产品提供了一个受控的，真实世界的测试，这样，来自潜在用户的反馈可以用来形成最终的产品。 它也为有兴趣的顾客提供了下一个发布版本的预览。 验收测试确保产品在正式发布之前，被顾客认为是可接受的。
• 打包产品。 此项活动构建和打包要发布的产品。 它产生出所有需要有效地学习，安装，操作，使用和维护产品的工件。
• 计划项目。 在最后的项目迭代期间，要为项目验收评审准备一个最终的状态评估，如果评审成功，将标记为顾客正式接受软件产品的点。 然后，项目经理通过安排遗留资产和重新安排遗留人员，完成项目关闭。

在某些情况下，可能需要更新系统需求和设计。 但是，任何重要的变更，应当被延迟到未来产生的解决方案，以维护其稳定性。 参见上面对精化阶段有关提炼需求和设计组件活动的讨论。

在产品化阶段的末尾，产品发布里程碑按照以下的标准来评估项目：

• 用户满意吗？
• 是否实际的资源花费相比已计划花费是可接受的？

在产品发布里程碑处，产品处于生产之中，并且发布后的维护周期开始了。

在产品化阶段里程碑处完成的一些基本工作产品包括：

• 风险列表
• 测试计划
• 测试用例
• 测试脚本
• 实现元素，包括源代码
• 部署单元
• 构建
• 用户支持资料
• 安装验证过程（IVP）
• 产品

RUP for System z Web 站点

本章介绍了 RUP for System z Web 站点，其从头至尾，用不同的详细程度详细地描述了开发过程， Web 站点可以产生出 RUP for System z 的 Rational Method Composer 插件。 ⁸

RUP for System z Web 站点（参见图 2）的欢迎页面放在以下三个章节：

• 学习 RUP for System z 。 本章包括与 RUP for System z 有关的学习和介绍性资料。它主要面向初学者。
• 实现 RUP for System z 。 本章包括帮助您实现您的项目的 RUP for System z 的资料。 它面向高级实践者。
• 定制 RUP for System z 。 本章包括帮助您定制 RUP for System z 的资料，如果需要，以更好地满足您的项目需要。 它面向项目经理和方法设计师。

图 2： RUP for System z Web 站点的欢迎页面

除了这三个章节之外－－学习，实现，定制－－要最好地满足不同读者的需要，Web 站点详细说明了 RUP for System z 的端到端的生命周期。 它以不同的详细程度，从头至尾地描述了一个开发过程，如图 3 所示。在最高层上，一个概览图展示了大的景象。 最低层显示了完整的交付过程，包括一个详细的工作分解结构（WBS）。 在这之间是一个路线图－－提供了对初学者的一个文本化的过程描述，还有一个过程基础页面－－包括大多数表格，其被设计用来为高级实践者提供所有链接，他们需要这些链接，通过执行一个精确的活动或任务来达成一个特定目标。

图 3： 生命周期以不同的详细程度，展示给不同的读者

Web 站点的这三个章节－－学习，实现，定制－－的描述如下所示。

学习 RUP for System z

本章包括如下主题：

• 介绍 RUP 及其 SOA Extension。 本章介绍 RUP，包括一些软件开发 ¹⁰ 的关键现代基本原理，以及其面向服务架构（SOA）的扩展（RUP for SOMA）。
• 为什么需要 RUP for System z 。 本章阐述了创建 RUP for System z 背后的基本原理。也描述了传统瀑布式开发模型和 RUP 迭代开发模型之间的主要差异。
• RUP 和 z 的术语映射。 本章将 RUP 术语映射到 System z 软件开发过程中所使用的等价的术语，以简化迁移到 RUP 时的学习过程。
• RUP for System z 路线图。 与本文中所采用的方法类似，路线图遍历了一个典型 System z 开发项目的所有阶段（先启，精化，构建和产品化）。

实现 RUP for System z

本章包括如下主题：

• 过程基础。 本页面为高级 z 实践者提供了用以执行特定活动或任务的所有必要的链接。 这是您的过程的简要说明！
• RUP for System z 端到端生命周期。 此交付过程是 RUP for System z 端到端生命周期的一个例子。 它包括使用活动图进行说明的工作分解结构。 它可以被直接使用或复制和修改，以适应您的项目的需要。
• Catalog Manager 案例研究。 此案例研究提供了一个使用 RUP for System z 的 CICS COBOL Catalog Manager 应用程序的开发模拟。此应用程序使用 CICS Transaction Server3，并被设计用以说明 CICS 应用程序作为 Web 服务的最佳实践。 要证明此方法，我们向已有应用程序增加了一个用例（Replenish Inventory），我们创建了 COBOL 代码，并且我们将其作为一个 Web 服务。

此案例研究包括许多工作产品范例，从业务用例到源代码，以整个项目生命周期的不同完成状态进行显示，如表 2 所示。

表 2： 在 RUP for System z 中不同完成状态的工作产品范例
　

工作产品	先启	精化	构建	产品化
业务用例	100%
愿景	100%
词汇表	40%
软件开发计划	80%	95%	100%
迭代计划	E1 100%
风险列表	25%	50%	75%	100%
用例模型	20%	80%	100%
补充规约	20%	80%
软件构架文档	10%	100%
分析模型		50%	100%
设计模型		60%	95%
服务模型		60%	95%
测试计划	10%	30%	90%
测试用例和测试脚本		40%	80%	100%
源代码			95%
安装验证过程		80%

Catalog Manager 案例研究的大多数工作产品已经使用 IBM 工具产生了。 在项目过程中使用了以下工具：

• IBM Rational Software Architect 被用于创建 UML 模型： 用例，分析、设计以及服务模型。 IBM Rational Software Modeler 也已经被使用了。 图 4 显示了一个使用 Rational Software Architect 创建的类图/模块图。 注意，模版使用了原型 <<Module>> 进行模型化。

图4. Catalog Manager Replenish Inventory 类图/模块图

• IBM Rational SoDA® 被用于在 Rational Software Architect 或 Rational Software Modeler 中产生一个用例模型调查报告。
• IBM Rational RequisitePro® 被用于文档化和管理需求。
• IBM WebSphere® Developer for zSeries (WDz) 被用于测试 Catalog Manager Web 服务客户端，如图 5 所示。

图 5： 激活 Catalog Manager Replenish Inventory Web 服务

• IBM Rational Manual Tester 被用于执行测试用例。
• IBM Rational Functional Tester 被用于自动化测试集。
• Rational Method Composer 被用于将 RUP for System z 工作分解结构导出到一个 IBM Rational Portfolio Manager 软件开发计划中。
• IBM Rational Portfolio Manager 被用于裁剪 Catalog Manger 项目的软件开发计划，以及详细说明迭代计划。
• IBM Rational ClearCase® 和 IBM Software Configuration and Library Manager 被用于进行配置管理。

最后，此案例研究说明了如何快速而简单地将 EGL ⁴ 用于开发 Catalog Manager 案例研究应用程序的 Web 接口。

定制 RUP for System z

本章包括如下主题：

• 为什么定制 RUP for System z 。 此指南讨论了定制 RUP for System z 的基本原理。
• 如何创建一个特定于您的项目的项目计划。 此指南提供了如何为您自己的项目创建一个项目计划的信息，通过修改从 Rational Method Composer 导出的一个项目计划。
• 如何使用 RMC 定制一个过程。 此工具向导提供了如何使用 Rational Method Composer 定制一个过程的信息，可以帮助更好地满足您的项目或组织的需求。

更多的有关方法的开发和定制的信息，可以参见 Rational Edge 的文章“方法开发的路线图” ¹¹ 和 Rational Method Developer 培训课程 ⁸ 。

总结

RUP for System z 为实践者提供了一个端到端的生命周期，其可以很容易在 z 上实现，因为它是简洁的，并有众多的范例。 事实上，它包括了一个完整的案例研究，来自于一个作为 Web 服务的 CICS COBOL 应用程序。 案例研究包括了在整个项目生命周期，以不同完成状态显示的众多的工作产品，并证明了 IBM 工具如何被用于创建这些工作产品。

RUP for System z 生命周期包含了现代的软件开发基本原理，以及在 z 环境中当前所使用的实践。 还句话说，RUP for System z 使顾客能够利用 Rational 在软件工程领域二十五年来的经验和现代软件开发实践，以及 IBM 的在 z 环境中开发应用程序的长期经验。

最后，值得提到的是，RUP for System z 生命周期可适用于 System z 范围的外部，适用于任何使用程序化编程语言的开发。

致谢

我们想感谢所有审核人员的贡献，感谢他们对这篇文章初稿的深刻见解。 特别感谢 Joe DeCarlo，他在加利福尼亚圣何塞，领导 IBM 的 RUP for System z 项目。

注释

¹ IBM System z Web 站点： www.ibm.com/systems/z/

² 有关 RUP for System z 的更多信息： - RUP for System z 插件
- Cécile Péraire，Mike Edwards，Angelo Fernandes，Enrico Mancin 和 Kathy Carroll。 The IBM Rational Unified Process for System z 。 IBM 红皮书 SG24-7362-00，2007： www.redbooks.ibm.com/

³ CICS Transaction Server

⁴ Enterprise Generation Language 资源

⁵ RUP for Maintenance Projects 插件

⁶ Per Kroll 和 Philippe Kruchten。 The Rational Unified Process Made Easy： A Practitioners Guide to the RUP。 Addison-Wesley，2003年。

⁷ RUP for Service Oriented Modeling and Architecture V2.4

⁸为了解更多有关 Rational Method Composer 的信息，请查看以下资源：
- IBM developerWorks 上的 Rational Method Composer 产品资源页面
- IBM developerWorks 上的 Rational Method Composer 7.1 插件
- Per Kroll，“IBM Rational Method Composer 介绍”，The Rational Edge，2006 年 2 月。
- Peter Haumer，“IBM Rational Method Composer: 第 1 部分：关键概念”，2006 年 3 月。
- Peter Haumer，“IBM Rational Method Composer: 第 2 部分：创建方法内容和过程”，2006 年 4 月。
- IBM Rational 培训课程 PRJ350v2： Essentials of tailoring methods with IBM Rational Method Composer v7.0.1: 9。

⁹ 统一建模语言资源中心

¹⁰ Per Kroll 和 Walker Royce，“业务驱动开发的关键原则”，Rational Edge，2006 年 1 月。

¹¹ Cécile Péraire，“方法开发的路线图”， Rational Edge，2007 年 4 月。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。

讨论

• 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里 开始。
• 全球 Rational 用户组社区