UP还是敏捷方法?

原创 2007年09月20日 21:04:00
 

  目前UP或RUP软件开发过程已经被很多企业所采用,敏捷方法也逐渐被很多公司使用,究竟是采用UP(RUP)还是敏捷方法呢?哪个更有效呢?

 

  最有效的方法其实是根据企业自身的实际情况,来综合采用这两种方法,选择最适合你的最佳实践。

 

  所谓最佳实践,是指人们在多年的实践过程中总结出来的最佳的开发软件的一些方法。

 

  RUP中的最佳实践有:迭代式的开发、管理需求、使用构件架构、可视化建模、检验质量、控制变更,和使用Rational工具等。

 

  敏捷方法以XP为例:

  四大价值有:沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇气(Courage)。

  五个原则:提供快速反馈、简单假设、制造增量式的变化、包容变化、质保工作。

  十二个实践原则:计划的制定、小版本、简单设计、测试、持续整合、重构、配对编程、代码共享、每周只工作40小时、现场客户、隐喻、编码标准。

 

  从文字上看两种方法中一致的有:迭代式开发、质量保证工作(检验质量,质保工作)。

 

  下面就来分析一下这些最佳实践。

 

1.      可视化建模

  XP虽然没有明确指出,需要进行可视化建模,但在实施过程中,编码之前,一般会在纸上划出要实现部分的草图,而且也使用UML,尽管是简单设计,但无论简单设计与否,这实际上就是在进行可视化建模。所以,在这点上与RUP是一致的。

 

2.      使用构件架构

  RUP提倡利用构件提高可重用性。

  XP提倡重构、配对编程,这实际上是利用这些手段来提高代码的质量,而提高可重用性,进行可重用的构件的设计,实际上是最主要的工作,包括设计模式的使用等等。

  所以,在这一点上,两种方法的观点是一致的。

 

3.      控制变更

  变更控制工具在软件开发企业中已经广泛使用,这一点不存在争议。尽管XP没有把它明确提出来。

 

4.      管理需求

  XP没有管理需求的说法,但事实上对于关乎软件项目的全局的重要的功能需求,和非功能需求,是一定需要控制的,否则,如果项目进行到一半,然后推倒重来,即便是神仙恐怕也没办法让项目成功;至于对全局影响不大的变化,自然可以灵活处理,拥抱也好,放到下一个版本发布都是可行的。

  所以,在这一点上两种方法也并不矛盾。

 

5.      CASE工具的使用

  RUP当然想让你是用他们RATIONAL的工具了。

  XP拥护者中有人认为用纸和笔是最好的方法,但是如果用CASE工具可以提高效率的话,为什么要拒绝使用呢?

  建议根据企业中员工都习惯的方式来决定是否使用,以及使用什么工具。

 

6.      简单设计

  这恐怕是争议较多的一点,RUP提倡先进行系统分析,设计,然后再进行编码;XP则觉得只要画张草图,就可以编码了,之后就重构,拥抱变化吧。

 

  其实我们要根据项目的复杂情况来决定设计工作要进行的程度。如果项目很复杂,一张草图恐怕真的没有办法阐述清楚,也没有办法成为涉众之间进行交流的工作产品。这样就必须对这个复杂的问题进行抽象,提取,简化复杂程度,直到简化到可以被人们容易理解,这个过程就是系统分析设计。

 

  对于简单问题自然不需要进行详细的分析设计。

 

7.      重构

  重构是提高代码质量的有效手段,因为迫于进度压力等原因,通常一次就写出优秀的代码确实不太可能,因此,重构可以发挥很好的促进作用。

  RUP中的代码审查,走查等手段从检验的角度来进行代码质量保证,当然这都是事后的手段,如果代码质量不合格,自然需要修改,这可以算作一种促进重构的推动力。

 

8.      配对编程

  两个人的智慧胜一人,在这一条上得到了充分的体现,但对人员素质要求还是较高的,如果人员素质参差不齐,可能就变成一个人指导另一个人,或者两个人没办法达成一致意见。

  所以,通过代码审查,走查等手段同样可以起到对代码质量进行监督,检验的目的。

 

9.      测试

  XP中提倡的测试先行,的确可以在没有良好的设计模型的情况下,起到一个明确思路的作用。但如果有设计模型,在功能和接口都已经明确设计好了的情况下,测试先行或后行区别可能并不大,但一定要有测试程序,这有利于进行回归测试。

 

10.   持续整合

  持续整合是检验工作成果的有效手段,在不影响正常工作进度的情况下,整合工作做得越早越好,这样可以及时发现整合过程中的问题。

 

11.   小版本发布

  RUP也提倡每个迭代周期发布一个可以运行的版本,当然这个迭代周期是多长时间,可以根据项目的具体情况来决定。

 

  总之,要灵活使用这些最佳实践,任何方法都不是简单的教条,一定要具体问题具体分析,这样才能保证软件项目的成功。

相关文章推荐

迭代,敏捷开发和UP

  什么是软件开发中的迭代开发?  就是开发被组织成一系列固定的短期小项目,称为迭代,每次迭代都产生,经过测试、集成并可执行的局部系统。系统在迭代中持续扩展和精化,并以循环反馈和调整为核心驱动力,最终...

数据库设计中的敏捷方法

  • 2009年03月27日 17:00
  • 46KB
  • 下载

敏捷方法与经典软工的较量

  • 2009年04月04日 10:13
  • 134KB
  • 下载

SpecDD系列:(混合的敏捷方法模型)主要过程概述

敏捷已成为当今使用最广泛的开发方法。有趣的是,敏捷方法的流行性并不是因为它取代了其他开发方法,相反它与这些方法进行了更好地融合。现实世界众多敏捷项目的成功,也证明了敏捷将走向杂化的未来。       ...

用户故事与敏捷方法

  • 2012年06月21日 12:53
  • 2MB
  • 下载

结构化和敏捷方法及过程修炼

  • 2011年09月10日 11:26
  • 287KB
  • 下载

用户故事与敏捷方法第一章

第1章  概览       软件需求是一个沟通问题。需要新软件的人(使用或销售软件的人)必须与开发新软件的人进行交流。一个项目的成功,依赖于很多不同的信息,这些信息来自各有不同的人员:一方是客户...

用户故事与敏捷方法,完整扫描版

  • 2014年01月12日 10:17
  • 86.47MB
  • 下载

软件项目管理与敏捷方法

  • 2016年08月15日 18:11
  • 24.53MB
  • 下载

如何弥补敏捷方法中的薄弱环节?

近几年来,敏捷作为一种很实用、上手快、轻量级的方法,被越来越多的开发团队所采用。然而,在很多大团队中,敏捷方法的实施带来了包括在人员管理、工作计划、沟通和文档记录等诸多问题。2009年,有知名市场研究...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:UP还是敏捷方法?
举报原因:
原因补充:

(最多只允许输入30个字)