Rational Unified Process

1. Rational Unified Process 李云峰

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

3. 什么是软件过程？ • 软件过程是由一系列的项目的阶段，方法，技术和实践组成，人们利用它们来开发、维护软件和相关的产物（artifacts）。 • 在面向对象的软件过程领域，主要有三种方法：RUP、OOSP和OPEN Process。

4. 我们是否需要软件过程？ • 一个有效的软件过程将能够增加一个组织的软件生产力，因为： • 通过理解软件是怎样被开发的，你能够做出关于开发工具选择和雇用员工等方面的更聪明的决定 • 它使你的成就（包括文档，代码等）标准化，从而提升项目组间的软件的可重用性和一致性 • 它向你的组织提供了一个引进目前最好的软件惯例的一个绝佳机会，如代码审查，配置管理，变更控制， 结构化建模等 • 提高软件维护和技术支持能力。 • 首先，它定义了怎样管理软件变更，并且适当的考虑了你将来发行的软件可能带来的维护任务，从而使你的变更管理流线化（streamlining） • 第二，它定义了怎样平滑的将软件转换成operations and support, the operations and support efforts 怎样实际操作。没有有效的operations and support processes, 你的软件将在很短的时间内变得无法使用。 • 管理软件复杂性。软件正变得越来越复杂，没有一个有效的方法来开发和维护软件，则你所有的努力都会付之东流。 • 管理软件项目。大部分组织都有几个项目在同时开发，维护的项目则更多，所有的这些项目都需要被有效的管理。 • Manage e-commerce projects. 我们正在构建的软件的本质也在发生变化，从70年代的简单的批处理系统到结构化技术，到现在朝着的可交互，国际化，用户友好，7*24，高密度交易，高可用性发展，最重要的是，这些项目中的绝大部分都是面向对象的，基于组件技术的。

5. 最佳实践 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.

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

7. 最佳实践:迭代开发 • 什么是迭代开发？ • 为什么要采用迭代开发？ • 迭代方法的优点 • 适应变化 • 规避风险 • 学习式 • 不断增长的重用性 • 获得更高的质量

8. 什么是迭代开发？ • 采用迭代开发的项目的生命周期由一系列的迭代过程组成。每个迭代包含了一系列松散耦合的活动，如商业建模、需求调研、分析和设计、实现、测试和发布。不同的阶段工作的侧重点也不同： • 在初始阶段和细化阶段的迭代主要关注在项目管理、需求调研和系统设计的活动 • 在构造阶段的迭代主要集中在设计、实现和测试上 • 在交付阶段的迭代主要关注的是测试和发布

9. 为什么要采用迭代开发？ In a waterfall lifecycle, you can't verify whether you have stayed clear of a risk until late in the lifecycle

10. 为什么要采用迭代开发？ 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.

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

12. 适应需求的变化 • 需求变化或需求“膨胀”是项目失败的主要原因，后果是：推迟交付、计划失效、不满意的客户和烦躁的开发人员。 • 项目进行过程中，用户的主意会不断改变，这是人的天性，因为他们对系统的认识在不断的变化。 • 迭代开发能很好地适应这种战术上的改变，例如可以先向用户交付一个功能缩减了的产品，不但可以领先竞争对手，而且可以使用户更好地表达他们的真正的需求。同时迭代开发也能适应技术上的变化，特别是当系统平台或地层基础信息结构的变化，例如当需求分析和系统设计完成后，用户更换了操作系统或数据库，只要在构造阶段采用新的平台即可，即使修改设计，工作也很少。

13. 规避风险 • 在进行前期的迭代中，已经经历了所有的核心工作流，对工具、软件和人员技能等很多方面有了经验，可以及时发现项目计划中的风险因素。 • 迭代开发通过循序渐进的方式集成产品，而不是到最后来个大包装。最后集成所有的功能不但困难、耗时，而且难于准确地把握工作的进度。

