rup与敏捷开发之比较

《rup与敏捷开发之比较》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、RUP与敏捷开发之比较RUP（RationalUnifiedProcess）是由原Rational公司（现为IBM收购）推出的一种完整而且近乎完美的软件过程。RUP总结了经过多年商业化验证的6条最有效的软件开发经验，这些经验被称为“最佳实践”。分别为：迭代式开发，管理需求，使用基于构件的体系结构，可视化建模，验证软件质量，控制软件变更。在RUP中有9个核心工作流，分别为①业务建模，②需求，③分析与设计，④实现，⑤测试，⑥部署，⑦配置与变更管理，⑧项目管理，⑨环境。其中前6个为核心过程工作流程，后3个为核心支持工作流程。RU

2、P把软件生命周期划分为4个阶段：初始阶段，细化阶段，构建阶段，移交阶段。每个阶段都有明确的目标，并且定义了用来评估是否达到这些目标的里程碑，在每个阶段结束前都有一个里程碑评估该阶段的工作成果。所以RUP的计划性是很强的。事实上，RUP重复一系列组成软件生命周期的循环。每次循环都经历一个完整的生命周期，她的文档也是非常丰富的。从针对领域建模的类图（classdiagram），系统顺序图SSD（systemsequencediagram），和做需求的用例（usecase），用例图（usecasediagram），到做设计的顺序

3、图（sequencediagram），通讯图（communicationdiagram），以及描述体系结构的包图（packagediagram）,部署图（deploymentdiagram）等等。不可否认，RUP作为中大型软件的开发过程是很合适的。因而便有以下的问题，RUP对于小型软件开发是否完美呢？答案是否定的，严格的计划，复杂的文档对于小的团队简直就是噩梦。因为几乎没人愿意花大把的时间在生成文档上。所以对RUP进行适当的裁剪以适应小项目，小团队的需求变得迫切起来。于是在2001年2月，众多软件专家联合起草了敏捷开发宣言

4、。旨在使软件开发团队具有高效工作和快速响应变化的能力。个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户需求胜过合同谈判；响应变化胜过遵循计划。以上便是敏捷宣言的4个基本价值观。敏捷实际上是轻量级的软件开发方法，敏捷开发的最佳实践有极限编程(XP)SCRUM方法，DSDM方法等。敏捷开发作为一种TSP团队软件过程，她和RUP一样，非常注重了解团队每个成员的优点，缺点。发挥队员的长处，帮助队员客服弱点，互相帮助，共同成长，最终整个团队的能力得到提高。我们重点看看敏捷过程中最负盛名的一个——极限编程（XP）。由此

5、比较RUP与敏捷过程的异同。首先，项目组针对客户代表提出的“用户故事”（类似于用例，但比用例简单，通常仅描述功能需求）进行讨论，提出隐喻，在此项活动中可能需要对体系结构进行“试探”（所谓试探就是提出相关技术难点的试探性解决方案）。然后，项目组在隐喻和用户故事的基础上，根据客户设定的优先级制订交付计划（为了制订出切实可行的交付计划，可能需要对某些技术难点进行试探）。接下来开始多个迭代过程（通常，每个迭代历时1~3周），在迭代期内产生的新用户故事不在本次迭代内解决，以保证本次迭代开发过程不受干扰。开发出的新版本软件通过测试之后

6、交付客户使用。综上所述，以极限编程为杰出代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特征，而且在快速的同时任然能够保持可持续的开发速度。上述这些特点使得敏捷过程能够很好的适应商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束。由此我们可以知道，敏捷开发与RUP相比裁剪了很多内容。这些内容主要集中在每次迭代的流程。在RUP中，每个迭代都严格遵循着9个工作流。而敏捷开发则是“能用则用，能不用则不用”。即对我有用的工作，我会做，对我无用的工作，可以跳过。另外，敏捷过程中客户的位置与作用是重要的，不可替代。可

7、以说客户也是软件开发团队中的一员，更是软件的最终验收人。因为有了客户的参与，所以软件开发变得简单、清晰。在RUP中大量使用了UML建模，所以团队人员得先熟悉UML，否则除了RUP模型图之外你基本上看不懂细节内容。可是在普通企业里，大部分人（尤其是领导和管理人员）不熟悉UML。所以在敏捷过程中，我们不提倡面面俱到的文档。敏捷建模才是开发人员应该重点掌握的，所谓敏捷建模就是不依赖于专业的建模工具（如RationalRose，MicrosoftVisio），而是大量使用白板（也可以是白纸，黑板等等）画草图。而且草图也不一定完全遵

8、循UML文法，只要是方便团队成员之间的沟通和理解均可。举一实例，在我去年暑假所做的一个基于Android平台的定向运动游戏项目中，我们小组就大量使用了UML草图，直接手工画，方便快捷。一般来说，对于小型项目，硬件要求和系统复杂度都相对较低。所以很多团队都省去了配置与变更管理这项工作流，而且效果很好。在敏