了解快速应用程序开发模型

已发表: 2022-09-11

了解快速应用程序开发模型

快速应用程序开发(RAD)是一种软件开发方法,它强调规划和原型阶段,以快速获得用户的反馈。 与更传统的软件开发方法(包括初步设计和后续实施)相比,RAD 强调更大的灵活性。 不断的用户输入和快速的增量改进有助于在一天结束时获得更好的结果。

在 1990 年代,James Martin 将快速应用程序开发定义为传统瀑布程序的替代方案。 传统的瀑布方法是建筑行业和许多其他工作范围修改不常见且成本高昂的领域的绝佳解决方案。 如果您已经开始在桥上施工,那么您不太可能在建造桥梁的过程中转而建造渡轮。

软件的进步允许更大程度的适应性。 可以使用更广泛的方法来解决相同的业务难题,并且可以以较低的成本进行修改。 因此,公司牺牲了精确的设计和规划,转而采用反复试验的迭代过程。 此外,当消费者观察到改进时,他们更有可能提出建设性的批评。

快速应用程序开发是否适合我的项目?

正如我们之前所解释的,RAD 不会在不灵活的环境中运行。 它不适用于以下情况:

  • 有必要事先了解财务限制和时间表。
  • 要么您无法始终如一地访问用户,要么他们没有动力将时间和精力投入到项目中。
  • 由于其范围,该项目需要相当多的人(通常称为利益相关者)的参与。

这些限制通常适用于政府运营的大型企业和组织。 另一方面,即使在这些情况下,快速应用程序开发过程的某些方面也适用。 例如,具有固定价格的项目可能会为原型阶段和一定数量的修订分配资金。 如果您有合适的用户,您可以将原型的范围限制在最不清楚的部分。

另一方面,快速应用程序开发框架在中小型组织和部门项目中表现得非常好。 只要业务用户拥有资金并有动力实现结果。 这是许多业务线 (LOB) 应用程序的主要例证。 通用短语是指更有效地自动化和运营公司某些方面的软件程序。

同样,RAD 是一种在开发网站时有效的方法。 这些通常是由有限的利益相关者组成的适度项目,但必须尽早将它们包括在内,因为设计是一个极具争议的话题,每个人都会有话要说!

阶段和方法论

在快速应用程序开发方法下,耗时的计划阶段被成本较低的原型阶段所取代。 具体来说,RAD 模型建议将过程分为以下四个阶段:

需求计划

用户和项目团队将在此阶段共同确定未来系统的目标。 公司的成功是首要关注的问题。 标准不是很严格。 在原型仍在开发过程中修改或调整它们的能力是必不可少的。

用户设计

快速应用程序开发技术与传统的瀑布模型不同,它强调用户设计是流程的基本组成部分。 在这个阶段,开发人员做的第一件事就是制作原型。 目标是快速且经济地向客户展示需要展示的东西。 如果原型只能满足某些标准或只能处理可能情况的子集,则不会破坏交易。 在编码方面可以走捷径。

原型完成后,会显示给用户以获取反馈。 团队尽可能多地收集输入,在这个阶段,基本标准容易受到不可避免的修改。 写下来有意义的事情在付诸实践时可能会呈现出不同的外观。 当开发人员收到此输入时,他们会返回原型流程并继续这样做,直到消费者对最终结果感到满意。

建造

在这一点上,我们完全清楚必须满足的要求。 是时候完成系统的开发和测试了,以便准备好在生产中使用。 不会有更多的捷径; 相反,重点将放在质量、可扩展性、可维护性和其他因素上。 然而,即使到了这么晚的时候,消费者仍然会在引入新功能时通过提供评论来继续互动。 在开发快速应用程序的迭代过程中,此时仍有进一步微调的空间。

根据我们最终使用的工具和所涉及的其他因素,到目前为止,我们在原型制作过程中所做的工作甚至无法使用。

切换

这是最后一步,包括用户培训、可接受性测试和新系统的实施。

快速应用程序开发与。 敏捷

“RAD”这个名字是在敏捷开发方法论之前十年创造的,由于它的迭代方法,RAD 有时被称为敏捷的“父级”。 另一方面,情况并非如此。 与 RAD 相比,敏捷是一种哲学观点,它不仅仅包含软件开发,它是一种规范的开发技术。

可以安全地假设快速应用程序开发 (RAD) 与其他敏捷软件开发方法(例如 Scrum、看板等)属于同一家族。

快速应用程序开发的优缺点

由于 RAD,关注点从可预测性转向适应性,这既有好的也有坏的影响。

优点:

减少费用和危险

用户只能在项目交付给他们后查看方法的结果并提供评论。 此时需要进行的不可避免的调整既费时又费钱。 当使用快速应用程序开发过程时,在实施后必须重写一半解决方案的机会显着降低。

质量上乘