14. 提高重用性 • 一个迭代生命周期更利于重用的实现，因为可以更早地识别出公共的部分 • 识别和开发重用部分是很困难的。在早期的迭代中进行设计复查可以使软件体系结构工程师识别出不确定的、潜在的重用，并在以后的迭代中完善和实现这些公共代码 • 可以更早地利用商业组件产品 (COTS)。可以不断地进行选择和集成 ，并验证这些产品与你的体系结构的适合程度

15. 学习式的开发过程 • 开发人员可以不断学习，在整个生命周期中能力和专长会不断地增长 • 测试人员可以更早开始测试，技术文档可以更早地撰写，等等，而不是仅仅作计划 而迟迟不启动，消磨大家的热情和能力。对额外的培训和外部帮助可以尽早地被发现。 • 过程本身可以被不断地改进和完善。在每个迭代结束后，不仅仅从产品进度的角度考察一个项目，而且还分析组织或项目组中的哪些工作需要改善，可以使下个迭代周期中的工作能更有效地进行

16. 达到更高的质量标准 • 迭代开发过程可以获得更健壮的产品体系结构，因为错误通过多次迭代被不断发现和纠正。 • 迭代开发也使产品得到了更充分的测试。核心功能会有很多机会被测试到。测试本身，以及任何测试软件也会在迭代过程中走向成熟。

17. 最佳实践：管理需求 • 什么是需求管理？ • 问题分析 • 理解客户的需要 • 定义系统 • 管理项目的范围 • 系统定义的求精 • 管理需求的变更 • 用例驱动（Use-case driven）的开发

18. 什么是需求管理 • 需求管理是发现、记录、组织和跟踪一个系统不断变化的需求的一套系统的方法。 • 我们定义需求（requirement）为： • 系统必须符合地某种条件或必须具备的某种能力 • 对需求管理的正规定义是：需求管理是一种系统的方法，以完成： • 抽取、组织和文档化系统的需求 • 建立和维持客户和项目组对系统需求变化认识的一致性 • 实现有效的需求管理的关键因素包括需求的清晰的陈述、适宜的属性和对其它需求及其它项目资料关联性的可跟踪性。

19. 什么是需求管理 • 收集需求会遇到的困难： • 需求不总是显而易见的，可能来自很多渠道 • 需求有时很难用文字表达的很清楚 • 在不同的细节上会有很多不同类型的需求 • 如果不加控制，需求的数量会变得不可管理 • 需求经常互相关联，也会和其它软件工程过程的交付项相关 • 需求有唯一的性质或属性，例如它们的重要性各不相同，实现的难易程度各不相同 • 需求有时被功能交叉的多组人管理着 • 需求变更

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

21. 问题分析 • 问题分析的主要任务是理解问题、初始化客户的需求，提出高层次的解决方案。 • “找到问题背后的问题” • 在问题提分析过程中，要对真实的问题达成一致，要定义从业务角度看系统的边界和业务约束。同时要明确所构造的系统可给用户带来什么回报。

22. 理解用户的需要 • 需求可能来自很多方面，例如客户、合作伙伴、最终用户和领域专家等。你必须知道如何最好地确定需求的来源和如何从这些来源获取需求，同时还要进行正确的取舍 • 需求信息的主要提供者我们称之为项目的客户（风险承担人 stakeholders） • 可以使用的技术手段包括访问、头脑风暴、概念原型、询问和竞争分析等。 • 分析出的需求要使用文字或图形进行清晰的表达，并设置需求的优先级。

23. 定义系统 • 定义系统指将对客户需求的理解翻译和组织成对要构建的系统更有意义描述。 • 在系统定义的前期,要确定需求文档的格式、语言形式、需求规范的深度和粒度、需求的优先级和所需的工作量、技术和管理上的风险和初始范围；还可能包括早期的原型系统和与最重要的需求相关的设计模型 • 系统定义的输出应是用自然语言和图形两者对系统的描述

24. 管理项目的范围 • 为了有效地运转一个项目，你必须仔细地衡量需求的优先级别，并控制它们的规模 • 很多项目都受害于项目开发人员将工作集中在所谓的“复活节彩蛋”（即开发者认为有趣且富有挑战性）的工作上，而不是将精力集中在那些可以降低风险或使系统体系结构更稳定的工作上。 • 为了确保能够尽早地解决或降低项目风险，你应该采用增量开发的方法，在每次增加过程中仔细地选择需求。为此，你需要和客户针对每次迭代的项目的范围进行协商。

25. 对系统定义进行细化求精 • 系统的详细定义需要使客户能够理解、同意并在上面签字，它不仅需要覆盖功能性需求，而且要符合法律或规范的要求，以及可用性和可靠性、性能、支持和维护等方面的要求。 • 一个易犯的错误是认为实现复杂的东西需要复杂的定义。这导致解释项目和系统目的的困难。人们可以被强制，但是它们不会提供好的输入，以为他们不理解。 • 对文档的观众的理解必须给与特殊的关注。通常，对不同的观众需要有不同类型的描述 • use-case方法，经常伴由简单的可视原型，是对系统详细定义进行沟通的一种非常有效的方法。Use cases告诉了用户系统是被如何使用的。 • 系统详细定义的另一个 组成部分是系统的测试计划

26. 管理需求的变更 • 不管你多小心地定义需求，需求总是会发生变化的。需求变化难于管理的原因不仅在于，一个变化的需求或多或少都需要花费一定的时间来实现一个特殊的新功能，而且一个需求的变化可能会影响其他的需求。 • 你需要保证你给出的需求具有适应变更的弹性结构，并且使用跟踪连接表示需求之间，需求和项目生命周期中其它文档的依赖关系。 • 管理需求变更地活动包括建立一个基线（baseline）、确定哪些依赖关系是重要的，必须被跟踪的，建立相关内容的可跟踪性，以及变更控制

27. Use Case驱动的开发 • Use cases不是一个简单的需求列表，而是向用户描述了系统如何使用的场景。这提供了更好的完整性和一致性，并且使你从用户角度出发对需求的重要性有了更深入的理解 • “use-case驱动方法”是指use cases是整个开发过程的基础

28. Use Case驱动的开发 • Use cases在几个核心工作流程中都扮演着重要的角色： • use cases的概念可以被用来表述在商业建模工作流中定义的商业过程，这一变例称为"business use case". • use-case模型是需求分析工作流的结果 • 在分析和设计中，use-cases在设计模型中被实现。 • 在设计模型的实现中，因为use cases是设计模型的基础，因此它们根据设计类被实现 • 在测试中，use cases仍是识别测试用例和测试过程的基础 • 在项目管理工作流中，use cases被用作对迭代开发进行计划的基础 • 在发布工作流中，Use cases构成了用户手册内容的基础 ，也可以用来定义产品的定购单元，例如用户可以从use cases中选择一些构成自己的配置

29. 最佳实践：使用组件体系结构 Component-based architecture with layers.

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

31. 什么是组件体系结构？ • 组件具有良好定义的接口和行为 • 组件对内部的内容进行了封装 • 组件是可重用、可替换的 • 以组件技术为基础的体系结构努力降低系统的规模和复杂度，因此更强壮，更富有弹性

32. 体系结构要点 • Use cases驱动着RUP整个生命周期内的各项活动，但是设计活动是围绕系统体系结构进行的，对软件为主的项目，更具体的是以软件体系结构为中心的。 • 在早期的迭代过程中——主要是在细化阶段——主要的工作就是要形成并验证软件体系结构，它在初始的开发循环中是以可执行的体系结构原型方式出现的，并在以后的迭代中演化为最终系统。 • 建立可执行的体系结构原型是指部分地实现系统，以验证所选择的系统功能和属性，尤其是非功能性需求。构造它是为了降低与性能、吞吐量、容量、可靠性和其它性质有关的风险，以使完整的系统功能可以在构造阶段在一个坚实的基础上去实现。

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

