级别： 初级 Jeff Smith, 软件开发方法学家, IBM
Dan Popescu, RUP 内容开发, IBM
2006 年 9 月 14 日 本文来自于 Rational Edge：本文中作者介绍了创建完整的用户定制的软件开发过程所需的4个步骤，这种软件开发过程基于 Rational Method Composer 产品所提供的库。
你可以很容易找到过程实施与过程采纳相关的讨论。但其中却很少提到如何开始一个过程开发的工作
1
。本文从过程工具的角度重点的阐述了如何开始一个过程开发项目的主题。
Rational Method Composer (RMC) 提供了唯一一种用来设计用户定制软件开发过程的方法。插件体系架构、用过引用的重用，内容与过程生命周期的分离，在如何构建与裁剪开发过程方面提供了灵活性。 本文描述了某个使用场景的案例，这个场景的设计基于使用现存的RMC方法内容库来更有效的开始过程开发的工作 。
开发过程的困难之一就是这种工作的开端。下面是一些普遍遇到的问题：
-
不知道从哪里开始。 你是否应该从零开始？有时候在已有过程上开始会变得更糟。
-
信息过量。 经常的情况是，存在很多需要审核的信息来源，而这些来源正是开发过程所必需的；太多的静态信息（文档，文档，文档...）。
-
不同过程所有者兴趣之间的平衡。组织中的不同角色在各种过程开发与过程方面起到不同的作用。
-
过程相关信息的组织。 把过程中的各种不同元素组织在一起总是很困难的，更不用说进行更新与维护信息了。
-
开发环境限制。 手写静态文档很难概念化过程，很难定义过程和它所相关联的内容。
-
内在过程的复杂度。 过程总是令人畏缩的复杂，如果某类工具平台的帮助去处理过程会是很长困难的。
使用 Rational 统一过程（Rational Unified Process ®或 RUP ®）可以解决过程开发中的部分问题。 RMC 带有一些默认方法内容库，这些方法库被包含在可以被直接使用的 RMC 工具的插件中，并且 RUP 插件也被包含于 RMC 插件库中。我们将会展示一种利用已有库来开始过程开发的方法。下面是简单的四个步骤 1) 查看 RUP 库， 2) 创建路线图， 3) 执行 RUP 差异分析，最后， 4)利用RMC的内容可变性特性定制你的进程。
查看 RUP 库
RMC 包含了许多过程内容。正如其他开发环境一样，在你能够精通它之前，你必须熟悉那些可使用的库。 想象一下你被要求使用一个 IDE 写一个Java 程序。在你写代码前，你首先需决定要导入哪些库。这样，在知道了哪些需要扩展，哪些需要实现后，你才能够更有效率的编写出代码。同样，在RMC中，在你开始构建过程之前，首先需熟悉过程内容，这部分内容会以上面所提到过的默认方法库插件的形式出现。一个插件包括方法端（方法内容包，Method Content package）和过程端（过程包，Processes package），如图1所示。
图1： RMC 方法库插件
为了查看插件，我们浏览一下方法内容包和过程。一旦你熟悉了这些插件，你可以"发布" 一个插件，从而了解它们如何在已发布的版本中相互协调工作。在RMC中，发布版本是过程开发的最终目标的很大的部分。过程的发布版本以HTML的形式体表达过程的部署。发布版本通过方法配置得以实现。
2
基础插件的方式使得RMC中插件的应用变得简单。例如，定位到 rup_soa_plug-in，并且双击它。"Referenced Plug-ins" 部分显示出被 rup_soa_plugin 引用的的额外插件。在这个例子中，你可以清楚的了解到它是派生自 rup 和 rup_bm 插件的。
你已经查看了 RMC 方法内容库，现在你可以创建属于你自己的方法插件了。这个时候，我们将使用 RUP 作为基础来构建软件项目管理过程。首先，右键点击方法库视图。在上下文菜单中选择 New Method Plug-in（新建方法插件）。在 New Method Plug-in（新建方法插件）窗口中，为这个插件取名为 "acme software project management." 你所看到应该如图2所示。
图2： "software project management process" 插件
创建路线图
下一步，你要确定如何你的软件开发生命周期职能区域如何工作。（在你与主要涉众商讨了路线图之后，你需要把结果加入"software project management process"插件中）。在这个阶段，你不需考虑 RMC，你只需要简单的描述出过程中需要执行的活动。下面是一个例子，它反映了出从软件项目经理的角度过程的四个阶段：
可行性
可行性活动确定了项目的技术、财务和进度方面的可行性。软件项目经理建立并管理软件的可行性计划。这个计划与软件开发计划和风险管理计划共同作为评估项目可行性的依据。如果软件指导委员会认为项目是可行的，那么这个项目进入到分析阶段，否则就取消项目。
分析
在分析活动中，项目经理与项目审查小组共同反复审查计划。除此之外，由于项目已进入到关注需求和软件架构的阶段，此时软件项目经理有必要编写一份风险列表。在整个项目开发过程中这个正式的工件将被一直维护。在需要之时，软件项目经理会在管理评审小组的帮助下更新软件开发计划。
开发
在开发过程中最主要的项目管理活动包括更新软件开发计划，维护项目评审记录，依据软件项目管理小组的评审计划进行项目评估。
产品化
产品化活动包括为用户部署、实现软件功能。软件项目经理有责任保证当项目交付报告（Project Closeout Report）被获取时，软件项目顺利完成。除此之外，软件项目管理小组使用上线后评审报告（Post-Launch Review Report） 和项目终止后分析文档（Project Post-Mortem Analysis Document）来不断完善软件项目管理工作。
在你与主要涉众商讨了路线图之后，你需要把结果加入"software project management process"插件中。这在RMC中是一项简单的过程。首先，依据如下步骤：
- 找到 software project management process 插件。
- 打开 Method Content 包，右键点击 Content Packages。
- 选择 New--»Content Package。在 Name 框中，输入 Guidance。
- 完成 File--»Save All 操作。
- 打开 Guidance 内容包。你将发现RMC已经自动为你生成了 Roles（角色）、Tasks（任务）、 Work Products（工作产品） 和 Guidance（指导）。你可以使用这个为这些与插件指导相关的条目进行分组。
- 右键点击 Guidance content package 中的 Guidance 元素来创建路线图。 RMC会显示出你可以创建的各种不同指导的上下文菜单。
- 选择 New--»Roadmap。
- 在 Name 框中，选择 software_pm_process_roadmap。 这是与路线图相关联的文件名。
- 在 Presentation Name 框中，输入 Software Project Management Process Roadmap。这是当你浏览路线图时所显示的名字。
这时，你可以创建你的路线图，并且可以通过在 Main Description 框中输入路线图的内容从而将其加入到你的过程。为了方便编写内容，点击 Main Description 左侧的富文本编辑器图标。 RMC 为构建过程内容提供了方便的富文本编辑器功能。图3显示了 Preview（预览）模式下的路线图的例子，你可以通过路线图的 Preview（预览）标签看到。
图 3： Software Project Management Roadmap 的预览
现在我们有了文档化的描述，根据未来涉众的反馈信息修改路线图就像访问插件，打开RMC中的路线图，更新 Main Description 里的内容一样容易。RMC 在过程中为你组织并维护了路线图。
这些路线图可以有各种不同的形式。在编写你自己的路线图之前，请从方法插件中打开方法插件库，它包含了rup, rup_legacy_evol_plugin、rup_j2ee_plug-in、rup_soa_plugin 和 rup_ux_modeling_plugin。
实现 RUP 差异分析
在与涉众对你的过程达成一致后，你可以开始确定你的过程和RUP间最主要的区别了。从工作产品开始。表1显示了你的软件项目管理过程与RUP间的部分区别。
Table 1: Work product mapping
| 软件项目管理过程工作产品 | RUP 工作产品 |
|---|
| 软件可行性计划 | X | | 软件开发计划 | 软件开发计划 | | 风险管理计划 | 风险管理计划 | | 迭代计划 | 迭代计划 | | 风险计划 | 风险计划 | | 项目评审记录 | 项目评审记录 | | 项目度量 | 项目测量 | | 迭代评估 | 迭代评估 | | 项目交付报告 | X | | 上线后（Post-Launch）评审报告 | X | | 项目终止（Post-Mortem）评审文档 | X | | X | 业务用例 | | X | 部署计划 | | X | 问题列表 | | X | 状态评估 | | X | 工作次序 |
当创建这些对比时，验证其完整性是非常重要的。你需要确定两件事。第一，当RUP组件存在于你的工作产品中的时候，它是否真正实现了你所需要的目标？如果在你的软件项目管理过程中存在RUP工作产品中没有副本，你是否应该增加这个工作产品？是否有可能把你自己的某些工作产品迁移为RUP工作产品？ 当你执行这个分析过程时，提供一个映射的基本原理是一个很好的主意。
当你熟悉了工作产品的对比后，你应该开始确定角色。根据可行性、分析、开发与产品化的阶段性目标来评估角色。
使用内容可变性（content variability）
一旦你已经确定了工作产品、角色、阶段、阶段目标和任务，你现在可以应用RMC的内容可变性特征优化你的过程。内容可变性允许通过贡献、扩展或替换修改已存在的过程元素。下面的表 2 简要的概述了这三种可变性类型。
表2：可变性类型| 可变性类型 | 描述 |
|---|
| 贡献 | 贡献元素用来在基本元素之上增加属性。贡献提供了一种方式来增加基本元素的属性，这种方式不用改变任何已存在的属性，例如，添加一个附加的样式。
| | 替换 | 替换元素用来代替基本元素中的部分属性。替换提供了一种方式来代替基本元素，这种方式不用改变任何已存在的属性。在大部分情况下，它是用在方法插件中的，这些插件用来替换特定的内容元素，例如角色，任务或者是拥有全新变量的活动或改变这些元素间基本关系的活动。这所导致的结果是基本内容元素在逻辑上被新的替换元素所代替，而引入的关联仍然指向原先的元素，但却拥有新的属性值和外延的关联属性。 | | 扩展 | 扩展元素继承了基本元素的特性。扩展允许方法插件通过提供扩展元素的继承，从而达到重复使用来自于基本插件元素的作用。扩展元素的属性值和关联实例继承自"被继承" 元素。结果是扩展元素拥有与"被继承"元素相同的属性，但却可以定义属于其本身的属性。扩展不是用来修改基本插件的内容的，而是为扩展插件提供定义其内容的能力，而这些内容是已定义的内容变量。 |
例如，在审查完你的工作产品映射后，你发现 RUP 的 software development plan 与你所需要的过程十分相近。你决定使用贡献可变性类型来修改 RUP 的 software development plan ，而不是构建另一个工作产品。在RMC中通过下步骤来实现：
- 进入 Library View 中的 software project management process 插件。
- 打开 Method Content 包，右键点击 Content Packages 。
- 选择 New--»Content Package。 在 Name 框中，输入 Software Project Management 。
- 选择 File--»Save All 。
- 打开 Software Project Management 内容包。你会发现RMC已经自动为你生成了 Roles（角色）、Tasks（任务）、 Work Products（工作产品） 和 Guidance（指导）。你可以使用这个为这些与插件指导相关的条目进行分组。
- 为了对 RUP software project management plan 进行贡献类型的可变性操作，并且在你的过程中使用它，右键点击 Software Project Management 内容包中的 Work Product 元素。 RMC 会以工件（artifacts）、交付产物（deliverables） 或者成果（outcomes）的形式显示出不用类型工作产品的菜单。由于我们所使用的RUP中的 software development plan 属于工件，因此选择New--»Artifact 。
- 在 Name 框中，输入 sw_development_plan 。 Presentation Name 框为空。（因为你正使用贡献类型来修改 software development plan 工件，因此需要保留RUP工件的命名）
- 下翻到 sw_development_plan 底部直至"Content Variability" 部分，在 Variability 下，选择 Contributes（贡献）。
- 在正下面的 Base 域中，选择 Select 按钮。（为了方便起见，在 Select Artifacts Dialog 窗口中，点击 Collapse All 按钮。）
- 现在，打开RUP插件，打开 Management 包和 Project Planning 包。选择 rup_software_development_plan 工件, 点击OK。
- 现在，你为你的 software development plan 工件所选择任何文档都将被加入到RUP software development plan 文档的尾部。试着做一下，例如，在你的工件的 Main Description 中输入 "This plan serves as the overarching plan for the entire software development effort." 。点击 Save All 。
现在，你已经获得了来自于 RUP software development 与在 Main Description 中你所添加的内容的支持，拥有了对自己过程的软件开发计划。（注意：为了了解RMC如何处理内容可变性，你需要切换到 Browsing 透视图。这超出了本文的讨论范围）
后续步骤
RMC 明确了方法维度与过程维度的区别。方法内容回答了这个问题 "将产生什么？" "谁来负责与需要什么技能？" 和"如何生产工作产品？" 过程维度处理"什么时候" 的问题 － 换句话说，方法内容元素如何暂时的与半规则序列相关联。
在后续文章中，我们将明确的指出在后面的步骤中如何结合开发过程维度和方法维度 － 例如，能力模式。除此之外，我们将关注过程的发布准备工作，包括如何通过自定义类别定义视图。
总结
过程开发是一项复杂的工作，具有独特的挑战性。完全不同的过程信息源、相互矛盾的涉众需求、信息过量、过程复杂度（这只是其中的一小部分），这些都是过程开发中的障碍。RMC工具不能解决所有这些问题，但是通过插件重用和方法内容组织等手段，它可以使得工作的起步阶段变得更加简易。
注释
1 阅读，例如， Maria Ericsson、 Zoe Eason、 Lynn Mueller 撰写的“改造你的软件开发能力：一种适应组织变化的框架”； Michael F. Hanford 撰写的“项目组合管理入门”； 和 Bill Higgins 撰写的“管理业务流程集成项目的基本原则”
2 要了解更多关于如何发布过程的信息，请浏览 Peter Haumer 的 “IBM Rational Method Composer: 第一部分：关键概念”
参考资料
作者简介  | | | Jeff Smith 是一名IBM软件开发方法论学家，他为IBM对于商业开发的定义作出了很大贡献，他主要从事这类开发方法的测试与验证。在加入 IBM Rational 商业方法内容团队之前，他主要进行医疗设备领域的软件研发工作。Jeff 拥有伦敦大学经济学院(LSE)有关信息系统分析、设计与实施方面的理学硕士学位。 |
| | | Dan Popescu 是 RUP Content Development 软对的一名成员。他在两个领域中总共拥有19年的软件开发经验 ，并且获得了电子工程理学硕士学位。在加入 IBM Rational前， Dan 为电信与半导体设备开发系统，他扮演过多种角色，包括软件架构师，团队负责人，和过程工程师。 |
对本文的评价
| 