如果用户积极参与原型制作过程,最终的程序可能会更好地适用于用户的活动。 而且,无论结果如何,都会不负众望。

缺点:

糟糕的设计

在原型阶段追求特定业务需求并走捷径时,您可能会发现自己走得太远了。 从而导致糟糕的设计和整体解决方案。

无法有效扩大规模

RAD 范式假定团队和最终用户高度密切地协作。 一旦团队规模太大或利益相关者数量过多,原型过程将始终以缓慢的速度进行。 此外,向各方解释项目范围的频繁变化变得具有挑战性。 因此,RAD 被认为最适合中小型群体。

后端客户的承诺

快速应用程序开发技术预计在项目的整个生命周期中都会有大量的用户输入。 据报道,对于业内最合格的专业人士来说尤其如此,他们也恰好是组织中最忙碌的人。

无法控制

在项目的原型阶段结束之前,由于明显的原因,准确预测项目的范围、预算或时间表是不可行的。 但是,根据需求计划过程的结果,您仍然可以建立一些一般预期。

开发团队

快速应用程序开发工具 (RAD)

RAD 方法的应用主要依赖于快速原型设计和紧密合作。 因此,选择适当的工具来协助这些努力至关重要。 幸运的是,有很多选择可供选择。

设计和原型制作

Figma 和 InVision 等快速应用程序开发技术使视觉设计师和 UX 专业人员能够快速构建并与最终用户共享可点击的原型。 它们具有完整的设计,因此开发人员可以收集用户输入。 一旦原型的其中一个迭代获得批准,他们就可以将项目导出为格式以供前端开发人员重用。 因此,标志着其过渡到建设阶段。 尽管创建网站是迄今为止这些工具最常见的用途,但对更复杂的最终用户应用程序或门户网站的用户体验进行原型设计是另一种用途。

业务分析师使用其他应用程序的频率要高得多,例如 Balsamiq。 他们专注于使用线框创建用户体验原型。 然后,他们稍后实施最终设计。 这些是对包含复杂用户交互的更广泛系统进行初步建模的绝佳选择。

发展

建立应用程序的开发阶段往往是耗时最多、成本最高、不确定性最大的阶段。 因此,当前用于快速应用程序开发的平台集成了经过测试的架构。 这些是实现标准功能的现成组件,以及使快速开发更容易的工具。 它们中的每一个都使您更容易更快地提供结果。 无论您是处于项目的原型设计阶段,还是处于建设阶段。

Gartner 和 Forrester 等咨询公司不断开发新的术语来区分这些平台。 通常包括以下内容:低代码/无代码应用平台 (LCAP)、高生产力应用平台即服务 (HPAPaaS) 和多体验开发平台。 这些都是您可以使用的不同类型的应用程序平台 (MXDP) 的示例。 但是,最后,它们中的每一个都可以根据其预期的读者群进行分类。

低代码/无代码平台

这些平台背后的基本概念是使没有编码专业知识的业务用户(也称为高级用户或公民开发人员)能够快速提供功能性应用程序。 当然,这种简单性缺乏灵活性和各种限制。 在最近的一篇文章中,我讨论了这些限制及其危害。 因此,此类平台的目标市场包括原型设计或基本解决方案。以开发人员为中心的平台

这些平台利用了软件开发的快速性和兴奋性。 主要通过提供更高级别的 API 和代码生产。 因此,程序员不再需要重复编写样板代码和实现标准功能。

Embarcadero RAD Studio,前身为 Borland Delphi,是该行业的先驱之一。 他们以其视觉用户界面设计而闻名。 Borland Delphi 是它的姓氏。 它在网络出现之前就已经存在,并且仍然可以用于台式计算机和移动设备上的应用程序。

Web 是其他快速应用程序开发框架的主要目标。 因为它是现代与终端消费者沟通的最常用方法。 例如,在 Jmix,我们努力将可视化数据模型和界面设计的便捷性与当今开源技术的功效相结合。 此策略加快了您创建原型的速度。 但是,它还使您能够将原型开发成完整的企业应用程序,该应用程序具有稳定和可扩展的结构。

结论

坚持敏捷思维的开发方法之一是快速应用程序开发 (RAD)。 最终用户的积极参与和使用这些用户的输入开发快速、迭代的原型是 RAD 方法的两个核心原则。 在确保最终用户的满意度之后,接下来的注意力转向提供适合生产的软件。

选择合适的工具对于确保快速原型制作至关重要。 因此,在给定项目中有效使用 RAD 方法。 好消息是可以使用多种工具和平台。 这些迎合了各种应用程序、项目的阶段和团队的技能组合。

尽管 RAD 是一个古老的想法,但它现在正在复兴。 这是当前数字化转型趋势和加快产品上市时间的直接结果。 当用于适当类型的项目并与适当类型的团队一起使用时,RAD 方法可以在更少的风险和更短的时间内实现更高的客户满意度。