您的位置:知识库 » 软件工程

从IT方法论来谈RUP

作者: 快乐学习  来源: 博客园  发布时间: 2009-08-19 11:24  阅读: 2527 次  推荐: 0   原文链接   [收藏]  

  在《从IT方法论来谈Scrum》中我谈到了6Ways方法框架,本篇仍用6Ways方法框架来概括的谈谈RUP方法。

  软件开发过程描述了软件构造、部署和维护的一种方法。统一过程(Unified Process)是一种流行的构造面向对象系统的软件开发过程。RUP(Rational Unified Process)是对UP的详细精化,并且已经被广泛采纳。有些人可能一看到RUP提供这么多流程和工件,觉得不够敏捷,我认为RUP本身其实是一个方法框架,本身也可以采纳一些现在敏捷实践。采用什么方法重要,但采用方法后的执行更重要,对RUP来说,如果我们做得好就是敏捷,做不好就可能瀑布了。

The way of thinking

  软件开发中成功的项目比例很少,原因很多,如:没有正确的理解用户需求、没有能力处理需求的改变、模块不能集成、软件很难维护和扩展、很晚才发现重要的项目缺陷、不好的软件质量、不能接收的软件性能等。基于导致项目失败的这些原因,RUP认为下面这些最佳实践可以改善软件的开发状况:

  1. 在早期迭代中解决高风险和高价值的问题
  2. 不断的让用户参与评估、反馈和需求
  3. 在早期迭代中建立内聚的核心架构
  4. 不断地验证质量:提早、经常和实际的测试
  5. 可视化软件建模(使用UML)
  6. 仔细的管理需求
  7. 实行变更请求和配置管理

The way of working

  迭代是UP最重要的思想。RUP重要的概念之一:周期(cycles),如下图由多个周期构成一个软件开发生命周期。

  对于每个周期,下图展现了更为详细的不同阶段(Phase)和流程:

四个阶段

  1. 初始阶段(Inception):预见项目的范围、构想和业务案例 (Lifecycle Objective)
    1. 初始阶段不是一个需求阶段,而是类似与可行性阶段,项目相关人员是否就项目的构想达成基本的一致,项目是否值得继续进行认真的研究
    2. 时间不应超过一周,只需要确定这个项目是否值得认真研究,而不是真正去深入研究项目(这个工作留待细化阶段进行)如果预选就决定项目必须进行,而且项目明显是可行的,那么初始阶段会很短,可能只包含一次需求研讨会,并为第一次迭代执行计划,然后就快速的进入细化阶段
    3. 主要实践活动-用例建模
    4. 对于迭代开发的一个关键理解在于:过程中的工件在初始阶段只是部分完成,在之后的迭代中在逐步精化提炼。例如,用例模型可以列举大多数所需的用例和参与者,但其中可能只有10%的用例会被详细描述,这样就足以建立起有关系统的范围、目标和风险的高层的大致构想。
    5. 主要工件:是否意味着大量的文档?工件是可选的,只需要从下面选择对项目确实有价值的工件,放弃哪些不必要的工件,工件的关键不是文档或图表本身,而是其中蕴含的思想、分析和前期准备。
      1. 构想和业务案例:描述高层的目标和约束、业务案例,并提供一个执行摘要
      2. 用例模型:描述功能需求和相关的非功能需求
      3. 补充规范:描述其他需求
      4. 术语表:关键的领域术语
      5. 风险列表和风险管理计划:描述业务、技术、资源和进度的风险,以及如何减轻这些风险或该如何应对
      6. 原型和概念验证:阐明构想,验证技术问题。
      7. 迭代计划:描述在第一次细化迭代中该作什么
      8. 阶段计划和软件开发计划:对细化阶段的持续时间和工作量进行低精度的猜测。开发涉及的工具、人员、培训和其他资源
      9. 开发案例:描述为本项目定制的统一过程的步骤和工件。在统一过程中,总需要为项目定制一些步骤或工件
  2. 细化阶段(Elaboration):已精化的构想,核心架构的迭代实现,高风险的解决,大多数需求和范围的识别,更为现实的评估。 (Lifecycle Architecture)
    1. 细化阶段不是一个需求或设计阶段,而是一个迭代实现核心架构并降低高风险的阶段
  3. 构造阶段(Construction):迭代实现遗留下来的风险较低和比较容易的元素,准备部署 (Initial Operational Capability)
  4. 移交阶段(Transition):beta测试,部署 (Product Release)

多个流程

  1. 业务建模:在开发单独的应用时,业务建模包括领域对象建模。在从事大规模业务分析或业务过程再工程时,业务建模包括跨越整个企业的业务过程的动态建模。
  2. 需求:对应用的需求分析,如写出用例和识别非功能性需求
  3. 分析和设计:设计的所有方面,包括总体架构、对象、数据库、网络连接等。分析强调的是对问题和需求的调查研究,而不是解决方案。设计强调的是满足需求的概念上的解决方案,而不是其实现。分析和设计可以被概括为:作正确的事(分析)和正确的做事(设计)。
  4. 实现:编程和构建系统,而不是部署系统
  5. 测试
  6. 配置和变更管理
  7. 项目管理
  8. 环境:指建立工具并为项目定制过程,也就是说,设置工具和过程环境。

  1-5为核心工作流程,6-8为支持工作流程

The way of controlling

  1. 如何计划和管理迭代:需要多少迭代?每次迭代多长时间?每次迭代的目的是什么?如何跟踪每次迭代情况?
    1. The Phase Plan (Project Plan):一个粗略的计划,每个开发项目只有一份项目计划。包括了一个周期(cycle)内所有的环节(有时也可以包含多个周期)。计划包含主要里程碑的时间,要求的资源。如果能够明确分几个iteratio,则需要标识时每个小里程碑的时间和目的。

    2. The Iteration Plan:迭代计划,包含当前迭代的详细计划,包括时间、任务和资源分配,在当前迭代后半期还需要包含下一个迭代的计划
  2. 风险管理
  3. 度量

The way of modeling

RUP在不同流程中会由不同模型支持,下图为模型和流程对应图:

对于每个模型,RUP描述who在when时how做what。RUP使用五个主要元素来表达:

  • 角色: the who

  • 活动: the how

  • 工件:the what

  • 工作流: the when

  • 规程(Disciplines): 组合前面四种元素

下图为其中一个示例:

The way of supporting

Rational (现IBM)提供了对RUP的工具支持。

The way of communicating

  RUP定义了一系列流程和工件,这些工作作为各角色间沟通的主要内容,用例和架构是RUP的两个重要内容。

  1. 用例驱动开发:使用用例表达需求,对业务进行描述。用例作为整个开发流程的基础。
  2. 架构为中心流程:架构使用多个、协调一致的视图来表达系统,作为概念、构建、管理和演进系统的主要工件

其他

IBM Rational Unified Process

developerWorks 中国 RUP资源  RUP搜索

如何做一个成功的架构师——玩转RUP

Enterprise Unified Process(EUP)  一个RUP的扩展

Agile Modeling and the Rational Unified Process (RUP)  EUP 引入了许多企业级别的规程,包括操作和支持以及七个企业规程:企业业务建模、组合管理、企业架构、战略重用、人员管理、企业管理、软件流程改进。RUP 与 EUP 之间的一个基本区别在于后者处理完整的 IT 生命周期。RUP 仅处理该生命周期的软件开发部分。

Making the Unified Process Work in Practice

The Agile Unified Process (AUP)

统一过程 UP/AUP/RUP 资源

RUP presentation

书籍

The Rational Unified Process: An Introduction, Third Edition

Applying UML and Patterns:An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)

编写有效用例

UP和XP

  1. UP建议增量的编写用例和非功能性需求文档(XP不是)
  2. UP建议在迭代开始,主要编程之前绘制更多的可视化设计图(例如耗时半天或一天),XP建议用一点点时间来做可视化设计(例如30分钟)
0
0
标签:RUP

软件工程热门文章

    软件工程最新文章

      最新新闻

        热门新闻