| UML软件工程组织 | |||
| |
|||
|
|||
方法开发的路线图
作者: Cécile Péraire 出处:IBM
本文来自于 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对不同类型方法元素的定义。
一个方法元素可以从两个不同的但是同等重要的角度来看：从方法设计师的角度，他定义了方法构架，因此可以确定方法元素和它们之间的关系；或者从方法作者的角度，他编写方法元素的说明（比如，文本的和图形的内容）。由于方法开发的大量精力都花费在编写方法元素上，所以第二个角度非常重要。由于这个原因，一个叫做方法元素描述（Method Element Description ）的分离工作产品被用来引用方法元素的内容（即使方法元素描述工作产品包含于方法元素工作产品中）。 另外其它具体针对方法开发的必要工作产品归纳在表格2中，并有负责每个工作产品的角色。关于这些工作产品的附加信息紧跟在表格2的后面。
在这个项目的前期，推荐利用一个方法纲要来概述这个方法。方法纲要的目标是帮助团队鉴定候选方法元素和它们之间的一些关系，并为一些关键元素做出初始的描述。这种做法取决于这个项目的类型（从零开始创建方法，对现有的仅有内容元素的方法的扩展，对现有的有内容和过程元素方法的扩展等等。），方法纲要可能采取各种各样的形式。比如，它可能包括一个或者更多以下的元素：生命周期的预排，对候选角色的简洁描述、任务、工作产品，以及它们之间的关系；候选方法指导方针的列表（模板、例子、白皮书等等。）；早期的工作分解结构（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总结了被推荐的支持这个方法开发工作的工作产品
在本文所提出的方法开发的方法，是基于四个RUP的阶段：先启、精化、构建和产品化。本章节带您快速浏览一下一个典型项目的每个阶段。 这个部分描述了一个方法开发项目的先启阶段，包括它的主要目标，评估标准，在最后阶段必要工作产品的状态，以及基本的任务。 先启目标 先启阶段的主要目标是在这个项目目标的基础上使涉众能够通力合作，并使他们接受这个项目是值得去完成的。 先启评估标准 在先启阶段的末尾，这个项目要根据以下的标准来评估：
如果这个项目不能达到这些标准，就可能会被放弃或者被重新认真考虑。 在先启阶段的末尾基本工作产品的状态
基本任务在中一次典型的先启迭代中被执行 先启阶段的工作产品是通过执行图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中一些任务、角色、工作产品，活动以及现代最佳实践的定义。这个度量还确保了每个方法元素能够清晰地依靠一个或者更多的阶段目标。
这个部分根据一个方法开发项目的主要目标，评估标准，此阶段结束时基本工作产品的状态和基本任务，对它的精化阶段进行了描述。 精化目标 精化阶段的主要目标是调整的基线，为构建阶段中大量的编写工作提供一个稳定可靠的基础。这个构架的稳定性是根据一个或者多个方法Web站点来评估的。 精化的评估标准 在精化阶段的末尾，这个项目是根据以下的标准来评估的：
如果这个项目不能达到这个标准，这个项目就会流产或者被重新考虑。 精化阶段结束时基本工作产品的状态
精化阶段中专门针对方法开发的工作产品是通过执行图4中显示的任务而产生的。注意其它的任务和工作产品可能也可以应用（比如，为了测试网站），但是我们并不推荐使用。图4中任务的执行应该受到一个清晰的愿景和项目计划的驱动， 无论它们是什么样的形式。方法评审者包括主要的同行和其他领域问题专家(SME)。然而，在评估这个方法的时候我们还建议有其他涉众的参与，像从业者和顾客，依次来确保这个方法是可用的，且能够满足涉众的需求。 
图4：精化阶段中详细的方法基本任务，还有与它们相关的角色和输入/输出工作产品 表 5 提供了构造方法任务的描述。
这个阶段根据它的主要目标、评估标准，此阶段结束时基本工作产品的状态和基本任务对方法开发项目的构建阶段进行了描述。 构建目标 构建阶段的主要目标是基线构架的基础上完成这个方法的开发工作，并且为这个从业团体准备一个产品化质量的方法。 构建评估标准 在构建阶段结束时，这个项目是按照以下标准来评估的：在从业者社区这个方法足够稳定成熟，以至于可以在社区中进行配置。 如果这个项目不能达到这个标准，产品化阶段就会被延迟。 构建阶段结束时基本工作产品的状态
在构建阶段的一个典型迭代中执行的基本任务 构建阶段中专门针对方法开发的工作产品是通过执行图5中显示的任务而产生的。注意其它的任务和工作产品可能也可以应用（比如，为了测试网站），但是我们并不推荐使用。图5中任务的执行应该受到一个项目计划的驱动， 无论它们是什么样的形式，这样构建阶段的每一次迭代中需要完成是什么就显而易见，因此这个团队就能够集中精力尽快交付结果，因为创造性的进程在后面驱使着他们。方法评审者包括主要同行和其他领域问题专家 (SME)。然而，在评估这个方法的时候我们还建议有其他涉众的参与，像从业者和顾客，依次来确保这个方法是可用的，且能够满足涉众的需求。 
图5： 构建阶段中详细的方法基本任务，还有与它们相关的角色和输入/输出工作产品 这个阶段根据它的主要目标、评估标准，在最后阶段必要工作产品的状态，以及基本的任务对方法开发项目中的产品化阶段进行了描述。 产品化目标 产品化阶段的主要目标是确保为从业者提供一个优良质量的可利用的方法。 产品化评估标准 在产品化阶段的最后，这个项目要按照以下标准来进行评估：这个方法已经分配到从业者团体中，并且从业者对此感到满意。 如果这个项目不能达到这个标准，这个项目的结束不得不通过依次的延迟发布版本来完成。 在产品化阶段的最后，发布版本的维护循环就开始了。这可能包括开始一个新的循环，或者一些额外的维护版本。
产品化阶段中专门针对方法开发的工作产品是通过执行图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：介绍。
|
||||||||||||||||||||||||||||||||||||||||||||
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