34. 体系结构要点 • 体系结构之所以重要，是因为： • 体系结构是你获得和保持对项目的控制，以管理项目的复杂度和保持系统的整体性。一个复杂系统不是各部分的简单相加，更不是一系列互不相关的小的技术决策的累积；它必须通过某种统一的、一致的结构使这些部分系统地组织起来，它必须提供系统如何增长的精确的规则，以避免系统的复杂度膨胀到人们难以理解的地步。体系结构通过建立一个公共的参考集合、一套公共的词汇提供了贯穿整个项目的沟通和理解的手段 • 体系结构是大规模重用的一个有效的基础。通过主要组件和关键接口的清晰表述，体系结构可以获得重用——包括接口重用和外部重用。而且，它还可以获得在更高层次的重用：在一个产品线中重用体系结构自身来处理在一个公共领域中的不同问题。 • 体系结构提供了项目管理的基础。计划和人员可以沿着主要组成成分进行组织。基础的结构性决定是由一个小的、紧密耦合的体系结构小组组成的。开发被划分成一系列的小组，每个小组负责系统的一个或几个部分。

35. 基于组件的开发(CBD) • 一个软件组件可以被定义为软件的非平凡片断、一个模块、一个包或一个子系统，组件都有一个清晰的功能、有一个明确的边界并能够被集成到一个良好定义的体系结构中。它是设计中的某个抽象概念的物理实现。 • 组件来自不同的场合： • 在定义一个非常模块化的体系结构中，你识别、分隔、设计、开发和测试良好格式（ well-formed）的组件。这些组件可以被独立地测试和逐渐地被集成以构成整个系统。 • 进一步，其中的一些组件可以被重用，特别是能够解决一定范围内的公共问题的组件。这些可重用组件构成了企业内部重用机制的基础，可以不断提高软件开发的生产率和质量。 • 最近，组件基础结构，例如CORBA、Internet、ActiveX和JavaBeans等的商业成功引发了各种领域商业组件开发的热潮，使你可以直接购买各种功能的组件并集成到你的系统中，而不必从头开发。

36. 基于组件的开发(CBD) • 模块化和封装的思想将面向对象技术引入了软件开发。而另一个变化正在发生，软件开发从一行一行地编码变成了通过组装组件来集成系统。 • RUP通过以下手段支持基于组件的软件开发： • 迭代开发的方法允许你渐进地识别组件，决定哪些组件应被开发，哪些要重用，哪些要购买。 • 对软件体系结构的关注使你能有力地表达结构——组件和它们的集成方式——包括基本机制和模式等 • 包、子系统和层等概念在分析设计过程可以用来组织组件和定义接口 • 测试首先围绕组件进行，然后再逐渐集成新的组件，构成更大的系统进行测试

37. 最佳实践：可视化建模（UML) Visual modeling raises the level of abstraction

38. 最佳实践：可视化建模（UML) • 什么是可视化建模？ • 我们为什么要建模？

39. 什么是可视化建模？ • 可视化建模就是使用语义丰富、图形和文本形式的符号系统进行软件设计。 • 一个符号系统，如UML，可以使抽象的层次被提升，而同时保持了语法和语义的严谨性通过这种方式，可以促进开发团队的沟通、 使读者能够理解设计，并为实现提供无二义性的设计基础

40. 我们为什么要建模？ • 一个模型是一个系统的简化的视图，它从一个特殊的角度展示了系统的必要的元素，隐藏了那些非必要的细节信息。 • 模型可以用来帮助完成： • 加深对复杂系统的理解 • 以较低的成本探索和比较不同的设计方案 • 构成实现的基础 • 准确地捕获需求 • 无二义性地传达设计决策

41. 加深对复杂系统的理解 • 模型的重要性随着系统复杂度的增加而增加。例如，一个小应用程序的构造可以由一个人根据他大脑中的构思在几天之内完成，但是一个有成千上万行代码的电子商务系统 或者交通控制系统，一个人可能永远也完成不了。构造模型可以使开发人员将精力集中在更宏观的层面上，理解组件的交互和发现设计中致命的缺陷。例如： • Use Cases图可以无二义性地描述行为 • 类图和数据模型图可以准确地描述设计 • 状态转换图可以描述系统的动态行为 • 建模之所以重要，是因为模型能够帮助开发团队用可视化的方法描述和记录系统的行为和结构，却不会在复杂性中迷失方向。

