time 
设为首页】【收藏本站
当前位置: 主页 > 软件工程 > 分析与建模 > 使用敏捷流程和建模构建企业应用程序

使用敏捷流程和建模构建企业应用程序

时间:2009-12-01 20:27 点击:580次 字体:[ ]




  摘要

  软件开发方法学由来已久,通常包括一个流程或建模技巧,或者二者兼而有之。比如,过去和现在使用过的开发方法就包括:Structured Systems Analysis and Design Methodology(结构化系统分析和设计方法,SSADM)、Object Modeling Technique(面向对象建模技术,OMT),以及Rational Unified Process(Rational统一流程,RUP),等等。最近的研究表明,采用SSADM瀑布式开发方式完成Big requirements up front(预先最大需求,BRUF)或big design up front(预先最大设计,BDUF)的传统方法,不仅造成时间和精力的极大浪费,还会导致软件开发项目遭遇挑战,并/或全盘失败。本文将探讨BRUF和BDUF的替代方法,以尽可能减少企业软件应用程序开发中的这种浪费。

  本文大部分内容直接摘自《Agile Java Development With Spring, Hibernate and Eclipse》一书。

  问题

  Standish Group是一家积极开展软件开发项目失败原因研究的组织。该组织2000年度的CHAOS报告指出,此年内23%的软件项目以失败告终,49%受到质疑。1994年以来,该组织不断发布具有类似结论的报告。比如,1998年的报告就显示了类似的结论:28%的开发项目以失败告终,46%的项目受到质疑。由Standish Group发布的另外一组关于应用程序内置功能使用情况的统计数据更让人震惊。该报告认为,在应用程序的功能中,有45%用户从未使用,19%很少使用,16%偶尔使用,13%经常使用,只有7%始终使用。这些数据表明,开发人员构建的大部分功能用户从未使用,这不免让人觉得匪夷所思。

  尽管这只是一家之言,但它的确与我20年的信息技术职业生涯的所见所闻相符。既然BRUF和BDUF存在一些问题,我们现在就来探讨一下潜在的解决方案。

  解决方案

  Standish Group还提出了十大成功因素,称为CHAOS Ten。其中的一些主要因素包括管理层的支持、用户的参与、富有经验的项目经理、明确的业务目标和最小化的范围。我所经历过的被取消、被质疑并/或失败的项目也完全印证了这四大成功因素的重要性。

  2001年,17位软件开发方法学家齐聚一堂,将各自的开发方法学进行了汇总,并共同定义了术语敏捷(Agile)。会议最终制定了Manifesto for Agile Software Development(敏捷软件开发宣言),并确立了一系列敏捷开发方法的价值观念和原则。术语敏捷涵盖了众多开发方法,其中包括Extreme Programming (极限编程,XP)、Scrum、Feature Driven Development(特性驱动软件开发,FDD)、Agile Modeling(敏捷建模)以及Crystal等等。由于流程和建模常常互为补充,因此许多软件开发方法学同时包含这二者。

  由于敏捷方法遵循一套共同的原则和价值观念,因此该方法不言自明的优点便是用户可拥有各种技术选择,并可按用户环境定制所选技术。本文将在使用极限编程(XP)和敏捷模型驱动开发(Agile Model Driven Development,AMDD)进行企业应用程序开发时,采取这样的做法。XP提供了完整的软件开发生命周期,而AMDD则提供建模原则。然而,由于XP整个生命周期流程的社会性超出了本文的范围,因此本文将更关注于AMDD而非XP。

  使用XP进行软件开发

  XP由Kent Beck、Ward Cunningham和Ron Jeffries共同开发,是有纪律并流线化的完整生命周期开发流程。由于XP的方面书籍颇多,因此我只概括说明我对该方法的理解。

  XP项目通常先由用户以几项到几十项user story的形式提出成功开发的需求。user story是客户(终端用户、业务分析师或其他项目涉众)用一到三个句子列出的功能需求。此后客户为其指定优先顺序,并将user story分为一个版本计划中的不同迭代,并优先开发优先级较高的user story。每一次迭代结束后,向客户发布该迭代中实现的user story的生产就绪代码(也就是说,通过了可接受性测试)。图1为XP生命周期简图。

  使用敏捷流程和建模构建企业应用程序_www.fengfly.com
          图1.XP生命周期简图

  敏捷方法的共同特征是更短、更频繁的软件开发项目周期。就XP而言,这包括以下方面:

  更短的发布时间(比如两到三个月)
  更短的迭代周期(比如一到三周)
  更短的编译时间(比如十分钟)
  更频繁的整合,每天一到数次,甚至在每次代码签入(check in)后不断自动整合。

  XP的其他重要方面还包括让开发团队(开发人员、测试人员、项目经理)和客户或其代表同在开发现场。这样做的目的是为了便于交流,而交流正是XP项目成功的关键。

  XP也强调简洁。比如,Kent Beck在其《Extreme Programming Explained》(第2版)(中文译名:《解析极限编程》)一书中问道:“可以运行的最简单程序是什么样的?”就软件应用程序的设计而言,这一原则体现在增量设计形式上。Scott W. Ambler (敏捷建模大师)也喜欢称其为即时设计(Just-in-time Design)。其理念是先完成整体架构和前端设计,把细节设计留到需要时(如迭代周期中)进行。

  限于篇幅,本文并未涉及XP其他诸多方面内容,比如结对编程(pair programming ),稳定的开发进度,以及代码集体所有权等问题。此外,有必要指出,XP并不是一种要全部接受或全部拒绝的方法。换句话说,不用在项目中全盘采纳XP的所有做法。比如,Mike Cohn(由Addison-Wesley出版的《User Stories Applied》一书的作者)近期在一封邮件写到:“我鼓励开发团队从Scrum入手,随后要‘发明XP’,意思是希望他们能找到适合自己环境的XP实践。”简而言之,如果您有兴趣使用XP,我鼓励您通过相关书籍或网站对XP进行研究,这些网站包括extremeprogramming.org、xprogramming.com以及xp123.com。



本文地址 : http://www.fengfly.com/plus/view-158720-1.html
标签: 构建 流程 应用程序 企业 使用 敏捷
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码: