1
 软件工程
1.4.3.5 2.3.5 Rational统一过程

2.3.5 Rational统一过程

1.Rational统一过程的定义

Rational统一过程(Rational Unified Process)是Rational公司开发和维护的过程产品。Rational统一过程的开发团队同用户、合作伙伴、Rational产品小组及用户公司共同协作,确保开发过程持续地更新和提高以反映新的经验和不断演化的实践经验。

Rational统一过程是一种可配置的过程,提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下,确保满足最终用户需求的高质量产品。Rational统一过程既适用小的开发团队也适合大型开发组织。Rational统一过程建立简洁和清晰的过程结构,为开发过程家族提供通用性,并且,它可以变更以容纳不同的情况,它还能对大部分开发过程提供自动化的工具支持。这些工具被用于创建和维护软件开发过程(可视化建模、编程、测试等)的各种各样的产物,特别是模型,其中包括著名的Unified Modeling Language(UML)。

Rational统一过程强调开发和维护模型,具有语义丰富的软件系统表达,而非强调大量的文本工作。对于所有的关键开发活动,它为每个团队成员提供了使用准则、模板、工具进行访问的基础知识。而通过对相同基础知识的理解,无论是进行需求分析、设计、测试项目管理或配置管理,均能确保全体成员共享相同的知识、过程和开发软件的视图。

Rational统一过程以适合于大范围项目和机构的方式捕捉了许多现代软件开发过程的最佳实践。这些最佳实践给开发团队提供了大量经验。

2.Rational统一过程的6个最佳实践

Rational统一过程描述了如何为软件开发团队有效地部署软件开发方法。最佳实践不仅可以精确地量化它们的价值,而且它们被许多成功的机构普遍的运用。为使整个团队有效利用最佳实践,Rational统一过程为每个团队成员提供了必要准则、模板和工具指导。

1)迭代的开发产品

面对当今复杂的软件系统,使用连续的开发方法:如首先定义整个问题,设计完整的解决方案,编制软件并最终测试产品,是不可能的,而需要一种能够通过一系列细化,若干个渐进的反复过程而生成有效解决方案的迭代方法。Rational统一过程专注于处理生存周期中每个阶段最高风险的迭代开发方法,极大地减少了项目的风险。迭代方法通过可验证的方法来减少风险。

2)需求管理

Rational统一过程描述了如何提取、组织和文档化需求的功能和限制;如何跟踪和文档化折中方案和决策;如何捕获和进行商业需求交流。过程中用例和场景的使用被证明是捕获功能性需求的卓越方法,并确保由它们来驱动设计、实现和软件的测试,使最终系统更能满足最终用户的需要。它们给开发和发布系统提供了连续的和可跟踪的线索。

3)基于构件的体系结构

Rational统一过程在全力以赴开发之前,关注于早期的开发和健壮可执行体系结构的基线。它描述了如何设计灵活的、可修改的、直观便于理解的且促进有效软件重用的弹性结构。Rational统一过程支持基于构件的软件开发。构件是实现清晰功能的模块、子系统。Rational统一过程提供了使用新的及现有构件定义体系结构的系统化方法。它们被组装为良好定义的结构,或是特殊的、底层结构如Internet、CORBA和COM等工业级的重用构件。

4)可视化软件建模

开发过程显示了对软件进行可视化建模,捕获体系结构和构件的构架和行为。这允许隐藏细节和使用“图形构件块”来书写代码。可视化抽象帮助沟通软件的不同方面,观察各元素如何配合在一起,确保构件模块代码的一致性,保持设计和实现的一致性,促进明确的沟通。Rational公司创建的工业级标准Unified Modeling Language(UML)是成功的可视化软件建模的基础。

5)验证软件质量

质量应该基于可靠性、功能性、应用性和系统性,并能根据需求来进行验证。质量评估被内建于过程和所有的活动,包括全体成员使用客观的度量和标准,而不是事后型的或单独小组进行的分离活动。

6)控制软件的变更

控制软件的变更包括确定每个修改是可接受的且是能被跟踪的。开发过程描述了如何控制、跟踪和监控修改以确保成功的迭代开发。它同时指导如何通过隔离修改和控制整个软件产物(如模型、代码、文档等)的修改来为每个开发者建立安全的工作区。另外,它通过描述进行自动化集成和建立管理使小队如同单个单元来工作。

3.Rational统一过程模型

Rational统一过程将软件生命周期分解为一个个周期,每一个周期又划分为4个连续的阶段。

1)初始阶段

初始阶段的目标是为系统建立商业案例和确定项目的边界。为了达到该目标必须识别所有与系统交互的外部实体,在较高层次上定义交互的特性。初始阶段的任务还包括识别所有用例和描述一些重要的用例。其中,商业用例包括验收规范、风险评估、所需资源估计、体现主要里程碑日期的阶段计划。