42. 低成本探索和比较不同的设计方案 • 简单的模型可以被创建和修改来对不同的设计方案进行比较和筛选，这种成本相对是低廉的。 • 在代价高昂的编码工作开始之前，创造性的想法可以被捕捉到，并由其他开发人员对其进行复查 • 当与迭代开发相结合时，可视化模型帮助开发人员了解设计的变更和在整个开发团队中，对这些变更进行充分的沟通

43. 构成实现的基础 • 今天许多项目都采用面向对象程序语言来获得重用性、对设计变更的适应性和系统的稳定性。 为了获得这些收益，在设计中使用对象技术甚至更重要。RUP产生一个面向对象的设计模型，它是实现的基础。 • 通过适当工具的辅助，一个设计模型可以用来产生实现的一个初始代码集合，这称为正向工程(forward engineering)或代码生成(code generation)。设计模型还可以被增强，通过包含进足够的信息直接构造系统。 • 逆向工程（Reverse engineering）可以被用来从已经存在的实现中产生设计模型。这可以用来评估已经实现的系统。 • 双向工程（Round trip engineering）同时包含正向和逆向技术来保证设计和实现的一致性。与迭代过程和恰当的工具结合，双向工程可以使在每个迭代中的设计和代码保持同步。

44. 准确地捕捉需求 • 在构造一个系统之前，捕捉需求是至关重要的。使用无二义性的模型规范需求保证了所有项目的风险承担人（stakeholders）可以理解需求，并就需求达成一致的意见。 • 模型将系统的外部行为从实现中分离出去使你可以集中精力研究系统的使用，而不会受实现细节的干扰

45. 无二义性地传达设计决策 • RUP使用UML，UML是一种用来描述系统工程和商业工程的符号系统。一个标准的符号系统扮演着如下的角色 (see [BOO95])： • 它是一种用来对那些不明显的或不能从代码中直接推断出的设计决策进行沟通的语言 • 它提供的语义必须足够的丰富，以能表达所有重要的策略和技术决策 • 它提供一种很具体的形式，使人们能够用它进行推理，并且使工具能够管理 • UML代表了整个对象技术产业的软件建模趋势

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

47. 最佳实践：验证质量 • 在整个生命周期内的质量验证是什么含义？ • 质量是什么？ • 简介 • 质量的定义 • 谁对质量负责？ • 关于质量的常见的错误概念 • 在RUP中进行质量管理

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

49. 质量是什么？——简介 • 质量是我们在所有的产品、流程和服务中所追求的东西。但是，“质量是什么呢？”，每个人会有不同的观点。通常的回答包括： • “质量……我不知道怎样确切描述它，但是当我遇到质量的问题时，我会知道的” • “……满足需求” • 或许针对软件的关于质量的最常见的引述是关于它不被满足时的评论： • “他们怎么能发行这么低质量的东西？” • 这些回答反映了一些问题，但是它们并没有对如何严格地进行质量检查和提高产品质量给出标准。 • 质量不是一个单一的特征或属性。它是可以被一个产品或一个过程所拥有的多维特征。产品质量关注于构造正确的产品，而过程质量关注正确地构造产品。

50. 质量的定义 • 质量的定义在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中，质量被定义为： • 满足下列识别条件的特征： • 满足或超过达成一致的需求集 • 使用达成一致的测量方法和判据进行评估 • 使用达成一致的过程产生 • 达到质量要求不简单是“满足需求”或者产生出满足用户要求和期望的产品。质量还包括证明达到质量要求的测量方法和判断标准，以及实现一个过程来保证产品是通过这一过程产生的，从而能够达到一定的质量，这一过程是可重复和可管理的。