RUP是用例驱动,以架构为中心,迭代式开发过程。
一、用例驱动
用例(Use Case)是一种通过用户的使用场景获得需求的技术。区别于传统的功能分解获取需求的办法,用例方法强调用户是如何使用系统的,即描述用户与系统之间的交互,而不涉及系统内部的行为。用例的一般表示法是UML用例图。
用例方法的主要特点有:
- 需求表述的抽象性。用例方法以UML用例图的形式表示,对于用例、参与者之间的关系一目了然,能更在一个高的抽象级别上理解系统。
- 需求表述的完整性。某些用户可能并不了解他会使用到系统的某个功能,但UML用例图将有助于发现这些问题。
用例驱动指的是在软件开发过程中,采用用例方法捕获及分析业务需求,并确保由它们来驱动软件的设计、实现和测试,使最终系统更能满足最终用户的需要。
二、以架构为中心
软件架构(体系结构)是构成软件各部分的组件、组件之间的交互及组件组合的约束。软件架构也关系到功能性、可用性、系统弹性、性能、可重用性、可理解性等方面。
在RUP开发的细化阶段,建立一个健壮架构的基础。在构造阶段和交付阶段,再进一步完善架构。在整个开发过程中,架构进一步完善。RUP强调以架构为中心,有利用打造一个可持续开发、可持续维护的软件;且最大限度规避了项目的技术风险。
三、迭代式开发
RUP是一个基于迭代式生命周期模型定义的软件过程。RUP分为4个阶段,即初始阶段、细化阶段、构造阶段、交付阶段。每个阶段可以有多次迭代。在每次迭代中,包含商业建模、需求、分析及设计、测试、部署等依次进行的活动(核心过程工作流),以及配置和变更管理、项目管理、环境(核心支持工作流)。
由于是迭代式开发,在后一阶段就有机会更正前一阶段的错误和疏漏。但是,这样会不会产生惰性,导致把更多问题遗留到后续的迭代中呢?RUP明确定义了各阶段的目标,必须在达到目标后,才能进入下一阶段:
- 初始阶段,目标是确定项目边界。
- 细化阶段,目标是分析业务领域以确定架构,并编制明细项目计划。
- 在构建阶段,目标是构造可运行的代码,并集成测试。
- 交付阶段的重点是确保软件对最终用户是可用的。
http://www.caixiaodong.com/archives/87.html
RUP的缺点:
RUP的优点很多。用例驱动对需求管理非常有利,能够确保需求在与用户交互时、系统实现时均不被遗漏;以架构为中心有利于打造一个强健的系统,而不会因系统规模增大而倒塌;迭代式开发有效消解了风险。那么,RUP还有什么不完美的吗?
对于我们这些行业应用软件开发者来说,RUP过于复杂。
用例驱动。用例分析作为一项软件技术,远远比功能分解复杂。大部分需求人员不具备编写用例的能力,用户多数看不懂用例。因此,在交互过程中,传统以功能列表描述为主的《需求规格说明书》应用更加广泛。
以架构为中心。对于业务逻辑非常复杂的系统,打造一个强健的架构是必须的。但对于一些业务逻辑相对简单,而用户交互逻辑复杂的系统,过于强调架构似乎没有必要。例如,对于一个有着很多模块的网站,各个模块相对独立,访问各自的表,维护一套用例图、类图、时序图就成为累赘。
迭代式开发。迭代式开发作为消解风险是非常必要的。RUP迭代中的6个核心工作流和3个核心支持工作流过于繁杂,必须为每个工作流指定其执行者。虽然RUP指出这些工作流在每次迭代中并不都是必须的,但对于一个严谨的软件过程来说,给予项目经理过多的裁剪权,也意味着为项目引入新的风险。
声明:本文转载自:http://qingfengxia2.blog.163.com/blog/static/2547840720091017105427309/