Rational Unified Process 是软件工程的过程。它提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下,确保满足最终用户需求的高质量产品。
什么是 Rational 统一过程( Rational Unified Process)?
Rational Unified Process 是软件工程的过程。它提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下,确保满足最终用户需求的高质量产品。
Rational Unified Process 是 Rational 公司开发和维护的过程产品。Rational Unified Process 的开发团队同顾客、合作伙伴、Rational 产品小组及顾问公司共同协作,确保开发过程持续地更新和提高以反映新的经验和不断演化的实践经验。
Rational Unified Process 提高了团队生产力。对于所有的关键开发活动,它为每个团队成员提供了使用准则、模板、工具指导来进行访问的知识基础。而通过对相同知识基础的理解,
无论你是进行需求分析、设计、测试项目管理或配置管理,均能确保全体成员共享相同的知识、过程和开发软件的视图。
Rational Unified Process 的活动创建和维护模型。 Rational Unified Process 强调开发和维护模型--语义丰富的软件系统表达,而非强调大量的文本工作。
Rational Unified Process是有效使用 Unified Modeling Language (UML)的指南。UML是良好沟通需求、体系结构和设计的工业标准语言。UML 由 Rational 软件公司创建,现在由标准化对象管理机构(OMG)维护。
Rational Unified Process 能对大部分开发过程提供自动化的工具支持。它们被用来创建和维护软件开发过程(可视化建模、编程、测试等)的各种各样的产物--特别是模型。另外在每个迭代过程的变更管理和配置管理相关的文档工作支持方面也是非常有价值的。
Rational Unified Process 是可配置的过程。没有一个开发过程能适合所有的软件开发。Rational Unified Process 既适用小的开发团队也适合大型开发组织。Rational Unified Process 建立简洁和清晰的过程结构为开发过程家族提供通用性。并且,它可以变更以容纳不同的情况。它还包含了开发工具包,为配置适应特定组织机构的开发过程提供了支持。
Rational Unified Process 以适合于大范围项目和机构的方式捕捉了许多现代软件开发过程的最佳实践。部署这些最佳实践经验--使用 Rational Unified Process 作为指南--给开发团队提供了大量的关键优势。在下节中,我们对 Rational Unified Process 的6个基本最佳实践经验进行描述。
![]() ![]() |
![]()
|
Rational Unified Process 描述了如何为软件开发团队有效的部署经过商业化验证的软件开发方法。它们被称为"最佳实践"不仅仅因为你可以精确地量化它们的价值,而且它们被许多成功的机构普遍的运用。为使整个团队有效利用最佳实践,Rational Unified Process 为每个团队成员提供了必要准则、模板和工具指导;
迭代的开发产品 -- 面对当今的复杂的软件系统,使用连续的开发方法:如首先定义整个问题,设计完整的解决方案,编制软件并最终测试产品,是不可能的。需要一种能够通过一系列细化,若干个渐进的反复过程而生成有效解决方案的迭代方法。Rational Unified Process 支持专注于处理生命周期中每个阶段中最高风险的迭代开发方法,极大地减少了项目的风险性。迭代方法通过可验证的方法来帮助减少风险--经常性的、可执行版本使最终用户不断的介入和反馈。因为每个迭代过程以可执行版本告终,开发团队停留在产生结果上,频繁的状态检查帮助确保项目能按时进行。迭代化方法同样使得需求、特色、日程上战略性的变化更为容易。
需求管理 -- Rational Unified Process 描述了如何提取、组织和文档化需要的功能和限制;跟踪和文档化折衷方案和决策; 捕获和进行商业需求交流。过程中用例和场景的使用被证明是捕获功能性需求的卓越方法,并确保由它们来驱动设计、实现和软件的测试,使最终系统更能满足最终用户的需要。它们给开发和发布系统提供了连续的和可跟踪的线索。 __
基于构件的体系结构 -- 该过程在全力以赴开发之前,关注于早期的开发和健壮可执行体系结构的基线。它描述了如何设计灵活的,可容纳修改的,直观便于理解的,并且促进有效软件重用的弹性结构。Rational Unified Process 支持基于构件的软件开发。构件是实现清晰功能的模块、子系统。Rational Unified Process 提供了使用新的及现有构件定义体系结构的系统化方法。它们被组装为良好定义的结构,或是特殊的、底层结构如Internet、CORBA 和 COM 等的工业级重用构件。
可视化软件建模-- 开发过程显示了对软件如何可视化建模,捕获体系结构和构件的构架和行为。这允许你隐藏细节和使用"图形构件块"来书写代码。可视化抽象帮助你沟通软件的不同方面,观察各元素如何配合在一起,确保构件模块一致于代码,保持设计和实现的一致性,促进明确的沟通。Rational软件公司创建的工业级标准 Unified Modeling Language(UML)是成功可视化软件建模的基础。
验证软件质量 -- 拙劣的应用程序性能和可靠性是戏剧性展示当今软件可接受性的特点。从而,质量应该基于可靠性、功能性、应用和系统性能根据需求来进行验证。Rational Unified Process帮助计划、设计、实现、执行和评估这些测试类型。质量评估被内建于过程、所有的活动,包括全体成员,使用客观的度量和标准,并且不是事后型的或单独小组进行的分离活动。
控制软件的变更 -- 管理变更的能力--确定每个修改是可接受的,能被跟踪的--在变更不可避免环境中是必须的。开发过程描述了如何控制、跟踪和监控修改以确保成功的迭代开发。它同时指导如何通过隔离修改和控制整个软件产物(例如,模型、代码、文档等)的修改来为每个开发者建立安全的工作区。另外,它通过描述如何进行自动化集成和建立管理使小队如同单个单元来工作。
![]() ![]() |
![]()
|
二维结构
开发过程可以用二维结构或沿着两个坐标轴来表达:
![]() ![]() |
![]()
|
这是开发过程沿时间的动态组织结构。
软件生命周期被分解为周期,每一个周期工作在产品新的一代上。Rational Unified Process将周期又划分为四个连续的阶段。
每个阶段终结于良好定义的里程碑--某些关键决策必须做出的时间点,因此关键的目标必须被达到。
过程中的阶段和主要里程碑
每个阶段均有明确的目标。
初始阶段的目标是为系统建立商业案例和确定项目的边界。
为了达到该目的必须识别所有与系统交互的外部实体,在较高层次上定义交互的特性。它包括识别所有用例和描述一些重要的用例。商业案例包括验收规范、风险评估、所需资源估计、体现主要里程碑日期的阶段计划。
本阶段具有非常重要的意义,在这个阶段中,关注的是整个项目进行工程中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说,初始阶段的时间可能很短。
本阶段的主要目标如下:
初始阶段的产出是:
初始阶段结束时是第一个重要的里程碑:生命周期目标里程碑。初始阶段的评审标准:
如果无法通过这些里程碑,则项目可能被取消或仔细地重新考虑。
细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。
为了达到该目的,必须对系统具有"英里宽和英寸深"的观察。体系结构的决策必须在理解整个系统的基础上作出:它的范围,主要功能和如性能等非功能性需求。
容易引起争论,细化阶段是四个阶段中最关键的阶段。该阶段结束时,硬"工程"可以认为已结束,项目则经历最后的审判日:决策是否项目提交给构建和交付阶段。对于大多数项目,这也相当于从移动的、轻松的、灵巧的、低风险的运作过渡到高成本、高风险并带有较大惯性的运作过程。而过程必须能容纳变化,细化阶段活动确保了结构、需求和计划是足够稳定的,风险被充分减轻,所以可以为开发结果预先决定成本和日程安排。概念上,其逼真程度一致于机构实行费用固定的构建阶段的必要程度。
在细化阶段,可执行的结构原形在一个或多个迭代过程中建立,依赖于项目的范围、规模、风险和先进程度。工作量必须至少处理初始阶段中识别的关键用例,关键用例典型揭示了项目主要技术的风险。通常我们的目标是一个由产品质量级别构件组成的可进化的原型,但这并不排除开发一个或多个探索性、可抛弃的原型来减少如:设计/需求折衷,构件可行性研究,或者给投资者、顾客即最终用户演示版本等特定的风险。
本阶段的主要目标如下:
初始阶段的产出是:
细化阶段结束是第二个重要的里程碑:生命周期的结构里程碑。此刻,检验详细的系统目标
和范围、结构的选择以及主要风险的解决方案。主要的审核标准包括回答以下的问题:
如果无法通过这些里程碑,则项目可能被取消或仔细地重新考虑。
在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。
构建阶段,从某种意义上说,是重点在管理资源和控制运作以优化成本、日程、质量的生产过程。就这一点而言,管理的理念经历了初始阶段和细化阶段的智力资产开发到构建阶段和交付阶段可发布产品的过渡。
许多项目规模大的足够产生许多平行的增量构建过程,这些平行的活动可以极大地加速版本发布的有效性;同时也增加了资源管理和工作流同步的复杂性。健壮的体系结构和易于理解的计划是高度关联的。换言之,体系结构上关键的质量是构建的容易程度。这也是在细化阶段平衡的体系结构和计划被强调的原因。
本阶段的主要目标如下:
构建阶段的产出是可以交付给最终用户的产品。它最小包括:
创建阶段结束是第三个重要的项目里程碑(初始功能里程碑)。此刻,决定是否软件、环境、用户可以运作而不会将项目暴露在高度风险下。该版本也常被称为"beta"版。
构建阶段主要的审核标准包括回答以下的问题:
如果无法通过这些里程碑,则移交不得不被延迟。
交付阶段的目的是将软件产品交付给用户群体。
只要产品发布给最终用户,问题常常就会出现:要求开发新版本,纠正问题或完成被延迟的问题。
当基线成熟得足够发布到最终用户时,就进入了交付阶段。其典型要求一些可用的系统子集被开发到可接收的质量级别及用户文档可供使用,从而交付给用户的所有部分均可以有正面的效果。这包括:
构建阶段关注于向用户提交产品的活动。典型的,该阶段包括若干重复过程,包括 beba 版本、通用版本、bug 修补版和增强版。相当大的工作量消耗在开发面向用户的文档,培训用户。在初始产品使用时,支持用户并处理用户的反馈。开发生命周期的该点,用户反馈主要限定在产品性能调整、配置、安装和使用问题。
本阶段的目标是确保软件产品可以提交给最终用户。本阶段根据实际需要可以分为几个循环。本阶段的具体目标如下:
该阶段依照产品的类型,可能从非常简单到极端复杂的范围内变化。例如,现有的桌面产品的新版本可能非常简单,而替代国际机场的流量系统会非常复杂。
在交付阶段的终点是第四个重要的项目里程碑,产品发布里程碑。此时,决定是否目标已达到或开始另一个周期。在许多情况下,里程碑会与下一个周期的初始阶段相重叠。
发布阶段的审核标准主要包括以下两个问题:
Rational Unified Process 的每个阶段可以进一步被分解为迭代过程。迭代过程是导致可执行产品版本(内部和外部)的完整开发循环,是最终产品的一个子集,从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。
迭代方法的益处
与传统的瀑布式方法相比,迭代过程具有以下的优点:
![]() ![]() |
![]()
|
开发过程中的静态结构(Static Structure of the Process)
开发流程定义了"谁""何时""如何"做"某事"。四种主要的建模元素被用来表达 Rational Unified Process:
角色、活动和工作产物
角色定义了个人或由若干人所组成小组的行为和责任。可以认为角色是项目组中个人戴的"帽子"。单个人可以佩戴多个不同的帽子。这是一个非常重要的区别。因为通常容易将角色认为是个人或小组本身,在 Unified Process 中,角色还定义了如何完成工作。所分派给角色的责任既包括某系列的活动,还包括成为产物的拥有者。
人与角色
某个角色的活动是可能要求该角色中的个体执行的工作单元。活动具有明确的目的,通常表现为一些产物,如模型、类、计划等。每个活动分派给特定的角色。活动通常占用几个小时至几天,常常牵涉一个角色,影响到一个或少量的产物。活动应可以用来作为计划和进展的组成元素;如果活动太小,它将被忽略,而如果太大,则进展不得不表现为活动的组成部分。
活动的例子:
产物是被产生的、修改,或为过程所使用的一段信息。产物是项目的实际产品、项目产生的事物,或者供向最终产品迈进时使用。产物用作角色执行某个活动的输入,同时也是该活动的输出。在面向对象的设计术语中,如活动是活动对象(角色)上的操作一样,产物是这些活动的参数。
产物可以具有不同的形式:
仅依靠角色、活动和产物的列举并不能组成一个过程。需要一种方法来描述能产生若干有价值的有意义结果的活动序列,显示角色之间的交互作用。
工作流是产生具有可观察结果的活动序列。
UML 术语中,工作流可以表达为序列图、协同图,或活动图。在本文中,使用活动图的形式来描述。
工作流样例
注意要表达活动之间的所有依赖关系并不是总可能或切合实际的。常常两个活动较表现的交织得更紧密,特别是在涉及到同一个角色或个人时。人不是机器,对于人而言,工作流不能按字面地翻译成程序,被精确地、机械地执行。
下节中,我们将讨论开发过程中最基本的工作流,称之为核心工作流。
![]() ![]() |
![]()
|
Rational Unified Process 中有9个核心工作流,代表了所有角色和活动的逻辑分组情况。
9个核心的过程工作流
核心工作流分为6个核心"工程"工作流
和3个核心"支持"工作流
尽管6个核心工程工作流能使人想起传统瀑布流程中的几个阶段,但应注意迭代过程中的阶段是不同的,这些工作流在整个生命期中一次又一次被访问。9个核心工作流在项目中的实际完整的工作流中轮流被使用,在每一次迭代中以不同的重点和强度重复。
决大多数商业工程化的主要问题,是软件工程人员和商业工程人员之间不能正确地交流。这导致了商业工程的产出没有作为软件开发输入而正确地被使用,反之亦然。Rational Unified Process 针对该情况为两个群体提供了相同的语言和过程,同时显示了如何在商业和软件模型中创建和保持直接的可跟踪性。
在商业建模中,使用商业用例来文档化商业过程,从而确保了组织中所有支持商业过程人员达到共识。商业用例被分析以理解商业过程如何被业务支持,而这些在商业对象模型中被核实。
许多项目可能不进行商业建模。
需求工作流的目标是描述系统应做"什么",并允许开发人员和用户就该描述达成共识。为了达到该目标,进行提取、组织、文档化需要的功能和约束;跟踪、为折衷方案及决定形成文档。
蓝图被创建,需求被提取。代表用户和其他可能与开发系统交互的其它系统的 Actor 被指明。Use case 被识别,表示系统的行为。因为use case 根据 actor 的要求开发,系统与用户之间的联系更紧密。系统展示了用于再生系统的用例模型。
样例用例模型
每一个用例被仔细地描述。用例描述显示了系统如何与 actor 交互及系统的行为.非功能性的需求在补充说明中体现。
Use case 起到贯穿整个系统的开发周期线索的作用。相同的用例模型在需求捕获阶段、分析设计阶段和测试阶段中使用。
分析设计工作流的目标是显示系统"如何"在实现阶段被"实现"的。你需要一个如下系统:
分析设计结果是一个设计模型和可选的分析模型。设计模型是源代码的抽象;即设计模型充当源代码如何被组建和编制的"蓝图"。
设计模型由设计类和一些描述组成。设计类被组织成具有良好接口的设计包和设计子系统,而描述则体现了类的对象如何协同工作实现用例的功能。
下图是上例 use-case 模型的设计模型示例的一个部分。
设计活动以体系结构设计为中心。结构的产物和验证是早期迭代的主要焦点。结构由若干结构视图来表达,这些视图捕获了主要的构架设计的决定。本质上,结构视图是整个设计的抽象和简化,该视图中细节被放在了一旁,使重要的特点体现得更加清晰。结构不仅仅是良好设计模型的承载媒介,而且在系统的开发中能提高任何被创建模型的质量。
实现阶段的目的:
系统通过完成构件而实现。Rational Unified Process 描绘了如何重用现有的组件,或实现经过良好责任定义的新构件,使系统更易于使用,提高了系统的可重用性。
构件被构造成实施子系统。子系统被表现为带有附加结构或管理信息的目录形式。例如,子系统可以被创建为文件系统中的文件夹或目录,或 Rational Apex for C++ or Ada,或 Java中的包。
测试的目的是:
Rational Unified Process 提出了迭代的方法,意味着在整个项目中进行测试,从而允许尽可能早的发现缺陷,从根本上降低了修改缺陷的成本。测试类似于三维模型,分别从可靠性、功能性、应用和系统性能来进行。流程从每个维度描述了如何经历测试生命周期的几个阶段,计划、设计、实现、执行和审核。
另外,描述了何时及如何引入测试自动化的策略。使用迭代的方法,测试自动化是非常重要的,它允许在每次迭代结束及为每个新产品进行回归测试。
发布工作流的目标是成功地生成版本,将软件分发给最终用户。它包括了范围广泛的活动。
许多情况下,还包括如下的活动
尽管发布工作流主要被集中在交付阶段,但早期阶段需要加入为创建阶段后期的发布做准备的许多活动。
Rational Unified Process 中的发布和环境工作较其它工作流包含了较少的内容。
软件项目管理是一门艺术,它平衡了互相冲突的目标,管理风险,克服各种限制来成功地发布满足投资用户和使用者需要地软件。如此少的无争议的成功项目无疑是该项任务难度的证明。
工作流主要集中在迭代开发过程的特殊方面。本节我们的目标是提供以下的事物来使该任务更简单。
它并不是成功的灵丹妙药,但提供了管理项目能显著提高软件成功发布的方法。
本工作流中,描绘了如何在多个成员组成的项目中控制大量的产出物。控制有助于避免混乱,确保不会由以下的问题而造成产品的冲突。
工作流提供了准则管理演化系统中的多个变体,跟踪给定软件创建过程中的版本。根据用户定义地版本规则建造程序或整个版本,实施特定于现场的开发策略。
工作流描述了了如何管理并行开发、分布式开发,如何自动化创建工程。这在如每天均需要频繁编译链接的重复过程中尤为重要。如果没有有力的自动化是不可能的同,时也阐述了对产品修改原因、时间、人员保持审计记录。
工作流也涵盖了变更需求管理,即如何报告缺陷,在它们的是生命周期中如何管理,及如何使用缺陷来跟踪进展和发展的倾向。
环境工作流的目的是给软件开发组织提供软件开发环境--过程和工具--软件开发团队需要它们的支持。
工作流集中在项目环境中配置过程的活动,同样着重支持项目的开发规范的活动。提供了逐步指导手册,介绍了如何在组织中实现过程。
环境工作流还包含了提供了定制流程所必须的准则、模板、工具的开发工具箱。开发工具箱在本文后续的"定制流程的开发工具箱"中更详尽的讨论。
环境工作流没有被牵涉到如选择、获取、使其运行和维护开发环境等的具体方面。
![]() ![]() |
![]()
|
Rational Unified Process -具体产品
Rational Unified Process 产品包括:
Rational Unified Process 允许使用任何流行的浏览器如:IE、Netscape Navigator 进行浏览。使用 Rational Unified Process ,你仅需少许的鼠标点击即可获得所需的信息。该知识基础包含了许多超文本链接,各种过程元素用交互的图案来表达,很容易直观的寻找相关信息。功能强大的搜索引擎、索引、"资源管理器式外观"的树状浏览使得使用该过程很容易。浏览按钮允许如同读书一般前后翻页。
信息在若干不同的视图中表现,允许你相关于角色、特定活动或工作流来查看信息。对于关键的项目角色,提供易于学习的指导过程。
交互式的图象和可导航的按钮使查找特定的信息更加方便
Rational Unified Process 足够通用及完备,如同它名字所描述的一般。然而,在某些情况下,该软件开发过程需要被修改、调整和剪裁以容纳具体的特性、约束和机构的历史情况。特别的,该过程不应该盲目的被遵循,形成许多无用的工作,产生无用产物。它应尽可能的精炼并能够快速地、可预见地产生高质量的软件。
开发过程包含了开发工具包,它包括了指导如何定制过程以满足机构或项目特定需要的指南。工具包还包括了创建过程,以及搜索引擎、索引、场所地图、树型浏览器等的衍生和操作的模板。开发工具包使得能定制组织结构维持 Rational Unified Process 的感观。
开发过程定制程度越高,则定制化向未来过程版本的移植越困难。开发工具包描述了减少定制化移植时工作的策略、工具和技术。
软件工程化过程需要工具支持系统生命期的所有活动,尤其是支持开发、维护和各种各样产物的簿记--特别是模型。迭代的开发过程对使用的工具集提出了特殊的要求,如工具的集成和模型代码之间的双向工程。同样,还需要支持跟踪需求,文档自动化以及测试自动化如促进回归测试等的工具。Rational Unified Process 可以与各种各样的工具一同使用,包括 Rational公司和其它供应商的产品。而 Rational提供许多有效支持 Rational Unified Process 良好集成的工具。
下面提供了支持 Rational Unified Process 的工具清单。
Rational Unified Process 对于大多数产品均提供了工具指引(Tool Mentors)。工具指引是详细介绍如何操作工具以实现开发过程的指南(即弹出什么样的窗口,对话框中的信息及如何漫游的工具)。工具指引允许将独立于工具的过程链接至日常工作的实际操作工具。
![]() ![]() |
![]()
|
Rational Unified Process 经过了许多年的成熟期并反映了许多人和公司的集体经验。让我们简要地看一下如下图所示它的历史:
Rational 统一过程的演进历史
从时间上回顾,Rational Unified Process 是 Rational Objectory Process(version 4)的直接继承者。Rational Unified Process 合并了数据工程、商业建模、项目管理和配置管理领域更多的东西,后者作为与 Prue Atria 的归并结果。它更紧密地集成至 Rational 软件工具集。Rational Unified Process 是"Rational Approach" 与Objectory process (version 3)的综合,在1995年 Rational 软件公司与 Objectory AB 合并之后。从它的 Objectory 前任,继承了过程结构和 use case 的中心概念。从它的 Rational 背景,得到了迭代开发和体系结构的系统阐述。该版本同样包括了Requisite,Inc 配置管理部分和从 SQA,?Inc 继承的详细测试过程。最后,该开发过程是第一个使用了统一建模语言(UML0.8)。
Objectory process 作为 Ivar Jacobson 的 Ericsson 经验于1987在瑞典被创建。该过程称为他公司 Objectory AB 的产品。由于以 use case 概念和面向对象的方法为中心,它很快得到了软件工业的认可并被许多世界级的公司集成。Objectory process 的简单版本作为课本在1992年被出版。
Rational Unified Process 是更为通用方法的一个特定的、详细的实例,该通用方法在 Ivar Jacobson,Grady Booch,和James Rumbaugh 所著的课本《The Unified Software Development Process》有介绍。