本文为这一挑战提供了一个简单的解决方案。揭示了如何有效利用开发案例（Development Case） 和 评审记录（Review Record）-- 两者都是 IBM Rational Unified Process®， 或 RUP的组件®， -- 以确保符合基于RUP工程的过程规范。这种方法可以增强所有相关工程产品的质量， 并且减少了团队成员无法有效沟通的风险。

虽然RUP 很好的描述了开发案例和评审记录， 但是它没能完全解释它们间的关联关系 -- 这正是本文后面所要讨论的。除此之外，我将会提供一个实际的RUP的 Microsoft Word模版的修改实例，读者可以直接使用。

使用 RUP开发案例

与其把 RUP称作 "方法论"还不如将其称为过程框架来的准确。 RUP提供了一个丰富的 候选 工作产品集，用以定义、指定、验证、通信与评估您的软件开发成果。一些用户将这些工作产品称为"自助餐"; 您可以在框架中选择那些有用的。您选择创建的每件工作产品都需要使用实现项目功能的员工。因此明智的选择将会是非常重要的。

多年来，我发现 RUP初学者错误的认为他们 "仅仅在需要的时候" 才要完成这些工作产品-- 甚至更糟的是，将其作为 "学习过程中的练习。" 1 这样增加了学习 RUP的弯路（并可能造成相比之前过程更低的生产力）， 增加了项目开销，就使得项目发起人错误的认为 RUP 是臃肿昂贵的。不幸的是，企业也许会因为误解RUP的低效而回到先前的工作。因此，我建议RUP的初学者在成功应用RUP项目之前使用 较少的工作产品。

开发案例用以帮助您鉴别针对特定项目的工作产品。在RUP项目开始阶段，使用工作产品帮助理解范围、成本、进度和项目的风险参数是十分有必要的，您可以据此决定是否有必要继续下去。您所使用的过程度在计算您的成果中将是重要的因素。 2 将使用的工作产品数目（和正式形式）降为最低也能够减少成本 -- 不增加项目对不可接受度的风险。 没有过程的结果是混乱的，但是 过多的过程是种浪费。

表 1A-C 表示了 Microsoft Word产生的一个 开发案例的例子。我调整了RUP所用的的版本格式。注意,Rational Method Composer 7.0提供了一个更为全面的，基于 Excel版本的开发案例模版。 我的版本包括了解释及表中列含义的部分。我仅包含了依据 RUP Requirements Discipline 的，针对特定企业的候选工作产品集。 我还增加了一个非RUP特定企业工作产品的例子 -- Questionnaire -- 以满足涉众的要求。

表格 1A：本表格解释了Tables B 和 C中出现的列的意义。

列名	目的	内容/注释
工作产品	RUP工作产品列表，按照RUP工作过程分组
启始, 精化, 构建, 产品化	描述是否是在一个特定RUP阶段进行更新的特定工作产品	可能的价值： 必须 应当 可以 不可以
评审类型	列出谁对工作产品QA过程部分负责、有责任、进行咨询或被通知。 注意：当完成了 咨询，需要在 评审记录中生成记录	可能的批准者： EA（企业架构师，Enterprise Architecture） DA（数据架构师，Data Architecture） SC（指导委员会，Steering Committee） PE（过程工程师，Process Engineer） PM（项目经理，Project Manager） BR（业务代表，Business Representative） 财务人员 IA（内部审计人员，Internal Audit） SA（系统分析师，Systems Analyst） RS（需求详述人员，Requirements Specifier） DT（开发团队 ，evelopment Team）
签署	如果有的话，显示谁必须对工作产品进行签署。	空白表示不需要进行签署。列出需要对工作产品进行签署的涉众人员，可以使用上面行中的涉众列表。

表格 1B：对于按照工作过程划分的工作产品的需求

工作产品	启始	精化	构建	产品化	评审类型				签署
					R	A	C	I
项目术语表	必须	必须	必须	必须	RS
需求管理计划	必须	不可以	不可以	不可以	SA	PE
涉众需求	必须	可以	不可以	不可以	RS	BR
补充规格说明	必须	必须	可以	可以		BR	EA	DA	EA，BR
用例模型	必须	必须	可以	不可以	SA	BR	EA，PE	SC	SC
用例情节板	不可以	不可以	不可以	不可以	SA	BR	EA
界面原型	可以	必须	不可以	不可以	DT	BR	EA
愿景	必须	必须	可以	可以		BR	PE	CSA，SC	SC
调查表	必须	不可以	不可以	不可以	RS	BR

表 1C：工作产品说明

