rational unified process

Rational Unified Process

李云峰

内容• 软件过程简介• 最佳实践• RUP 的四个阶段• RUP 的关键概念和核心工作流

什么是软件过程？• 软件过程是由一系列的项目的阶段，方法，

技术和实践组成，人们利用它们来开发、维护软件和相关的产物（ artifacts ）。

• 在面向对象的软件过程领域，主要有三种方法： RUP 、 OOSP 和 OPEN Process 。

我们是否需要软件过程？• 一个有效的软件过程将能够增加一个组织的软件生产力，因为：

– 通过理解软件是怎样被开发的，你能够做出关于开发工具选择和雇用员工等方面的更聪明的决定

– 它使你的成就（包括文档，代码等）标准化，从而提升项目组间的软件的可重用性和一致性

– 它向你的组织提供了一个引进目前最好的软件惯例的一个绝佳机会，如代码审查，配置管理，变更控制，结构化建模等

– 提高软件维护和技术支持能力。• 首先，它定义了怎样管理软件变更，并且适当的考虑了你将来发行的软件可能带来的维

护任务，从而使你的变更管理流线化（ streamlining ）• 第二，它定义了怎样平滑的将软件转换成 operations and support, the operations and sup

port efforts 怎样实际操作。没有有效的 operations and support processes, 你的软件将在很短的时间内变得无法使用。

– 管理软件复杂性。软件正变得越来越复杂，没有一个有效的方法来开发和维护软件，则你所有的努力都会付之东流。

– 管理软件项目。大部分组织都有几个项目在同时开发，维护的项目则更多，所有的这些项目都需要被有效的管理。

– Manage e-commerce projects. 我们正在构建的软件的本质也在发生变化，从 70 年代的简单的批处理系统到结构化技术，到现在朝着的可交互，国际化，用户友好，7*24 ，高密度交易，高可用性发展，最重要的是，这些项目中的绝大部分都是面向对象的，基于组件技术的。

最佳实践

The Rational Unified Process shows how you can apply best practices of software engineering, and how you can use tools to automate your software engineering process.

最佳实践 :迭代开发

为了降低风险，以一种迭代的风格进行增量开发。每次迭代都产生一个可执行的发布项

最佳实践 : 迭代开发• 什么是迭代开发？ • 为什么要采用迭代开发？• 迭代方法的优点

– 适应变化 – 规避风险– 学习式– 不断增长的重用性– 获得更高的质量

什么是迭代开发？• 采用迭代开发的项目的生命周期由一系列的

迭代过程组成。每个迭代包含了一系列松散耦合的活动，如商业建模、需求调研、分析和设计、实现、测试和发布。不同的阶段工作的侧重点也不同：– 在初始阶段和细化阶段的迭代主要关注在项目管

理、需求调研和系统设计的活动– 在构造阶段的迭代主要集中在设计、实现和测试上

– 在交付阶段的迭代主要关注的是测试和发布

为什么要采用迭代开发？

In a waterfall lifecycle, you can't verify whether you have stayed clear of a risk until late in the lifecycle

为什么要采用迭代开发？

In an iterative lifecycle, you select what increment to develop in an iteration based on a list of key risks. Since the iteration produces a tested executable, you can verify whether you have mitigated the targeted risks or not.

迭代方法的优点• 与瀑布式开发方法相比，迭代开发能够：

– 更能适应需求的变化– 功能是逐渐被集成进最终产品中的– 可以尽早发现风险和陷阱– 使开发团队在不断学习的过程中，改进工作质量– 可以更有效地进行软件的重用– 可以得到性能更稳定的产品– 可以适应产品开发过程中技术的升级和变化– 迭代过程本身也在不断的改善和优化

适应需求的变化• 需求变化或需求“膨胀”是项目失败的主要原因，后果是：推迟交付、计划失效、不满意的客户和烦躁的开发人员。

• 项目进行过程中，用户的主意会不断改变，这是人的天性，因为他们对系统的认识在不断的变化。

• 迭代开发能很好地适应这种战术上的改变，例如可以先向用户交付一个功能缩减了的产品，不但可以领先竞争对手，而且可以使用户更好地表达他们的真正的需求。同时迭代开发也能适应技术上的变化，特别是当系统平台或地层基础信息结构的变化，例如当需求分析和系统设计完成后，用户更换了操作系统或数据库，只要在构造阶段采用新的平台即可，即使修改设计，工作也很少。

规避风险• 在进行前期的迭代中，已经经历了所有的核

心工作流，对工具、软件和人员技能等很多方面有了经验，可以及时发现项目计划中的风险因素。

• 迭代开发通过循序渐进的方式集成产品，而不是到最后来个大包装。最后集成所有的功能不但困难、耗时，而且难于准确地把握工作的进度。

提高重用性• 一个迭代生命周期更利于重用的实现，因为

可以更早地识别出公共的部分• 识别和开发重用部分是很困难的。在早期的

迭代中进行设计复查可以使软件体系结构工程师识别出不确定的、潜在的重用，并在以后的迭代中完善和实现这些公共代码

• 可以更早地利用商业组件产品 (COTS) 。可以不断地进行选择和集成，并验证这些产品与你的体系结构的适合程度

学习式的开发过程• 开发人员可以不断学习，在整个生命周期中

能力和专长会不断地增长• 测试人员可以更早开始测试，技术文档可以

更早地撰写，等等，而不是仅仅作计划而迟迟不启动，消磨大家的热情和能力。对额外的培训和外部帮助可以尽早地被发现。

• 过程本身可以被不断地改进和完善。在每个迭代结束后，不仅仅从产品进度的角度考察一个项目，而且还分析组织或项目组中的哪些工作需要改善，可以使下个迭代周期中的工作能更有效地进行

达到更高的质量标准• 迭代开发过程可以获得更健壮的产品体系结

构，因为错误通过多次迭代被不断发现和纠正。

• 迭代开发也使产品得到了更充分的测试。核心功能会有很多机会被测试到。测试本身，以及任何测试软件也会在迭代过程中走向成熟。

最佳实践：管理需求• 什么是需求管理？

– 问题分析– 理解客户的需要– 定义系统– 管理项目的范围– 系统定义的求精– 管理需求的变更

• 用例驱动（ Use-case driven ）的开发

什么是需求管理• 需求管理是发现、记录、组织和跟踪一个系统不断

变化的需求的一套系统的方法。• 我们定义需求（ requirement ）为：

– 系统必须符合地某种条件或必须具备的某种能力• 对需求管理的正规定义是：需求管理是一种系统的

方法，以完成：– 抽取、组织和文档化系统的需求– 建立和维持客户和项目组对系统需求变化认识的一致性

• 实现有效的需求管理的关键因素包括需求的清晰的陈述、适宜的属性和对其它需求及其它项目资料关联性的可跟踪性。

什么是需求管理• 收集需求会遇到的困难：

– 需求不总是显而易见的，可能来自很多渠道– 需求有时很难用文字表达的很清楚– 在不同的细节上会有很多不同类型的需求– 如果不加控制，需求的数量会变得不可管理– 需求经常互相关联，也会和其它软件工程过程的

