在小型项目中使用IBMRationalUnifiedProcess:极限编程剖析资源-CSDN文库

49 浏览量 2021-03-05 06:42:25 上传评论收藏 274KB PDF 举报

资源推荐

资源详情

资源评论

在小型项目中使用在小型项目中使用IBMRationalUnifiedProcess:极限编程剖析极限编程剖析

IBM Rational Unified Process®（或简称 RUP®）是一个完善的软件开发过程框架，它具有若

干种即装即用的实例。源自 RUP 的过程范围很广，从满足短周期的小型项目需要的轻量级

RUP，到满足大型的、可能是分布式的项目团队需要的更加完备的过程。各种类型和规模的项

目都已成功地使用了 RUP。本白皮书说明了如何在小型项目中以轻量级的方式应用 RUP。我

们将要讲解如何在一个完整项目的上下文范围内应用极限编程（XP）技术。

摘要

IBM Rational Unified Process®（或简称 RUP®）是一个完善的软件开发过程框架，它具有若

干种即装即用的实例。源自 RUP 的过程范围很广，从满足短周期的小型项目需要的轻量级

RUP，到满足大型的、可能是分布式的项目团队需要的更加完备的过程。各种类型和规模的项

目都已成功地使用了 RUP。本白皮书说明了如何在小型项目中以轻量级的方式应用 RUP。我

们将要讲解如何在一个完整项目的上下文范围内应用极限编程（XP）技术。

引言

一个小故事

一天早上，一名经理找到我询问我是否可以花几个星期为一家公司刚刚启动的投资建立一个简

单的信息系统。我正厌烦手头的项目而渴望新项目启动带来刺激，于是我为这个机会欢欣雀跃-

-我快速开始行动，为新的伟大解决方案进行开发，而摆脱我工作的大型机构的官僚和手续的束

缚。

事情在开始阶段进行得很顺利。在头六个月中，我都工作很长时间并且自得其乐。我的工作效

率不可思议，并且一些工作堪称是我职业生涯中的杰作。开发周期是快速的，而且我每隔几周

就可以完成系统中一些新的主要部分。与用户的交互过程简单而直接，我们都属于一个紧密联

系的团队，而且可以免除一些手续和文档。也没有什么正式的设计；代码就是设计，设计也就

是代码。一切都是这样的完美！

这种完美只持续了一段时间。随着系统开发的进行，我们需要开展更多的工作。现有代码随着

问题的变更而必须进行完善，而且我们也相应精化了所需工作的概念。我雇了一些开发人员帮

助进行开发。我们就像一个单元一样工作，经常对一些问题互相讨论。这加强了沟通同时也免

除了形式。

一年过去了。

我们还在增加开发人员。整个团队从 3 个人到 5 个人，然后是 7 个人。每次增加人员时，都要

花很长的时间来学习，如果没有经验，那么就很难理解和解释整套系统，即使是一个概览。我

们开始使用白板图来更加正式地展示系统的整体结构、主要概念和接口。

我们仍然在使用测试作为验证系统是否满足需要的主要手段。很多新来的开发人员都站在用户

的立场上，我们发现项目早期非正式的需求和个人联系已经不能满足需要了。我们花费了更长

的时间来计划我们要建立的目标内容。结果由于我们保留了讨论的文字记录，而不用频繁地回

想已经做过的决定。我们还发现描述需求和使用场景有助于向系统的新用户介绍情况。

系统的规模和复杂度不断增加，意外的情况发生了--需要清楚地描述系统的构架。在项目初

期，构架大部分存于我的头脑中，后来潦草地记在笔记或活动挂图中。不过，随着项目的人员

越来越多，构架有些失控。由于不是每个人都和我一样富有经验，他们无法发现某些变更对整

个构架带来的影响。我们不得不使用更精确的术语定义对系统构架的约束。任何可能影响构架

的变更都需要团队进行商讨，并且最终获得我的同意。我们绕了一圈后才发现了这个问题，接

受了一些重大教训之后，这在真正认识到构架的重要性。

这是一段真实经历。它只讲述了这个项目中的一部分困难经历。这些经历只在一个方面是不同

寻常的：我们中的一部分人从开始的最后一直在一起，时间一年有余。开发人员经常在一个项

目中半途而来，没等结束就已经离开，丝毫看不到他们的所作所为带来的后续影响。

这个项目本该使用一些过程进行管理。过程太多会误事，但是不使用过程会带来新的风险。就

像投资高风险股票的人仅仅看到高回报一样，几乎不使用过程的项目组忽略了项目环境中的关

键风险，其实是在"期望得到最好的结果，但是没有为最坏的情况做打算"。

概述

本文讨论了如何将过程应用到例如上文所述的项目中。我们的目的是为了得到使用过程的"恰当

级别"。了解开发团队所面对的挑战以及其所处的来务环境，可以得出过程使用的恰当级别。如

果我们理解了这些挑战，就可以使用刚好足够的过程来降低风险。不论是轻量级的还是其

他，"一刀切"过程是不存在的。在以下内容中，我们来研究这一思想，即过程的恰当级别可以

作为一个风险的函数。

我们集中讨论如何通过使用两个流行的方法得到过程的恰当级别：Rational Unified Process 或

简称 RUP 以及极限编程（XP）。我们展示如何在小型项目中使用 RUP 以及 RUP 如何处理

XP 没有涉及到的领域。二者融合为项目团队提供了所需的指南--减少风险同时完成交付软件产

品的目标。

RUP 是由 IBM Rational 开发的过程框架。它是一种迭代的开发方法，基于六个经过行业验证

的最佳实践（参见 RUP 附录）。随着时间的推进，一个基于 RUP 的项目将经历四个阶段：起

始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）、交付阶段

（Transition）。每个阶段都包括一次或者多次的迭代。在每次迭代中，您根据不同的要求或工

作流（如需求、分析和设计等）投入不同的工作量。RUP 的关键驱动因素就是降低风险。

RUP 通过数千个项目中数千名 IBM Rational 客户和合作伙伴使用而得到精化。下图展示了一

个典型迭代过程的工作流：

典型迭代流典型迭代流

作为风险如何影响过程的一个例子，我们应该考虑是否需要为业务建模。如果由于对业务的理

解中没有考虑到一些重大风险，将导致我们所构建的系统是错误的，那么我们就应该执行一些

业务建模工作。我们需要正式进行建模工作吗？这取决于我们的涉众--如果一个小团队将非正

式地使用结果，那么我们也许只进行非正式的记录就可以。如果组织中的其他人也将使用结果

或者查看结果，那么我们可能就要投入更大的努力，并且确保该结果的正确性和可理解性。

您可以定制 RUP 使其满足几乎任何项目的需要。如果没有满足您特定需要的即装即用的过程

或路线图，您可以轻松地创建您自己的路线图。路线图描述了该项目如何计划使用过程，因此

代表了该项目的特定过程实例。这就意味着，RUP 可以按需要变得简单或复杂，我们将在本文

中详细解释。

XP 是一个用于小型项目中的以代码为中心的轻量级过程（参见 XP 附录）。它来自 Kent Beck

的创意，在大概 1997 年 Chrysler 公司的 C 3 工资单项目中得到软件界的关注。如同 RUP 一

样，XP 也是基于迭代的，并且体现了诸如小规模发布、简单设计、测试以及持续迭代几项实

践，。XP 为恰当的项目和环境引入了一些有效的技术；不过，其中也存在隐藏的假设、活动

和角色。

RUP 和 XP 具有不同的基本原理。RUP 是过程组件、方法以及技术的框架，您可以将其应用

于任何特定的软件项目，我们希望用户限定 RUP 的使用范围。XP，从另一方面来说，是一个

具有更多限制的过程，需要附加内容以使其适合完整的开发项目。这些不同点解释了软件开发

界的一个观点：开发大型系统的人员使用 RUP 解决问题，而开发小型系统的人员使用 XP 作

为解决方案。我们的经验表明大部分的软件项目都处于两者之间--尽力找寻适用于各自情况的

过程的恰当级别。单纯地使用两者之一是不充分的。

当您在 RUP 中融合了 XP 技术时，您会得到过程的正确量，既满足了项目所有成员的需要，

又解决了所有主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队，其中用户

是团队的一部分，那么 XP 完全可以胜任。对于团队越来越分散，代码量越来越大，或者构架

没有很好定义的情况，您需要做一些其他工作。在用户交互具有"契约"风格的项目中，仅有 XP

是不够的。RUP 是一个框架，您可以从 RUP 出发，在必要时以一组更健壮的技术来扩展

XP。

本文的以下部分描述了一个基于 RUP 四个阶段的小型项目。在每个阶段中，我们都确定了所

产生的活动和工件。虽然 RUP 和 XP 具有不同的角色和职责，但是我们在这里不会处理这些

差异。对于任何组织或项目，实际项目成员必须在过程中与正确的角色关联起来。

项目启动－起始阶段

对于新的开发项目来说，起始阶段是很重要的，在项目继续进行前，您必须处理重要的业务与

需求风险。对于那些增强现有系统的项目，起始阶段是比较短暂的，但是其目的仍是确定该项

目的实施价值及可行性。

在起始阶段中，为了构建软件您可以创建业务案例。视图是起始过程中的关键工件。它是系统

的高级描述。它为每个人解释该系统是什么、可能使用系统的用户、使用系统的原因、必须具

备的功能，以及存在的约束。视图可能很短，也许只有一两段。视图往往包括软件必须为客户

提供的关键功能。

下面的例子展示了一个项目的很短视图，该项目对 Rational 的外部网站进行了改造。

为使

Rational

的地位达到电子开发（包括工具、服务和最佳实践）的世界领先程度，可以通过

动态的、个性化的网站加强客户关系，为访问者提供自助服务、支持和目标内容。新的过程和

技术启用可以使内容供应商通过一种简化的、自动的解决方案加速发布并提高内容的质量。

RUP 起始阶段中 4 个重要活动为：

制定项目的范围。如果我们打算构建一个系统，我们需要知道其内容以及它如何满足涉众的需

要。在这个活动中，我们捕获内容和最重要的需求的足够详细的信息，从而得出产品可接受的

标准。

计划并准备业务案例。我们使用视图作为指导，定义风险缓和策略，开发起始的项目计划，并

确定已知成本、日程计划，以及盈利率平衡。

综合得出备选构架。如果正在计划中的系统没什么新颖性，而且使用的框架广为人之，那么您

可以跳过这一步。我们一旦知道客户的需求，就要开始分配时间研究可行的备选构架。新技术

能够带来解决软件问题的新的并且经过改进的解决方案。在过程的早期花些时间评估购买还是

创建系统，并选择技术，也可以开发出一个起始原型，这些都可以减少项目的一些主要风险。

准备项目环境。任何项目都需要项目环境。不论您使用 XP 技术（例如结对编程），还是较传

统的技术，您都需要确定团队将要使用的物理资源、软件工具以及步骤。

进行小型项目开发时，并不需要太多的"过程时间"来执行起始过程。您往往可以在几天中或者

更少的时间里完成，下面的内容说明了本阶段除了视图之外的预期工件。

一个经批准的业务案例

涉众有机会从业务的角度认定项目是值得进行的。RUP 和 XP 都承认最好在早期就得出项目是

否值得进行的结论，以免在一个注定将要失败的项目中花费宝贵的资源。如同在"Planning

Extreme Programming" 一书描述的那样，XP 对于项目是如何形成的以及涉及哪些角色这两个

问题的回答是比较模糊的（似乎在现有项目或系统的环境中是最清晰的），但是在研究阶

段，XP 处理的工件与 RUP 起始过程中的是相同的。

不论您在 XP 中非正式地考虑业务问题，还是在 RUP 中将业务案例做成一流的项目工件，您

都需要考虑这些问题。风险清单您应该在整个项目开发过程中都保持记录 Risk List（风险清

单）。使用有风险清单可以是一个具有经过计划的风险缓和策略的简单清单。为各个风险设定

优先级。任何与项目有关的人员都可以随时看到风险的内容以及如何处理风险，但是没有提供

解决风险的一般方式。

初步项目计划

本计划包括资源估算、规模以及阶段计划。对于任何项目，这些估算都是不断变化的，您必须

监控它们。

项目验收计划

您的计划正式与否依赖于项目的类型。您必须判断客户会如何才能认为您的项目取得了成功。

对于一个 XP 项目，客户会采取验收测试的形式。在更普遍的过程中，客户可能不会真正地进

行测试，但是接受的标准必须直接由客户作出，或者由另一个角色作出，例如与客户直接接触

的系统分析员。也可能存在其他的验收标准，例如创建最终用户文档和帮助，但是XP并不涉及

此内容。

起始细化迭代计划

在基于 RUP 的项目中，在上次迭代的最后，您将详细计划下次迭代。在迭代的最后，您可以

评估迭代开始时设立的标准。XP 提供了探监控与衡量迭代成功的一些优秀技巧。衡量标准是

简单的，您可以轻松地将它们合并到迭代计划和评估标准中。

起始用例模型

虽然这听起来比较正式而让人望之却步，但是它却相当简单。用例与客户在XP中编写的"故

事"相对应。其间的差异就是一个用例就是一套完整的动作，由参与者或系统外部的人员或事物

发起，这正是用例的价值所在。用例可能包括若干个XP"故事"。RUP 为了定义项目的边界，

推荐在起始过程中确定用户与角色。从用户的观点关注整套操作有助于将系统分为有价值的部

分。这有助于判定恰当的实施特性，因此我们能够在每次迭代的最后向客户交付一些成果（可

能在起始迭代与细化迭代早期除外）。

RUP 与 XP 都可以帮助我们确保避免一种情况，即整个项目已完成 80％，但都不是可交付的

形式。我们一直希望发布的系统对用户都是有价值的。

在这一点上，用例模型在识别用例和参与者方面几乎没有或只有很少提供支持的细节。它可以

是手工或使用工具绘制的简单的文本或者 UML（统一建模语言）图。该模型帮助我们确保已经

包含了涉众所关心的正确的功能，并且没用忘记任何功能，并允许我们轻松地查看整个系统。

用例根据若干因素设定优先级，这些因素包括风险、对客户的重要程度以及技术难点。起始阶

段中不需要过于正式的或过大的工件。按照您的需求让它们保持简单或者正式就可以。XP 包

括对计划与系统验收的指南，但是 RUP 需要在项目的早期添加更多的一些内容。这些少量添

加可能通过处理一套更完整的风险而为项目提供很大的价值。

细化阶段

细化阶段的目标是为系统构架设立基线，为在构建阶段大量的设计与实施工作打下坚实的基

础。构架通过考虑最重要的需求（那些对系统构架影响最大的需求）与评估风险演进而来。构

架的稳定性是通过一个或多个构架原型进行评估的。

在 RUP 中，设计活动主要关注系统构架的概念，对于软件密集型的系统来说，就是软件构架

的概念。使用组件构架是在 RUP 中体现的软件开发 6 项最佳实践其中之一，该实践推荐在开

发与所作所为构架上要投入一些时间。在这项工作花费的时间可以减缓与脆弱的、僵化日系统

有关的风险。

XP 使用"隐喻"替换了构架的概念。隐喻只捕获构架的一部分，而其余构架部分则随着代码开发

的自然结果而演进。XP假定构架的形成是从生成简单的代码开始，然后进行持续的代码重构。

在 RUP 中，构架不只是"隐喻"。在细化阶段中，您构建可执行的构架，从中可能降低与是否满

足非功能性需求相关的许多风险，例如性能、可靠性以及健壮性。通过阅读XP文献，很可能推

断出一些 RUP 为细化阶段所描述的内容，尤其是过于 XP 所称的基础设施的过分关注，都是

徒劳无功的。XP 认为在没有必要的情况下创建基础设施所做的工作导致了解决方案过于复

杂，并且所创建的结果对客户没有价值。在 RUP 中，构架与基础设施不是等同的。

在 RUP 与 XP 中创建构架的方法是截然不同。RUP 建议您关注构架，避免随时间变化而产生

的范围蔓延、增加项目规模以及采用新技术带来的风险。XP 采用足够简单或是很好理解的现

有构架，该构架能够随着代码而演进。XP 建议您不要为明天而设计，而要为今天而实施。XP

相信如果您尽可能地保持设计简单，那么将来管理起来也轻而易举。RUP 希望您考虑该主张带

来的风险。如果系统或者部分系统在未来不得不重写，那么 XP 认为这种举措比现在就计划这

种可能性更明智而且花费更少。对于一些系统，这是千真万确的，而且使用 RUP 时，在您细

化阶段考虑风险也会得出同一结论。RUP 并不认为对于所有系统这都是正确的，而且经验表明

对于那些较大型、较复杂和没有先例的系统来说，这可能是灾难性的。

虽然为未来的可能性（可能永远不会生生）花费太多的精力可能是一种浪费但是对未来进行足

够的关注不失为一件精明之举。多少公司能花得起代价不断重写或者甚至是重构代码呢？

对于任何项目，在细化阶段您应该至少完成这三项活动：

定义、验证并且设定构架的基线。定义、验证并且设定构架的基线。使用风险清单从起始阶段开发备选构架。我们关注是否能够

保证构想中的软件具有可行性。如果选定技术对于系统没什么新颖性或者复杂性，这项任务不

会花费太长时间。如果您正在向现有系统中添加内容，那么如果现有构架不需要进行变更，这

项任务就不是必要的。但是当真正出现构架风险时，您并不想让您的架构来"碰运气"。

作为这项活动的一部分，您可能执行一些组件选择，并且做出决定进行购买/创建/重用组件。

如果这需要大量工作，您可以将其分为单独的活动。

精化视图。精化视图。在起始阶段，您开发了一个视图。因为你要确定项目的可行性，并且涉众有时间检

查和评价系统，因此可能要对视图文档及需求作出一些变更。对视图与需求的修改一般在细化

阶段进行。在细化阶段的最后，您已经深刻理解了用来构建和计划的最关键的用例。涉众需要

得到认可，在当前构架的环境中，只要按照当前的计划开发整个系统，就能实现当前的设想。

在随后的迭代过程中，变更的数量应该有所减少，但是您可能会在每次迭代中花一些时间进行

需求管理。

为构建阶段创建迭代计划并且设定基线为构建阶段创建迭代计划并且设定基线。现在，可以为您的计划填充细节了。在每次构建迭代

的最后，您可以按需要重新考虑计划并且进行调整。调整过程经常是必需的，因为需要进行的

工作往往被错误地估算，业务环境也会常常变化，有时需求也会发生变更。为用例、场景以及

技术工作设定优先级，然后将它们分配到迭代过程中。在每次迭代过程的最后，您计划产生一

个能够为涉众提供价值的工作产品。

您可以在细化阶段执行其他活动。我们推荐您建立测试环境并且开始开发测试。虽然详细的代

码还没有完成，但是您仍然可以设计测试，也许可以实施集成测试。程序员应该随时准备进行

单元测试，并且了解如何使用项目选定的测试工具。XP 推荐您在编写代码前先设计测试内

容。这是个独到的见解，尤其是当您向现有代码主体中添加内容时。不过，无论您选择如何进

行测试，都应该在细化阶段建立常规测试体制。

RUP 描述的细化阶段包括 XP 中的研究阶段和投入阶段。XP 处理技术风险（例如新颖性和复

杂性）的方式为使用"spike"解决方案，例如花费一些时间进行试验以对工作量进行估算。这种

技术在许多案例中都是有效的，当较大风险没有体现在单个用例或"故事"中时，您就需要花些

工夫确保系统的成功而且对工作量进行精确的估算。

在细化阶段，您会经常更新工件，例如起始阶段的需求与风险清单。在细化阶段可能出现的工

剩余16页未读，继续阅读

评论收藏

内容反馈

weixin_38723753

粉丝: 2
资源: 907

在小型项目中使用IBMRationalUnifiedProcess:极限编程剖析

使用极限编程改善项目的设计和灵活性[译]

敏捷建模：极限编程和统一过程的有效实践

敏捷建模：极限编程和统一过程的有效实践———— 好东西！

捷建模-极限编程和统一过程的有效实践

解析极限编程:拥抱变化(原书第2版)

极限编程1.1（极限编程系列）

Java_极限编程Java_极限编程

极限编程 ppt 极限编程

极限编程1.3（极限编程系列）

解析极限编程 拥抱变化.z01

解析极限编程 拥抱变化.zip

敏捷建模极限编程和统一过程的有效实践

鸡啄米：C++编程入门系列

《解析极限编程：拥抱变化》（原书第2版）_解析极限编程：拥抱变化_

极限编程的例子 老师发的课件

极限编程 xp相关资料

极限编程（Extreme Programming）-XP之旅

解析极限编程-拥抱变化(原书第2版).中文版

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

光伏-储能并网系统仿真.rar

NPPJSONViewer.zip

GD32替换STM32注意事项.pdf

XCP协议的规范文档

VS2015安装证书，JavaScript_ProjectSystem.msi，JavaScript_LanguageService.msi

CANoe通过CAPL脚本实现自动测试

蓝牙BLE协议中文版.pdf

最新资源

解析极限编程拥抱变化.z01

解析极限编程拥抱变化.zip

极限编程的例子老师发的课件

Qt 5实现串口调试助手（源工程文件、0积分下载）