Rational Unified Process（或者简称为RUP） 是一套由Rational Software开发的完整的软件开发过程框架。它使用迭代式开发方法学，也可以被描述为"用例驱动的、风险驱动的和架构驱动的"。对于许多的刚刚开始使用RUP 的软件开发人员来说，这些都是新概念，也就意味着，在项目中第一次使用RUP 时，需要大量的培训和指导。仅仅"看看书"是不够用的！本白皮书描述了Volvo Information Technology 是如何实施RUP 的，如何通过调查问卷评估使用RUP 带来的影响，以及如何使用SPICE Framework（ISO 15504）评估开发团队软件过程能力的改善的。

摘要
Rational Unified Process（或者简称为RUP） 是一套由Rational Software开发的完整的软件开发过程框架。它使用迭代式开发方法学，也可以被描述为"用例驱动的、风险驱动的和架构驱动的"。对于许多的刚刚开始使用RUP 的软件开发人员来说，这些都是新概念，也就意味着，在项目中第一次使用RUP 时，需要大量的培训和指导。仅仅"看看书"是不够用的！本白皮书描述了Volvo Information Technology 是如何实施RUP 的，如何通过调查问卷评估使用RUP 带来的影响，以及如何使用SPICE Framework（ISO 15504）评估开发团队软件过程能力的改善的。

简介

Volvo IT
Volvo Information Technology（Volvo IT） 是一家AB Volvo 的全资子公司，AB Volvo 是Nordic地区最大的工业集团之一。Volvo IT提供在各种技术环境下的所有类型的工业IT 解决方案。该公司成立于1998年，由不同Volvo Group公司的所有IT 资源合并而成。Volvo IT 为Volvo Group、Volvo Cars（自从1999年以来由Ford Motor Company拥有）和其他的选定客户提供成本最优的IT 解决方案，并获得了长期的业务价值。

Volvo IT 是一家全球综合性的IT公司，拥有4300 名员工，每年销售量超过50亿瑞典克隆。 Application Development Techniques组织是一家更大型的站点，负责为应用程序和维护团队提供包括开发过程、方法、工具和应用程序开发环境的技术支持。

Volvo IT的软件过程改善环境
软件过程的改善常常在业务环境中进行。由于Application Development是Volvo IT中的关键过程之一，所以实施新的Application Development Process就必须被看作是对关键过程的一个主要改善。在我们努力实施RUP的过程中，主要围绕三个"层次"进行工作。

• 方法策略级别
• 过程/方法开发级别
• 应用程序开发级别

图1：软件过程改善环境

在方法策略级别，我们关注于业务的挑战和目标，以及通过在Volvo IT中改善软件过程所期望得到的效果。这些在"业务环境"章节中进行了讨论。

为了实现方法策略的目标，我们需要面向例如应用程序开发的过程和方法。在"新应用程序开发过程的实施"一章中，我们讨论了评估、选择和实施这种过程和方法的策略。在这章中，我们也讨论了实施的目标和验证软件过程改善级别的预期效果的结果。

评估RUP 实施结果的基础就是使用RUP 的项目的结果。在"RUP 项目中的经验"一章中，我们介绍了从客户和开发人员中得到的一些反馈和教训。

在"评估使用RUP 的效果"一章中，我们讨论了如何将RUP 项目中得到的经验与SPICE评估方法协同起来使用，从而验证改善Volvo IT的软件过程所得到预期效果的程度。

业务环境

业务的挑战和目标
如同IT 领域中的大多数其他公司一样，Volvo IT也面对着新的挑战，需要改变开发交付品和维护软件应用程序的方式。其中一些挑战包括：

• 应用程序与业务的集成程度越来越高。因此，应用程序开发过程必须与业务工程过程相集成。
• 业务变更的频率是逐渐增加的。因此Volvo IT必须提高生产力，从而能够对新的和正在变更的需求做出回应。
• 客户想要使用全球化的解决方案。这一事实导致了项目数量的增加，项目团队分布于不同的国家和大洲。

结论就是我们需要应用程序开发过程，将其与我们现有的项目管理和业务工程过程协同起来，创建一个框架以满足挑战并完成目标。

预期效果
使用新过程框架的长期预期效果包括：