交付项相关– 需求有唯一的性质或属性，例如它们的重要性各

不相同，实现的难易程度各不相同– 需求有时被功能交叉的多组人管理着– 需求变更

什么是需求管理？• 要克服上述的困难，我们必须学习和掌握以下的技能：– 问题分析– 理解客户的需要– 定义系统– 管理和控制项目的范围– 对系统的定义不断细化求精– 管理需求的变更

问题分析• 问题分析的主要任务是理解问题、初始化客

户的需求，提出高层次的解决方案。• “找到问题背后的问题”• 在问题提分析过程中，要对真实的问题达成

一致，要定义从业务角度看系统的边界和业务约束。同时要明确所构造的系统可给用户带来什么回报。

理解用户的需要• 需求可能来自很多方面，例如客户、合作伙伴、最终用户和领域专家等。你必须知道如何最好地确定需求的来源和如何从这些来源获取需求，同时还要进行正确的取舍

• 需求信息的主要提供者我们称之为项目的客户（风险承担人 stakeholders ）

• 可以使用的技术手段包括访问、头脑风暴、概念原型、询问和竞争分析等。

• 分析出的需求要使用文字或图形进行清晰的表达，并设置需求的优先级。

定义系统• 定义系统指将对客户需求的理解翻译和组织

成对要构建的系统更有意义描述。• 在系统定义的前期 , 要确定需求文档的格式、语言形式、需求规范的深度和粒度、需求的优先级和所需的工作量、技术和管理上的风险和初始范围；还可能包括早期的原型系统和与最重要的需求相关的设计模型

• 系统定义的输出应是用自然语言和图形两者对系统的描述

管理项目的范围• 为了有效地运转一个项目，你必须仔细地衡

量需求的优先级别，并控制它们的规模• 很多项目都受害于项目开发人员将工作集中

在所谓的“复活节彩蛋”（即开发者认为有趣且富有挑战性）的工作上，而不是将精力集中在那些可以降低风险或使系统体系结构更稳定的工作上。

• 为了确保能够尽早地解决或降低项目风险，你应该采用增量开发的方法，在每次增加过程中仔细地选择需求。为此，你需要和客户针对每次迭代的项目的范围进行协商。

对系统定义进行细化求精• 系统的详细定义需要使客户能够理解、同意并在上面签字，

它不仅需要覆盖功能性需求，而且要符合法律或规范的要求，以及可用性和可靠性、性能、支持和维护等方面的要求。

• 一个易犯的错误是认为实现复杂的东西需要复杂的定义。这导致解释项目和系统目的的困难。人们可以被强制，但是它们不会提供好的输入，以为他们不理解。

• 对文档的观众的理解必须给与特殊的关注。通常，对不同的观众需要有不同类型的描述

• use-case 方法，经常伴由简单的可视原型，是对系统详细定义进行沟通的一种非常有效的方法。 Use cases告诉了用户系统是被如何使用的。

• 系统详细定义的另一个组成部分是系统的测试计划

管理需求的变更• 不管你多小心地定义需求，需求总是会发生变化的。

需求变化难于管理的原因不仅在于，一个变化的需求或多或少都需要花费一定的时间来实现一个特殊的新功能，而且一个需求的变化可能会影响其他的需求。

• 你需要保证你给出的需求具有适应变更的弹性结构，并且使用跟踪连接表示需求之间，需求和项目生命周期中其它文档的依赖关系。

• 管理需求变更地活动包括建立一个基线（ baseline ）、确定哪些依赖关系是重要的，必须被跟踪的，建立相关内容的可跟踪性，以及变更控制

Use Case驱动的开发• Use cases 不是一个简单的需求列表，而是向

用户描述了系统如何使用的场景。这提供了更好的完整性和一致性，并且使你从用户角度出发对需求的重要性有了更深入的理解

• “use-case驱动方法”是指 use cases 是整个开发过程的基础

Use Case驱动的开发• Use cases 在几个核心工作流程中都扮演着重要的角色：– use cases 的概念可以被用来表述在商业建模工作流中定义的商业过程，

这一变例称为 "business use case".

– use-case 模型是需求分析工作流的结果– 在分析和设计中， use-cases 在设计模型中被实现。– 在设计模型的实现中，因为 use cases 是设计模型的基础，因此它们根据设计类被实现

– 在测试中， use cases仍是识别测试用例和测试过程的基础– 在项目管理工作流中， use cases 被用作对迭代开发进行计划的基础– 在发布工作流中， Use cases 构成了用户手册内容的基础，也可以用

来定义产品的定购单元，例如用户可以从 use cases 中选择一些构成自己的配置

最佳实践：使用组件体系结构

Component-based architecture with layers.

最佳实践：使用组件体系结构• 什么是组件体系结构？• 体系结构的重点• 基于组件技术的开发（ Component-based De

velopment ——CBD ）

什么是组件体系结构？• 组件具有良好定义的接口和行为• 组件对内部的内容进行了封装• 组件是可重用、可替换的• 以组件技术为基础的体系结构努力降低系统

的规模和复杂度，因此更强壮，更富有弹性

体系结构要点• Use cases驱动着 RUP整个生命周期内的各项活动，但是设计活动是围绕系统体系结构进行的，对软件为主的项目，更具体的是以软件体系结构为中心的。

• 在早期的迭代过程中——主要是在细化阶段——主要的工作就是要形成并验证软件体系结构，它在初始的开发循环中是以可执行的体系结构原型方式出现的，并在以后的迭代中演化为最终系统。

• 建立可执行的体系结构原型是指部分地实现系统，以验证所选择的系统功能和属性，尤其是非功能性需求。构造它是为了降低与性能、吞吐量、容量、可靠性和其它性质有关的风险，以使完整的系统功能可以在构造阶段在一个坚实的基础上去实现。

体系结构要点• RUP 提供了一套设计、开发和验证体系结构

的方法，包括围绕多种体系结构视图的体系结构描述、捕捉体系结构风格、设计规则和约束的模板。设计工作流包含识别体系结构约束和重要体系结构元素的特定活动，也提供了如何进行体系结构选择的指导。管理过程指明了在早期迭代中如何在计划中将体系结构设计以及对应的主要技术风险纳入考虑之中。

体系结构要点• 体系结构之所以重要，是因为：

– 体系结构是你获得和保持对项目的控制，以管理项目的复杂度和保持系统的整体性。一个复杂系统不是各部分的简单相加，更不是一系列互不相关的小的技术决策的累积；它必须通过某种统一的、一致的结构使这些部分系统地组织起来，它必须提供系统如何增长的精确的规则，以避免系统的复杂度膨胀到人们难以理解的地步。体系结构通过建立一个公共的参考集合、一套公共的词汇提供了贯穿整个项目的沟通和理解的手段

