本文来自于 Rational Edge：这篇文章描述了一个迭代的、风险驱动的、以构架为中心的，以及面向质量的方法开发的方法，这源自于IBM Rational 统一过程（Rational Unified Process，RUP)开发团队的长期经验。它首先描述了这个工作产品的产生，然后阐述了一个在整个方法开发项目中逐步应用这个方法的路线图。这个方法利用了软件开发和RUP规程，能够使用IBM Rational Method Composer (RMC)来执行。
多年以来，IBM Rational Unified Process®，或者RUP®，团队一直采用“利用自己成果”的方法在开发方法框架，也就是说，运用RUP自己所提倡的规程、过程和技巧来进行软件开发工作。然而，开发一个像RUP一样的方法框架与开发一个软件应用程序并不完全一样。 1 这些年以来，RUP团队对于方法开发的具体需求已经适应了它自己的过程和技巧。 2 利用IBM Rational Method Composer 3 (RMC)的实用性，已经有越来越多IBM内部的团队和顾客开始规定或者自定义方法。因此，对方法开发的指导的需求也日益增长。
这篇文章基于我在RUP团队开发方法中的经验提出了一个方法开发的方法。这个方法通过一个路线图呈现出来，这个路线图可以指导您完成一个典型方法开发项目的整个生命周期。在这之后是方法与软件开发主要不同与相同点的讨论，还有方法开发项目过程中基本工作产品定义的介绍，我将从头至尾地谈到典型方法开发项目的每一个状态（先启、精化、构建，以及产品化）。
这篇文章介绍的方法开发的方法是迭代的和风险驱动的。我着重强调了每个迭代中以增量方式开发实际的方法，与简单地产生项目相关文档是对立的。这使得反馈和项目的计划或者指导等灵活性更加便利。这种方法集中强调对现有资产的评估，以及在项目早期稳定方法架构和任何高风险的方法元素，从而避免了可能导致项目失败的问题的出现。它还通过早期介绍，以及对此方法进行频繁的检查和测试强调了质量的重要性。
我已经在脑子里用RMC对这个被提议的方法进行了定义，既确保了这个方法与工具术语上的一致性，又保证使用RMC可以使这个方法很容易地被执行。无论如何，这种方法在RMC环境以外能够非常广泛地被利用。比如，您可以利用它编写一本方法书籍。
这种方法支持临时新方法的定义，还对现有方法有效自定义制定的支持，例如，将RUP延伸为面向服务的架构（SOA 的 RUP），或者将SOA的RUP延伸为System z (RUP for z)。然而，这种方法却不能解决将几个现有的方法整合统一化的问题， 4 就像在对一个已经破坏的构架或者项目计划修整的基础上对现有的已定项目的修改一样。
方法与软件开发
业务驱动开发的关键原则，就像Per Kroll和Walker Royce 5 对软件集约系统定义的那样，在方法的环境中仍然可以普遍适用。因此，他们能够很好地为改良的方法项目结果进行指导。这些原则是：
- 调整过程。正确确定这个项目需求的开发过程是十分关键的。并不是越多越好，也不是越少越好。而是，一个项目所应用的正式程序的数量，精确度以及控制必须根据各种因素来确定，这些因素包括团队的规模和分布，外部影响限制的数量，以及这个项目所处的状态。
- 平衡竞争涉众的优先权。平衡经常相冲突的业务和涉众的需求是十分重要的，同样，在这些需求满足的条件下平衡自定义开发与资产重新利用也很重要。
- 跨团队协作。 鼓励最佳的项目范围间的沟通非常重要。这可以通过正确的团队组织和设置有效的合作环境来完成。
- 迭代地展示价值。 一个反复的过程允许开发团队更好地适应变化，获得反馈并将它分解到项目中去，从而尽早地减少风险，动态调整过程。
- 提升抽象层次：提高抽象层的水平有助于降低复杂性和项目所需的文档的数量。可以通过重新利用，对高水平建模工具的使用，以及早期稳定构架来达到。
- 持续关注质量：在项目的整个生命周期都应该强调质量的重要性。由于迭代过程能够提供许多度量和修正机会，所以用它来达到高标准的质量是非常适合的。
在将这些原则应用到方法开发中时，非常重要的一点是要切记它与软件开发的不同和相同点。其中最大的不同可能是，方法开发强调生成文本的和图形的内容，这些都是靠网络连接连通的，而且支持图形模式；而软件开发强调的是产生代码。在方法开发项目中，没有必要编写和测试代码，但是仍然需要测试所有的连接。
许多软件需求技术对方法都是可适用的。比如用例，可以用来定义这个方法的范围，鉴别那些利用此方法达到他们目标的研制人的不同类型（例如，典型的用户），还可以详细说明这些研制人是怎样利用这方法来达到他们的目的的。可用性需求可以建立在用例方案和一些可用性因素的基础上（学习的简易性，对学习超时的保留，方案竞争的速度，或者主观满意度。）其它非功能性需求也十分重要，比如复杂性（调节方法水平的复杂性，从而使听众得到认可），组合型（将现有的插件方法组合起来的能力），或者本地化的能力（由于地域的差别，加强方法适应的能力）。
由于方法静态的特征，静态分析技术——尤其是方法检查——在方法质量中扮演了一个必须的角色。静态分析包括分析方法元素来检查他们是否对一些外在的或者内含的道具表示满意，比如内容正确性，良好的信息显示，或者与方法设计者指导法方针的遵从性。静态分析要么是人工的，比如检查，要么是自动化的，像拼写和语法校验。此外，动态验证技术的应用，像测试仍然是可用的。比如，如果研制人是通过网站得知这个方法的，测试可能包括一些功能性的测试（例如，方法要在用例环境下进行测试）和可用性测试（例如，用例环境是不同用户团队中用可用性因素来测试的）。
在构架和设计水平，方法开发与软件开发有许多相似之处。比如，构建一个方法库，像RMC包括RUP和它的扩展。为了提供整合性，增强灵活性和增加重新利用的机会，构架组织也应该能够做到松散地耦合与组件的高度粘合。方法架构一个非常重要的特征是它对变化和演变简易性的适应性能。方法是需要修改和额外的时间的，尤其是在当今拥有不断变化过程的世界。例如，您可能在某个时候为了合并遵从性和管理需要改变一个现有的方法。
最后，管理一个方法开发项目与管理一个软件开发项目并没有根本的不同。迭代与风险驱动开发的相同原则可以被成功地应用，并有助于团队集中关注交付增量价值的问题。然而，方法开发项目的特性是，它至少涉及到两个截然不同的生命周期：由方法开发团队执行的项目生命周期，以及构建阶段的方法生命周期。项目经理需要同时对这两个生命周期都比较熟悉，可以通过由一个人来扮演项目经理和方法设计人员两个角色来实现。
方法开发工作产品
这个部分呈现了在方法开发项目中产生的必需工作产品。我将那些对方法开发比较特殊的工作产品与那些跟大多数开发工作类型相关的产品区分开来（例如，为了分辨这个项目的图像和目录）。
特殊的方法工作产品
一个方法首先要根据方法元素来定义。一个方法元素有可能是一个内容元素（角色、任务、工作产品，或者内容指南），或者一个过程元素（活动、能力模式，交付过程，或者过程指南）。查看表格1对不同类型方法元素的定义。
表格1：方法元素的不同类型和定义
| 方法元素 |
| 内容元素 |
过程元素 |
- 角色。对一个或者几个单个人员相关技能，资格以及影响力的设置。
- 任务。工作的可分配单元。每个任务都被分配到一个特定的角色。
- 工作产品。任务中任何被使用的，产生的或者修改的事物。
- 内容指南。添加到内容元素中的补充信息（例如，模板、样例、工具向导，或者白皮书）。
|
- 活动。对任务以及它们相关的角色和工作产品进行分组。为过程展现关键的构架板块，可以用来构成效力模式或者交付过程。
- 能力模式。一系列可重新使用的活动。可以重新利用组成交付过程。
- 交付过程。端到端的完整项目生命周期。
- 过程指南。添加到过程元素的追加信息（比如，路线图）。
|
一个方法元素可以从两个不同的但是同等重要的角度来看：从方法设计师的角度，他定义了方法构架，因此可以确定方法元素和它们之间的关系；或者从方法作者的角度，他编写方法元素的说明（比如，文本的和图形的内容）。由于方法开发的大量精力都花费在编写方法元素上，所以第二个角度非常重要。由于这个原因，一个叫做方法元素描述（Method Element Description ）的分离工作产品被用来引用方法元素的内容（即使方法元素描述工作产品包含于方法元素工作产品中）。
另外其它具体针对方法开发的必要工作产品归纳在表格2中，并有负责每个工作产品的角色。关于这些工作产品的附加信息紧跟在表格2的后面。
表格2：方法开发必要的工作产品，以及它们相关的角色
| 工作产品 |
角色 |
方法纲要
方法的框架，确定候选方法元素，还可能包含一些它们之间的相互关系和早期的描述。 |
方法设计师
浏览所有方法的定义。同义词： 方法架构师、方法工程师、过程工程师。 |
方法定义
根据方法元素术语（包括他们的描述）和它们的相互关系对方法进行结构良好的定义，对一个或者更多的方法配置进行描述。 在RMC中，一个方法定义是一个复合的工作产品，包括所有的方法插件和与方法构建相关的方法配置。
- 方法插件
根据它的方法元素和它们的相互关系对方法组分（或者整个方法，如果仅用了一个组分来定义这个方法）进行结构良好的定义。
在RMC中，一个方法插件就是一个装载方法包的容器。
- 方法包 在RMC中，一个方法包就是一个装载方法元素（和其他方法包）的容器。
- 方法元素 内容元素（角色、任务、工作产品，或者内容指南）或者过程元素（活动、能力模式、交付过程、或者过程指南）。查看表格1中的定义。
方法配置
对方法结构的描述，或者这个方法的版本。
在RMC中，方法配置规定了如何在方法元素的基础上构建一个方法Web站点，包括对方法插件 和方法包的筛选，以及将在方法Web站点的树形浏览器中显示的窗口。
|
方法Web站点
方法开发项目的主要输出。它使这个完整的方法，或者方法框架能够顺利展现在一系列互连的网页上。
在RMC中，方法Web站点是自动从方法定义生成的（每个方法配置生成一个方法Web站点）。
注意这个工作产品是取决于图形模式的。例如，如果您正在编写一本方法书籍，那么这个方法Web站点就会被一本方法书取代。
|
方法元素描述
对内容元素的描述（比如，文本的和图形的内容）。 |
方法创作
编写方法元素的内容。 |
在这个项目的前期，推荐利用一个方法纲要来概述这个方法。方法纲要的目标是帮助团队鉴定候选方法元素和它们之间的一些关系，并为一些关键元素做出初始的描述。这种做法取决于这个项目的类型（从零开始创建方法，对现有的仅有内容元素的方法的扩展，对现有的有内容和过程元素方法的扩展等等。），方法纲要可能采取各种各样的形式。比如，它可能包括一个或者更多以下的元素：生命周期的预排，对候选角色的简洁描述、任务、工作产品，以及它们之间的关系；候选方法指导方针的列表（模板、例子、白皮书等等。）；早期的工作分解结构（WBS）；或者方法Web站点的模拟。方法纲要可能被存档于源代码中，文字处理器文件中、电子表格中，或者图像模式中，或者利用任何其它的支持。这个免费的框架意味着要鼓励创造性的思维，并允许团队利用内容、格式、符号来定义和检查方法中一些最初的拟定，对最适合它们的需求和技巧起支持的作用。一旦一个新的方法，或者部分方法开始在方法纲要中形成，这个时候就应该运行Rational Method Composer，整个方法可以被更正式更完整地被定义。这时就可以抛弃方法纲要，继续研究其它的观念，比如发展成一个方法路标（过程指导），或者发展成一个所有方法元素的列表。在以后某些时候，可以用它来分派责任和跟踪过程。
方法定义就是根据它的方法元素（包括它们的描述）和它们之间的关系对方法进行的一个结构良好的定义。方法定义同时还可以通过鉴别表现出一个或者更多结构或者方法版本，对于每一个结构，还可以鉴定研制人使用了哪些元素和怎样使用的。在RMC中，如图1所描述的那样，方法定义是一个复合的工作产品，包括所有的方法插件和被构建的方法相关的方法配置。换句话说，一个方法定义对应着被构建方法相关的RMC库子集。
方法插件是一个根据方法元素（包括它们的描述）和它们的相互关系对方法成分进行的结构良好的定义。在RMC中，一个方法插件就是一个方法包的容器，而这个容器反过来又包含着方法元素和其它潜在的包。方法插件和方法包允许在适当的粒度水平组织方法元素。这种水平的粒度需要脑子里自始至终对重新使用有相当仔细的考虑。的确，方法插件和方法包都是方法配置可重用的组分。
方法配置是对方法（如小项目的RUP和大项目的RUP）的一个版本的描述。在RMC中，一个方法配置可以规定怎样用精选的方法插件和方法包中的方法元素来组成方法Web站点（因为您可能不想公布在特定配置环境下这个方法所详细定义的所有方法元素）。这个方法配置同时还规定了将在方法Web站点树形浏览器中显示的窗口。
方法Web站点是一个方法开发项目的主要成果。它通过一系列相互连接的网页使最新定义的方法，或者方法框架能够展现给研制人员。在RMC中，方法Web站点是从方法定义（一个方法配置生成一个方法Web站点）中自动生成的。图2提供了方法Web站点的例子。注意整个工作产品所呈现的形式取决于表达模式。例如，如果您编写一本方法书，那么这个就会被一本方法书取代。
为了总结构成方法定义不同成分的角色，我将使用专门的打折销售成套书籍的书店来类比：一个方法插件可比作书店的一个部门（旅游、喜剧、儿童等等。），方法包可比作一套打包出售的书，方法元素可比作单本的书籍，方法配置可比作您的购书目录，方法Web站点可比作购物袋，您在购物结束后带回家的那些书。
图1：RUP for z 在 RMC 中的方法定义的例子，包括发布在RUP for z 方法Web站点的选定的元素
图1提供了一个RUP for z 的 RMC 的方法定义的例子，包括三个方法插件（rup、rup_for_soa 和rup_for_z，因为插件是通过扩展rup和rup_for_soa来定义的）和一个方法配置（RUP for z 配置）。尽管这个方法定义包含三个方法插件，但是只有一个rup_for_z插件在RUP for z方法开发成果的范围之内。（rup and rup_for_soa在范围之外是因为它们在这个项目过程中没有被修改）。RUP for z 配置决定了RUP for z发布在网站上的内容。在整个简单的例子中，这个网站将包括rup的方法内容包的内容元素（rup的Processes包已经被过滤掉），rup_for_soa的方法内容包的内容元素（rup_for_soa的Processes包已经被过滤掉），还有rup_for_z的所有方法元素（来自方法内容和过程包）。从业者们将能够通过图1中View栏中显示的导航树来操作这个网站。
图2显示了一个RUP for z 的方法Web站点例子，它来自显示在图1中的方法定义。
图2：RUP for z的方法Web站点的例子
从新创建方法的例子中，方法定义在这个项目的开始是空白。在一个自定义方法中，方法定义已经包含了与现有方法相关的插件——但并不包含现有的配置，然而，由于一种配置是专门为特定的方法设定的，因此并不是一种可重新使用的资产。例如，为了创建一个RUP for z的自定义版本，您可以用方法定义来开始，包括图1中所显示的插件。然后您可以添加，至少可以增加：一个新的方法插件（涉及到现有的插件：rup, rup_for_soa, and rup_for_z），是专门给您的新方法规定方法元素；和一个新方法配置，用来对您的新方法Web站点进行配置。您的新方法元素可以由新创建或者利用相互关系的变量对现有方法的一些元素进行衡量 6 （例如，贡献、扩展，或者代替）。
现在是明确地定义两个我曾在上面间接提到过术语的最佳时机：
- 方法架构是根据重要的构件和它们之间的相互关系对这个方法结构的阐述。
- 方法设计也涉及到方法的结构，包括所有的构件和它们之间的关系。
在RMC中的构件是方法插件、方法包，、方法元素和方法配置。
注意对方法架构和方法设计是不需要新的工作产品的，因为它们是在RMC中直接被定义的，并且在方法定义工作产品范围内。那就是说，除非这个团队注意到了要在分离的工作产品中捕获它们的需要，比如，像一个构架文档和一个图形模式——它们都是定义复杂的方法的很好的例子。
支持的工作产品
除了我刚才所描述的专门针对方法开发的必需工作产品以外，尽管事实上这篇文章所描述的方法着重强调的是开发真正的方法而不是产生项目相关的文档，却可能会不时对产生一些支持这个开发工作的额外工作产品有所帮助。在这个部分我介绍了一些工作产品，虽然不是专门针对方法开发的，但是已经被证明可以支持各种大量的方法开发工作。类似的工作产品在其它方法中也能找到，像OpenUP/Basic 7 或者RUP本身。在一定程度上您要根据许多因素将这些支持的工作产品形式化，包括项目复杂性，开发组织的文化，以及项目管理动态。
由于每个项目都需要一个获取所有涉众期望，项目规模，以及需求和限制的来源，我建议将这个信息存档到愿景文件中。愿景可以充当顾客和开发组织之间的契约。
由于我坚定地相信迭代和风险驱动方法对方法开发带来的好处，所以我建议利用一个项目计划来有效的执行这个方法。这个项目计划规定了这个项目的状态和重要事件。它可能包含一个能够定义每次迭代详细情况的迭代计划（比如，就分配有资源的任务来说）；迭代评估将评估一次迭代的结果并执行必要的中间修正；另外风险列表对风险进行鉴定和对它们进行优先划分，还要详细说明必需的处理或者缓解突发事件的行动。
表格3总结了被推荐的支持这个方法开发工作的工作产品
表格3：支持的工作产品和它们的相关角色
| 工作产品 |
角色 |
愿景
获取涉众对被开发方法的看法，以及对方法规模，需求和限制的观点。 |
分析师
通过搜集他们所输入的信息推定需要解决的问题，和通过为需求获取和设定优先权，从而提出涉众所关注的问题。 |
项目计划
搜集所有管理这个项目的需要的信息。它的主要部分由一个大概的计划组成，包括项目状态和重要事件。包括以下几点：
- 迭代计划（每次迭代都有个计划）
一个周密的计划描述了工作的目标，工作分配，以及每次迭代的评估标准。
- 迭代评估（每次迭代都有一次评估）
获取一次迭代的结果，评估标准所达到的程度，教训的总结，以及需要做的更改。
- 风险列表
项目中已知的和未知的风险列表，还附有具体的缓解方法和处理偶发事件的行动。
|
项目经理
领导这个项目的计划，并使涉众与计划的相互关系协调起来，保持项目团队能够集中精力来达到项目的目标。在大多数方法开发项目（异常复杂的例子除外）中，项目经理和方法设计师角色是由同一个人担任的。 |
方法开发路线图
在本文所提出的方法开发的方法，是基于四个RUP的阶段：先启、精化、构建和产品化。本章节带您快速浏览一下一个典型项目的每个阶段。
先启阶段
这个部分描述了一个方法开发项目的先启阶段，包括它的主要目标，评估标准，在最后阶段必要工作产品的状态，以及基本的任务。
先启目标
先启阶段的主要目标是在这个项目目标的基础上使涉众能够通力合作，并使他们接受这个项目是值得去完成的。
先启评估标准
在先启阶段的末尾，这个项目要根据以下的标准来评估：
- 涉众在规模、需求，限制以及进度评估上的合作。
- 所有的风险都被鉴定，并且针对每个风险都有一个缓解方法或者处理偶发事件的策略。
- 这个方法开发环境能够就地支持精化阶段。尤其是配置管理环境（比如IBM Rational ClearCase®）和方法开放环境（比如RMC）应该设置。
- 这个团队已经受到很好的训练，因此他们已经准备好开始精化阶段了。
如果这个项目不能达到这些标准，就可能会被放弃或者被重新认真考虑。
在先启阶段的末尾基本工作产品的状态
- 愿景。 涉众的期望，项目的范围，需求以及约束都被存档。
- 项目计划。 在这个阶段，它们的持续时间和目标都被明确定义。最初精化迭代的迭代计划已经完成并核查。最初的项目风险也已经确定。
- 方法纲要（可选）。 早期的可能处理非常特殊的风险。
基本任务在中一次典型的先启迭代中被执行
先启阶段的工作产品是通过执行图3所示的任务来完成的。注意其它的任务和工作产品可能适用（比如设置这个方法开发的环境和对团队人员进行培训），但是很少被推荐。图3所表述了涉众的角色都是利害关系人，比如顾客、从业者和问题专家 (SME)，他们为了确保团队构建了一个正确的方法，并能按时在预算之类完成，驱动先启阶段的所有任务。
图3：先启阶段的基本任务，还有相关的角色和输入/输出工作产品
表格4描述了纲要方法任务。这个任务独立于项目团队所采取的实际策略来定义这个方法，例如，自顶向下的（根据状态和它们的目标对整个生命周期的定义使得内容元素的鉴定更为便利）或者自底向上的（对内容元素的定义促使了生命周期的鉴定）。在实践中，项目团队通常联合使用这两种策略，这样促使了更多联合方法的产生，从这种意义上说每个内容元素能够更明确地连接在一个或者更多的阶段目标中。
例如，RUP for System z 8 方法的核心是利用一个自顶向下的策略来定义的，是在为期两个多周一系列自由讨论会议的背景下完成的。这些自由讨论的结果归档在方法纲要中。首先，z 的从业者们为了适应z环境的特殊需求，被要求对每个RUP阶段进行检查 ，鉴定它的主要目标和交付产品的任何一个必要变化。这样使得团队成员能够鉴定第一批需要被添加到RUP来满足z群体需求的工作产品（比如模块和安装验证过程），并且与最初RUP阶段的目标适用于z 的事实达成一致。第二，z的从业者们被要求对他们今天所执行的高水平的活动进行描述，这样使他们能够达到每个阶段的目标。允许团队对每一个阶段，对按照一定顺序的有代表性的迭代或者高水平活动的联合进行详细说明。第三，z的从业者们被要求对按照不同角色执行的任务（和潜在的附加活动）分组和工作产品的生产进行详细说明；有多少现有的RUP元素就要执行多少工作。这样团队可以确定要被添加到RUP for z中的一系列的任务（比如模块设计和定义安装验证过程）和相关角色以及工作产品。这种策略引导出一个当前应用在z环境中描述软件开发实践的端到端的过程和衡量包含于RUP中一些任务、角色、工作产品，活动以及现代最佳实践的定义。这个度量还确保了每个方法元素能够清晰地依靠一个或者更多的阶段目标。
表格4：纲要方法任务的描述
任务：
纲要方法 |
这个任务概述了方法纲要中的方法。它确定了候选方法元素和它们之间的一些关系，并对一些关键元素做了初始的描述。在这个任务执行中一些潜在的相应步骤如下面所提到的（没有具体的次序）： |
 |