• 将良好定义的业务需求作为应用程序开发项目的输入。
• 在交付时提供更优秀的产品以满足实际需要。
• 在应用程序第一个版本交付之前使用更短的指导时间
• 更多的项目准时并在预算内完成
• 减少重复工作的成本
• 更好的产品可维护性
• 面向应用程序开发的一个共同过程

新应用程序开发过程的实施
Gartner 小组说过：

"在拥有100到200名开发人员的AD 组织中要完全实施AD 方法学最少需要2到3年。"

由于Volvo IT比Gartner所引用公司的规模要大得多，所以这项工作就更需要花费时间，也需要正确的管理，这一点是很重要的。Volvo IT在1998年中期启动了一个项目，以制定如何管理方法问题以及如何发现合适的共同应用程序开发过程备选方案的策略。

方法策略
在业务中实施或变更应用程序开发过程是一项带有很多陷阱的任务。在方法策略中，我们将"关键成功因素"应用于工作中以在公司中建立一个共同应用程序开发过程。成功因素恰恰是基于Gartner Group以及其他人所发现内容之上的。一些最重要的成功因素包括：

• 管理承诺
  我们确信，从最上级的管理层开始，绝对需要进行非常有效的承诺，而且管理层需要懂得公司将要实施一个新的、共同过程时所要面对的变化的程度。
• 室内过程工程技能
  应用程序开发过程（包括其不同变量）是Volvo IT业务的中心部分，因此，很重要的一点就是我们要控制公司内部不同过程变量的内容和配置。
• 应用程序开发过程以及其方法和工具之间的集成
  仅仅使用一个过程（描述要做什么）进行应用程序开发是不够的，仅仅使用方法（描述如何完成）也是不够的--它们两者我们都需要，不同的方法和工具之间以及与过程之间都是一致的。
• 过程必须是易于分布的
  由于我们已经意识到所选择的过程会持续演化发展，所以过程新版本和配置的分布必须是容易实现的。太多的过程和方法已经成为了"货架件"，这并不是我们所说"实施"的意思。

评价标准
在方法策略的基础上，Volvo IT决定开始研究面向应用程序开发过程的合适后备的市场。对于Volvo IT来说，其目标是从支持现代应用程序开发实践的市场供应商手中得到一个已知的、试验过的以及已测试的标准过程，并且使用该过程。

要完成这个目标，我们首先需要创建一套用来评估不同后备方案的标准，并关注这一过程本身以及与供应商可能的关系。我们设定的标准包括：

• 迭代式过程。
  要能够对快速变化的业务需求作出回应，重要的一点就是过程需要支持迭代式开发。
• 过程必须是可配置的。
  每个项目都有其自己的特点，一个过程是对理想情况的普通的、标准的描述。因此，该过程必须是可配置的，以满足特定项目的需要。不过，即使每个项目具有其独特性，也可能使用"项目类型"将项目进行分类。因此，我们也需要配置该过程，不仅仅是对于特定的项目，对于一些"过程变量"也是如此。
• 全球性培训与支持
  在Volvo IT中的开发人员可以得到相当的培训并对我们主要的站点所在地提供支持，这是很重要的。
• 选择合适的供应商
  由于这是一个长期的投资活动，重要的就是要选择能够使我们在市场上经受挑战的供应商。供应商使用的策略应该能够根据客户的需要持续进行过程的开发，这也是很重要的。

基于这一标准，Volvo IT 评估了许多不同的、可能使用的过程和可能合作的供应商，结果就是我们选择了Rational Unified Process作为我们的共同应用程序开发过程。

MAPS--RUP 的实施项目
在实施策略的基础上，Volvo IT决定建立一个实施RUP 的项目。项目的名称为MAPS --进行系统开发的方法和过程。

分阶段的方法

改变业务的"产品过程"常常意味着给相关业务带来压力。当业务的过程变化并因此造成业务流程变化时，这就意味着一个很大程度上的文化转换。这种文化转换意味着业务中的人员需要改变他们"查看"和"考虑"业务的方式。

为了促使这种文化转换，我们必须开始积攒新应用程序开发过程的经验。由于我们已经意识到对于我们公司来说，不可能在一个全新的项目中马上开始使用RUP ，所以我们决定使用一个分步骤的实施方法。根据这一方法，第一步就是启动一些试验项目，并且在这些项目经验的基础上按照一些实施的步骤将其继续应用于更多的项目中。（参见图2）