– 体系结构是大规模重用的一个有效的基础。通过主要组件和关键接口的清晰表述，体系结构可以获得重用——包括接口重用和外部重用。而且，它还可以获得在更高层次的重用：在一个产品线中重用体系结构自身来处理在一个公共领域中的不同问题。

– 体系结构提供了项目管理的基础。计划和人员可以沿着主要组成成分进行组织。基础的结构性决定是由一个小的、紧密耦合的体系结构小组组成的。开发被划分成一系列的小组，每个小组负责系统的一个或几个部分。

基于组件的开发 (CBD)

• 一个软件组件可以被定义为软件的非平凡片断、一个模块、一个包或一个子系统，组件都有一个清晰的功能、有一个明确的边界并能够被集成到一个良好定义的体系结构中。它是设计中的某个抽象概念的物理实现。

• 组件来自不同的场合：– 在定义一个非常模块化的体系结构中，你识别、分隔、设计、开发和测试良好格式（ well-formed ）的组件。这些组件可以被独立地测试和逐渐地被集成以构成整个系统。

– 进一步，其中的一些组件可以被重用，特别是能够解决一定范围内的公共问题的组件。这些可重用组件构成了企业内部重用机制的基础，可以不断提高软件开发的生产率和质量。

– 最近，组件基础结构，例如 CORBA 、 Internet 、 ActiveX 和 JavaBeans 等的商业成功引发了各种领域商业组件开发的热潮，使你可以直接购买各种功能的组件并集成到你的系统中，而不必从头开发。

基于组件的开发 (CBD)

• 模块化和封装的思想将面向对象技术引入了软件开发。而另一个变化正在发生，软件开发从一行一行地编码变成了通过组装组件来集成系统。

• RUP 通过以下手段支持基于组件的软件开发：– 迭代开发的方法允许你渐进地识别组件，决定哪些组件应

被开发，哪些要重用，哪些要购买。– 对软件体系结构的关注使你能有力地表达结构——组件和

它们的集成方式——包括基本机制和模式等– 包、子系统和层等概念在分析设计过程可以用来组织组件

和定义接口– 测试首先围绕组件进行，然后再逐渐集成新的组件，构成

更大的系统进行测试

最佳实践：可视化建模（ UML)

Visual modeling raises the level of abstraction

最佳实践：可视化建模（ UML)

• 什么是可视化建模？• 我们为什么要建模？

什么是可视化建模？• 可视化建模就是使用语义丰富、图形和文本形式的符号系统进行软件设计。

• 一个符号系统，如 UML ，可以使抽象的层次被提升，而同时保持了语法和语义的严谨性通过这种方式，可以促进开发团队的沟通、使读者能够理解设计，并为实现提供无二义性的设计基础

我们为什么要建模？• 一个模型是一个系统的简化的视图，它从一

个特殊的角度展示了系统的必要的元素，隐藏了那些非必要的细节信息。

• 模型可以用来帮助完成：– 加深对复杂系统的理解– 以较低的成本探索和比较不同的设计方案– 构成实现的基础– 准确地捕获需求– 无二义性地传达设计决策

加深对复杂系统的理解• 模型的重要性随着系统复杂度的增加而增加。例如，

一个小应用程序的构造可以由一个人根据他大脑中的构思在几天之内完成，但是一个有成千上万行代码的电子商务系统或者交通控制系统，一个人可能永远也完成不了。构造模型可以使开发人员将精力集中在更宏观的层面上，理解组件的交互和发现设计中致命的缺陷。例如：– Use Cases图可以无二义性地描述行为– 类图和数据模型图可以准确地描述设计– 状态转换图可以描述系统的动态行为

• 建模之所以重要，是因为模型能够帮助开发团队用可视化的方法描述和记录系统的行为和结构，却不会在复杂性中迷失方向。

低成本探索和比较不同的设计方案• 简单的模型可以被创建和修改来对不同的设计方案进行比较和筛选，这种成本相对是低廉的。

• 在代价高昂的编码工作开始之前，创造性的想法可以被捕捉到，并由其他开发人员对其进行复查

• 当与迭代开发相结合时，可视化模型帮助开发人员了解设计的变更和在整个开发团队中，对这些变更进行充分的沟通

构成实现的基础• 今天许多项目都采用面向对象程序语言来获得重用性、对设计变更的适应性和系统的稳定性。为了获得这些收益，在设计中使用对象技术甚至更重要。 RUP 产生一个面向对象的设计模型，它是实现的基础。

• 通过适当工具的辅助，一个设计模型可以用来产生实现的一个初始代码集合，这称为正向工程 (forward engineering)或代码生成 (code generation) 。设计模型还可以被增强，通过包含进足够的信息直接构造系统。

• 逆向工程（ Reverse engineering ）可以被用来从已经存在的实现中产生设计模型。这可以用来评估已经实现的系统。

• 双向工程（ Round trip engineering ）同时包含正向和逆向技术来保证设计和实现的一致性。与迭代过程和恰当的工具结合，双向工程可以使在每个迭代中的设计和代码保持同步。

准确地捕捉需求• 在构造一个系统之前，捕捉需求是至关重要

的。使用无二义性的模型规范需求保证了所有项目的风险承担人（ stakeholders ）可以理解需求，并就需求达成一致的意见。

• 模型将系统的外部行为从实现中分离出去使你可以集中精力研究系统的使用，而不会受实现细节的干扰

无二义性地传达设计决策• RUP 使用 UML ， UML 是一种用来描述系

统工程和商业工程的符号系统。一个标准的符号系统扮演着如下的角色 (see [BOO95]) ：– 它是一种用来对那些不明显的或不能从代码中直接推断出的设计决策进行沟通的语言

– 它提供的语义必须足够的丰富，以能表达所有重要的策略和技术决策

– 它提供一种很具体的形式，使人们能够用它进行推理，并且使工具能够管理

• UML 代表了整个对象技术产业的软件建模趋势

最佳实践：验证质量

软件问题在发布之后进行修改需要付出 100~1000倍的代价。在整个产品生命周期中验证和管理质量是保证在正确的时间达到正确的目标的关键。

最佳实践：验证质量• 在整个生命周期内的质量验证是什么含义？• 质量是什么？

– 简介– 质量的定义– 谁对质量负责？– 关于质量的常见的错误概念– 在 RUP 中进行质量管理

在整个生命周期内的质量验证是什么含义？

• 所有人工制品（ artifacts ）的质量在它们成熟之前，在生命周期中必须在几个点上被评估，这是非常重要的。

• 人工制品应该在产生它们的活动完成后和每次迭代的末尾被评估。特别的，当可执行软件被生成时，它必须在每次迭代中经受重要场景地验证和测试，以便对设计进行更切实的折衷，尽早地消除人为错误。这与传统方法有很大的不同，传统的方法是在整个生命周期的最后测试集成的软件

质量是什么？——简介• 质量是我们在所有的产品、流程和服务中所追求的东西。但

是，“质量是什么呢？”，每个人会有不同的观点。通常的回答包括：– “质量……我不知道怎样确切描述它，但是当我遇到质量的问题时，

我会知道的”– “……满足需求”

