了解最新技术文章
快速应用程序开发(或 RAD 模型)本质上是一种敏捷的项目开发策略,它为您设计和构建软件解决方案的方式提供了一个超级灵活和适应性强的过程。它取代了与严格的设计规范相结合的冗长、以计划为中心的方法,而是优先考虑快速原型设计和反馈。
这个想法是快速适应问题、机会和更新,同时能够做出数据驱动的决策,并根据从先前或正在进行的流程中获得的需求和知识来设计和开发解决方案。
然而,多年来,这种方法及其概念发生了变化(并继续这样做)。这是可以理解的,考虑到这完全是关于适应、灵活性和根据项目、人员、技术和时间而变化的事实。
回顾 80 年代处于“婴儿期”的快速应用程序开发模型,它最初是由 Barry Boehm 在其 1986 年的论文“软件开发和增强的螺旋模型”中构想的。这种以风险为导向的创新方法培养了一种新的软件开发理念,将不同模型的元素组合到一个项目中,包括瀑布式、增量式、进化原型等。
这种快速软件开发的早期替代方案是对遵循解决方案实施范例的预定义要求的特别限制和严格的瀑布方法的回应。 如果它在几十年前不适用,想象一下传统模式现在有多么过时和阻碍变革?
当然,其他编程先驱,如 James Martin、James Kerr、Richard Hunter 进一步采用了这种创新方法,并且它在软件中的应用程度已经成熟并不断显着成熟。
即便如此,仍有一些核心开发原则保持不变,它们都源于您不是在建造建筑物的普遍概念。您正在构建软件。软件也在发展。它可以灵活地改变并成为更贴近最终用户需求的产品。为此,您需要利用某些 RAD 步骤和阶段,这些步骤和阶段已被证明是制定更优质解决方案的成功公式。
上面提到的制胜法宝包括 4 个快速应用程序开发阶段:
计划要求
用户设计和输入
快速施工
定稿
第 1 阶段:概述产品的“要点”是RAD 流程的第一步。这是程序员、产品所有者、经理、用户和设计师聚集在一起总结范围、需求、目的、潜在障碍和其他项目的特殊性的时候。但是他们使要求足够灵活,因此他们可以在必要时更轻松地进行任何更新。
第 2 阶段:这是一个连续的 RAD 阶段,从头到尾持续,通常与原型设计和测试相关。用户与技术团队一起工作,就系统迄今为止的工作方式提供反馈,解决缺点,阐明需要更改/保留的特性、功能和用户流程,定义软件变得多么直观和用户友好出,等等。
第 3 阶段:此时特性和功能最终确定,开发人员根据从前一阶段收集的反馈开始着手产品构建。RAD 与其他模型之间的主要区别之一正是在快速构建阶段最为明显,因为它为程序员提供了已经在原型中讨论、构建和测试的模块。因此,这是一个巨大的节省时间。
第 4 阶段:经过最终测试、用户培训、界面微调、质量和稳定性评估,产品从批准进入实际环境。
降低因过于复杂而无法执行的不可行设计带来的风险。
在项目生命周期的早期而不是在系统已经实施时清除问题和错误。
允许快速审查并让用户体验原型,提供建设性反馈并更有效地确定可能的改进。
在整个过程中邀请用户,而不仅仅是在开始/结束时,这更容易消除设计和用户体验差异。
该系统可以按功能构建在模块和功能中,从而可以进行更详细的测试并深入了解其目标业务方面。
通过经过良好测试的原型和 RAD 项目交付更高质量和更可用的软件通常需要更少的时间来完成和与 UX 携手并进。
最大限度地减少规划阶段并滋养快节奏的原型迭代。
PM 和利益相关者可以更好地监控进度和结果,因为项目通常被分解成多个块和更易于管理的任务。
通过轻松集成低代码/无代码工具和自动化,消除容易出错的手动编码并鼓励代码重用。
可能会导致忽略系统架构并淡化非功能性需求 (NFR)。
不适用于需要完全控制和更好规划的大型团队和项目。
由于其灵活性和迭代性,管理起来更加困难和分散。
仅适用于模块化系统 100%。
由于原型的潜在循环周期,可能需要过于频繁的会议。
由于对外观的关注——面向用户的前端,一些后端流程和最佳实践受到了损害(这可以通过使用低代码开发工具来消除,但更多关于这一点的内容如下)。
我已经缩小了一些场景和用例,它们将帮助您确定 RAD 模型是否适合您和您的团队。那么,什么时候选择和使用呢?
用于开发由用户界面需求驱动的软件。
当您想要添加和使用原型而不是/除了设计规范并在模块中构建和展示项目时。
取代以计划为中心的瀑布流程,这些流程通常在淘汰和赶上开发中潜在的灾难性故障方面很慢,并实施专注于单元开发的自适应流程,为用户测试、反馈和可操作的用户体验洞察提供足够的时间和空间.
通常拥有/与中小型项目团队合作时。
用户愿意从一开始就参与软件开发过程,并在整个产品生命周期中始终提供反馈。
如果团队可以(并且欢迎)在项目允许的情况下经常重复,而不必每次都从头开始设计开发过程。
如果您和您的团队想要根据数据和证据采取行动,以检测关键风险因素并相应地调整流程。例如,评估原型,确定实施方面的瓶颈和设计复杂性,然后花时间重构系统。
在计划工作/采用代码可重用性以提高速度和效率时。
三个原因:
首先,当我瞄准时间和成本效益时。
现在有更多的时间来处理我工作的关键方面是非常重要的。结合软件开发的成本,RAD 方法如此受欢迎也就不足为奇了。对我来说,从事中小型项目需要开箱即用的一键式流程,这将节省足够的启动时间。众所周知,通常最耗时的过程是开始做一些事情,比如 PoC、设计实现、部署等。
其次,因为快速的软件开发让我可以使用像App Builder这样的低代码平台,可以轻松集成到流程中,从而加快从设计到代码的一切。
我不希望有一个解决方案会“做完所有事情然后忘记”,而是奠定应用程序的基础。但是这些平台如此有用和有价值的原因是因为它们消除了从头开始创建项目/存储库结构的需要,完成所有用于数据绑定的样板代码,管理应用程序路由和主题,处理所有初始配置步骤视觉组件和应用程序在不同屏幕中的实际布局以及这些屏幕内的视觉部分。它也可以与 Indigo.Design 等其他工具完美配合,将 Sketch和Adobe XD 文件转换为功能齐全的应用程序并形成完整的设计到代码解决方案。
最后,我什至可以减少一些最痛苦的 RAD 缺点。
我之前提到过,应用程序制造商也会介入以消除后端受损等缺点。如何?例如,App Builder 可以让我更轻松地开发 Web API,使用真实的系统组件,确保数据完整性,处理数据绑定,最后在 Angular和Blazor中单击即可生成生产就绪代码。
一个巨大的奖励因素是应用程序更快地获得利益相关者的批准。这样我就可以花更多的时间在应用程序的实际业务逻辑上,通常是后端实现。
像 App Builder 这样的平台确实适合这种特殊类型的应用程序开发过程,因为它们通过使用低代码功能有助于提高灵活性并加快产品周期。这种 RAD + App Builder 的组合能够减少 80% 的开发时间,并摒弃了有时需要多次重新设计的 POC 的后续重新设计。
该过程中的所有这些步骤都在平台内部进行。而不是处理一个或多个冲刺和概念或发现研究阶段,最初将项目从两周扩展到四个星期,我使用该平台将其全部缩短到一两天。
RAD 可能是您简化和改进软件开发操作的一种方式,但它实际上是一种方法论。它不是工具或编程语言。这就是为什么我选择了几个可用于简化某些数字产品设计和开发过程的平台。
这是清单。
5 设计和原型制作工具
靛蓝设计
草图
无花果
Adobe XD
视觉工作室
5 测试和反馈工具
靛蓝设计
视觉工作室
变戏法
用户测试
用户缩放
5 快速应用程序开发工具
应用程序生成器
吻流
Zoho Creator
外系统
Salesforce 应用云