图2：分阶段方法

MAPS 项目的预期结果为：

• 足够数量的经RUP 培训的开发人员，能够使用UML和Rational Suite，从至少一个项目中获取如何将过程、方法和工具协同使用的经验。
• 足够数量的室内职员，从而可以使Volvo IT在需要RUP指导员和RUP 专家时能够进行自身支持。
• 适合Volvo IT特定需求的支持资料，从而能够为RUP 项目提供支持。

MAPS 项目应持续进行，直到开发人员、指导员以及专家这些"关键人物"的数量达到要求。

如何启动？

我们通过在第一次实施步骤中定义合适项目的选择标准而启动。定义这个标准的原因就是我们意识到我们不能承受第一个RUP 项目出现任何闪失，所以我们必须精挑细选，才能决定哪些项目应该作为第一批使用RUP 的项目。该标准包括：

• 项目规模：项目团队 3-10人，持续3-9个月，2000-5000个工时。
• 学习时间：绝对不能在"紧要的最后期限"才交付产品。我们也预料到在第一个项目的初始阶段生产力会有所下降：我们估计，至少额外需要4周的时间才能学会新的过程、方法和工具。
• 学习的兴趣：项目经理和团队必须对于学习RUP 感兴趣。

如何组织？

经验证，学习新事物（例如，RUP、UML以及其工具）的最有效方式就是将理论与实践相结合。要能第一次使用RUP 和其工具，并且同时创建高质量的产品，该项目团队就需要大量的技术支持。RUP 指导员的职责就是提供这些技术支持。技术支持材料由RUP 专家进行开发。他们在为开发人员提供技术支持的同时，也要帮助RUP 指导员。开始时，我们需要使用外部专家，因为在Volvo IT中，还没有做好准备的室内职员可以承担起指导员或专家的重任。

我们意识到对于MAPS 项目来说，不可能将RUP "推入"组织中--我们需要组织进行"拉动"。要达到这一目标，我们在Volvo IT的每个开发站点都设立了本地协调员。协调员可以被看作为项目的子经理，他们的职责就是在他或她的站点内协调所有的RUP 实施活动。实际上，协调员也包括于MAPS 项目团队中。

图3：RUP 实施项目组织结构图

这一方法经验证非常奏效。今天，我们的Volvo IT 职员已经能够承担起RUP 指导员和RUP 专家的重任了。

实施过程的关键角色

在Volvo IT中，使用RUP是组织系列的职责。例如培训、授权、工具和指导之类的资源由MAPS 项目提供。

RUP 指导员

RUP 指导员的长期目标就是在他或她的站点为RUP 的使用提供技术支持，向项目成员提供切实可行的帮助，将新的开发活动、计划和结果通知给感兴趣的一方。

短期的目标就是学习如何进行指导；通过参加RUP项目掌握过程、方法和工具，并通过参加指导员网络与其他指导员交换经验。

指导员需要理解每个工作流中产出的工件，并且根据项目的特点理解每个阶段和迭代过程中恰当的信心度。

要想成为一名RUP 指导员，系统开发的经验是必需的，也必须理解开发的角色以及他们在过程中的位置。通过考虑项目的类型和项目成员以前的经历，指导员必须能够判断哪些工具是合适的。指导员也需要优秀的个人品质，例如领导才能（策划事情并关注于结果）、沟通技巧（能够聆听、具有必胜的信心、能够激励他人并使人信服）以及教育的能力（能够将理论应用于实践）。

RUP 专家

一名RUP 专家的职责包括支持材料的开发和改善，例如Volvo IT的RUP配置，以及其模板和指南等。专家也负责在为项目提供技术支持时帮助RUP指导员。要能承担起RUP专家的任务，应该具备技术支持RUP项目的广泛经验（例如，从RUP 指导员干起）、完整地理解RUP、过程配置和评审。

一般情况下，一名RUP 专家主要将注意力集中于一个或几个RUP工作流上。

协调员

协调员的职责就是在他或她的站点计划、管理和监视过程、方法和工具的使用。协调员的工作肯定要包括计划和监控RUP的使用，帮助站点管理层发现合适的RUP项目，协调培训，通知职员、客户和对于RUP感兴趣的其他方面人员。

协调员也应该作为一名项目控制委员会的成员加入使用RUP 的项目，并监控RUP 的使用和效果。

要能够成为一名协调员，必须总体上掌握RUP以及RUP与项目潜移默化的关联。协调员作为站点代表也必须受到来自管理层和开发人员方面的信任。

项目的主要活动
MAPS的主要活动是在不同RUP 项目中本地执行的。MAPS的主要职责就是协调所有那些活动。不同的活动可以使用下述组别进行分类。

培训

进行RUP 培训，方法和工具是成功的必要因素和先决条件！但是培训只能提供RUP、方法和工具的理论知识。我们承认这些理论知识并不是足够的，因此在第一次RUP项目中，培训阶段后续还跟有技术支持（见下面）。

根据人员在项目中的角色不同，参照下表，他或她推荐使用不同的培训课程。大多数的培训课程是标准的Rational课程，但是我们也为那些需要了解RUP 项目特性、RUP 项目之间的不同以及传统项目的人员提供一个简短的介绍性培训。这一目标群体中的人员包括客户、用户以及常常参与控制委员会的Volvo IT经理。

图4：每个关键项目角色和其他项目干系人需要进行的基础培训

为RUP 项目提供技术支持

如上面所述，学习RUP 的方法就是将理论知识与实际工作结合起来。在RUP 项目经验的基础上，我们将这种技术支持分为三类：工作组、指导活动和评审。

图5：工作组和评审结构

工作组
我们非常快地意识到当第一次面对特定问题时，几乎所有的项目都面临相同的问题。为使指导更有效并有预测性，我们创建了一套可配置的工作组。每个工作组：

• 刷新理论知识，从培训课程中有所收获。
• 将理论知识应用于特定RUP 项目的问题、工件等中。

由于RUP 、UML和其工具对于大多数开发人员来说都是新的，所以让工作组尽早将精力集中在项目上是很重要的。在实践中，这就意味着一般情况下，在初始和细化阶段很重视这种技术支持。

指导
指导是对工作站间RUP项目团队不同角色提供的日常技术支持。指导活动一般情况下其本质是很有实际意义的，并且是摸得着的。它主要关系如何解释RUP活动或工件、如何在特定情况下创建特定的UML模型，或者如何在特定情况下使用某一工具。

评审
评审是非常重要的！除了进行正常的评审以确保项目中的产品质量之外，我们也要评估对项目提供的技术支持的效果。这种"额外的"评估过程对我们来说是很重要的，由于RUP 实施要在其支持的RUP项目取得成功的基础上才能进行评估。

评审至少要在阶段的末期进行，但是它们也可以在迭代过程的末端用做为"状态评估"。

从RUP 项目中得到的经验
实施和开始使用一个新的共同应用程序开发过程对于像Volvo IT这样的公司来说算是一笔很大的投资了。因此，对于我们来说，很重要的一点就是要得到有关RUP本身和其技术支持是如何被RUP 项目团队成员和客户接受的反馈。

调查表
评价RUP和RUP技术支持的一种方式就是使用调查表。当RUP项目结束之后，该评估过程由客户代表、项目经理和项目团队共同完成。调查表主要关注5个不同的方面：

• RUP 与"传统工作方式"相比较
• 开发过程
• 培训过程
• 指导和技术支持
• 迭代的方法

对于每个方面，我们都使用若干个问题从项目干系人那里得到意见。

调查结果经汇编后提供给项目团队和MAPS 项目控制委员会。我们的总体目标是至少80％的调查对象是满意的（按照1-4级，要达到3或4级）。结果表明我们远远超过了这一目标--在一些案例中甚至达到了95％！

如果我们对从调查表中的详细问题得到的经验以及由被访者提供的附加评论进行总结的话，得出的最重要的消息包括：

• 在项目过程中对于需求和风险的关注是尤其值得欣赏的。
• 维护应用程序的成本预计要低于维护使用传统方法开发的应用程序的成本。
• 实施一个新的应用程序开发过程是一种对于能力的投资，并且必须作为一种长期的改善。

成功案例
最有价值的证明就是当RUP项目的客户表示他们喜欢"新的"工作方式时。我们已经得到了这样一些例子。下面的内容引自一个RUP项目的客户，出版于一家Volvo IT的内部杂志：

