快速应用开发

快速应用开发RAD ),也称为Rapid Application BuildingRAB ),既是适应性软件开发方法的一般术语,也是James Martin快速开发方法的名称。通常,软件开发的RAD方法更少强调计划,并更加强调适应过程。原型通常是除了设计规格外或有时甚至是使用设计规格。

RAD特别适合(尽管不限于)开发由用户界面要求驱动的软件图形用户界面构建器通常称为快速应用程序开发工具。其他快速发展的方法包括自适应敏捷螺旋统一模型。

历史

快速的应用开发是对1970年代和1980年代开发的计划驱动瀑布过程的响应,例如结构化系统分析和设计方法(SSADM)。这些方法的问题之一是它们是基于用于设计和建造桥梁和建筑物的传统工程模型。软件是本质上不同的工件。软件可以从根本上更改用于解决问题的整个过程。结果,从开发过程中获得的知识本身可以反馈解决方案的要求和设计。计划驱动的方法试图严格地定义要求,解决方案和实施计划的计划,并具有阻止变化的过程。另一方面,RAD方法认识到软件开发是一个知识密集的过程,并提供了灵活的过程,这些过程有助于利用项目在改进或调整解决方案的项目过程中获得的知识。

第一个这样的RAD替代方法是由Barry Boehm开发的,被称为螺旋模型。 BOEHM和其他随后的RAD方法强调开发原型以及或而不是严格的设计规格。原型比传统规格具有多个优点:

  • 降低风险。原型可以在生命周期的早期测试系统最困难的潜在部分。这可以为设计的可行性提供有价值的信息,并可以防止团队寻求实现太复杂或耗时无法实施的解决方案。在生命周期而不是以后发现问题的好处是RAD方法的关键好处。可以找到较便宜的问题要越早解决。
  • 用户比创建规格更好地使用和反应。在瀑布模型中,用户通常会在一组要求上签名,但是当使用实施的系统呈现以突然意识到给定的设计缺乏一些关键功能或太复杂。总的来说,大多数用户可以在可以体验运行系统的原型而不是抽像地定义该系统的原型时提供更多有用的反馈。
  • 原型可以是可用的,并且可以演变成完整的产品。在某些RAD方法中使用的一种方法是将系统构建为一系列原型,这些原型从最小功能到对最终完成的系统的适度有用。除了上述两个优点之外,这一点的优点是,在此过程中,用户可以在更早的时间内获得有用的业务功能。

詹姆斯·马丁(James Martin)Barry Boehm和其他人的思想开始,在1980年代在IBM开发了快速的应用开发方法,并最终通过在1991年出版一本书《​​快速应用程序开发》(Rapid Application Development)进行了正式化。即使在IT专业人员中,这也引起了RAD一词的混乱。将RAD作为瀑布模型的一般替代方案和RAD作为Martin创建的特定方法很重要。 Martin方法是针对知识密集和UI密集型业务系统量身定制的。

詹姆斯·克尔(James Kerr)和理查德·亨特(Richard Hunter)等RAD先驱进一步发展并改善了这些想法,他们共同撰写了有关该主题Inside Rad的开创性书籍,该书跟随了Rad项目经理的旅程,他开车并改进了Rad Rady方法。 - 在一个实际的RAD项目上。这些从业人员以及像他们一样的人,有助于RAD获得流行,以替代传统系统项目生命周期的方法。

业务重新设计的高峰期期间,RAD方法也成熟。重新设计业务流程的想法是从根本上重新考虑核心业务流程,例如销售和客户支持,并考虑到信息技术的新功能。 RAD通常是较大的业务工程计划的重要组成部分。 RAD的快速原型方法是帮助用户和分析师“开箱即用”的关键工具,以了解技术可能会从根本上重塑核心业务流程的创新方式。

詹姆斯·马丁(James Martin)对RAD的许多舒适感源于杜邦的信息工程部门及其领导人斯科特·舒尔茨(Scott Schultz)以及他们与约翰·安德伍德(John Underwood)的关系,后者领导了一家定制的RAD开发公司,该公司开创了澳大利亚和香港的许多成功项目。

成功的项目,包括ANZ BankLend LeaseBHP可口可乐Amatil, Alcan香港骑师俱乐部等。

导致斯科特·舒尔茨(Scott Shultz)和詹姆斯·马丁(James Martin)的成功都与约翰·安德伍德(John Underwood)一起在澳大利亚度过了一段时间,以了解为什么澳大利亚在实施重要的任务批判性RAD项目方面取得了不成比例的方法和细节。

