RUP
到1980年代末，面向对象的软件设计（Object-Oriented Design，OOD）逐渐成为业界主流。
为了统一业界诸多且混乱的面向对象方法论，并且改变瀑布模型那种僵硬的开发模式，James Rumbaugh、Grady Booch和Ivar Jacobson这三位计算机大佬创建了UML（Unified Modeling Language，统一建模语言）和RUP（Rational Unified Process，Rational统一过程）这两大利器。
UML本质上就是一种图形标记方法，通过一套完整的图形符号来描述软件设计中的各种语义和元素，统一工程师们的沟通语境。
而RUP则是一种建立在UML之上的，面向对象设计的，用例驱动（Use Case Driven）的，重量级的软件开发过程。
UML和用例驱动这两个特点其实就是一个：RUP比较重视开发过程中生成的各种交付件，包括但不限于开发文档、模板、设计图、代码、接口文档、测试报告、用户手册等。
所以如果对UML非常熟悉，且能够比较熟练地画出各种UML图形（例如，用例图，类图，时序图，流程图，状态图，部署图等）的话，那么可以说RUP已经掌握了80%以上，这一点都不夸张。剩下的无非就是按照它的流程要求输出一些报告、指南等交付件。
之所以说RUP是一种重量级的开发过程，是因为下面几个原因。
在横向上，
RUP遵循瀑布流程，有业务建模、需求、分析设计、实现、测试、部署、配置和变更管理、项目管理、和环境这九大核心流程。在纵向上，
RUP分为四个大的迭代阶段：初始阶段、细化阶段、构造阶段和移交阶段。在每个阶段中，都会把上面的九大核心流程执行一遍。当然，也可以根据情况适当调整流程。RUP定义了一系列的概念，包括角色、活动和工件等，将个人、团队、业务和需求通过这些概念有机地糅合在了一起。相较之于代码，
RUP更重视各种在流程进行过程中产出的交付件，尤其是各种需求用例和软件的架构设计文档，是RUP关心的重点。
所以，RUP基本上就是为大公司或者大型软件开发团队量身定制的一套软件开发方法论，或者开发过程。
因为没有哪个小公司或初创团队会把流程和交付搞得这么复杂，这么中规中矩。
和瀑布模型一样，RUP也有自己的适用场景，例如极为重视软件质量的银行、保险、证券一类的金融行业应用，以及需要持续不断进行高质量交付的外包公司，都比较适合采用RUP开发过程。
但和瀑布模型不同的是，瀑布模型整体上偏静态，也就是需求一旦确定，修改、变更不仅麻烦，而且成本很高。但RUP本身是不断迭代的，所以它的过程更偏动态一些，即使需求一时无法确定或者后续发生了变更，也还有重新审视、更正的机会。
感谢支持
更多内容，请移步《超级个体》。