"太奇妙了！我们被邀请参加一次对话，并得到了一个扭转乾坤的解决方案。"
"我们已经发现这些不同的阶段带来的是我们可能永远想不到的事情。当及时构建起架构时，我们没有在最后时刻碰到任何令人不愉快的意外情况。"
"他们确实发现了奏效的不同解决方案的实例，并使用每个人都能理解的方式进行了解释。从产品负责人到组装人员，每个人都参加并影响了过程。他们对于我们的需要和愿望总是乐于接受的。仿佛他们几乎可以在字里行间得到信息。以这种方式进行工作使我们更好地扩展需求。

评估使用RUP 带来的效果

如何度量使用RUP 带来的效果
经培训使用RUP 的开发人员总数估计在1000人。这相当于投资范围从5000万－10000 万瑞士克隆，等于500-1000万美元。因此高级管理层提出的问题就没什么可大惊小怪的了："你能证明RUP 很值得投资吗？"如果在项目的第一个回合中使用RUP 并没有得到的肯定效果，那我们为什么还要继续呢？

好，我们能度量些什么呢？

• 　
• 很明显，为得到RUP试验的反馈而设计的调查表不能作为客观的证据。当您是第一个采用新过程并使用新工具的人时，一般情况下都是值得肯定的。
• 仅仅通过查看使用RUP 的项目的发布精确度（与早期估算的实际时间和成本相比）对于判定RUP的效果来说还是不足够的。相反，迭代式方法可以使客户和供应商能够对于范围和优先级随着问题和解决方案发展而出现的变更达成共识。
• 随后，我们要使用软件过程改善与能力判定（SPICE）框架评估"过程能力"。通过评估项目团队的"传统工作方式"，以及随后将这些数据与相同团队"使用RUP 进行工作"的评估结果进行比较，我们就有希望能够记录团队的软件过程能力是如何得到改善的。

SPICE 框架
SPICE（ISO/IEC 15504）提供了一个关于过程和过程能力的二维模型，将其做为过程评估的基础。将过程分组为五个类别：

• 客户－供应商过程，例如需求引导
• 工程过程，例如软件构建
• 技术支持过程，例如配置管理
• 管理过程，例如项目管理
• 组织过程，例如人力资源管理

在每个类别中，都使用该过程的目的来描述过程，包括一个过程实施的预计结果的列表。对于每个过程来说，使用9个属性评估过程的能力，检验过程的性能，管理方式，得到的产品，以及变更的管理方式等等。这些属性的评定级别用于获得该过程的能力级别。每个过程都有不同的能力级别评定。

图6：SPICE 的能力级别

SPICE 与美国Carnegie Mellon大学的软件工程机构（SEI）提出的能力成熟度模型（CMM）有很多相同的地方。主要的区别就在于SPICE 允许您选择想要评估的过程，而且每个过程都通过自身订立评审级别，在SPICE 中，CMM 根据特定的需求将必须执行的过程"打包"，以使组织处于特定成熟度上。新的集成CMM（CMMI）为SPICE提供了一种简单的方法。

面向RUP 建立目标能力标准
因此，应该能够建立一种组织以理想方式使用RUP所能达到的"目标能力标准"。实际上，这种目标标准已存在于Rational Software 之中，是由Rational Software 的John Smith 于1998年进行的内部学习时得到的。该研究过程使用较老版本的SPICE 对较老版本的RUP 进行了评估。

2000年春天，在瑞典的University of Boras使用当前版本的SPICE 判定了RUP 5.5版本的"目标能力标准"。这一研究的结果表明在使用RUP 方法时能力级别3在理想的情况下预期可以满足选定过程的要求。不过，对于使用RUP工作的团队来说，期望在2-3年的时间达到预期标准。我们不能期望项目团队在第一个使用RUP 的项目中就达到3级标准（如果他们的启动级别是1或2的话）。

"使用ISO/IEC TR 15504 预测软件质量--Rational Unified Process 的能力判定"，掌握信息学的原理，Hogskolan I Boras ，Marie Jakobsson 著，导师：Alec Dorling（2000年春）

图7：RUP 的SPICE 能力标准

评估程序
我们设定一个评估程序判定在我们的RUP实施过程第一步骤中10个RUP 项目团队中的三个的"之前/之后"能力标准。所选项目代表了不同的应用程序地区、不同的站点和不同的技术环境。

我们使用了一名外部咨询师培训一些内部评估员，并且领导评估小组，同时，我们使用下述阶段根据SPICE的需求计划我们的评估程序：

• 前评估调查表，带有一组关键文档
• 评估计划和日程安排
• 项目团队的1个小时的简介（会见的前一周）
• 项目团队为期1天的会见
• 检验与评定级别
• 项目团队研究结果的反馈（会见之后）
• 评估报告（会见之后的一星期）

在评估的过程方面，评估的范围如图8所示。对于所有这些过程，在以理想的方式使用RUP 5.5时，其期望的能力级别为3。

对于每个被评估的项目：

• "前评估"或者"传统的工作方式"在项目开始前执行，来看一看如果不将其选定为使用RUP 的项目，该项目可能会如何来执行。
• "后评估"，在RUP 的构建阶段评估RUP 的工作方式。

会见应该被限定在一天内进行，尽量少打扰项目团队，在同时也要收集足够的信息从而可以正确地评定级别。如果一天时间太短不足以评估所有的过程的话，我们就需要对评估过程制定计划。我们也发现在某些情况下，评估集成与测试过程进行得有些过早了，这是由于在第一次迭代过程中这些过程还没有进行到能够得到公平评定的程度。

评估结果
下图是一个项目的评估结果。对于每个过程来说，上面的条是"传统的工作方式"，下面的条是"使用RUP进行工作"。

图8：对于一个RUP 项目的"评估能力级别"

该图表明，在需求、分析、设计和项目管理过程中，能力已从1级增加到2级。在传统的工作方式中没有进行验证和风险管理过程。"使用RUP 进行工作"的项目被评定为1级。

在所有我们评估过的三个项目中，需求、分析、设计、构建和项目管理过程在"使用RUP 进行工作"的项目中都被评定为2级（只有一个例外）。在对这些首次使用RUP 的项目提供指导时，焦点集中在这些过程上。很清楚，在开始使用RUP 时，焦点就是在首先得到终端产品上，这就意味着，工程过程、建模技术和新工具最受人瞩目。这些项目中，有两个是初次使用Windows DNA 环境，这就需要在技术方面给予更多的培训和指导。

评估结果清楚地指出，RUP 的实施确实取得了效果。不过，随着使用RUP 经验的增加，还存在很大的潜力进一步改善过程能力。建议项目团队在反馈期间进行过程改善活动， 在反馈期间中提出每次评估的结果并进行讨论。也存在改善管理与技术支持过程中提供给RUP项目的技术支持的潜力。建议的行为包括技术支持的内容以及如何提供技术支持两方面，并在评估期间进行记录。因此，评估过程除了能提供证据以表明实施RUP 得到肯定的效果之外，也对我们进行实施过程的方式所存在的优点和缺点进行了有价值的深入分析。

如何将过程能力转化为生产力
当我们向管理层汇报我们的发现成果时，他们十分高兴，但是还是要问那个问题："你能告诉我们将会节省多少钱吗？"

很好，这是一个难以回答的问题 ．．．不过2001年4月发行的IT Metrics Strategies 里有一篇文章，讨论了工作于CMM 级别2的团队与工作于CMM 级别1的团队相比是如何的快速、省钱和优秀。该篇文章在从CMM评估到Quantitative Software Management（QSM）运行的大型数据库所得的校准统计数据的基础上，包括了对超过2500个项目的生产力度量。虽然该文讨论的都是些很大型的项目，该文也引用了由QSM 提供的数据，表明了在编码和测试一个大概50000行代码的业务应用程序时，从CMM级别1 向CMM级别2升级将会

• 减少17％的日程安排
• 减少46％的工作量
• 减少51％的缺陷

而且，从CMM级别2向CMM级别3升级又会减少50％的工作量和缺陷！

现在，CMM成熟度级别并不与SPICE能力级别完全相同，但是有一点是很明确的：软件过程改善会对面市时间和成本以及产品的质量带来非常肯定的影响。

通过实施RUP ，我们能够在2-3年的时间范围内将使用RUP 进行工作的团队的选定过程达到能力级别3。因此，即使根据"Volvo IT 解决方案"实施RUP所需的投资是相当多的，我们潜在节省的成本会更多。

管理层高层接受了这一"间接证据链"，并且允许我们继续执行实施计划的下个步骤。

结束语

我们达到目标了吗？
在调查表和客户证明反馈的基础上，得出的结论表明我们正在朝着正确的方向前进。客户和开发人员喜欢新的工作方式，并且也承认需求的质量提高了，可以建立起更稳固的架构。在项目的早期管理变化的需求并且得到产品的一个版本的可能性增加了，而且在项目中尽早运行特别受欣赏。他们也期望根据RUP 创建的产品维护起来会更加方便和便宜。

SPICE评估结果清楚地指出，RUP的实施提高了应用程序开发能力。不过，随着使用RUP经验的增加，还存在更大的潜力进一步提高过程能力。

我们也知道要达到"应用程序开发的共同过程"这一目标还需要一些时间。可能需要再来5年，但是，现在我们有信心能够而且必须这样做。

总体建议
在这些经验和评估结果的基础上，我们认为实施RUP 的这一解决方案也会在其他组织中发挥作用。我们成功的一些主要因素包括：

• 管理层承诺。确定管理层从实施RUP 项目的开始和整个实施项目中提供有效的支持。
• 建立一个实施项目。在线性组织中将这种大型工作与一般活动分离是很重要的。建立一个单独的项目可能会为这一工作提供所需的关注和注意力。 分阶段的方法。不要尝试一次在公司的所有部门实施整个RUP项目。实施一种新的应用程序开发过程就是在公司中实施一种新的思维方式和工作方式。对于不同的角色需要将许多功能集合起来，而且这也需要时间。 良好定义的角色和职责。不要尝试将RUP "推入"组织。协调实施过程并且指导项目成员的组织需要具有良好定义的并且分布的职责。
• 打包的工作站（包括技术支持资料），经过协调以满足项目的特定需要。保证您能够使用精心准备的技术支持资料为RUP 项目提供技术支持。

不过 ．．．实施一个例如RUP的新的应用程序开发过程对于软件过程改善团队和公司来说仍然是一种挑战。我们得到的教训包括：

• 首要的投资。实施一个新的开发项目需要时间并要花费大量成本。因此，这种努力应该被看做是一种对于能力的投资。对于每项投资来说，您应该估算其可盈利性。
• 不要低估人力因素。改变人的思维方式和行为方式需要时间。保持耐心是很重要的。

尽管如此--这是可能的！

工业化 IT 成功背后的秘密

一个问题，虽然几乎已经得到解决，但仍然是一个没有解决的问题。一个可以在理论中奏效的解决方案还不是一个解决方案。直到解决方案已经验证能够完成实际工作（而且还没有在他处引起新的问题），问题才确实被解决了。这就是我们如何在业界的实际情况中经过多年以后学到的看待事物的方式。

获得成功不只需要具有完整的IT 知识。也需要深刻地理解当今市场中的业务流程和想要获得成功的业务公司的高端需求。

在Volvo IT ，您将遇到把Volvo 塑成汽车行业的领先IT用户的同伴。我们很高兴和您共享我们的知识和经验。而且，我们不怕挽起袖子大干一场，一定要保证工作成功完成。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• Philippe Kruchten，《The Rational Unified Process, An Introduction》（第二版），Addison-Wesley，2000。
  
  
• 有关SPICE框架的信息可以从SPICE的官方主页www.sqi.gu.edu.au/spice 得到。
  
  
• Paulk M. C.等人，《The Capability Maturity Model - Guidelines for improving the Software Process》，Addison-Wesley，1995。
  
  
• The assessment of RUP 5.0 against an older version of SPICE 可以从 www.rational.com/products/rup/resource_center/media/RUP15504final.pdf 得到。
  
  
• Jakobsson Marie，《Predicting software quality with ISO/IEC TR 15504 - Capability determination of the Rational Unified Process》，《Master Thesis of Informatics 2000:M17》, 计算机科学与商务管理系，瑞典Boras大学。
  
  
• Rifkin Stan.，《Climbing the SEI CMM Makes a Difference on Software Projects, in: IT Metrics Strategies》，2001年4月，The Cutter Consortium。
  
  
• Putnam Lawrence H.，Linking the QSM Productivity Index with the SEI Maturity Level，可在 www.qsm.com上得到。