级别: 初级 Peter Haumer, Solution Architect, IBM
2006 年 4 月 15 日 本文来自于 Rational Edge：对新的 IBM Rational Method Composer（RMC）的介绍的第二部分详细说明了在RMC中定义内容和过程的概念，并用实例解释了对方法内容编目和定义过程。
 上个月，我发表了两部分文章中的第一部分 ，介绍了新近发布的IBM Rational Method Composer (RMC)的重要概念的讨论和典型的RMC使用环境。这个月，我将在第二部分中提供更多这个概念的细节，它们在RMC中定义了方法内容和步骤。开始，我将回顾三个主要部分来建立方法内容和关系--即，角色，任务，和工作产品。然后，我将探讨指导和RMC所支持的各种不同类型的指导。我将展示给你如何用标准的和用户定义的类型去组织方法内容的目录。接着，我将在RMC中定义过程，给你提供一个关于RMC过程表示的原理，并且举一个你可以在RMC中使用和创建的不同种类过程的例子。
智力资本和资产作为方法内容和指导进行管理 让我们考虑一下建立方法内容的三个主要方面和关系--角色，任务，工作产品。 角色，任务，工作产品 在软件工程文献中最普遍引用的就是“软件的发展是一项团队运动，”17 指出开发者创造了软件，他们以合作和彼此交流工作成果来不断发展。在某种意义上，RMC 应用了非常普通，甚至标准的方法来定义开发的方法，18 正如 图 10 描述的, 通过定义开发角色，表示一组相关技能集合，资格和开发团队的责任。这些角色匹配于某种类型的工作产品：例如，开发者对源码负责，或者系统分析师对用例规范负责。为了创建和修改工作产品，角色被分配来执行某种具有输入输出的工作产品类型的任务。  图 10: 角色，任务，工作产品的核心方法内容概念的简化概念模型。 有经验的 Rational Unified Process ®， 或 RUP®， 使用者将意识到我们在之前的RUP版本中用 "活动（activity）" 来代替"任务（task）"。 我们改变了在在内容方法下的一些术语，正如我在第一部分中所描述的Unified Method Architecture (UMA) 和 SPEM 2.0 部分，来更好的反映这些术语的工业用法，提供更加紧密的过程制定和项目管理方法的连接。 并对比之前版本的RUP，RMC的一个新功能就是你可以设置一个多角色的任务。这强调了软件工程的协作属性，因为多任务需要不同技能，不同背景的人们共同完成。例如，一个叫作“划分需求优先级”的任务需要来自不同角色的技能和专业知识。你需要系统分析师的技能去表达最终用户的需求和优先权。你需要架构师的技能去为项目经理评估可行性和成本，并由此确定成本/收益比率。你还需要项目经理的技能来评估有多少开发资源和技能能够被获得，以对不同迭代进行资源分配和需求实现的优先级划分。所以，划分需求优先级就需要具有不同能力的人之间的协作。在之前版本的RUP建模方法中，我们被迫分配一个任务到三种角色中的一个或者创建一个新角色来满足这些技术，由此导致了大量的特定角色。在 RMC中，你可以分配你需要的所有角色给任务，并且清晰的定义执行工作所需的技能。实际上，当在一个项目中执行某个工作时，项目经理仍然可以决定是否一人一个角色或者一人同时执行多个角色。 RUP用户将注意到的另外一个改变就是工作产品的概念替代了 工件。 RUP仍然定义了工件，但是工作产品在RMC中已作为一般化的概念，它支持多于两种工作产品类型：可交付物和成果。可交付物被用来打包其他工作产品，交付到内部或外部团体。他们定义了以典型的或推荐的工作产品选择和某种可交付的文档形式的内容。成果是一种无形的工作产品，它们是一种结果或状态，如一台已安装的服务器或优化的网络。成果和工件最重要的区别是成果不是作为可重用资产的候选者。 将方法描述映射到方法内容中 在 第一部分 中，我解释了方法内容，它是一种展示软件工程文献中的基本开发方法和技术成果的方式，在RMC中它是通过角色，任务，工作产品的概念来表达的。例如， Rational Unified Process 覆盖了那些重要的开发规程中使用的所有开发方法。 例如： 用例分析。 许多书19描述了一个设计师如何从用例规范系统的创建面向对象分析模型。 开发并确定远景范围。另外一些作者20 已定义了一种方法来映射和交流涉众问题到业务需要再到项目的系统特性（需求）。 测试。 Cem Caner 等人已定义和发布了多种方法21来系统地进行测试计划，确定和设计测试方法，并进行系统回归测试。 类似的方法已由RUP内容团队从方法的来源映射到了一个或者多个任务上。如图 11展示的，每个任务由一连串相关执行角色和输入/输出工作产品和提供了额外的背景信息和细节的指导组成。  图11：执行用例分析的方法在RMC中被作为一个任务。此例子展示了一个任务如何被转换成HTML并且显示给RMC用户。在折叠部分提供了详细的步骤说明。所有的蓝色正文是相关方法内容元素的超链接。
点击放大 例如， 图 11 描述的是用例分析方法作为一个角色设计者所执行的任务是在 RUP中是如何表示的。这个任务把工作产品用例作为强制性的输入。它也包括了可选择输入的一些其他工作产品，像用例实现，分析类，术语表等等。作为工作产品的输出，任务定义了一个用例实现和分析模型组成的一个分析类。任务与不同的指导元素相连接，比如检查列表；特定技术（如执行用例分析）的指导方针；涉及诸如用例实现，分析类等的工作产品的细节的指导。最终，工具指导会描述如何使用诸如IBM Rational Rose, XDE, 或 Software Architect工具执行用例分析。 任务本身是一步步构成的，虽然这些步骤在执行中并不是按照严格的顺序。实际上，其中的一部分也许只在某种特别情况下才被执行，而且并不是对每一个用例都适用。例如，步骤"Reconcile the Analysis Use-Case Realizations"要求你已经至少执行了一次这个任务，才可以协调各个用例的实现。因此，步骤描述了任务执行者可选择的任务中的工作单位。正如你将在"使用 RMC 管理过程"部分看到的，实际上过程定义了某个时刻应该被执行的步骤。任务的步骤确定了执行过程中的各种不同的用例分析的方法，描述了为了实现任务的目标经过一个生命周期的所有工作。过程中方法元素的应用，提供了一种环境允许你决定方法的哪些部分实际上在生命周期的什么点上执行。 在RMC中定义和使用任务与软件工程中的定义有很多共同点。作为一个用例，一项任务应该具有清晰的目的，他可以让执行角色达到预先期望的目标。任务中的一个单独步骤（例如上例中的 "Create Analysis Use-Case Realization"），不能独立地提供价值。这个用例实现概念仅仅展示了在分析中的各项分析成分。所以，这是一种实现图11的分析任务的途径。 以清晰的目的定义任务对于确定和管理任务提供了相似的优势。涉众（例如过程执行者或开发者）与任务能够更加容易的联系起来，因为他们可以以更加全局的角度审视：为什么他们要做这项工作。定义和设置太多的低级工作单位不利于管理和交流。而且如果他们实现了对于发展目标的间隔划分，对于任务的交流和指导将变得更加简单。最终，执行一项任务的时间从小时到天。因此，过程评估不能靠计算任务数；它需要通过考虑各个单独任务来完成。（但是，建议你确定过程中发生的任务的估计，这些已在上文中提供了详细描述） 一个任务粒度的另一个规则是它一般只作用于一个或一小部分工作产品。换句话说，一项任务不应有太多的工作产品输出类型。在这种情况下，你也许会过细的定义一些本应合起来实现某个特殊功能的工作产品。也可以这么说，你的执行多个开发方法工作的任务应当被重新构成为多个分离的任务，以增加任务的可重用性，并关注于特定的目标。 对于用例，目的就是提供要达到任务目标所需的完整定义。这包括了二选一和任意选择的步骤。在这种意义上，对于用例的任务步骤表能确定过程中来源于不同"scenarios"的组合。设置对于任务的输入和输出工作产品关系在图 12中显示说明。为了完成用例类推，请注意任务中的执行角色不应和用例角色相互映射，因为角色是外部用户。角色象征了执行实际工作的开发者。所以，角色与在分析中的用例实现的控制组件或在商业中的用例实现的商人有相似之处。  图 12: 在RMC任务编辑中使用加号和减号按键设置输入输出工作产品关系
点击放大。 指导和分类 指导成分允许你增加额外信息使你的方法内容更加全面，且允许你加入更详细的描述，正像在 图 13 中的一样。RMC中支持的具体指导种类包括白皮书，目录，模版或术语定义。下面的第一张表完整的列出了所支持的指导种类。  图 13: 在RMC中指导与某个基于表格的编辑是同样合法的。这个图表展示了指导类型的编辑。基本上它包含了自由段落空间，允许像文档一样编辑白皮书。其他指导类型提供了更多特定编辑器；如，check item 编辑器被用来编辑检查表。
点击放大. RMC支持你像图 13一样以自由的方式进行比如指导元素的创建。然后你能通过简单的对话框在文档中创建链接，把指导与角色，任务或工作产品联系起来（例如，在步骤描述中，一个工作产品定义或另一个指导成元素的文字）或在独立参考部分中（如图 11的"More Information"段）。 表 1: RMC中支持的不同种指导类型。不同指导类与不同成分相关。例如一个模版仅与工作产品相联，而不与任务与角色相联。 The Rational Unified Process 提供了所允许的相关细节。| 检查单 | 确认需要完成或鉴别的条目。目录经常在预排或检查时使用。 | | 概念 | 要点主要方法与基本的相关原则有关。概念比指导方针涉及更多的一般要点，并且跨越工作产品和任务或活动。 | | 例子 | 提供一个完整工作产品或执行任务和活动的例子。 | | 指南 | 提供了如何执行某个特殊任务或组织任务的额外细节，或提供对工作产品和属性的额外细节，规则和推荐。 | | 实践 | 展示对工作产品或过程质量有积极的影响的策略。实践被垂直于方法和过程确定下来。他们能概述影响许多方法或某种过程的不同部分的方面。 | | 报告 | 自动产生的关于工作产品的内容提取的描述的模版。 | | 可重用资产 | 把已给的内容连接到一个已准备的解决方案。资产实例是设计模式或机制，框架的解决方案等。IBM Rational 的设计与工具支持资产打包与消费。 | | 路线图 | 复杂过程或活动的线形预排。(这是特定过程指导） | | 支持资料 | 其他类型指导的全部，不是在别处所特定定义的。它可以与全部内容成分相关联。 | | 模版 | 对于一个工作产品，提供一组预定义的内容，段落，包，头，标准格式，和段落包的使用描述。 | | 术语定义 | 定义术语且用来建立术语表。 | | 工具指导 | 表示如何使用某种工具独立或部分的完成工作。 | | 白皮书 | 与概念相似，但是可在外部回顾或发布且可在其他内容成分和指导中理解。 | 除了用指导来增补非正式的内容，你可以像图 14一样使用分类来组织和索引你的陈述内容。RMC 对于它的方法内容成分（诸如规则类任务，域类工作产品，角色设置组等）预定义了一组标准类。RMC 还允许你定义自己的类来确定你自己的逻辑组和对于角色，任务，工作产品和指导的陈述结构。你在RMC公布的内容中看到的所有树形结构都是基于这些分类的。它们本身的分类被认为是足够的成分（是的，有仍然可以按照它们自己分类），因为他们仍然可以包含丰富的细节描述来定义和概述分类。而且，你可以使用用户自定义类来创建自己内容的索引和目录。例如，你可以为CMMI22水准定义类，为基于这些水准的任务分类。  图 14: IBM Rational Unified Process的标准的和自定义的类的实例。 Disciplines 和 Role Sets 是对于标准类的例子。用户自定义类可以被用来对你的内容分类和为发布网页定义操控结构。 用Rational Method Composer管理过程 在文章的 第一段 ，我给了你在RMC中对过程的总的看法。在这部分，我们将看到创建过程的细节。我将讨论RMC如何使用可重复使用的建造块使你的工作过程更加便利 。我将展示给你如何创建混淆的方法内容和相关过程的具体方法内容。特别是，我们将看到如何对方法内容定义关联来指导你系统的完成你的过程。 RMC的过程表述的理由 发展过程定义了发展项目如何被执行。在大部分不同过程定义的文献中的一个共同属性，是各个阶段的顺序和产品的生命周期的关键点。过程还定义了如何通过定义工作，操作，或占用时间的顺序，专门技术或其他资源来发展，并最终产生成果。 诸如CMMI相关的过程框架定义了不同过程的成熟度水平。每个水平表示过程定义和工程制定的不同特性。例如， CMMI 定义了“已管理过程”，它能执行被识别出的活动。类似的过程有某种共同的特性：它按照策略执行；它使用高级技术人员，有足够的资源制造可控输出；它包括相关的涉众；他会是可监测的，可控的，可回顾的；并且可以评估过程描述。相反，“已定义过程”是一个从标准的过程裁减的管理过程。已定义的过程有一个进程描述且把工作产品，测试，和其他过程更新信息组合到过程资产中。 正如你将在此段看到的RMC过程支持许多属性。 正如我们之前看到的，方法内容是单独被定义的。它是作为一种为完成某种目的的用例来对待任务。为了创建过程，现在你需要定义在生命周期中有多少方式要被应用与排序。图 15 从概念上描述了方法内容（以任务，角色，工作产品三个主要成分定义）如何在生命周期中被应用。  图 15: 过程中应用方法内容。图表显示了方法内容如何用任务，角色，工作产品定义。 然而传统的基于瀑布式的研发过程能或多或少为任务定义直线型，但当今迭代的过程，诸如RUP, Scrum, 和 XP需要更复杂的结构来展现发展的增量。在这种结构中，工作被打包入可同时重复的块。 这些发展方法的变化仍然需要不同程度的规则和对过程描述的细节水平。传统的发展过程定义阶段基于预定义的可交付的类型，提供准确工作顺序的描述。快速发展过程仅需要非正规的工作描述，因为他们认为一旦目标被确定了，自我组织的团队能不受指导和控制。他们还很少注意面向可交付的工作的重复范围，而是专注于面向功能的关键点。最终，现今可升级的迭代过程提供了清晰的关于依靠工程类型和组织成熟度的工作的描述。 RMC 支持全部这些方法。 为了支持复杂过程结构和不同程度的形式，传统的迭代开发过程被设计成使用网状工作流程表示法。它允许你以层次化网状图定义复杂的过程结构，这些网状图的每个结点都能包含一个全新的网络图。例如，RUP 总和UML-like活动表一起定义过程。活动表能与工作一样表达相同的意思。他们还能使用控制流表达顺序。 第二种对于传统瀑布式和迭代开发过程的流行表述是工作分解结构。分解结构与网状活动图表相似，因为它们允许通过嵌套进行工作定义的精细化。他们使用一种被称为父级依赖关系的方式来排列工作，这种方法与控制流有些相似。通过这些父级节点，不相关的成分都可以自由的并行执行。另一个分解结构表示法的优势是他们在项目制定和管理应用方面非常流行，例如 IBM Rational Portfolio Manager 或 Microsoft Project。 在RMC中，分解结构支持在项目中连接过程定义和过程制定。 RMC综合了两种流行的活动图表过程表示方法和分解结构，形成了一种新的格式，它可以从内部表现过程。正如图 16展示的，基于这种格式，RMC 支持可交互的两种表达。  图 16: 对于同一过程结构的两种表达。过程先启阶段迭代不断出现在分解结构和活动图表中。如果可能，在一部视图里面的改变将会被转移到另一部视图。诸如在活动图表中的同步条一类的特定表达成分不会在分解结构中出现，但是适当的父级依赖关系信息仍然来源于依据简单图表规则的视图中。
点击放大 这里展示的例子用两种表示法描绘了Eclipse过程框架的基本统一过程在先启阶段迭代的过程。23一个RMC 过程工作者在任一个过程表达中工作，并且RMC将自动改变其他视图，因为每个视图来源于同一底层数据结构。当然，每个表述都不是完全相同的，都包括另一个表述所不具备的信息，例如在图 16的图表中的同步条和决定点就不在分解结构中。在这种情况下，另一个视图忽略了这个信息但是提供了一个连续图示，正如我们在图 16看到的父级依赖关系。例如，绘制从一个活动的到另一个活动的控制流链接或通过同步条在活动的分解结构间创建从结束到开始的父级依赖关系。正如你在图16顶部所看到的，父级节点根据图表里的控制流列出。例如，"Manage Requirements"和 "Determine Architectural Feasibility" 引用了元素四作为其父级节点。 创建一个带有分解结构的过程 例如传递过程或功能模式过程在RMC的过程编辑里作为网状活动的细目分类被创建。正像我们在上段中看到的，细目分类中的每一个活动能在活动图表中表示它的子活动。 所以，“活动”是定义过程的主要概念。你看到的过程编辑内部的许多成分来源于活动概念；换句话说，它们是活动的特殊作用。过程本身实际上只是特殊的活动，它允许过程在活动中嵌套。这提供了我们所定义的过程模式机制的实现。阶段和重复是作为RMC过程编辑中的活动被创建。你在RMC的过程中发现的唯一非活动的概念就是解释和重要事件。在RMC中以生命周期模型创建一个过程与在计划编制工具中创建一个计划非常相似。图 17 描述了一个如何使用定义阶段，反复和重要事件来开发RUP 或 BUP-like过程的例子。  图 17: 在RMC中使用分解结构为类RUP过程创建一个生命周期模型。这个屏幕截图还显示了“基于RUP过程”的顶层活动和允许你选择当前文档的活动图表。
点击放大。 正如你在 图 8中已看到的 (文章的第一段 )，展示了类似混乱的过程生命周期，你在RMC中没有被限制于使用类RUP生命周期模型，因为RMC 支持你创建几乎任何生命周期模型。 在图 17的过程中定义了四个阶段，因为它支持 RUP 生命周期模型。它的四个阶段不得不通过父级依赖关系顺序执行。在每个传递过程的阶段，你可以对于反复发生子活动。例如，在四个阶段中，如果每个阶段与其他的不同或者工作产品发展了，你可以以之前版本的过程为例，而不必以之后更详细的为例。举一个RUP的例子，之前的详尽工作需要在建立工作环境和初始化可执行结构方面作的比之后版本更好。 正像上面提到的，除了描述符和关键事件，在分解结构中的所有成分都是活动的，能有自己的活动图表，并且像在图18中似的能通过更多活动使其更精确。 图18展示了如何用高水平的四个活动来使先启迭代更精确。  图18：详细流程显示了：先启迭代活动如何被定义此类型迭代的高级工作的活动所改进。 同样的我们需要注意在右侧列中所提供的信息。除了先前提到的信息之外，建立这些活动的流程管理员同样也把一些被认为是正在进行的（在一个从这个流程起源的计划中，这些活动作为父类活动，动态的拥有相同的持续时间），可重复的（它们可以在序列中被执行许多次）或者拥有多重的事件（它们被不同的小组平行的执行许多次）的某些活动列入了清单。 一个和灵活的自组建小组工作的流程管理员，应该停下手中的工作，考虑图 18中所提到的流程是否完成了。这个流程通过定义阶段，不同的迭代种类，里程碑和高级活动的执行来提供了一个完整的开发流程。它或许仅仅提供了一个灵活的项目所需要的细节以及形式的数量。然而不管怎样，在接下来的部分中，我们将向您展示如何应用方法来满足你的流程。这种方法内容应该定义了：当任务作为这些活动的一部分被执行的时候，哪些工作产品应该被生产或者定义。这种方法参考提供了另外一种细目分类细节的级别，这个细目分类可以被用来计划或者执行流程。它们同时应该为开发小组提供一种指导服务，使他们不致于想要把这个级别的细节映射到一个项目中被计划和跟踪的工作中。 使用方法目录描述符来改进流程 一个RMC中的活动可以通过使用其他的嵌套活动和引用，改进成为方法目录调用描述符或者两者的结合物。一个描述符基本上就是一个流程中的引用对象，一方面它表现了一个活动中，象一个任务或者工作产品这样的一个方法目录元素事件。另一方面，它同时拥有自己的关系和文档属性，这些关系和文档属性定义了这个特定的方法目录元素和其他默认定义之间的区别。 例如，正如我们在图 5 (第一部分)中所看到的，一个任务可以通过简单地把它拖拽到一个活动的顶部，从而被RMC中的一个流程所应用。然而它并不是建立一个任务的拷贝，而是建立一个任务的描述符。这个描述符从任务中继承了特征和关系，使它可以被扩展和重写。这就使得每一个活动都定义了各自一系列的描述符。这种活动的每一个描述符都仅仅包含关系和信息，而这些关系和信息都是特定的情况或者它所应用的流程环境。例如，“项目经理”这个角色，通常是对一个不同产品（如项目计划，迭代计划，风险列表，产品项目列表等等）的长列表负责。项目经理这个方法目录元素角色列举了所有这些关系，提供了项目经理所应负责的工作产品的完整列表。然而，在一个特定的活动环境中，一个项目经理的角色描述符应该只会列出管理人员负责的工作产品，这个工作产品是这个活动在整个流程中这一点上的环境中的。把图 20上面的过程流程作为例子，你将看到项目经理角色被活动Manage the Project和活动Initiate the Project中的描述符说表示。在第一个活动的环境中，只有"Iteration Plan"和"Work Items"中的项目经理职责是相关的。而第二个活动完全没有处理这些工件，因此只有"Project Plan"的职责在这个角色描述符中显示出来了。 当添加描述符到一个流程时，你可以从概念上总体描述的图 15中所提到的三维的任何一维开始。RMC提供给你三种过程视图样式，有工作细木分类为中心的，工作产品为中心的和角色为中心的。不管你喜欢从哪里开始，RMC都可以在另外两维中支持你完成信息。RMC使用交互式的向导，它可以帮助你动态的从基于图 15左侧插图所示关系的方法目录中找回信息，并且向候选人建议建立额外的描述符。 例如，图 19显示了一个场景，它展示了流程管理员拖拽“项目经理”角色到活动"Manage the Iteration"中，从而表示了这个角色在这个活动中履行了工作。  图 19：在活动中应用项目经理角色后，RMC要求用户如果他想把任何工作产品添加到这个角色负责的流程。它通过检查方法目录中定义的关系来找回信息。用户选择了工作产品之后，RMC把它们作为工作产品描述符添加到流程，并且在它们之间建立职责关系。 为了指导用户在基于知识结构上完成活动，RMC已经在方法目录中被应用，RMC现在建议流程管理员进一步的添加工作产品到Project Manager负责的活动中。在图 19所示的例子中，流程管理员选择了“Work Items List”和“Iteration Plan”这两个工件。RMC为这两个工作产品添加描述符到相同的活动“Manage the Iteration”中，并且使得项目经理描述符作为这些工作产品描述符的职责角色。在添加这些新的工作产品描述符到流程之后，RMC继续提出意见（图 19中不可见的）。这一次，它促使所有的任务都把被选中的工作产品作为输出列出，因为这些任务都将被当作好的候选添加到流程中。 做出这些在RMC中添加描述符的选择，并没有迫使你经常的建立包括任务，工作产品和角色描述符的完整流程。你应该经常建立更加灵活的，轻量级别的工作流程，比如说在活动中仅仅包含被操作的工作产品，和图 20中所描述例子那样的工作产品的随意的角色职责。这个例子显示了较低的视图——我们在每一个活动中为工作产品描述符调用入口和出口状态。  图 20: 一个没有任何任务描述符的轻量级别的流程。图中显示了同个流程的两个视图。图中上部的Consolidated View显示了流程中细目分类的定义。每一个活动定义了执行的角色，同时也是工作产品的角色职责。Work Product Usage视图显示了流程的工作产品，为每个工作产品描述符在每一个活动中定义开始（入口）和结束（出口）状态。在这个流程中，相关联的角色的职责是负责把它们的工作产品从入口状态转换到出口状态。 入口状态表示了活动可以开始时，工作产品所应处的状态，出口状态定义了在活动可以结束之时，工作产品所应处的状态。在象上面提到的流程中，角色可以选择它们自己的方法，用来达到所需要的工作产品状态，而不需要按照形式的和说明性的任务描述那样做。当然，这些流程中仍然要包括足够的形式，用来定义哪些角色为哪些工作产品负责，以及所期望的结果是什么。 观点 在这两部分文章中，我介绍了一些我对IBM Rational Method Composer以及Eclipse Process Framework (EPF)工具的总体看法和一点想法。另外我还发表一篇更高级别的，关于上面两个方面的主要概念和性能的文章，在那篇文章中，我们反复的推敲，用详细的概念以及特定工具描述了这些概念。 为了能够更好的使用RMC以及EPF工具，我们推荐您浏览这些工具的在线帮助，这些帮助中包含了很多交互式的指南，它们可以给您一步一步地介绍如何执行这篇文章中所描述的场景。 RMC额外的应用和性能的介绍是超出这篇初级文章介绍范围的，我们将在接下来的The Rational Edge这篇文章或者IBM developerWorks/Rational的其他地方介绍。其它主题包含如何导入以及管理员文本文档；如何从不同的来源（特别是RMC的前身，IBM Rational Process Workbench）移植内容；以及如何为发表的结构建立分类的和导航的构造；如何使用动态模式绑定性能快速的汇集和裁剪流程；如何使用可变性和插件机制去扩展第三方内容和流程；如何作为计划模版从RMC导入流程到IBM Rational Portfolio Manager；以及如何利用版本控制系统，如IBM Rational ClearCase或者CVS来使用RMC。 感谢 如果没有很多充满激情和奉献精神的优秀的团队，就不会有现在发表的这篇文章。我在这里由衷地感谢：RUP开发小组，QA小组，RUP内容小组，RUP产品小组，IRUP小组，IBM Global Services Method小组，UMA指导委员会Rational领域的成员，以及其他IBM方法小组，Tivoli ITUP小组，以及来自IBM内外的所有早期改编人员和Beta用户，在最后当然还有ISSR为RMC和EPF做出的辛苦努力。 注释 17参见，例如，Walker Royce，Software Project Management: A Unified Framework。Addison-Wesley Professional，1998 18 OMG，"Software Process Engineering Metamodel," 1.1版, formal/2005-01-06, 2005 http://www.omg.org/technology/documents/formal/spem.htm 19 参见 I. Jacobson 等，Object-Oriented Software Engineering: A Use Case Driven Approach。Addison-Wesley, 1992; Peter Eeles, Kelli Houston, 和 Wojtek Kozaczynski, Building J2EE Applications with the Rational Unified Process。Addison-Wesley, 2002; 以及我自己的名为"Use Case-Based Software Development"的一章，在场景，故事，用例， 由Ian Alexander 和 Neil Maiden Wiley 2004年编辑。 20 Dean Leffingwell 和 Don Widrig, Managing Software Requirements: A Use Case Approach，第二版，Addison-Wesley 2003; 还有 Kurt Bittner 和 Ian Spence，Use Case Modeling，Addison-Wesley 2003。 21 Cem Kaner, Jack Falk, 以及 Hung Quoc Nguyen，Testing Computer Software，第二版。Wiley 1999。 22 Capability Maturity Model Integration。参见软件工程研究所的Web站点http://www.sei.cmu.edu/可以得到更多信息。 23 参见 Ricardo Balduino，"Basic Unified Process: A Process for Small and Agile Projects，" http://www.eclipse.org/proposals/beacon/Basic%20Unified%20Process.pdf Eclipse.org 2005。
参考资料 -
您可以参阅本文在 developerWorks 全球站点上的 英文原文。
关于作者  | 
| | Peter Haumer 是一位IBM Rational Method Composer 产品平台的架构分析师。他负责定义下一代过程工程工具，并展示了IBM在SPEM2.0 的OMG中所做的开创性工作。在加入Rational Unified Process小组之前，他是IBM品牌高级专业服务顾问。他提供在线咨询和培训，并且辅助和指导客户正确使用 Rational Unified Process 和其他 Rational 工具。他所涉及的领域包括需求管理，面向企业应用架构的面向对象分析与设计，和软件过程实施。加入Rational之前，他专注于基础研究，涉及的领域包括需求工程和可伸缩性的集成过程辅助软件工具架构。 Peter 获得了德国亚琛技术大学颁发的计算机科学博士学位。 |
对本文的评价
| 