• 或许针对软件的关于质量的最常见的引述是关于它不被满足时的评论：– “他们怎么能发行这么低质量的东西？”

• 这些回答反映了一些问题，但是它们并没有对如何严格地进行质量检查和提高产品质量给出标准。

• 质量不是一个单一的特征或属性。它是可以被一个产品或一个过程所拥有的多维特征。产品质量关注于构造正确的产品，而过程质量关注正确地构造产品。

质量的定义• 质量的定义在 American Heritage Dictionary 中的定义为：

– Quality ： An inherent or distinguishing characteristic; a property. b. A personal trait, especially a character trait. 2. Essential character; nature. 3.a. Superiority of kind. b. Degree or grade of excellence.

• 如上可见，质量不是一维的，它包含很多方面。在 RUP 中，质量被定义为：– 满足下列识别条件的特征：

• 满足或超过达成一致的需求集• 使用达成一致的测量方法和判据进行评估• 使用达成一致的过程产生

• 达到质量要求不简单是“满足需求”或者产生出满足用户要求和期望的产品。质量还包括证明达到质量要求的测量方法和判断标准，以及实现一个过程来保证产品是通过这一过程产生的，从而能够达到一定的质量，这一过程是可重复和可管理的。

谁为质量负责？• 一个常见的错误概念是质量是某个小组的责任。这一错误概

念又经常被被建立一个小组，有时称为质量保证小组（其它的名称可能是测试、质量控制、或质量工程等等）并赋予他们特许和责任的活动强化。

• 质量应该是，也必须是每个人的责任。获得质量必须集成所有的过程活动，而不是分离的规则，因此必须使每个人对他生产的产品和他们参与的过程的实现负责

• 每个角色对质量获得的贡献是通过以下方式和途径实现的：– 产品质量——对在每个被生产出的人工制品中的所有质量获得的贡献– 过程质量——对他们参与的过程活动的质量获得的贡献

• 每个人都分享获得高质量产品的责任和荣誉，也共同承担低质量产品的耻辱。但是仅有那些直接参与到一个特定的过程单元中的人对这些过程单元（包括其中的人工制品）的质量负责。但是必须有某个人对质量管理负责，即他要监控，保证质量被管理、测量和实现。管理质量的责任人是项目经理。

关于质量的常见的错误概念• 质量可以以添加或测试的方式进入到产品中

– 没有关于产品是什么、它需要作什么、谁使用它、它如何被使用等等的描述，我们不可能生产出产品。同样，质量和它的获取如果没有被表述、测量或与生产过程分离，也是无法得到的。

• 质量是一维的，是单一的属性或单一的特征，并且质量对每个人意味着同样的事情– 质量不是一维的，不是单一的属性或特征。质量通过多种途径被测量——质量测度和判据被建立，以满足项目、组织和客户的要求

– 质量可以沿着多维进行测量——一些被应用到过程质量，一些被应用到产品质量，一些则同时应用于两者。质量的测量可以反映：

• 进展：例如证明 use cases或里程碑的完成• 变化：计划和实际在进度、预算、人员需求等方面的差异• 可靠性：在执行过程中对失败（崩溃、内存泄漏等）的抵抗能力 (crashi

ng, hanging, memory leaks, and so on) during execution • 功能：产品按照期望对必须的 use cases 的实现和执行情况• 性能：产品在规定的时间内的执行和响应能力，在外部操作环境发生变

化时的连续工作能力

关于质量的常见的错误概念• 质量是自己发生的

– 质量自己是不会发生的。要想获得质量，一个过程必须被实现、附加和测量。 RUP 的目的就是提供一条规范化的途径在一个开发组织内分配任务和责任，目标是在预期的进度和预算内，生产出满足最终用户要求的高质量的软件产品。 RUP 采用了许多现代软件开发的先进思想，通过适当的裁剪可以适应范围很广的项目和组织。工作流环境对如何最佳地配置你需要的过程提供了指南

– 过程可以被配置，质量——可接受的判据——可以被协商。这其中常见的因素包括：

• 风险（包括责任和义务） • 市场机会 • 利润要求 • 人员或进度方面的问题• 预算

• 关于过程和判据的改变的接受必须在项目开始的时候被识别出来，并达成一致。

在 RUP 中进行质量管理• 质量管理的目的在于：

– 识别出可接受的质量的恰当的标志（测度）– 识别出进行质量评估中应使用的恰当的测量方法– 尽早尽最大可能地识别并处理影响质量的问题

• 质量管理的实现贯穿在 RUP 所有工作流、阶段和迭代中。通常，贯穿整个生命周期的质量管理意味着产品质量和过程质量都要被实现、测量和评估。下面是一些在工作流中进行质量管理的重要的例子：– 在需求分析工作流中的质量管理包括分析需求文档的一致性（文档之间，以及需求文

档和其它文档之间）、清晰性（在所有角色之间明确地沟通信息）和精确性（合适的细节深度和准确程度）

– 在分析设计工作流中质量管理包括评估设计，包括设计模型的一致性、设计和需求的一致性、设计和实现的一致性。

– 在实现工作流中质量管理包括根据需求、设计和测试文档评估源代码和可执行程序– 测试工作流是质量管理活动高度集中的地方– 环境工作流与测试工作流相似，包含了许多质量管理活动。在这里你可以发现关于如何配置过程的指南。

– 在发布工作流中质量管理包括根据需求、设计和测试文档评估实现和发布文档，评估可执行产品和交付文档。

– 在项目管理工作流中质量管理包括对质量管理各个方面的全面描述，包括各种复查和评审

最佳实践：控制变更

Controlling changes is more than just check-in and check-out of files. It includes management of workspaces, parallel development, integration, as well as builds.

最佳实践：控制变更• 当你开发一个软件为主的系统时，一个关键的挑战

是你必须管理分布在不同地点、在不同开发小组中的开发人员和多次迭代、各种发布项和产品，以及各种平台。没有规范化的控制机制，开发过程会很快陷入混乱。在 RUP 中配置和变更管理工作流告诉你如何适应这种挑战。

• 协调开发人员和开发团队的活动和产出的工作包含建立可重复的过程来管理软件和文档的变更。这种协调可以根据项目的优先级和风险来合理地调配资源，并能主动地管理在迭代过程中的工作变化。与迭代开发配合，可以使你能连续地监控变更，可以主动地发现和解决问题

最佳实践：控制变更• 协调迭代和发布项包括在每次迭代结束时建立和发布一个测试过的基线。维护每个发布项的元素之间，和多个发布项的元素之间的可跟踪性对评估和管理变更的影响是十分重要的。

• 控制变更可以从根本上解决软件开发中的一些问题：– 需求变更的工作流被定义，并且是可重复的。– 变更请求能够清晰及时地被沟通和处理– 被隔离开的工作空间降低了平行工作的组员之间的影响– 变更率统计为客观地评价项目状态提供了良好的指标– 工作空间包含所有配置，具有一致性– 变更的传播是可评估的、可控制的– 变更可以在一个健壮的、可定制的系统中被维护和管理

