目录
|
快速应用开发(以下简称RAD)是由计算机顾问和作家James Martin于1991年最早提出的,是一种试图快速生成系统而不会牺牲质量的结构化开发方法。RAD与原型法有同样的目标——对用户需求做出快速反应,但它范围更广。该方法现在已经被广泛应用于全球的先进IT社区,使用的单位从美国陆军研究实验室到香港特别行政区的信息技术服务部。RAD的目标是在60到90天的短时间内建立符合用户要求的业务软件。这一目标意味着用户和开发者都需要做出一定的让步。但是,由于80:20的指导原则(开发最重要的80%的功能所需要的时间往往只占整个开发周期的20%),这种妥协无碍大局。在用户和开发者对拟开发的管理信息系统项目缺乏共识和目标的情况下,快速应用开发是一种行之有效的开发模式。
许多单位都经历过代价沉重的管理信息系统开发项目。整个开发过程不仅耗费大量的时间和资源,而且最终交付使用的系统也往往无法达到用户预期的要求。
传统系统开发方法的第一步通常是收集用户的业务要求。在此之后,用户就可能要耐心等待结果。实际上,开发过程如此漫长,在此过程中,用户的业务要求和期望均可能发生迅速的变化。从这种意义上说,传统的方法就像一个“要么全部,要么什么也没有”的解决方案。当开发流程全部完成,系统交给用户使用时,还是不能满足当时的需求。RAD是解决这类问题的有效工具。
(1)软件工具的发展,由第三代语言发展到第四代语言,集成化计算机辅助软件工程(I-CASE)工具的出现。
(2)开发队伍的变化,最终用户全面介入开发过程,通过选拔与培训组成的最终用户人员参加的联合需求规划(Joint Requirement Planning,简称JRP)小组和联合应用设计(joint Application Development,简称JAD)小组,成为开发队伍的主体。
(3)富有成效的开发工作管理,强调开发生产率的控制与效益评估,保证RAD任务的顺利进行,开拓具有革新精神的管理方法。
(4)基于信息工程方法论的最佳生命周期——需求计划阶段、用户设计阶段、系统建造阶段和系统转换阶段。
必须强调指出,RAD是项目级的开发方法沦,而不是全组织MIS建设的方法论。只有在信息工程的MIS体系结构的基础之上,RAD才有用武之地;离开MIS体系结构和总体数据模型,是搞不好RAD的。
快速应用开发模型是一个增量型的软件开发过程模型,强调极短的开发周期。该模型是瀑布模型的一个“高速”变种,通过大量使用可复用构件,采用基于构件的建造方法赢得了快速开发。如果正确地理解了需求,而且约束了项目的范围,利用这种模型可以很快创建出功能完善的信息系统。其流程从业务建模开始,随后是数据建模、过程建模、应用生成、测试及反复。RAD模型的工作过程如图所示。
确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向及其处理等,可以辅之以数据流图。
为支持业务过程的数据流查找数据对象集合、定义数据对象属性,并与其他数据对象的关系构成数据模型,可辅之以E-R图。
使数据对象在信息流中完成各业务功能,创建过程以描述数据对象的增加、修改、删除、查找,即细化数据流图中的处理框。
利用第四代语言(4GL)写出处理程序,重用已有构件或创建新的可重用构件,利用环境提供的工具自动生成以构造出整个的应用系统。
对新创建的构件进行测试。而对于大量重用的构件,一般只做总体测试。
下图描述了Martin提出的四阶段的RAD生命周期。Martin生命周期各阶段的名称与结构化开发方法有所不同,但其包括的工作顺序是相同的。
在结构化开发方法中,来自信息系统部门的代表负责主要的工作,用户仅在新系统与老系统交接阶段参与。而在RAD方法中却恰好相反,除了构建阶段而外,用户在各阶段都起了主要作用,如下图所示。Martin的基本逻辑就是,用户的参与程度越高,尤其是早期阶段,系统开发就越快。
管理者尤其是高层管理者应该是喜欢用新的方式来做事的试验者,或者是能很快知道如何使用新的方法的早期采用者。
比起由单个小组开展所有的系统生命周期活动,RAD认识到由几个专门小组完成工作会更为有效。这些小组的成员精通完成指定任务所需的方法及工具。Martin称之为SWAT(Skilled With Advanced Tools)小组。
基本的RAD方法就是RAD生命周期。
RAD工具主要包括第四代编程语言、配合原型开发和代码生成的CASE工具。CASE工具使用计算机来编制文档,这些文档可以转换到操作软件和数据库中。
RAD方法通过大量使用可复用构件加快了开发速度,对信息系统的开发特别有效。但是与所有其他开发方法一样,RAD方法也存在一些缺陷,使其在一些场合下不能奏效。下表列出了对RAD方法的适用性分析结果。
适用RAD的情况 | 不适用RAD的情况 |
开发的软件相对独立.可以单独使用 | 应用软件必须与多个现有系统或程序协同工作 |
软件可利用许多现有的类库(APIs) | 几乎没有现成可用的组件 |
系统操作性能(如速度)并非关键的考虑因素 | 程序具有很高的操作性能指标 |
应用的开发可以使用高端的软件开发工具 | 系统开发不能使用高端的软件开发工具 |
系统用户覆盖面较窄(内部使用或面向垂直市场) | 系统用户覆盖面广,数量大(面向水平市场或大众) |
项目的范围(“宏观”进度表)和时限(“微观”进度 表)都受到较严格的控制 | BAD偏离目标,变成快速但粗制滥造的开发 |
系统可靠性并非关键的考虑因素 | 系统可靠性目标要求较高 |
系统可分解成多个独立的模块 | 系统无法模块化(无法进行多组同步开发) |
所采用的技术相对成熟(已使用超过一年) | 使用过于“前卫”的技术,因而风险过高 |