成功案例

    最有价值的证明就是当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 的工作方式。

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