最佳实践的实现• Rational 的工具• 工具规范指南• 过程指南• 可配置的过程

Rational 的工具• Rational Administrator • Rational AnalystStudio • Rational ClearCase • Rational ClearQuest • Rational Purify • Rational PureCoverage • Rational Quantify • Rational RequisitePro • Rational Robot

• Rational Rose • Rational Process Work

bench • Rational SoDA • Rational TestFactory • Rational TestManager • Rational Unified Proces

s

工具规范指南

Tool mentors provide a link between the Rational Unified Process and other Rational tools

过程指南

Users of Rational tools have access to context sensitive help linking to the Rational Unified Process

可配置的过程

The Rational Unified Process provides a framework that can be customized to each software development organization's specific needs. Factors that affect how the customization should look include what technology is used, what tools are employed, as well as what processes are currently used in the organization.

软件开发过程的四个阶段• 从开发工程管理的角度， RUP 中一个软件开发周期分为四个

不同的阶段 (Phase) ，每个阶段都有一个主要的里程碑（ Milestone) 。这四个阶段按时间顺序依次为：– 初始阶段 (Inception Phase)– 细化阶段（ Elaboration Phase ）– 构建阶段 (Construction Phase)– 移交阶段（ Transition Phase ）

• 四个阶段通过四个里程碑区分开来，这四个里程碑依次为：– 目标里程碑 (Objective Milestone)– 结构里程碑（ Architecture Milestone ）– 功能里程碑 (Operational Capability Milestone)– 产品发布里程碑 (Product Release Milestone)

• 在每个阶段结束时都有一个阶段评审，如果当前的开发状态达到了相应里程碑的要求那么就可以进入到下一个开发阶段中。

工作量和时间开销 • 每个阶段的工作量和时间开销都是不一样的，

而且不同的项目其开销分配也会互不相同，但是对于一个中等规模的开发项目来说，其大体的资源分配情况如下：

初始细化构建移交工作量 5% 20% 65% 10%

时间 10% 30% 50% 10%

上述图表中需要注意的是：从时间分配上来说，四个阶段的分配比例是1： 3： 5： 1，其中构建阶段（主要是编码）的时间只占到整个项目的时间的一半，而以需求建模和分析设计为主要工作的初始阶段和细化阶段的时间占到了整个项目时间的 40%。

初始阶段 (Inception Phase)

• 阶段目标• 目标里程碑评审标准• 阶段评审的产物（ Artifacts ）和需要达到的状态

阶段目标• 本阶段的主要目标是就软件开发周期的目标在各风险承担人

时间达成共识。对于一个全新的软件开发项目来说，本阶段具有非常重要的意义，在这个阶段中，关注的是整个项目进行工程中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段的时间可能很短。

• 本阶段的主要目标如下：– 1．明确软件系统的范围和边界条件，包括从功能角度的前景分析

（ Vision ）、产品验收标准（ Acceptance Criteria ）和哪些做与哪些不做的相关决定。

– 2．明确区分系统的关键 Use-case 和主要的功能场景 (Operational Scenarios)

– 3．展现或者演示至少一种符合主要场景要求的候选软件体系结构– 4．对整个项目做最初的项目成本和日程估计（更详细的估计将在随后的细化阶段中作出）

– 5．估计出潜在的风险（主要指各种不确定因素造成的潜在风险）– 6．准备好项目的支持环境

目标里程碑评审标准• 初始阶段的里程碑是目标里程碑，因此本阶段

主要是评估项目的目标以决定是否继续项目或者直接取消。主要标准包括：– 风险承担人就范围定义、成本 /日程估计达成共识– 一致认同已经捕获了正确的需求集合，并对这些需求有了共同的理解

– 一致认同成本 /日程估计、优先级、风险和开发工程等是合宜的

– 所有的风险已经标识出来，并且针对每项风险都有了应对策略

阶段评审的产物和需要达到的状态产物（按照重要性排序）应达到的状态

Vision(SA) 核心需求，关键特色和主要约束都已形成文档Business Case(PM) 建立并已确认Risk List & Risk Management Plan (PM)

早期的项目风险已经标识出来

Business Rules(BPA) 核心业务规则已经归档Stakeholder’s Request & Target Organization Assessment (BPA)

完成

Business Architecture Document & Supplementary Business Specification （ BPA ）

完成

阶段评审的产物和需要达到的状态产品（按照重要性排序）应达到的状态

Software Development Plan(PM)

标识出早期的阶段、持续时间和相关目标； SDP 中的资源估计 ( 主要是对时间、项目组成员、和开发环境等成本的估计 ) 应该和 Business Case保持一致。资源估计可以包括直到产品交付的整个项目，也可以只估计到细化阶段就可以了。对于完整的项目估计来说，可能是非常粗略的。这些估计将在随后的每个阶段和循环过程中不断细化、精确和修正。根据项目要求的不同， SDP 中可以包含一个或多个专门的计划文档，此外， SDP 中的工作指导类文档至少应该有草案的形式。

Iteration Plan(PM) 为细化阶段的第一个循环准备的循环计划已经完成并通过评审

Product Acceptance Plan(PM)

已经评审并建立基线，该计划在随后的循环过程中如果出现了附加的需求将加以细化


Development Case(PE) 基于 Rational Unified Process 建立，可以修改或扩展，已形成文档并通过评审

Project-Specific Templates(PE)

整个项目的相关模版已准备好

Use-Case Modeling Guidelines(SA)

已纳入基线

Tools(TS) 所有支持项目的工具已经选好，下一步循环工作必需的工具安装完毕

Glossary(SA) 主要的术语已经定义并经过评审Use-Case Model (Actors, Use Cases)(SA,UID,UCS)

重要的 Actors 和 Use-case已经标识出来，最为关键的 Use-case 的事件流框架形成。

User Interface Prototypes 界面原型 (UID)

主要界面原型


Business Use-case Model 和 Business Object Model (Organization Unit,Business Use-case Realization,Business Entity,Business Worker) (BPA & BD)

系统中用到的关键概念已经形成文档并经过评审。

Prototypes （可选）针对 Vision或 Business Case或者某个特定风险准备好一个或多个概念原型

Requirement Management Plan & Requirement Attribute Repository(SA)

RMP完成，准备好需求属性库

角色说明• SA——System Analyst

• UID——UI Designer

• UCS——Use-case Specifier

• PM——Project Manager

• BPA——Business Process Analyst

• BD——Business Designer

• PE——Process Engineer

• TS——Tool Specialist

需求类• Vision• Use-case Model( 包括和核心 use-case 实现相关的 Object Mod

el)• Core Use-case,UI Prototype• Business Use-case Model( 含 Business Object Model, 包括 Wor

ker,Organization Unit,Entity 等 )• Stakeholder’s Request & Target Organization Assessment• Business Architecture Document & Supplementary Business S

pecification• Business Rules• Use-case Model Guideline 的 Draft• Glossary• Requirement Management Plan & Requirements Attribute Re

pository