詹姆斯·马丁·拉德方法

詹姆斯·马丁(James Martin)的阶段

詹姆斯·马丁(James Martin)将RAD的方法分为四个不同的阶段:

  1. 需求计划阶段- 结合了系统开发生命周期(SDLC)的系统规划和系统分析阶段的要素。用户,经理和IT工作人员讨论并就业务需求项目范围,约束和系统需求进行了讨论并达成协议。当团队在关键问题上达成共识并获得管理授权以继续时,它将结束。
  2. 用户设计阶段- 在此阶段,用户与系统分析师进行交互,并开发代表所有系统过程,输入输出的模型原型。 RAD组或子组通常使用联合应用设计(JAD)技术和案例工具的组合,将用户需求转化为工作模型。用户设计是一个连续的交互式过程,可让用户理解,修改并最终批准满足其需求的系统的工作模型。
  3. 施工阶段- 专注于类似于SDLC的程序和应用程序开发任务。但是,在RAD中,用户继续参与,并且随着实际屏幕或报告的开发,仍然可以提出更改或改进。它的任务是编程和应用程序开发,编码单位集成系统测试
  4. 切割阶段- 类似于SDLC实施阶段的最终任务,包括数据转换,测试,转换为新系统和用户培训。与传统方法相比,整个过程被压缩。结果,新系统的构建,交付并放置更快。

优点

在现代信息技术环境中,现在许多系统都使用一定程度的快速应用开发(不一定是James Martin方法)构建。除了马丁的方法外,敏捷方法理性统一过程通常用于RAD开发。

据称的RAD的优势包括:

  • 更好的质量。通过让用户与不断发展的原型互动,从RAD项目中的业务功能通常比通过瀑布模型实现的要高得多。该软件可以更有,并且有更好的机会专注于对最终用户至关重要的业务问题,而不是开发人员感兴趣的技术问题。但是,这不包括通常称为非功能要求(又称质量属性)(包括安全性可移植性)的其他类别。
  • 风险控制。尽管RAD的许多文献都集中在速度和用户参与上,但正确完成RAD的关键特征是降低风险。值得记住的是,Boehm最初将螺旋模型描述为基于风险的方法。 RAD方法可以早期关注关键风险因素,并根据过程初期收集的经验证据来适应它们。例如,原型制作系统中一些最复杂的部分的复杂性。
  • 更多的项目按时完成并在预算之内完成。通过关注增量单位的发展,减少了灾难性大型瀑布项目的灾难性失败的机会。在瀑布模型中,经过六个月或更长时间的分析和开发,需要对整个系统进行根本性重新思考。使用RAD,这种信息可以在此过程的早期发现并采取行动。

缺点

所谓的RAD缺点包括:

  • 新方法的风险。对于大多数IT商店而言,Rad是一种新方法,需要经验丰富的专业人员重新考虑他们的工作方式。人类几乎总是不愿改变,而使用新工具或方法进行的任何项目都将仅仅由于团队学习的要求而更有可能第一次失败。
  • 缺乏对非功能性要求的重视,在正常操作中,最终用户通常看不到这些要求。
  • 需要稀缺的资源。几乎所有的RAD方法都具有共同点的一件事是,在用户和开发人员之间的整个生命周期中,相互作用更多。在瀑布模型中,用户将定义需求,然后大部分时间随着开发人员创建系统而消失。在RAD中,用户从一开始和几乎整个项目都参与其中。这要求企业愿意投资应用领域专家的时间。悖论是,专家越好,他们越熟悉自己的领域,他们实际经营业务的要求就越多,可能很难说服他们的主管投入时间。没有这样的承诺,RAD项目将无法成功。
  • 控制较少。 RAD的优点之一是它提供了一个灵活的适应过程。理想是能够迅速适应问题和机遇。灵活性和控制之间是不可避免的权衡,更多的是另一种。如果一个项目(例如,关键生命软件)值的控制超过敏捷性RAD是不合适的。
  • 设计差。在某些情况下,对原型的关注可能太远,导致“黑客和测试”方法,其中开发人员不断对单个组件进行微小的更改,而忽略了可能导致更好整体设计的系统体系结构问题。对于像马丁的方法这样的方法论,这尤其是一个问题,它非常专注于系统的用户界面。
  • 缺乏可扩展性。 RAD通常专注于中小型项目团队。上面引用的其他问题(较少的设计和控制)在使用RAD方法的大规模系统时提出了特殊挑战。

也可以看看

实施RAD的实用概念:

其他类似的概念: