RUP方法.docx

RUP方法.docx

《RUP方法.docx》由会员分享，可在线阅读，更多相关《RUP方法.docx（14页珍藏版）》请在冰点文库上搜索。

RUP方法

Rational统一过程引论（原书第2版）

（美）PhilippeKruchten著

周伯生吴超英王佳丽译

机械工业出版社2002.5

ISBN7-111-09630-4

38.00元

前言

●Rational统一过程：

RationalUnifiedProcess,RUP

●通过本书，你将

✓掌握Rational统一过程中的词汇并理解其结构；

✓理解在一个项目中RUP如何向你提供完成特定职责所需要的指导

●参考书：

✓UML用户指南

✓UML参考手册

✓软件项目管理：

一个统一的框架

●如何使用这本书：

✓在一个全部采用或部分采用RUP的开发组织中工作的软件专业人员：

顺序阅读本书

✓项目经理：

风险驱动和迭代开发过程的含义

✧第1章

✧第2章

✧第4章

✧第7章

✓过程工程师、方法学家：

需要裁剪RUP，并在它们的组织中建立起这种过程，下面描述了过程结构以及全面RUP的方法

✧第3章

✧第7章

●获取更多的信息

✓

●第二版按：

RUP2000进行了更新。

RUP2000在广度和深度上都有所扩充：

✓广度：

✧增加了关于业务工程，非功能性需求管理，多级分析式应用程序的开发与实施等。

✧原有内容改进：

应用程序接口设计（特别是Web应用程序），使用模式与框架设计，开发实时和反应式系统。

✧测试工作扩展到：

从确认构架原型到验证各种不同项目和各种不同技术。

✓深度：

扩展了——

✧过程制品

✧活动和阶段的检测表与指南

第一部分过程

第3章静态结构：

过程描述

●本章：

✓讲述如何表述RUP。

✓介绍重要概念：

✧工作人员

✧活动

✧制品

✧工作流

✓在过程描述中使用其他元素。

3.1Rational统一过程的模型

●一个模型描述了谁做、做什么、怎么做和什么时候做。

●RUP应用了4种重要的模型元素：

✓工作人员：

谁做

✓活动：

怎么做

✓制品：

做什么

✓工作流：

什么时候做

●图3-1显示了上述元素的前3项：

3.2工作人员

●过程中的中心概念是工作人员：

✓工作人员（worker）定义了个人或作为群组一起工作的人们的行为和职责。

✓工作人员执行的行为用活动（activity）表示，而每一个工作人员都与一组内聚的活动相联系。

✧内聚，是指这些活动必须由一个人来完成。

✓对于每个工作人员的职责的表示通常与某一特定制品（artifact）相联系，这些制品是由工作人员制造、修改和控制的。

●在RUP中：

✓工作人员是用于定义每个人应该如何完成工作的角色。

✓工作人员不是个人，它描述了在业务中个人的行为和职责。

✓从个人到工作人员的映射，是由项目经理在计划项目和分配人员时完成的。

这样的映射可以使一个人担当几个不同的工作人员，同时一个工作人员又可以由几个人来担当。

✓对于不同的工作人员，担任这个工作人员的个人必须有一系列相应的技能。

●工作人员的例子：

✓系统分析员：

通过概述系统功能和界定系统，引导和协调需求引发和用例建模。

✓设计师：

定义一个或多个类的职责、操作、属性和它们之间的关系，并决定如何调整类以适应实现环境。

✓测试设计师：

负责计划、设计、实现和评估测试，包括产生测试计划和测试模型，执行测试规程，评估测试覆盖率、测试结果和测试效率。

●图3-2人和工作人员

3.3活动

●活动：

✓定义了工作人员执行的工作。

✓将在项目语境中产生有意义的结果。

✓有明确的目的（结果）。

✓时间从几个小时到几天——大小要适当

✓影响到一个或几个制品——影响面到适中

✓对同一个制品，可能会重复多次。

✧尤其是在精化和扩展系统时从一个迭代过程到另一个迭代过程。

✧一般被同一个工作人员完成，但不一定是同一个人

●典型的活动和对应的工作人员：

✓计划迭代过程——项目经理

✓寻找用例和参与者——系统分析员

✓评审设计——设计评审员（设计员）

✓执行性能测试——性能测试人员（测试人员）

●活动步骤：

✓思考

✓执行

✓评审

3.4制品

●制品（artifact）分为输入制品和输出制品。

✓是由过程生产、修饰或使用的一条信息。

✓制品是项目有形的产品：

项目在生产出最终产品的过程中生产或使用它们。

✓工作人员把制品当做执行一项活动的输入，同时这个活动的输出或者结果也是制品。

●制品形式：

✓模型，如用例模型和设计模型

✓模型元素：

如类、用例或子系统

✓文档：

如一个业务用例或软件构架文档

✓源代码

✓可执行文件

●制品是RUP的术语。

与工作产品（workprocuct）、工作单元（workunit）等意思一样。

可交付产品是所有制品的子集，最终将交给用户。

●一些制品还能组成其他制品。

如：

✓设计模型包含了很多类

✓软件开发计划包含了许多其他计划：

人员配备计划、阶段计划、度量计划和迭代计划等。

●通常，制品不是文档。

RUP不鼓励系统地生产纸质文档，而是用生产和管理制品的工具来维护这些制品（这样可确保及时更新信息，也是实际项目工作的需要）：

✓存储在RationalRose中的设计模型

✓存储在MicrosoftProject中的项目计划

✓存储在ClearQuest中的缺陷

✓存储在RequisitePro中的项目需求数据库

●当然，对于项目的外部输入，清晰的文本文档还是必要的。

●制品是某个工作人员的责任，可以这么认为：

✓每一条信息必须是某个特定人的责任；

✓一个人可“拥有”该制品，但是许多人可以使用该制品，经过许可，他们甚至可以更新该制品。

●制品通常可以表示为：

“制品：

用例情景图板”

3.4.1报告

●模型和模型元素与报告有密切的联系。

●报告（report）从工具中抽象出关于模型和模型元素的信息。

✓如，一个报告是为评审工作提交的一个制品或一组制品。

✓报告不同于一般制品，它是不受版本控制影响的。

✓在任何时候，你都可以通过返回到产生该制品的地方重新产生该报告。

3.4.2制品集

●RUP中的制品分为5个信息集（informationset）：

✓管理集（managementset）：

包括所有与软件业务和项目管理有关的制品：

✧计划制品，如：

软件开发计划、业务案例、项目实际使用的过程实例（开发案例）等等

✧操作制品，如版本说明、状态评估、实施文档和缺陷数据。

✓需求集（requirementsset）：

包括所有与待开发的软件系统的定义有关的制品：

✧构想文档

✧以项目相关人员的需求、用例模型和补充规格说明的形式出现的需求。

✧业务模型，当要求理解系统支持的业务过程时需要这个制品。

✓设计集（designset），包括了对要构造（或正在构造）的系统的描述，以下列形式出现：

✧设计模型

✧构架模型

✧测试模型

✓实现集（implementationset），包括所有将会的信息：

✧安装资料

✧用户文档

✧培训材料

✓措施集（deploymentset）

●迭代开发中，这5个信息集在整个开发周期中是不断发展的。

不存在一个迭代过程，将它们全部固定下来。

3.5工作流

●仅仅有工作人员、活动、制品并不能正确地构成完整的过程。

需要一种方来描述能够产出有用成果的有重要意义的活动序列，并表示出工作人员之间的交互作用。

●UML中，一个工作流可以表示为一个序列图、协作图或活动图。

●不是所有的活动之间的依赖关系都是能够表示出来的。

✓两个活动之间的关系常常比显示出来的关系更加紧密的交织在一起，尤其是当它们涉及了同样的工作人员或个人。

✓人不是机器，因此工作流并不能完全解释为是人们要一成不变地、机械地遵守的程序。

●有很多组织工作流活动集的方法。

我们用以下工作流组织RUP：

✓核心工作流

✓工作流细节

✓迭代计划

3.5.1核心工作流

●严格地说，核心工作流是工作流类，工作流类有很多可能的工作流实例。

●RUP中有9个核心过程工作流（coreprocessworkflow）

✓6个核心工程工作流

✧业务建模工作流

✧需求工作流

✧分析和设计工作流

✧实现工作流

✧测试工作流

✧实施工作流

✓3个核心支持工作流

✧项目管理工作流

✧配置和变更工作流

✧环境工作流

●尽管6个核心工程工作流的名称会使你想起传统的瀑布过程的顺序阶段，但迭代过程中的阶段与瀑布模型的阶段并不相同

✓在整个生命周期，将一遍一遍地重新访问这些工作流。

✓一个项目中实际完整的工作流交错了这9个核心工作流，并且在每次迭代中的重点和密集程度都不同。

3.5.2工作流细节

●为了将工作流细化分解，RUP应用工作细节（workflowdetails）来表示与工作流联系紧密的一组特定活动。

例如，这些活动可能——

✓同时进行或者循环进行；

✓由在一个工作间中的一组工人完成；

✓生产出一些有意思的中间结果。

●工作流细节同时显示出信息流——从活动输入或输出的制品——以便显示出活动在不同的制品中是如何交互作用的。

3.5.3迭代计划

●迭代计划（iterationplan）是另一种表示过程的方法，它从在某一典型迭代过程中要完成的事情的角度更加详细地描述过程。

✓它们实际上最接近于工作流将处理的的问题。

✓可将它们视为某一特定迭代过程中的过程实例化，其中选择了在迭代中将有效运行的活动，并在必要时复制它们。

3.6附加过程元素

●工作人员、活动（在工作流中被组织）和制品展示了RUP静态结构的主干线。

但还有一些附加于活动或制品的元素，它们使得过程更容易理解和使用，并提供给实践者综合指导。

●这些附加过程元素是：

✓指南

✓模板

✓工具指南

✓概念

3.6.1指南

●活动和步骤应保持简单扼要。

需要有“指南”对下述两类人提供有用的信息：

✓查看指南的“新入门者”

✓有经验的“实践者”

●指南（guideline）附加于活动、步骤和制品之上。

✓它们在描述格式良好的制品的过程中非常重视它们的某一特定质量，例如如何构成一个好的用例或好的设计类。

✓指南还描述用来创建某一产品的特殊“技术”，或从一种制品转变到另一种制品的技术，或使用UML的技术。

✓指南还用来评定制品的质量（以与制品相关的检验表的形式出现）或评审活动。

●指南类型：

✓工作指南，给出如何理解活动尤其是组活动的实用建议；例如：

✧评审工作指南

✧用例研讨会工作指南

✓制品指南与某一特定制品相联系，并描述如何开发、评价和使用制品。

例如：

✧建模指南，来用描述格式良好的建模元素，如用例、类和测试用例。

✧编程指南，如具体针对一个项目的命名约定的描述。

适用于如C++和Ada等语言，用来描述格式良好的程序。

✧用户接口指南，如具体针对一个项目的窗口风格的描述：

调色板、字体、图标图库等

✧对如何生产某个特定制品的指南，如风险清单或迭代计划。

✧检查点，用来作为评审的一部分，或由工作人员用以检查活动是否完成的标准。

●某些指南需要为特定组织或特定项目细化或特殊化，以适应项目的特殊性，如使用的特定技术或工具。

3.6.2模板

●模板（template）是指模型、原型或制品。

例如：

✓微软的Word模板，用于写文档和一些报告。

✓为微软伯Word或FrameMaker提供的SoDA模板，用来从如RationalRose、RequisitePro或TeamTest这样的工具中提取信息。

✓微软的FrontPage模板，用于不同的过程元素。

✓微软的Project模板，用于项目计划。

●在使用指南之前，组织可以通过在模板中加入公司标识、项目标识或具体针对项目类型的信息将模板客户化。

3.6.3工具指南

●活动、步骤和相关指南给实践者提供了一般性指导，更进一步的指导是由工具指南（toolmentor）提供的。

●工具指南是一种提供指导的附加方法，它介绍了如何使用特定软件工具来完成每个步骤。

●RUP将活动与各种工具（如RationalRose、RequisitePro、ClearCase、ClearQuest和TestStudio等）相联系，从而提供了工具指南。

3.6.4概念

●一些关键概念，如迭代、阶段、制品、风险、性能测试等，将分别在过程的不同部分和相关的核心工作流一起介绍。

3.7过程框架

●在静态结构中，RUP建立了过程框架（framework）。

工作人员、制品、活动、指南、概念和工具指南等都是可以增加或替代的元素。

2.8小结

●RUP建立在3个基础实体上：

工作人员、活动和制品。

●在产出有价值成果的工作流序列中，工作流与活动、工作人员密切相关。

●指南、模板和工具指南给实践者提供了详细的指导，是对过程描述的有益补充。

●RUP是过程框架，使其将静态结构配置组织在一起。

第二部分过程工作流

第17章配置和实现Rational统一过程

17.1介绍

●配置RUP——通过修改Rational公司交付的过程框架，使这个过程产品适应采纳了这种方法的组织的需要和约束。

●实现RUP——通过改变组织的实践，组织能例行地、成功地使用RUP的全部或一部分。

●在开发案例中捕获配置RUP的结果：

✓开发案例列举了对于完整RUP做出的不同修改。

✓还可将开发案例做成对RUP的相关部分有着超级链接的网站。

17.2实现过程的效果

●过程改变非常困难，可能需要很长一段时间才能见到真正的结果。

✓这与采纳一种新的工具不同，采纳一种新的工具相对来说简单快捷一些。

下面过程可能需要几个小时或几周时间：

✧安装工具

✧阅读用户手册

✧查阅范例

✧培训课程（可选）

✓改变软件开发过程是一个文化的改变，通常也是政治和哲学的改变：

✧经常会影响到所涉及的个人的基本信仰和价值

✧同时也会改变他们理解工作及其价值的方法。

●过程的改变比技术和工具的改变给个人和组织带来的影响要大得多，所以：

✓必须仔细地制定计划和管理改变。

✓组织必须标识出机会和利益，并将它们清楚地传递给有利益关系的方面，提高他们的理解程度。

✓逐渐地从当前的实践转变为新的实践。

✓IvarJacobson其描述为“软件工程过程重组”。

●实现一个过程，必须解决以下问题：

✓人员及其能力、技术、动机和态度：

✧首先必须保证每一个人都受到适当的培训和激励。

Ø为了使实现过程的项目成功，重要的是要让工作人员尽早参与工作。

Ø因为在评估软件开发组织的当前状态时，他们是重要的信息来源。

✧其次，应该确保每一个人都能理解当前组织的状态并认识到组织所遇到的问题，在哪些方面可以改进以及如何改进。

——建立这样的理解是对项目作任何改变的成功关键之一。

✓支持工具：

✧必须使用新的工具，替代原有的工具。

✧新工具要与其他工具集成。

✓软件开发过程：

它包括：

✧生命周期模型

✧组织结果

✧要执行的活动

✧要遵循的实践经验

✧要生产的制品

✧软件开发过程范围

✓描述：

对于软件开发过程的描述

✓其他方面，如：

✧物理工作环境

✧管理结构

Ø员工待遇

Ø工作人员如何参与制定决策

✧组织结构，如

Ø报告

Ø组织单元

Ø工作组之间的关系

17.3逐步实现RUP

●实现一个新的过程可用6个步骤：

✓评估当前状态

✓建立（或修订）目的

✓识别风险

✓计划过程实现

✓执行过程实现

✓评估过程实现

17.3.1步骤1：

评估当前状态

●要识别出问题和潜在的待改进领域，应当了解：

✓软件开发组织的当前状态

✓参与的工作人员的种类，他们的能力水平、技能和动机

✓当前在组织中使用的工具

✓当前的软件工程过程以及是如何描述的

17.3.2步骤2：

建立（或修订）目的

●产生的结果是一个可度量的目的清单，为项目人员所理解。

17.3.3步骤3：

识别风险

●软件组织第一次使用迭代方法，可能会陷入许多陷阱之中：

✓无法将焦点集中到最重要的风险上

✓不得不测试所有已建立的制品

✓项目相关人员不理解迭代方示，如：

期望在SDLC早期完成对系统的完整设计。

✓可能会一个一个地计划系统的特性，而不是从项目一开始就（在高层上）计划完整的项目，并准备在过程中随时改变计划。

——如何提交一份高层的软件开发计划，包括范围等？

✓在迭代中有许多返工，也就是说在早期迭代中完成的工作要在后来的迭代中重做。

——是否需要一开始就告诉程序员，以后可能要返工？

✓不能控制需求变更，可能认为变更无关紧要，可以在以后的迭代中修正。

——如何管理需求？

什么工具？

✓过早地进行了过多的培训。

——如何培训员工

✓过于匆忙地为项目分配工作人员，导致太多人涉及到初始阶段。

这会使工作人员很难理解他们的责任，并且出现很多人员没有任务的风险。

✓工具支持不足。

✓不去评估制品的真正价值，因而产生不必要的制品。

17.3.4步骤4：

计划过程实现

●在开发组织中要为实现过程和工具制定一个计划。

这个计划应该明确描述如何有效地从组织的当前状态转移到目的状态。

●可以有不同的方法实现过程。

可以依据以下两个方面来选择方法：

✓当前组织对改变的需求

✓涉及的风险

17.3.5步骤5：

执行过程实现

●在实现过程中最破费时间的一步就是按照在前一步中定义的计划实现该过程。

包括：

✓开发新的开发案例或更新已存在的开发案例

✓获取并改造工具使之支持过程并使过程自动化

✓对开发群组中的成员进行使用新的过程和工具方面的培训

✓在软件开发项目中应用过程和工具

17.3.6步骤6：

评估过程实现

●当实现了该过程和工具，要进行评价工作：

✓是否达到了设定的目的？

✓评价人员、过程和工具，以了解当重新从步骤1开始时要关注哪些方面。

17.4配置过程

●通常，软件工程可以在两个层次上进行剪裁和修改：

✓组织范围内的过程

✓项目专用的过程

17.5实现过程也是一个项目

●过程实现项目的4个阶段：

✓将过程实现“展现”给出资人

✓处理主要风险

✓完成每一件事

✓在整个组织中实施过程。

17.6小结

●一个组织可以通过不同的方法采用RUP

●典型的方法是在实验性项目中试用部分RUP，而后该过程扩展到整个组织。

●采用RUP通常包括开发一个开发案例，即该过程的一个项目专用的版本。

●可以将开发案例做成一个网站。

它可能是RUP的在线修改，或者是一个可通过超级链接在线连接到RUP的网站。

●用于支持过程的工具必须同时到位。