PM类• Business Case• Risk List & Risk Management Plan• SDP• Iteration Plan & Iteration Assessment• Product Acceptance Plan• Problem Resolution Plan, Measure Plan, State

Assessment, Quality Assurance Plan• Work Order• Review Record(Project Reviewer)

PE类• Project-specific Templates

• Development Case

配置和变更管理• 建立配置工作区和管理库• 准备好变更请求库。

细化阶段 (Elaboration Phase)


阶段目标• 本阶段的主要目标是将软件系统的体系结构 (Architecture)纳入基线，为构建阶段的设计和实现建立一个稳定的工作基础。所以本阶段的里程碑是结构里程碑。软件体系结构是建立在对核心的软件需求（这里的核心软件需求指的是对整个软件结构构成重要影响的需求）的分析与思考和对主要项目风险的评估基础上的。可以通过对一个或多个软件结构化原型来评估体系结构的稳定性（ Stability ）。

• 细化阶段的主要目标包括：– 确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。

– 针对项目的软件结构上的主要风险已经解决或处理完成。– 通过完成软件结构上的主要场景建立软件体系结构的基线。– 建立一个包含高质量组件的可演化的产品原型– 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和

时间范围内。– 建立好产品的支持环境。

目标里程碑评审标准• 细化阶段的里程碑是结构里程碑，这是软件开发周期中第二

个重要的里程碑，在这个里程碑处，我们主要检查系统的目标和范围、软件体系结构的选择和主要项目风险的解决。具体的标准包括：– 产品 Vision 和需求已经稳定 – 软件体系结构已经稳定 – 可执行的原型表明主要的风险元素已经关注并且已经令人信服的加以

解决– 为构建阶段准备的循环计划已经足够详尽和精确以保证开发工作可以

进行– 构建阶段的循环计划已经被可靠的估计所支持– 所有的风险承担人都已经认同，在现有的软件体系结构下，如果当前计划在系统开发过程中得以贯彻，项目 Vision 应该可以得到满足。

– 针对计划开销而言，所有的资源开销是可以接受的


Prototypes 针对系统的关键功能和主要结构场景建立的一个或多个可执行的结构化原型。

Risk List & Risk Management Plan （ PM ）

更新并经过评审。

Development Case(PE)

根据早期的项目管理经验加以细化。为构建小组提供支持的开发环境、过程、工具和各种自动化工具已经到位。

Project-Specific Templates(PE)

文档模版已经用于建立软件文档产品

Tools(TS) 用于细化阶段的工具已经安装Software Architecture Document 和 Reference Architecture(AR)

已经创建并纳入基线，其中包括详细描述对软件结构构成重大影响的 use-case （通过 use-case图） , 对关键的实现机制和设计元素的标识，外加对流程和部署的定义和描述。


Analyse_Design Model ( 包括所有的子产品，包括对象模型、设计类、子系统和包、接口、事件，静态结构图，动态序列图、活动图，状态转移图等主要内容 ) （ AR,D ）

已经定义并纳入基线，对于和软件结构构成重大影响的 use-case 的实现已经定义，相关的行为已经分配到适当的设计元素中。组件已经标识出来，创建 /购买 / 复用决定做出，选好的结构化组件针对主要场景已经加以集成和评估。从这些活动中获得的教训可能会导致重新设计软件结构，重新考虑替代的设计方案和对需求的重新思考

Data Model （ DD ）定义并纳入基线，主要的数据库元素已经设计出来并通过评审

Implementation Model (and all constituent artifacts, including Components)(AR,IMP)

早期结构已经创建，主要组件已经确认并原型化


Vision(SA) 基于本阶段获得的新的信息加以细化。对形成软件结构和计划决策起主要作用的 use-cases 建立一个稳固的理解

Software Development Plan （ PM ）

更新并扩展到构建和移交阶段。

Guidelines, such as Design Guidelines and Programming Guidelines.

工作指南已经用于指导相关工作。

Iteration Plan & Iteration Assessment （ PM ）

针对构建阶段的循环计划已经完成并经过评审。

Use-Case Model (Actors, Use Cases)(SA,UCS)

use-case 模型基本完成 - 所有的 use-case 已经标识出来，所有的 Actors 也已标识出来，大多数 use-case （从需求分析中捕获的）的说明都已提供


Software Requirement Specification (UCS)

纳入基线

User Interface Prototype(UID) 完成Supplementary Specifications （ SA ）

捕获非功能需求的辅助规范已经形成文档并经过评审。

Business Case(PM) 如果结构化工作中发现了新的导致变更基本项目假定的问题，本文档将加以更新

User Manual and other Training Material （ TW,CB ）

基于 use-case形成早期版本。

角色说明• AR——Architect

• D——Designer

• DD——Database Designer

• IMP——Implementer

• TW——Technical Writer

• CB——Course Builder

需求类• Vision• Use-case Model( 包括 Actors,Use-cases,Use-case Real

ization)• SRS & Supplementary Specification• User Interface Prototype

PM类• Risk List

• SDP

• Iteration Plan

• Business Case

分析和设计类• Software Architecture Document & Reference

Architecture

• Analysis_Design Model(Include Object Model, Design Class, Package, Subsystem, Interface, Event and Diagrams)

• Implementation Model(Include Subsystem,Component)

• Data Model

• Prototypes

补充说明• 细化阶段需求建模结束、概要和详细设计工作也基本结束，

一部分和结构相关的组件已经开始编码。• 本阶段可以分为两个子阶段，第一个子阶段是以概要设计结束（完成软件体系结构设计）和需求建模基本结束为标志，此阶段主要参与人员是 SA(& Use-case Specifier) 和 Architect.可以称为概要设计阶段。此后是详细设计阶段，在详细设计阶段，需求建模只剩下 Refine System Definition 和 Manage Change Requirements两项主要工作。对于分析和设计工作来说，可能会有多个设计人员（包括 Designer,Database Designer,甚至部分 Implementer ）参与进来，这时 ,Architect 主要对软件的整体体系结构负责。

• 评审可以在概要设计结束和详细设计开始时进行。

构建阶段 (Construction Phase)


阶段目标• 构建阶段的主要目标是进一步完成剩余的部分需求和基于纳入基线的软件体系结构完成软件系统的开发工作。本阶段的详细目标包括如下内容：– 通过优化资源和避免不必要的返工达到开发成本的最小化– 根据实际需要达到适当的质量目标– 根据实际需要形成各个版本（ Alpha,Beta,and other test release ）– 对所有必须的功能完成分析、设计、开发和测试工作– 采用循环渐进的方式开发出一个可以提交给最终用户的完整产品– 确定软件、站点、用户都为产品的最终部署做好了相关准备– 达成一定程度上的并行开发机制

• 本阶段里程碑的达成标志着软件产品可以进入到产品部署的Beta测试阶段。

