UP可以用下面的话来概括—— 用例驱动、以构架为中心、迭代和增量的开发过程。
acobson在《Object-Oriented Software Engineering : A Use Case Drivern Approach》中给的定义是这样的：当希望改变系统的行为时，重建相对应的参与者和用例模型。整个系统的基础构架将有用户所希望使用系统行为进行的操作来控制。由于控制了所有模型，因此可以根据新需求修改系统。我们向用户询问他们希望改动的地方，也就是用例，并直接找出这些改变在其他模型的什么部分实现。
用例被用来驱动你开发过程中的各种实践，你的需求、设计、测试、部署都是需要在用例中去寻找理由的。
以构架为中心，就是要你使用构架的方法，采取组件化的方式进行建造你的系统。
在RUP中的构架，是一种设计的基线。建造这样的基线采取的策略是，从用例出发，寻找那些稳定的，业务意义重大的，技术风险可以在早期解决的部分，构建一个可以运行的程序。以后的开发，尽量使用以存在的组件。这一点同敏捷的做法是不相同的，其优势和弱势都存在。
而增量和迭代，就是要求在构建构架的基础上，添加新的部分，按照周期性提交最终结果的方式进行开发。UP的建议迭代周期是2周到6周，同时各个阶段的周期可以不同。
在UP中过程被划分为4个阶段，起始阶段、细化阶段、构造阶段、移交阶段。
起始阶段在理想的状况下是短暂的，可能只需要几天，以至于都不存在迭代。这个阶段的工作主要是需求工程的短小片断，去选择10%的需求(最要业务价值和技术价值，风险最高最应该早期解决)的TOP10高级需求list，项目的最初视图，商业用例的草图。
如果这个时期过长，那么往往是需求规格说明和计划过度的表现。
细化阶段，在我看来可能是UP中最关键的。核心的、具有构架意义的元素，将在一系列短小的timebox下的迭代内被编程和测试。并且这个阶段最后，可能会完成一个部分可靠的计划和评估。这个阶段的工作包括了需求和设计建模，同时也有编程和测试。在这个阶段需求通过迭代被不断的精华，并且最终达到大部分的稳定。同时开发一个系统的核心——构架，并使之达到稳定，也是这个阶段的目标。这个阶段是创造和发现的阶段，理想状况下需要的是一个小型的、精诚合作的高素质团队进行。由于这个阶段不可知因素和新的需求将被不断提出，迭代的周期往往比较长(例如3周)。同时这个阶段在整个开发过程中往往是和构造阶段的比例是3：10。
构造阶段是构建系统的主要阶段。这时需要在细化阶段已经建立起来的牢固基础上，去建造其他未完成部分。在这个阶段需求还可以变化，但是大的风险和意外应该已经在细化阶段被发现了。这个阶段的主要工作是编程，还包括测试(α)，文档的建立(比如用户使用文档)、性能优化。当然还会存在一些少量的需求和设计工作。这个阶段一般是由更多，更大的组进行并行的开发。这个阶段的迭代周期由于已经定义了大部分的风险和意外，迭代周期往往会比较短(一般在1-2周)。
移交阶段是系统的最终部署阶段。首先你需要发布一些release版本进行审核和反馈。往往在这个阶段的前期往往就已经冻结了代码，而只进行除错。可能还需要几个迭代周期，最后就是部署上线的工作。这个阶段往往还包括渠道的发行，培训，新旧系统的并行运转，数据的转换。往往会由专门的团队负责这个阶段的主要工作。
这四个阶段之间有里程碑需要被标示出来。起始阶段的里程碑是定义好软件的框架目标，也就是系统的视图和商业用例，最重要的是定义好高级需求列表。一般这个周期的里程碑被称为LCO(life cycle objectives)。细化阶段的完成以构建出一个构架为里程碑，一般称为LCA(life cycle architecture)。构建阶段的历程碑就是完成这个系统的全部。移交阶段就是完成这个系统的部署以完成合同。
UP定义了一组大概50个的工件集。这些工件都是按照其特有的工作流，在特有的角色的操作下建立的。这些工件是按照项目的具体要求进行专门的选择的，这也就是裁减。裁减的原则是less is better，这样才可以做到资源更加集中，成本更加集中和低廉。
对于UP的实施建议是(《the RUP made easy》)：
1、尽早而持续的排除风险，否则将给你带来麻烦。
2、交付给你客户有价值的东西——尽早并且经常性的交付。
3、在早期的迭代中重点在开发可执行的软件，而不是规格说明或者其他文档。
4、尽早适应项目变化。通过早期开发，多种需求工序，变更管理工具等等手段，激发变化和管理变化。
5、尽早建立可执行的构架基线。
6、最好使用面向组件开发，尽量重用现有组件。
7、以团队协作方式进行工作。例如使用交叉功能的团队。
8、质量在某种意义上是生命，不应该在出现质量问题时再追悔莫及。
UP有六个最佳实践：
1、timebox的迭代。
2、早期建立高风险、高价值的内聚构架。尽量使用现有组件。
3、持续性的验证质量。
4、可视化建模。
5、管理需求。
6、管理变化。
最多的错误理解：
1、没有使用迭代开发。
2、将起始阶段理解为需求阶段，也就是建立需求分析和详细说明。
将细化阶段理解为设计阶段，建立更详细的需求分析，建模和设计。
将构造阶段理解为编码。
将移交阶段理解为测试。
也就是拿UP的四个阶段类比为瀑布的四个阶段。
典型的做法是，在编码之前试图做绝大部分需求分析和设计，将项目的主要测试和评估放到项目的最后。
其他的错误方式还有：
迭代周期过长;迭代周期不在timebox内;迭代没有以被集成和被测试的基线结束;每次迭代都以产品发布作为结束(提交而非发布);细化阶段的目标是提交一个用之即抛弃的原型为目标(应该是起始阶段使用原型);开发案例太复杂，使用太多的工件;使用预见性的计划;开发小组制作许多模型和UML图，并且必须使用一个CASE工具;需要大量工具;在细化阶段完成之前旧完成构架文档;不使用官方的工件名称和阶段名称(up的目标在于建立一个跨项目的通用体系)。
RUP是UP的一个精华的商业过程，原则上在你没有授权的情况下不能叫做RUP，一般情况下你还需要使用Rational的产品支持你的过程(当然这是可选的)。UP是一个通用性的方法框架，实际上它和许多其他方法可以结合使用。当然极端状态下你也可以看到和瀑布方法结合使用，虽然这样做是违背up的基本理念的。同时up的过程需要按照不同的项目进行针对性的裁减，而由于up自身的工件和工作流的众多，裁减并不是一件容易的事情，特别是在不遵守less is better的原则的时候。up构架的定义同软件工程上的定义是有区别的。UP的思想更加类似敏捷而不是CMM。同时我们必须知道UP的顾问不等于迭代开发的顾问，或者说UP的实施者可能不是在实施迭代增量开发，这是目前UP实施失败的最多原因。同时我们必须看到很多关于UP和RUP的介绍文章和书籍是建立在对于UP的错误解释的基础上的。
写了这么多，我最希望大家注意的是——现在有许多对于UP不正确的说法在流传。最主要的就是使用一些瀑布的思想去解释UP。并且我们必须认识是使用UML不等于你就是在使用up。如果你不能把你的方法更加简单，你也就做不到更加控制，也就是做不到UP的最初动机。在你实施UP的时候，必须从所谓的传统软件工程的种种思维方式中解放出来。
UP其实是一种内核很小的方法论，实际上最简单的方式下你只需要选择两种工件就可以实施up，比如你选择远景视图和风险列表。
UP的价值观同敏捷的价值观是不同的，强调的是以项目为导向，而不是以人为导向，同时也同以过程为导向的CMM体系有所不同。其核心价值观在于：
1、使用UP指南和最佳实践是非常重要的，其他一些手段是可以从它们中推导出来的、
2、强调风险和价值的驱动。
3、为项目定义一个清晰的远景是非常重要的，这个远景总结了项目相关人员的需求。
4、以最佳实践为核心进行裁减UP，以此得到一个最小的方法过程集。
5、一个经过良好定义的过程是有用的。这个过程为项目中的人们的活动提供了指南性的帮助。
实际上历来就存在两种不同的UP——笨拙的和敏捷的。其分歧往往就是UP价值观最后的一条。
UP的建造者是一群有经验的工程人员，他们本身并不想建立一种笨拙的方法，他们更加赞同敏捷的UP。
作为那些新手，当然遵守UP的详细轨道是有益的。这会加强他们对于开发过程的学习了理解，并且有利于建立一个检查列表。高一级的人员则应该更加考虑如果建立有质量的工件，而不是优先考虑如何按照规定去工作。更高级的人员考虑问题应该从复用的角度去考虑问题，也就是优先的考虑建造可复用的工件。
而复用和可预见往往被一些人认为是必然联系在一起的，这一点同敏捷的适应性而非预见性又矛盾。实际上复用由两种方式，一种是提纯(也就是发现设计模式那样的工作)，一种是提前设计(也就是使用设计模式那样的工作)。这两种态度我想应该以提纯为主，设计为辅。
UP强调建立一个通用的词汇表，这会有利于项目和组织间的交流。当然这一点是被有些人所反对的，因为他们希望项目能绑定在某些特殊的组织中。
实际上过程究竟是一个定义的规定性过程，还是一个经验性的过程，是一个不同协调的和平衡的问题。它会由使用者的能力的增加愈来愈偏向经验性。但是你并不能就因此认为一群没有经验的开发者就必须遵守一个严格的规定性过程，实际上最初的过程一样需要他们按照经验去裁减以适合他们的能力。
文章来源于领测软件测试网 https://www.ltesting.net/