工作产品	阶段	说明
调查表	Incep	作者已经将其添加为我们可能希望产生的一个非RUP工作产品的范例。
愿景，用例模型	所有	由于RUP对团队来说是新鲜事物，过程工程师（PE）将会对这些工作产品的合适质量进行咨询。

注意，RUP 模版提供了我删掉的 "已用工具" 列。 当表格列有意义时，我会在一个独立表格中指定不同类型的工作产品使用哪种工具，以释放部分空间。

您可以根据自身情况增加 "必须，应当，可以，不可以" (MoSCoW) 3 RUP模版中的选项。我经常会用"不应当" 指出，例如，我们不应当 更新开发手册，因为已经存在企业标准。

为您的企业和项目裁减开发案例

有经验的RUP导师可以从开发案例中裁减不必要的工作产品。 例如，构建空中交通管制系统的软件需要某些工作产品以确保多重可靠性检查，满足可调整性等等。如果您的软件需要支持更多传统商务过程，那么您可以放心的从 开发案例中减少这些工作产品。

大部分企业都至少具有一个非RUP工作产品作为软件开发项目的一部分－－例如， Post-Implementation Review。项目管理办公室（PMO）的内部审计部分也许需要某个特定的工作产品。 这些可以作为开发案例的适当的规则。

删除不必要的工作产品，而增加特定企业的工作产品可以产生一个 开发案例，它指定了您所在的企业所承担的最大项目所需的过程－－包括了活动和形式。 最后产生了 企业级开发案例模版。

部分企业使用多个企业 开发案例s， 每一个都指定了不同类型的工程，例如应用开发， COTS 实现，商业模型，或是遗留系统改进。 之后，它们可以使用这些开发案例作为模版以裁减特定项目的开发案例。

当企业开始采用RUP时， 完成这一系列的开发案例是十分繁重且花费时间的过程。这是为个人定制RUP所必需的投资。这项工作经常被分给过程工程师，他们为每一工作产品解释目的和应用。随后的好消息就是，如果您已经创建了特定项目的 开发案例，这一过程将会是十分快速的。项目经理现在要理解这些工作产品的价值，他/她可以迅速与过程工程师讨论需要使用哪些产品。项目经理和过程工程师能够简单的调整先前的开发案例s以适应新项目的需要。

在很多企业中，最有经验的项目经理会负责过程工程师的工作。但是，如果这个人已经被教育为一个守旧的、形式主义过程方式的人，那么他或她很可能并不是裁减开发案例的最佳人选。符合过程工程师要求的人必须是知识渊博的，具有现代灵活项目管理的经验。他或她必须时刻监视流线型过程的工作而不降低质量 -- 包括了将项目工作产品保持最小化。

涉众签署工作产品的选择

当从企业级的开发案例模版创建他们自己的开发案例时，某些项目经理以为仅仅只要减少他们的开发案例，删除工作产品模版中所不需要的部分。这是错误的！相比较删除不使用的工作产品而言，更好的方式是在工作产品名称边输入"不需要" ，这表示您已经仔细考虑过它的价值，评估了不使用它的风险，才作出的决定。您的过程工程师（或是您的企业的过程专家）应该在开发案例上署名（或者以不正规的方式批准，例如，使用电子邮件），这样可以让每个人都准确的知道使用了哪些工作产品。您想要避免所有都一样的情况，例如像下面这样：

Marilyn－－一位项目经理，近几周来一直从事于一个基于RUP的直播项目。她将她的需求告诉了业务部门，但是他们拒绝在没有针对她所在公司的灾难恢复计划（Disaster Recovery Plan，一种非RUP工作产品）的情况下配置应用。于是她向Dave---业务经理---抱怨。 "我同意对于这样一个小项目来说，我们不需要灾难恢复计划，" Marilyn 说。 "这是可笑的，" Dave 回答到。 "我不会同意在没有DRP的情况下配置应用！"

在开始阶段，Marilyn 可以利用开发案例指定项目所需的工作产品，从而避免类似的情况发生，之后就可以获得涉众的支持。在这种情况下，业务经理也可以尽早提出反对意见, Marilyn可以尽早加入灾难恢复计划。或者，他也许早已认可这一捷径，而Marilyn就能够避免这一不愉快的障碍。

这就是 RUP的美妙之处。它能够使你变得更加灵活－－提供了来自涉众的支持。 传统的方法论往往没有提供类似的捷径。您多少次被为了完成毫无价值的工作产品（也许再也不会被任何人阅读）所羁绊－－仅仅因为您的老板不得不这样做？

使用开发案例指定评审