- 确定方法开发策略（像自顶向下和自底向上）。
- 检查现有的资产并确定可重复使用的机会。
- 确定与这个新方法相关的候选方法元素——内容和过程。如果可以，将这个项目范围之内的元素与项目范围之外的元素区分开来（因为它们已经出现在现有方法中并能够被重复数用）。
- 确定候选方法元素之间的候选关系（比如，哪个角色是负责工作产品的）。
- 为一些关键候选方法的元素进行初始的概述。
- 从涉众那里获取对方法纲要的返回信息。
|
精化阶段
这个部分根据一个方法开发项目的主要目标，评估标准，此阶段结束时基本工作产品的状态和基本任务，对它的精化阶段进行了描述。
精化目标
精化阶段的主要目标是调整的基线，为构建阶段中大量的编写工作提供一个稳定可靠的基础。这个构架的稳定性是根据一个或者多个方法Web站点来评估的。
精化的评估标准
在精化阶段的末尾，这个项目是根据以下的标准来评估的：
- 需求都很稳定。
- 方法架构比较稳定。
- 对绝大多数重要方法元素的描述相当稳定。
- 通过对一个或者多个方法Web站点的评估证明主要风险元素已经被处理完毕。
- 构建阶段的迭代计划非常详细，并促进工作继续进行。
- 在当前构架的背景下，如果执行当前的计划能够开发完整的方法，所有的涉众都认为目前的设想是可以实现的。
如果这个项目不能达到这个标准，这个项目就会流产或者被重新考虑。
精化阶段结束时基本工作产品的状态
- 方法纲要。 所有重要的候选方法元素和它们之间的关系都被确定。这个方法概述可能还包括一些关键元素的早期描述。这个概述已经被检查并受到赞同；比例，每个候选方法元素将变成一个方法定义的方法元素。
- 方法定义。 方法架构是原始资料。它包括所有重要的结构元素（方法插件包括方法包和方法元素，以及方法配置）和它们之间的关系。它权衡了现有的可用资产。方法设计的定义可能还不够完善。它包括非重要结构元素和它们之间的相互关系。
- 方法元素描述。 绝大多数方法元素的描述都比较粗糙，要么直接在RMC中要么使用任何其它的编辑器。重要的方法元素的描述都编写得非常完整并且都经过核查。
- 方法Web站点。 为了研究方法的重要问题和评估的可用性产生了一个或者更多的网站。
- 愿景。 窗口基于在这个阶段获取的新信息而得到改进的，这样就建立了一个对大多数关键需求稳定的认识，促使构架与计划的决策的形成。
- 项目计划。 项目计划是最新的并且扩展到能够覆盖到构建和产品化阶段。最初构建迭代的迭代计划已经完成并且被核查过。构建中随后迭代的迭代计划也已经设计好了。风险已经被校正并且核查过。
基本任务在精化中一个具有代表性迭代中执行
精化阶段中专门针对方法开发的工作产品是通过执行图4中显示的任务而产生的。注意其它的任务和工作产品可能也可以应用（比如，为了测试网站），但是我们并不推荐使用。图4中任务的执行应该受到一个清晰的愿景和项目计划的驱动， 无论它们是什么样的形式。方法评审者包括主要的同行和其他领域问题专家(SME)。然而，在评估这个方法的时候我们还建议有其他涉众的参与，像从业者和顾客，依次来确保这个方法是可用的，且能够满足涉众的需求。
图4：精化阶段中详细的方法基本任务，还有与它们相关的角色和输入/输出工作产品
表 5 提供了构造方法任务的描述。
表格5提供了对构造方法任务的描述
任务：
构造方法 |
这个任务根据方法插件、方法包、方法元素，方法配置和它们之间的关系构建了这个方法。在这个任务执行中一些潜在的相关步骤如以下所示（没有详细的顺序）： |
| |
- 如果可以，检查现有的方法插件结构形成这个新方法基础的过程。
- 定义与这个新方法相关的方法插件和对其他插件的相互依存关系，如果可以的话。
- 在合适的插件中定义方法包。
- 在合适的包中定义方法元素和它们的相互关系，包括评估现有资产的变量关系。
- 对方法元素进行逻辑分类（可以用标准的或者RMC中自定义分类来完成）。
- 定义导航窗口（可以用RMC中自定义分类来完成）。
- 通过选择一套将发布的方法插件的和方法包，以及导航窗口来定义方法配置。
- 从涉众获得关于这个方法结构的反馈。
|
构建阶段
这个阶段根据它的主要目标、评估标准，此阶段结束时基本工作产品的状态和基本任务对方法开发项目的构建阶段进行了描述。
构建目标
构建阶段的主要目标是基线构架的基础上完成这个方法的开发工作，并且为这个从业团体准备一个产品化质量的方法。
构建评估标准
在构建阶段结束时，这个项目是按照以下标准来评估的：在从业者社区这个方法足够稳定成熟，以至于可以在社区中进行配置。
如果这个项目不能达到这个标准，产品化阶段就会被延迟。
构建阶段结束时基本工作产品的状态
- 方法定义。 方法设计师已经有详细的定义。它包括所有的结构元素（方法插件包括方法包和方法元素，和方法配置）和它们之间的关系。
- 方法元素描述。方法元素的描述已经完成并且核查过，比如它们都存在于RMC中。
- 方法Web站点。一个覆盖全部方法的网站已经产生。这个网站已经进行了识别缺陷的测试，像断开的连接，或者结果的可用性。
- 项目计划。 最初构建迭代的迭代计划已经完成并且被核查过。构建中随后迭代的迭代计划也已经设计好了。风险已经被校正并且核查过。
在构建阶段的一个典型迭代中执行的基本任务
构建阶段中专门针对方法开发的工作产品是通过执行图5中显示的任务而产生的。注意其它的任务和工作产品可能也可以应用（比如，为了测试网站），但是我们并不推荐使用。图5中任务的执行应该受到一个项目计划的驱动， 无论它们是什么样的形式，这样构建阶段的每一次迭代中需要完成是什么就显而易见，因此这个团队就能够集中精力尽快交付结果，因为创造性的进程在后面驱使着他们。方法评审者包括主要同行和其他领域问题专家 (SME)。然而，在评估这个方法的时候我们还建议有其他涉众的参与，像从业者和顾客，依次来确保这个方法是可用的，且能够满足涉众的需求。
图5： 构建阶段中详细的方法基本任务，还有与它们相关的角色和输入/输出工作产品
产品化阶段
这个阶段根据它的主要目标、评估标准，在最后阶段必要工作产品的状态，以及基本的任务对方法开发项目中的产品化阶段进行了描述。
产品化目标
产品化阶段的主要目标是确保为从业者提供一个优良质量的可利用的方法。
产品化评估标准
在产品化阶段的最后，这个项目要按照以下标准来进行评估：这个方法已经分配到从业者团体中，并且从业者对此感到满意。
如果这个项目不能达到这个标准，这个项目的结束不得不通过依次的延迟发布版本来完成。
在产品化阶段的最后，发布版本的维护循环就开始了。这可能包括开始一个新的循环，或者一些额外的维护版本。
产品化阶段末尾基本工作产品的状态
- 方法定义。方法插件（包括方法元素描述）和方法配置已经完成，并且与这个需求保持一致。来自审核人员的反馈也应该考虑。
- 方法Web站点。一个覆盖完全方法的网站已经产成（测试过程中鉴别的问题已经被确定）。
在产品化阶段中的一个典型的迭代执行的基本任务
产品化阶段中专门针对方法开发的工作产品是通过执行图6中显示的任务而产生的。注意其它的任务和工作产品可能也可以应用（比如，为了测试网站），但是我们并不推荐使用。图6中任务的执行应该受到一个项目计划的驱动， 无论它们是什么样的形式，这样产品化阶段的每一次迭代中需要完成是什么就显而易见。因为创造性的进程在后面驱使着他们。这时方法评审者包括主要从业者，因为这个方法是在"beta"下进行评估的。然而，在评估这个方法的时候我们还建议有其他涉众的参与，像顾客，在方法评估过程中能够确保在这个项目结束之前满足涉众的需求。
图6：产品化阶段中详细的方法基本任务，还有与它们相关的角色和输入/输出工作产品
结论
这篇文章描述了一个迭代的、风险驱动的、以构架为中心的，以及面向质量的方法开发的方法。这个方法通过浏览一个方法开发项目的每个阶段来展现，根据以下几个方面：项目的主要目标、评估标准，在最后阶段必要工作产品的状态，以及这个阶段所执行的基本任务。
这个方法已经被执行和改进可许多年——还将继续被改进——在大量不同项目的背景下进行的：从通过工具指导来处理一个特殊的技术问题而对RUP进行相当简单地扩展，到通过各种指导方针，额外的内容元素和改进的生命周期来处理特殊的域而进行相当复杂的扩展（像RUP for COTS 9, 10 ）。在执行的过程中这个方法被存档在RUP for System中，并与一个中度或者高度复杂的典型方法开发工作相一致（一个五人团队，十四个周的项目期限，一个可交付的插件，一个可交付使用的配置，以及大约八十个新内容和过程元素）。
当前的这个方法被普遍看作一个称为Method Authoring Method Basic (MAM Basic)的RMC方法。这篇文章仅仅是对RUP团队所追求的对方法开发过程形式化的一个初步尝试。由于方法开发是一个大家兴趣逐步增长的领域，希望看到更多来自方法开发社区的指导、相关的各种话题，像方法架构、方法迭代或者方法配置管理。
感谢
我想感谢所有审核人员的贡献，感谢他们对这篇文章初稿的深刻见解。特别感谢Carlos Goti详细的评论和他始终精辟的建议，感谢RUP for System z团队对这个方法执行得如此彻底，并提供了建设性的反馈。最后，由于这篇文章所展现的方法来自多年来RUP和IRUP团队工作的努力，所以我要感谢这两个不平凡的团队中的每一个同事。
注释
1 Per Kroll和Philippe Kruchten。Rational Unified Process Made Easy: A Practitioners Guide to the RUP。2003年Addison-Wesley出版。
2在这篇文章中我讲述了两个方法的开发，意味着不用制定直接在项目中执行；对于方法框架，意思是为满足一个项目或者组织的特殊需求需要进一步地制定。为了简便起见，在整篇文章中我使用方法一词来表达方法和方法框架两种意义。
3为了解更多的RMC信息，请查看以下的资源：
4一个关于使用RMC简单方法自定义的良好信息资源是：IBM Global Services Course description: PRJ350v2 Essentials of Tailoring Methods with Rational Method Composer, v7.0.1.。
5 Per Kroll 和 Walker Royce， The Rational Edge，2005 年 12 月： 业务驱动开发的关键原则。
6 要得到更多关于可变性的信息，请参考 IBM Global Services course PRJ350v2。
7 要得到更多信息，请访问： http://www.eclipse.org/epf/。
8 要得到更多关于 System z 的信息，在以下 2007 年 2 月末的刊物中可以得到：
9 要得到更多的信息请访问：IBM Rational Method Composer (RMC) 7.1 Plug-ins。
10 Cécile Péraire and Russell Pannone， The Rational Edge， 2005 年 10 月， 基于 COTS 项目的 IBM Rational Unified Process：介绍。
参考资料