目标里程碑评审标准• 功能里程碑的达成意味着软件产品已经准备好提交给相应的产品移交小组。在这个阶段，所有的功能已经开发完成，所有的 Alpha测试也已完成。除了软件产品本身以外，软件用户手册和发布说明也已开发完成。具体的里程碑内容包括：– 发布的产品是否足够稳定和成熟到可以在用户那部署的程

度？– 所有的风险承担人是否已经做好将产品移交到用户手中的

准备？– 相对计划开销而言，所有的实际开销是否仍然可以接受 ?


"The System"(IN) 准备好进入 Beta测试Deployment Plan(DM) 开发、评估并已纳入基线Implementation Model (and all constituent artifacts, including Components)(AR,IMP)

从细化阶段的模型扩展到所有组件，完成

Test Plan, Test Procedure, Test Use-case, Test Results ， Workload Analysis Document(TD,T)

完成

Training Materials(TW,CB)（可选）

手册和培训资料基本完成

Iteration Plan （ PM ）

为移交阶段制订的循环计划已经完成并经过评审


Design Model (and all constituent artifacts)(D)

更新并完成

Development Case(PE) 基于早期项目经验完成，为支持产品移交小组的环境、工具和自动化工具已经到位

Project-Specific Templates(PE) 已经用于建立软件产品文档Tools(TS) 支持产品构建的工具已经安装Data Model(DD) 更新，包括所有支持持久存储的元素

(e.g. tables, indexes, object-to-relational mappings, etc.)

Supplementary Specifications(SA) 如果有新的需求出现将加以更新

Use-Case Model (Actors, Use Cases)(SA,UCS)

如果实现阶段发现新的需求将加以更新

角色说明• IN——Integrator

• DM——Deploy Manager

• TD——Test Designer

• T——Tester

测试类• Test Plan( 包括测试计划，集成测试计划 )• Test Procedure• Test Use-case• Test Results• Test Review Report

移交阶段 (Transition Phase)


阶段目标• 本阶段的目标是确保软件产品可以提交给最终用户。本阶段根据实际需要可以分为几个循环。本阶段的具体目标如下：– 进行 Beta测试以期达到最终用户的需要– 进行 Beta测试和旧系统的并轨– 转换功能数据库– 对最终用户和产品支持人员的培训– 提交给市场和产品销售部门– 和具体部署相关的工程活动– 协调 Bug修订、改进性能和可用性 (Usability) 等工作– 基于完整的 Vision 和产品验收标准对最终部署做出评估– 达到用户要求的满意度– 达成各风险承担人对产品部署基线已经完成的共识– 达成各风险承担人对产品部署符合 Vision 中标准的共识

目标里程碑评审标准• 移交阶段是以达成产品发布里程碑为标志的。

在这个里程碑处，我们可以判定目标是否满足，也可以决定是否开始一个新的软件开发周期。某些情况下，产品发布里程碑可能会跟下一个软件开发周期中的初始阶段的里程碑重合。产品发布里程碑是产品验收活动最终完成的结果。主要的评判标准包括：– 最终用户是否已经满意– 相对计划的开发开销而言实际的开发开销是否可以接受

阶段评审的产物和需要达到的状态产物（按照重要性排

序）应达到的状态

The Product Build 完成并满足需求Release Notes 完成Installation Artifacts 完成Training Material 完成，并确保用户对产品的使用和自

身维护工作已经满意End-User Support Material

完成，并确保用户对产品的使用和自身维护工作已经满意

开发过程中的静态结构• 开发流程定义了“谁”、“何时”、“如何”做“某事”四种主要的建模元素被用来表达 RUP：

•角色 (Roles)——谁•活动 (Activities)——如何• 产物 (Artifacts)——某事• 工作流 (Workflows)——何时

活动、产物、角色

角色 (Roles)• 角色定义了个人或由若干人所组成小组的行为和责任。可以认为角色是项目组中

个人戴的“帽子”。单个人可以佩戴多个不同的帽子。这是一个非常重要的区别，因为通常容易将角色认为是个人或小组本身。在 RUP 中角色还定义了如何完成工作。所分派给角色的责任既包括某系列的活动，还包括成为产物的拥有者。

活动 (Activities)

• 某个角色的活动是可能要求该角色中的个体执行的工作单元。活动具有明确的目的，通常表现为一些产物，如模型、类、计划等。每个活动分派给特定的角色。活动通常占用几个小时至几天，常常牵涉一个角色，影响到一个或少量的产物。活动应可以用来作为计划和进展的组成元素。如果活动太小它将被忽略；而如果太大，则进展不得不表现为活动的组成部分。活动的例子：– 计划一个迭代过程，对应角色：项目经理– 寻找 Use cases 和 Actors ，对应角色：系统分析员– 执行性能测试，对应角色：性能测试人员

产物 (Artifacts)

• 产物是被产生的、修改或为过程所使用的一段信息。产物是项目的实际产品，项目产生的事物或者供向最终产品迈进时使用。产物用作角色执行某个活动的输入，同时也是该活动的输出。在面向对象的设计术语中，如活动是活动对象角色上的操作一样，产物是这些活动的参数。

• 产物可以具有不同的形式：– 模型，如 Use Case 模型或设计模型– 模型组成元素，即模型中的如类、 Use Case或子系统般

的元素– 文档，如商业案例或软件结构文档– 源代码– 可执行文件

工作流 (Workflow)

• 仅依靠角色、活动和产物的列举并不能组成一个过程。需要一种方法来描述能产生若干有价值的、有意义结果的活动序列，显示角色之间的交互作用。

• 工作流是产生具有可观察结果的活动序列。• UML 术语中工作流可以表达为序列图、协作图或活动图。在 RUP 中使用活动图的形式来描述工作流

• 注意要表达活动之间的所有依赖关系并不是总可能或切合实际的，常常两个活动较表现的交织得更紧密，特别是在涉及到同一个角色或个人时。人不是机器，对于人而言工作流不能按字面地翻译成程序，被精确地、机械地执行。

核心工作流• RUP中有 9个核心工作流，代表了所有角色和活动的逻辑分组情况

• 核心工作流分为 6个核心工程工作流– 商业建模工作流– 需求工作流– 分析和设计工作流– 实现工作流– 测试工作流– 分发工作流

• 和 3个核心支持工作流– 项目管理工作流– 配置和变更控制工作流– 环境工作流

商业建模• 决大多数商业工程化的主要问题是软件工程人员和商业工程人员之间不能正确地交流。这导致了商业工程的产出没有作为软件开发输入而正确地被使用，反之亦然。 RUP针对该情况为两个群体提供了相同的语言和过程 , 同时显示了如何在商业和软件模型中创建和保持直接的可跟踪性 .

• 在商业建模中使用商业用例来文档化商业过程，从而确保了组织中所有支持商业过程人员达到共识。商业用例被分析以理解商业过程如何被业务支持，而这些在商业对象模型中被核实

• 许多项目可能不进行商业建模

商业建模

需求• 需求工作流的目标是描述系统应做“什么”，并允许开发人

员和用户就该描述达成共识。为了达到该目标，进行提取、组织、文档化需要的功能和约束；跟踪，为折衷方案及决定形成文档。

• 蓝图被创建，需求被提取。代表用户和其他可能与开发系统交互的其它系统的 Actor 被指明、 Use Case 被识别，表示系统的行为。因为 Use Case根据 Actor 的要求开发，系统与用户之间的联系更紧密。系统展示了用于再生系统的用例模型。

• 每一个用例被仔细地描述。用例描述显示了系统如何与 Actor 交互及系统的行为。非功能性的需求在补充说明中体现。

• Use Case起到贯穿整个系统的开发周期线索的作用。相同的用例模型在需求捕获阶段、分析设计阶段和测试阶段中使用。

需求

分析和设计• 分析设计工作流的目标是显示系统“如何”在“实现”阶段被实现的。

你需要一个如下系统：– 在特定的实现环境中完成用例描述中指定的任务和功能– 满足了所有的需求– 健壮的被建造（如果功能需求发生变化易于更改）

• 分析设计结果是一个设计模型和可选的分析模型。设计模型是源代码的抽象，即设计模型充当源代码如何被组建和编制的“蓝图”

• 设计模型由设计类和一些描述组成。设计类被组织成具有良好接口的设计包和设计子系统，而描述则体现了类的对象如何协同工作，实现用例的功能。

• 设计活动以体系结构设计为中心。结构的产物和验证是早期迭代的主要焦点。结构由若干结构视图来表达，这些视图捕获了主要的构架设计的决定。本质上结构视图是整个设计的抽象和简化。该视图中细节被放在了一旁，使重要的特点体现得更加清晰。结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高任何被创建模型的质量。

分析和设计

实现• 实现阶段的目的：

– 定义代码的组织结构——以层次化的实施子系统的形式– 实现类和对象——以构件的形式（源文件、二进制文件、

可执行文件等）– 将开发出的构件作为单元进行测试– 对由单个实现者（或小组）产生的结构集成为可执行的系

统• 系统通过完成构件而实现。 RUP描绘了如何重用现

有的组件或实现经过良好责任定义的新构件。使系统更易于使用，提高了系统的可重用性。

• 构件被构造成实施子系统。子系统被表现为带有附加结构或管理信息的目录形式。例如子系统可以被创建为文件系统中的文件夹或目录或 Java中的包

实现

测试• 测试的目的是：

– 验证对象间的交互作用– 验证软件构件的正确集成– 验证所有需求被正确的实现– 识别并确保在软件发布之前缺陷被处理

• RUP 提出了迭代的方法，意味着在整个项目中进行测试，从而允许尽可能早的发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型分别从可靠性、功能性、应用和系统性能来进行。流程从每个维度描述了如何经历测试生命周期的几个阶段，计划、设计、实现、执行和审核。

• 另外描述了何时及如何引入测试自动化的策略。使用迭代的方法，测试自动化是非常重要的，它允许在每次迭代结束及为每个新产品进行回归测试。

测试

发布• 发布工作流的目标是成功地生成版本，将软件分发给最终用户。它包括了范围广泛的活动：– 生成软件本身外的产品– 软件打包– 安装软件– 给用户提供帮助

• 许多情况下还包括如下的活动：– 计划和进行 Beta 测试版– 移植现有的软件或数据– 正式验收

• 尽管发布工作流主要被集中在交付阶段 ,但早期阶段需要加入为创建阶段后期的发布做准备的许多活动

发布

项目管理• 软件项目管理是一门艺术 ,它平衡了互相冲突的目

标，管理风险，克服各种限制来成功地发布满足投资用户和使用者需要的软件。如此少的无争议的成功项目无疑是该项任务难度的证明。

• 工作流主要集中在迭代开发过程的特殊方面。我们的目标是提供以下的事物来使该任务更简单：– 管理项目的框架– 计划配备执行监控项目的实践准则– 管理风险的框架

• 它并不是成功的灵丹妙药，但提供了管理项目能显著提高软件成功发布的方法

项目管理

配置和变更管理• 本工作流中描绘了如何在多个成员组成的项目中控制大量的产出物。控制

有助于避免混乱，确保不会由以下的问题而造成产品的冲突：– 同步更新，当两个或两个以上的角色各自工作在同一产物上时，最后一个修改者会破坏前者的工作

– 通知不达，当被若干开发者共享的产品中的问题被解决时，修改未被通知到一些开发者

– 多个版本，许多大型项目以演化的方式开发，一个版本可能供顾客使用，另一个版本用于测试，而第三个版本处于开发阶段。如果问题在其中任何一个版本中被发现则修改需要在所有版本中繁衍，从而可能产生混乱，导致昂贵的修改和重复劳动，除非变更被很好地控制和监控

• 工作流提供了准则管理演化系统中地多个变体，跟踪给定软件创建过程中的版本。根据用户定义的版本规则建造程序或整个版本，实施特定于现场的开发策略。

• 工作流描述了如何管理并行开发、分布式开发，如何自动化创建工程。这在如每天均需要频繁编译链接的重复过程中尤为重要。如果没有有力的自动化是不可能的，同时也阐述了对产品修改原因、时间、人员保持审计记录

• 工作流也涵盖了变更需求管理，即如何报告缺陷，在它们的生命周期中如何管理及如何使用缺陷来跟踪进展和发展的倾向

配置和变更管理

环境• 环境工作流的目的是给软件开发组织提供软件开发环境——过程和工具——软件开发队伍需要它们的支持

• 工作流集中在项目环境中配置过程的活动，同样着重支持项目的开发规范的活动。提供了逐步指导手册，介绍了如何在组织中实现过程

• 环境工作流还包含了提供了定制流程所必须的准则、模板、工具的开发工具箱。

• 环境工作流没有被牵涉到如选择、获取、使其运行和维护开发环境等的具体方面。

环境

RUP 的缺点• RUP仅仅包含了开发过程。它没有完全覆盖软件过

程，从图 1 能够明显看出，它丢失了维护和技术支持这两个重要的阶段。

• RUP 不支持组织内的多项目开发，导致组织内的大范围的重用无法实现。

• RUP缺少开发商的支持。你能自动完成软件过程的每一个方面？ Rational 提供了所有的工具供你选择，例如是否有 Rational help desk或者 Rational persistence modeling

• RUP 在度量管理，重用管理，人员管理和测试上有缺陷。

OOSP

• OOSP 的生命期（在 Process Patterns and More Process Patterns 中有详细描写），由过程模式的集合组成。一个过程模式是一些通用技术、动作和（或者）任务的集合组成，它能够解决某一方面的软件过程问题。就象设计模式提供了一些通用的软件设计问题的解决方案，过程模式解决一些通用的软件过程问题。

• 一个重要的特征是过程模式描述了你应该做什么，而不是怎样做？因为没有规定怎样做，所以能够很容易的将它进行裁剪，以适合你自己的需要。

• OOSP 包括 4 个项目阶段 -Initiate, Construct, Deliver, Maintain and Support 。每一个阶段都有相应的模式描述。这些模式可以帮助你完成 RUP 。

rational unified process

Documents