根据我的经验，RUP中所提供的开发案例的纵栏标题 "评审类型" 对于公司来说并不足够。人们并不了解评审参数中 "正式-外部"的含义。 4 我推荐使用特定企业的名词。例如，如果您执掌被称为 "项目管理委员会 （PMC）"的委员会，那么可以将 "PMC" 作为输入评审栏的数据。 如果您愿意，您甚至可以输入您的名字。例如， "咨询"评审类型的数据模型可以为 "Gary。" 只要是公司里都可以理解的就可以。

一部分人希望阅读工作产品；另一部分人对内容感兴趣；还有一部分希望了解它们是如何产生的。 表 1B 比标准RUP模版增加了支持更多的评审模型。它的属性值表示相关评审的角色和职责： "R" 负责; "A" 有责任; "C" 咨询和 "I" 被通知。 这样就允许 PM清楚地概括出每件工作产品的内容的责任。 表 1B 还增加了一栏以指定是否需要署名。这样，涉众就可以确定有责任一栏是否为应署名的人。

使用 RUP评审记录辅助开发案例

如果您正为您的项目使用开发案例定义个性化的过程， 那么祝贺您。 由于不必创建无价值的工作产品，您将节省大量金钱。但是，您如何才能知道项目正沿着 开发案例所规划的路线图前进？

使用RUP所提供的评审记录。这一有价值的工作组建可以有效辅助开发案例，并且是实现项目质量标准的关键。尤其是，它包含了与项目相关的所有日志。 5 它比署名（这是一种工程中常常使用的追踪方法）更加有效。它包括了所有类型的评审－－RUP 在认识这些评审重要性方面是相对独特的。

开发案例定义了您所需的评审；特别是，它完全符合过程路线图的要求。过程工程师可以监督在任意的项目过程中，谁需要评审哪些工作产品－－在正确的时间为正确的工作产品作质量保证测试。评审记录是一种记录并追踪质量保证评审的工具（参见图1）。

作质量评审最好的时机就是实时的 -- 当工作产品被实时创建的时候。如果您等到它们已经完成且要求涉众正式的"祈祷"时，已经丧失了评审实时效果的机会。 6

您有没有听到过，在项目接近完成的时候，企业架构师或数据库架构师抱怨说， "我怎么没有参考那种设计"？ 评审记录能够帮助您避免这种情况的发生，它记录了项目中所发生的所有评审，不管它是多么不正规的。例如，假设您交给架构师（他是设计工作产品的"顾问"）一张便条写着"这是我的设计。如果一星期之内没有收到您的回信，我将认为这是一个好的设计。" 虽然您没有正式的署名，但您的要求表示这是一种跨团队的合作方式，它降低了产生不符合企业架构标准的设计的风险。 您可以将其记录在评审记录并随时参考。

评审可以以各种不同的形式。 也许是一组获得愿景文档的人坐在一起聆听演讲，之后讨论所列出的特征列表。（虽然部分企业赞同这种高规格的评审，但我们设法尽可能简化评审）。也许项目经理在入口处提供文档，希望涉众给予建议。这种评审形式的灵活性是值得提倡的。这样有效确保了在正确的时间可以参考正确人的意见 。

您可以选择评审日志的颗粒度级别。如果您要介绍某件工作产品的新版本，那么您需要花费大量时间做日志记录。我倾向于仅仅记录参考的内容。表 2 是一个RUP所提供的经过调整了的版本的评审记录例子。

表 2：评审记录范例

工作产品评审记录
RUP 迭代	评审完成日期	已评审工作产品	评审参与人员	评审方法	问题	是否再次评审其他评审记录?	跟进措施	签名？	评审工作量总计
I1	2006年7月4日	愿景	BR	会议	无	否	无	Y	10 人时
E1	2006年8月1日	UC 情节板	EA，BR，SA	会议，白板	无	否	无	否	6 人时

注意以下几点：

• 如果评审完毕，有必要的话会出现在一个与工作产品关联的单独的表单上。
• 第一栏, RUP 迭代，指出所产生的RUP迭代 （例如，I1 = 第1个启始迭代)。
• 评审工作量总计 栏包括了评审的所有成果。 正如第一行所示，一次十人讨论愿景文档一小时的会议是十分昂贵的。获取评审所需的全部投资允许您在评审与改进质量间做出更好的取舍。
• 评审方法 栏所包括的属性值有：会议、电子邮件、陈述，等。

随着团队建立并评审每个工作产品，项目经理会在评审记录内记录评审情况并制定下一步计划。随时记录评审记录并不是一项繁重的任务；它只需要很少的时间就可以完成。

