无论是面向消费者的应用程序，还是内部业务工具，软件开发受两个原则指导:做什么软件和如何开发。选择构建什么应该由产品和市场策略来驱动。关于如何构建的决策应该通过查看最佳实践来确定。这意味着我们将放弃传统的软件开发模型，转而选择快速应用程序开发（RAD）
快速应用程序开发(RAD)不仅仅是一个流程或平台(稍后我们将讨论RAD与敏捷)，它代表了软件设计、构建和交付方式的根本转变。除了加快产品上市、降低成本和提高质量之外，RAD在概念上还与其他IT趋势保持一致，这些趋势有利于敏捷性、迭代和重用。这是一种新思维方式的一部分，它帮助企业转变为市场带来价值的方式和商业模式。
为什么我们需要构建新的认知模式？
传统的软件开发过程倾向于遵循线性瀑布式方法，每个阶段必须在下一个阶段开始之前完成。在每个阶段之间是团队之间的交接。虽然每个组织处理软件开发生命周期(SDLC)的方式不同，但它们通常从需求开始，以交付给客户结束。
瀑布式开发是数字时代的基础。然而，与其他学科一样，新的最佳实践也出现了。敏捷是RAD的一种表达方式，但还有其他表达方式。它们都为组织及其客户提供了关键的优势。
- 由原型驱动的更好的软件将需求变为现实，并鼓励客户提供有意义的反馈。
- 由于设计人员和开发人员专注于构建软件而不是等待检查点，因此可以加快产品上市时间。
- 快速的反馈循环可在流程的早期识别错误并加快修复速度，从而降低开发成本。
- 更有意义的迭代，可以更早地解决未知问题，并且可以更好地利用学习。
转变：更新人员，流程和优先级
瀑布方法是在1970年代初期引入的。RAD是在1991年詹姆斯·马丁（James Martin）的同名书中首次提出的。马丁认为，由于在漫长的软件开发过程中通常会发生很多的变化，不能在实际中融入突发事实的僵化瀑布式方法注定会失败。结果永远是质量较低，成本较高的产品，最终交付时间更长。
马丁的模型大致遵循与瀑布相同的流程——要求、设计、建造、切割——但有两个明显的区别。首先，这个过程变成了循环驱动的，而不是线性的。一旦了解了需求，就可以使用原型同时进行设计和构建，从而实现从开发到影响设计的反馈，反之亦然。
其次，马丁认为这种持续的反馈是绝对必要的。记录需求后，瀑布式开发与用户进行交互，然后在交付软件时与瀑布式开发进行交互。RAD让用户参与整个过程，对原型做出反应，并立即对开发产生影响。
相同和不同:RAD和其他非瀑布式SDLC模型
很多人可能没有听说过RAD，但是肯定听过敏捷。在敏捷思维之前，RAD已经存在了大约10年，它已经成为Martin思想最流行的表达方式。
我们来看看一些关键RAD和敏捷之间的差异,但重要的是要理解条款不可以互换。
- JAD或联合应用程序开发。JAD指的是用户和开发人员之间的协作设计，使其成为RAD的一个部分，而不是并行的。
- DSDM，即动态系统开发方法。这是敏捷的早期先驱，是将一些可重复的、可伸缩的过程引入到RAD原则的第一步。在今天的敏捷软件商店中，可以找到许多DSDM思想。
实际的原则:RAD想要什么(以及它是如何工作的)
在引入时，RAD的前提很简单。为了得到更好的软件，你必须以不同的方式来构建它。第一步是改掉瀑布的习惯。早期的RAD迭代并不是特别严格的，但是敏捷和其他方法填补了其中的一些细节。Martin的基本思想贯穿始终。
经营理念：快速，灵活，开放式
- 需求被收集，但被认为是整个生命周期中的移动目标。
- 软件是在模块化组件中设计和构建的，这些组件在循环中不断地根据需求进行测试，而不是在连续的阶段进行测试。
一旦软件达到足够的成熟度，它就可以被转换/发布。
目标：原型
RAD(和敏捷)的基础是原型的思想。原型是至少反映一些基本用户需求的软件的工作版本。这些通常被收集到一个正式的产品需求文档(PRD)或类似的交付品中。
第一个原型的想法不是要使它完美，而是要完成它。这允许团队在一些实质性的事情上进行协作，而不是继续争论抽象的含义和期望。原型通常从低保真度到高保真度。你可以猜到，低保真度意味着基本的功能已经实现，但是原型看起来或感觉上不像成品。高保真原型在形式和功能上都更接近需求。大多数团队从前者转向后者。
原型与MVP
熟悉敏捷开发的人，肯定读过关于最小可行产品(Minimum Viable Products，或MVP)的文章。它主要是指应用程序或组件的已达成共识的“初稿”。这并不一定意味着该产品已经准备好投放市场，而是意味着它捕获了足够的需求，可以用作迭代原型。
研究MVP的方法是让团队完成第一次学习和探索的循环。有了原型，设计和开发迭代就可以继续进行，而这些学习循环将通过SDLC彼此构建。
阶段:对流程的更仔细的观察
SDLC和RAD过程是由类似的组件阶段组成的。真正的区别在于工作的速度和并行运行流程各部分的能力。Martin的早期设想将一些瀑布流程简化，但关键功能依旧保持。
循序渐进：深入了解快速应用程序阶段
1、尽可能详细地捕获客户和技术需求。这些包括但不限于：
- 业务需求建模—业务需要对流程输入和输出、集成点以及最终的生产力度量进行建模
- 数据建模—数据输入和输出，源和系统涉及收集和分析
- 技术要求—应用程序在何处以及如何运行的技术要求，包括用户操作系统和后端基础设施
- 接口要求—应用程序的外观
2、这些需求只收集一次，但是RAD的迭代方法意味着它们可能会随着时间而改变。
- 原型设计是传统设计和反馈阶段的结合。
- 设计初始原型
- 测试原型与用户和技术要求
- 完善原型直到达到合适的最终状态
一旦MVP的目标达成，这个阶段就完成了。
3、原型将变成完整的应用程序。这是开发人员关注后端需求和默认详细信息（如安全性和可管理性）的地方。
4、SDLC完成后，就可以进行转换/实施，并且可以将软件移交给客户实施。
5、 最后，维护成为另一个持续的循环，在此循环中将应用更新和修复，计划定期发布，并根据需要扩展功能。
将原型优先于过程可以更快地产生更好的软件
与瀑布模型法的检查点不同，涉众在开始工作之前必须等待前一个阶段的移交，RAD强调并行地持续工作。快速开发不是一次收集需求，然后等待完成的产品来发现这些需求是否被满足，而是尽可能快速地进行设计和构建。
原型一旦建立，涉众就可以检查它，特别是用户。还可以测试它的特性集、集成、安全性和可伸缩性。虽然这个最初的原型离准备发布还有很长的路要走，但它仍然比一长串的需求清单要好很多。
产品的需求被收集起来，但是仍旧只是一个需求列表，用户通过与更接近最终产品的产品交互，可以实时产生有用的反馈意见。
目标:协作和跨功能的专业知识降低成本和复杂性
在开发人员方面，快速地转向原型化允许未知的未知更早地出现，给团队更多的时间来解决问题，特别是集成。可以更早地一起构建和测试组件，从而更快地减少在传统瀑布式SDLC中很久之后才会出现的错误。
RAD也是利用开发团队的跨功能专业知识的更好方法。与在孤岛中工作和仅在交接期间进行交互相比，团队可以协作设计、构建和修复工作原型中的代码。由于开发人员正在独立但同时构建系统的各个部分，因此它还可以识别在整个应用程序中重用代码和对象的机会。
快速的开发也简化了软件测试。除了在评估和更新原型时进行的非正式测试之外，还可以在连续迭代中管理单元和用户案例（用于敏捷开发环境）。这也意味着当用户验收测试的时候，消除了开发过程中可能会产生的意外。
使RAD发挥作用
我们已经知道，快速应用程序开发并不是特定工具和过程的指定列表。随着时间的推移，软件开发的敏捷和其他自适应方法已经帮助填补了一些细节，为RAD提供了一些可以共享和扩展的最佳实践。
然而，无论哪种快速路径适合企业的软件需求，接受并运行RAD仍然需要独特的文化和战略选择。如果没有对这些决定达成一致意见，那么要释放迭代的、自适应的软件设计和开发的全部潜力就会困难得多。
协作文化
不管开发团队的规模有多大，协作和沟通对于RAD的工作是至关重要的。面对不断的变化，团队将一起合作，所以他们需要在整个过程中保持合作和沟通。
协作不一定意味着接近。如果基础设置正确，那么即使是分布式组织也可以进行快速的应用程序开发工作。团队成员只需要在规定的工作时间内与其他人保持联系。
跨职能视角
将软件构建为对象或模块意味着即使在您的团队处理细粒度的技术和业务需求时，也要维护一个宏观的视角。快速开发在跨功能专业知识存在的情况下最为成功，但这并不意味着每个团队成员都必须能够构建软件、数据库和创建UI线框图。
这意味即使在独立的项目管理上，分布在应用程序不同末端的开发人员也要确保是在相同的方向上工作。在需求收集过程中尤其如此，在这个过程中，理解软件堆栈上下的含义至关重要。
持续的客户访问
最后，快速开发在整个过程中与客户或他们的涉众进行持续访问时效果最好。在传统的瀑布式开发中，客户签署需求，然后返回来进行UAT。在快速应用程序环境中，客户将参与整个流程。
客户希望以最低的成本获得高质量的产品。尽管RAD方法需要花费更多的时间，但投资却可以通过降低成本和缩短交货时间获得回报。最终，他们得到的产品可以完全满足他们的需求。
模块和平台
采用RAD不需要选择特定的开发平台。所选择的工具将需要匹配正在构建的内容的复杂性。
原型
在此阶段，原型工具对于快速管理诸如用户界面之类的细节很有用。
构建
市场上有许多出色的面向对象的应用程序构建平台，可让构建基本的SaaS应用程序。它们不像某些原型工具那样具有高度的灵活性，但是对于基本的工作流数字化，它们完全可以满足需求
