RUP开发实践

 原文的讨论在：

http://www.javaeye.com/topic/13647

整理以后转载在这里。

 

要说RUP，就要先说UP。
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强调建立一个通用的词汇表，这会有利于项目和组织间的交流。当然这一点是被有些人所反对的，因为他们希望项目能绑定在某些特殊的组织中。
实际上过程究竟是一个定义的规定性过程，还是一个经验性的过程，是一个不同协调的和平衡的问题。它会由使用者的能力的增加愈来愈偏向经验性。但是你并不能就因此认为一群没有经验的开发者就必须遵守一个严格的规定性过程，实际上最初的过程一样需要他们按照经验去裁减以适合他们的能力。

 

 

RUP用迭代来化解风险，用迭代来达到对软件质量的持续验证，因为每次迭代都包含测试。迭代周期分是根据所解决的风险来划分的，RUP建议我们在迭代开始前列出一个风险列表，按照风险的严重程度排序，然后决定在哪次迭代要解决什么风险。同时RUP的四大阶段也是和风险紧密关联的。
初始阶段：解决需求和商业上的风险，会产出架构文档，原型等。
细化阶段：解决架构上的风险，这个阶段的迭代周期一般不能超过2周，因为小的迭代才便于及时修改架构。
构造阶段：解决代码和运行上的风险，构造出一个可运行的软件。
移交阶段：解决发布的风险，将软件正式交付。
RUP的剪裁很重要，可以说RUP必须剪裁，通过剪裁，获得项目需要的role，work flow， activity， artifact，然后按照RUP产品（是一个基于htm和applet的文档性质的软件）的指引，在合适的时间，由合适的role进行合适的activity，产出合适的artifact，这就是RUP的指导作用。为什么我在前面的帖子里说xp不是一个完善的过程？因为xp没有一个指导性产品。我认为在现阶段，RUP比XP更适合国内的软件开发。
RUP是敏捷的，既然你推崇敏捷，为什么不试试RUP呢？：）

 

 

比较UP同XP最大的差别或许在于：
UP在精化阶段需要一个稳定的构架；
XP倾向于不断的重构得到最终的构架。
所以说XP更适合于具备优秀人员的团队，更多的强调个人主动性；
而UP更适合于大多数普通项目。

 

 

1、CMM重视过程、XP重视个人、RUP重视项目
2、CMM文档驱动、XP测试驱动(?)、RUP用例驱动
3、CMM要求准确设计、XP通过重构来设计、RUP要求核心设计
4、CMM认为人可以替换、XP认为人很重要，难以替换、RUP在中间
5、CMM不重视剪裁和重构(?)、XP缺乏重构指南、RUP缺乏剪裁指南

 

RUP的裁减很重要，然而RUP的裁减是一件困难的工作。
由于UP本身的复杂性，造成其需要在又充分的经验下才能被把握。而既便有充分的经验，你依然需要对组织有深刻的了解。同时由于对于没有经验的组织，能力会相对的低，引入的工件和流程必须保证在一个合理的范围内，采用less is better的原则来进行。而如何判断less，是一件不那么容易的事情，你往往会使用了过多的工件和流程。而如果你使用逐步添加工件和流程的策略，往往又会造成工件和工作流实施不协调的问题。
关于这一点，我当面和Ivar进行过讨论。他批驳了我关于UP其实是一种简单的方法，裁减起来也是简单的工作的观点。我想他是这个方面的专家，我就收回了我的观点。

那么对于UP和XP，你应该如何选择呢？
首先你要看你能找到的合适的过程指导者的偏好，他喜欢的就是你选择的。
其次你要看你组织的偏好，组织偏好的就是你选择的。
其次你要看你希望付出的成本结构，UP的初期成本付出一般情况下是比XP高的。
最后还有一个组织文化的问题和技术风格的问题，UP强调的构架开发，和XP强调的协作精神，不是每一个组织都能满足的。

我们可以假设在一个基本上没有任何能力的初级组织，在没有任何方法癖好的的情况下，应该去选择XP和UP中的谁来完成这个项目呢？
这种情况下我会选择实施XP，因为XP的过程更加有强制性，同时在实施XP之中也更加能够提供增加能力的机会。而且由于XP不强调早期就构建一个构架，因此对于能力的要求要比UP更低。而XP的TDD则更加能够保证设计和需求的精华。
那么是不是XP就比UP优秀，或者说XP的使用者就没有必要去学习UP了呢？
当然对于后出现的XP比UP更加具有优秀的元素是应该了，而UP由于被众多的不合格的实施者的推动下包含了太多的违背UP初衷的成分。
不过XP应该可以和UP能很好的合作，特别是XP是一个方法的系列，而不是一个过程。当项目和组织的能力发展之后，需要在过程上进行一些投入，这个时候使用UP就是一种选择，或者最少可以成为一种指导性的策略。
对于UP来说，最重要的部分在于构架的完成。这个方面是需要很强的能力的，或者说你的组织中至少要有一个绝对的专家级别的。这一点在国内大多数组织内都是难以做到的。而XP所提倡的系统隐喻的做法，则可以为培养构架专家提供一个良好的途径。也就是说当人们已经有足够的能力快速适应变化的时候，往往人们会选择去预测变化。实际上这样的预测完全是站在经验上的一种技术直觉，而不是传统意义上的未来预测。
谈论XP和UP谁更应该被实施多数情况下是一种无聊的口水战。而且往往由于UP的支持者自身对于UP的把握就很成问题，造成其对于UP的理解有非常多的偏差。因此就产生了众多的UP的不同说法。这样的情况是UP目前最大的问题。
而XP遇到的最大问题在于其还处于高度的发展时期，如果你是一个跟随者，将很难看到最前面的人究竟在什么地方。

 

我提供两个素材。第一，Ivar Jacobson 2002年接受我采访，评价XP说它没有积累知识的环节，这是RUP具备的。第二，Martin Fowler周六聊天，说XP不负责积累知识，知识存在于开发者那里。

 

 

rup对团队领导人的要求是非常全面的
rup的团队和《人月神话》里面讲的外科手术团队有点类似
我觉得在rup的团队中，最让人头痛的是团队领导人很难有效的控制团队的成员，
从而使得团队成员保持在整体的框架路线上。
xp对于人员的平均水平要求要高一些，但是对核心人员的要求比rup要低一些。