我扮演了一家中型企业过程工程师的角色，包括与项目经理一道定义 开发案例。我十分适合这一角色，因为我具有多年的RUP项目管理经验，且经历过很多成功与失败。在我看来，一名好的顾问应该是经历了很多错误并从中学到很多的人－－你付钱是为了让你避免再次重复同样的错误。如果您的企业刚刚开始进行迭代开发或RUP，借鉴内部顾问的经验也是非常重要的。 7

一旦项目经理和过程工程师决定了在开发案例中使用哪些工作产品，项目经理就可以用来做路线图，为每个团队成员分配工作建立适当的工作产品。开发案例定义了这些工作产品的期望评审点，因此它对于项目管理办公室，或 PMO （表 2中的企业事例具有PMO）十分有用。 PMO的一部分工作就是确保创建了工作产品并在适当的时机进行评审。在阶段评审时，PMO 可以简单的核对评审记录所对应的开发案例中所期望的工作产品列表，用以检查是否进行了全部所需的评审。如果项目经理知道会检查评审记录，那么他们都会用心的评审工作产品。

开发案例和评审记录的过程改进

RUP建议企业应在项目中的迭代过程中不断的努力改进过程，而不是在各个项目间进行改进。开发案例和评审记录能够支持这些成果。虽然那些对于RUP的更新有时会假设开发案例在初始阶段是一种 "快照型"工作产品，之后什么也不会改变，但这并不是真的。 作为评估迭代任务的一部分，团队常常要识别出那些并不十分有用的工作产品，或是那些有用的附加工作产品。这时，他们需要更新开发案例 和评审记录以反映这些改进之处，使得项目经理能够据此调整后续的迭代计划。

提示和收益

正如我们所见到的，开发案例 和评审记录共同确保开发团队在适当的时候生产出适当的产品，并以适当的方式由正确的人进行评审。使用他们来：

• 确保您使用 开发案例的定制版本创建了适当的工作产品（只是必需的）。
• 确保您利用评审记录在早期质量评审和校正周期中完成这些工作产品-- 以避免在开发后期的修补与重写。
• 关注于有效评估质量，而不是100%完成您的工作产品。

除了在开发周期中收集来自涉众反馈的明显好处外，获取工作产品的企业评审使得团队从项目中得到最好的实践锻炼，并能在企业内广泛传播。使用开发案例和评审记录可以以这种方式支持过程与全部工作产品质量的改进。

近年来，我们努力学习最灵活过程的可能；通过裁减软件开发项目中的臃肿部分节省了大量金钱。但是，这并不代表项目经理可以有什么捷径解决沟通和质量的风险。开发案例和评审记录提供了一个干净的，简单的路线图，覆盖了所有重要的基础，并且表示出了灵活性与原则间有效的平衡性。 8

感谢

感谢 Bruce MacIsaac 和 Scott Ambler 对于本文的见解。

注意

1 要了解使用大量过程的反模式，请参阅 Per Kroll and Philippe Kruchten，The Rational Unified Process Made Easy, 2003中的 "Common Mistakes When Adopting and Using the RUP"章节。

2 要了解更多关于软件成果评估的信息，请参阅 Barry Boehm 等，Software Cost Estimation with Cocomo II，Prentice-Hall: 2000。

3 要了解更多信息，请参阅 Dynamic System Development Method (DSDM) MoSCoW 规则。 搜索这一条目时，搜索引擎会返回许多基于Web的资源。

4要了解更多有关Review Type推荐价值的信息，请参阅 RUP开发案例模版。

5 Scott Ambler 建议本文称作 Quality Log 或 Compliancy Record, 正如很多人将"review" 与过度正规或繁重过程联系在一起。我更喜欢评审记录, 或评审日志。您可以使用对您有意义的名称。

6请浏览 Scott Ambler's "Best Practice or Process Smell?" 发表于: www.agilemodeling.com

7 当 Joshua Barnes的书，Implementing the IBM Rational Unified Process and Solutions: A Guide to Improving Your Software Development Capability and Maturity, 2007, ISBN: 0321369459,今年晚些时候出版的时候，它将包括执行RUP时有关顾问价值的讨论。

8 要了解有关使用太多过程所带来问题的讨论，请参阅Kroll & MacIsaac, Agility and Discipline Made Easy: Practices from OpenUP and RUP，Addison-Wesley Professional: 2006中的 "Common Mistakes When Adopting and Using the RUP"章节。

9 Pareto 规则指出，我们可以只花费20%的努力就可以完成80%的工作。这就是说，我们往往将80%的工作量浪费在了剩下的20%的工作。因此选择哪部分的20%的工作值得去做是很重要的。

参考资料

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