本阶段具有非常重要的意义,本阶段关注的是整个项目工程中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说,初始阶段的时间可能很短。初始阶段结束是第一个重要的里程碑:生命周期目标里程碑。

2)细化阶段

细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。为了达到该目标,必须对系统具有“英里宽和英寸深”的观察。体系结构的决策必须在理解整个系统的基础上作出。

细化阶段是4个阶段中最关键的阶段。该阶段结束时,硬“工程”可以认为已结束,项目则经历最后的审判日,决定是否将项目提交给构建阶段和交付阶段。对于大多数项目,这也相当于从移动的、轻松的、灵巧的、低风险的运作过渡到高成本、高风险并带有较大惯性的运作过程,而该过程必须能容纳变化。细化阶段的活动确保了结构、需求和计划是足够稳定的,风险被充分减轻,所以可以为开发结果预先决定成本和日程安排。

在细化阶段,依靠对项目的范围、规模、风险和先进程度的评估,可执行的结构原形可以在一个或多个迭代过程中建立。其工作必须至少包括处理初始阶段中识别的关键用例,这些关键用例揭示了项目的主要技术风险。细化阶段结束是第二个重要的里程碑:生存周期的结构里程碑。此刻,检验系统目标、范围和结构的选择及主要风险的解决方案已经作出。

3)构建阶段

在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽地测试。从某种意义上说,构建阶段是重点在管理资源和控制运作以优化成本、日程、质量的生产过程。就这一点而言,管理的理念已经不是初始阶段和细化阶段的基于智力资产的开发,而过渡到到构建阶段和交付阶段发布产品管理。

许多项目规模大得足够产生许多平行的增量构建过程,这些平行的活动可以极大地促进版本发布的有效性,同时也增加了资源管理和工作流同步的复杂性。健壮的体系结构和易于理解的计划是高度关联的。这也是在细化阶段平衡体系结构和强调计划的原因。创建阶段结束是第三个重要的项目里程碑:初始功能里程碑。创建阶段结束决定了软件是否可以运作,而不会将项目暴露在高度风险下。该版本也常称为“Beta”版。

4)交付阶段

交付阶段的目的是将软件产品交付给用户群体。只要产品发布给最终用户,问题常常就会出现:要求开发新版本,纠正问题或完成被延迟的问题。当基线成熟得足够发布给最终用户时,就进入了交付阶段。在交付阶段的终点是第四个重要的项目里程碑:产品发布里程碑。此时,决定目标系统是否开始另一个周期。

Rational统一过程的每个阶段可以进一步被分解为迭代过程。迭代过程是导致可执行产品版本(内部和外部)的完整开发循环,是最终产品的一个子集,从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。迭代过程不仅减小了风险、使得对变更控制更加容易,而且还使得项目小组可以在开发中获得高效的开发经验,并使项目获得较佳的总体质量。

4.Rational统一过程的9个核心工作流

工作流是产生具有可观察结果的活动序列。Rational统一过程有9个核心工作流,代表了所有角色和活动的逻辑分组情况。核心工作流分为6个核心“工程”工作流和3个核心“支持”工作流。

1)6个核心“工程”工作流

(1)商业建模工作流。在商业建模中,使用商业用例来文档化商业过程,从而确保了组织中所有支持商业过程的人员达成共识。

(2)需求工作流。需求工作流的目标是描述系统应做“什么”,并允许开发人员和用户就该描述达成共识。

(3)分析和设计工作流。分析和设计工作流的目标是显示系统“如何”在实现阶段被“实现”的。分析设计结果是一个设计模型和可选的分析模型。设计模型是源代码的抽象。

(4)实现工作流。系统通过完成构件而实现。构件被构造成实施子系统。子系统被表现为带有附加结构或管理信息的目录形式。

(5)测试工作流。测试类似于三维模型,分别从可靠性、功能性、应用性和系统性来进行测试。流程从每个维度描述了如何经历测试生存周期的几个阶段:计划、设计、实现、执行和审核。

(6)发布工作流。发布工作流的目标是成功地生成版本,将软件发布给最终用户。

2)3个核心“支持”工作流

(1)项目管理工作流。软件项目管理平衡相互冲突的目标,用于风险管理,克服各种限制来成功地发布满足投资用户和一般用户需要的软件。

(2)配置和变更控制工作流。描述了如何管理并行开发、分布式开发,如何自动化创建工程,这在每天都需要频繁编译链接的重复过程中尤为重要,同时也阐述了对产品修改的原因,保持对时间、人员的审计记录。

(3)环境工作流。环境工作流的目的是给软件开发组织提供软件开发环境、过程和工具。