文档介绍：一个学****案例: 使用 IBM Rational Unified Process 作为方法框架
文档选项
未显示需要 JavaScript 的文档选项
打印本页
窗体顶端
窗体底端
将此页作为电子邮件发送
级别: 初级
Maureen Field (mfield@), Group Leader, IT Project Office, Ford Credit
Venkat Alladi, Process Methodologist, Ciber, Inc.
2004 年 4 月 01 日
本文来源于 2003 年 Rational 用户大会的一个演讲稿,这个学****案例的研究讨论了一个公司成功的开发和部署以 IBM RUP 作为过程框架的迭代开发方法的真实经验。实现一个标准的过程和这个过程为开发组织提供的未来机会也将在本文中被关注。
介绍
本文被划分为五个部分。首先是一个简要的介绍,然后我们将讨论我们的开发工作,随后我们将讨论我们的部署工作、经验教训和对本文的总结。
这个案例研究是一个现实世界的真实的经历,它是关于我们的团队如何成功的开发和部署一个使用 RUP® 作为过程框架的迭代开发的方法的。这是福特公司和福特金融信贷公司共同工作的结果。福特金融信贷公司是福特公司的一个全资控股子公司,并且是汽车金融的最大供应商。我们在四十个国家为超过 11,000 个经销商提供车辆金融服务,并且自从 1959 年以来我们已经为超过五千万量汽车提供了贷款服务。我们以福特金融而闻名,通常媒体称我们为福特信贷。我们拥有超过 700 个职员的庞大的 IT 队伍。
我们的动机是什么呢?
我们很难跨越项目实现项目交付产物的共享。每一个团队都拥有自己的一套模板和他们自己的方法。当职员被从一个团队调到另一个团队时,他们必须学****新的方法。同时我们也很难利用公共团队。这些团队是外部的应用团队,他们提供良好的产品和项目服务。服务团队的例子包括象 DA 、DBA 、框架团队和构建团队。每个服务某一方面的应用团队都有不同的交付产物集合,因此他们没有一个公共的过程框架。
我们也有些晚的在项目中包含这些服务团队,因此导致了一些问题。人们在需要进入产品化阶段时才想起构建团队,而不是在适当的时候联系他们。
此外,我们的框架架构师一直被过程问题压的喘不过来气。框架架构师的工作是设计并维护我们的设计模式;相反他们一直被询问如何组织一个项目、什么过程应该被使用和项目应该有多少迭代。那不是他们的工作。
项目也正感觉到了另一个痛处:过晚的项目风险的识别。我们有一个必须连接数据仓库和为报告目的返回信息的项目。他们将这个需求留到了最后的时刻,并发现应用的性能不是足够快的。这对项目造成了很大的影响。
最重要的是,这种对拥有一个公共过程的努力是一个拉动的工作,而不是一个推动的工作。我们并没有在我们的组织中推进这种方法。而是我们被要求实施一个公共的软件开发过程。
我们为什么选择 RUP ?
在我们的组织中我们拥有一些在 RUP 方面的技术专长。我们也知道 RUP 是可以定制的。一些框架团队的人员说他们非常了解 RUP ,并起草了一份一页纸的 RUP 的概要,这显然是被过份的裁剪了。
我们也知道无论在公司内还是公司外我们都已经拥有丰富知识的资源。我们知道 RUP 提供了一个丰富的被在工业中清晰定义和良好理解的术语集合,我们也知道这是 RUP 真正的优势。RUP 的工业领先的位置给了我们和我们的管理层很大的信心。 RUP 是可以高度定制的,并且我们知道我们必须要做什么。
我们将如何按照我们的路线开始呢?
首先我们在六个项目中尝试使用 RUP ,这些项目覆盖了四个不同的业务领域。然后我们在公司论坛中推动大家对 RUP 的了解。RUP 已经在一些项目人员群体中有了一定的立足空间了,这给了我们很大的鼓励。我们确定了公司中的领域问题专家(SME)。然后我们开始了两个项目:一个负责开发 RUP 的自定义版本,另一个负责部署开发出来的自定义的 RUP 版本。我们的产出结果是我们称作为统一方案交付方法或者 USDM 的过程实例。它是基于 RUP 的,但是对于福特公司特定的组织和项目是需要定制的。例如,我们必须包括内部的控制考虑和我们的数据和记录的保留政策。此外,我们必须包括按照福特公司熟知的工作家族来定义角色。
USDM 也是非常注重实效的以保证实现真正的价值,甚至是对于快进度的项目,并且它也是足够灵活的以便我们能够使用它来满足我们众多项目的需要。
回页首
开发
我们将开发工作作为一个项目来实施。(见图 1)
图 1:开发项目
我们有一个目标,这个目标是针对福特的需要创建一个健壮的并且注重实效的面向对象的开发过程。我们同时还确立了这样的目标:定制 RUP