快速应用程式开发

快速应用程式开发（原名：Rapid Application Development、缩写：RAD）是指一种以最小幅度的规划并迅速地将原形完成的软体发展方法论。采用RAD进行软体开发的规划是和撰写软体本身交错同时进行的。通常能在没有大量预先规划的情况下，让软体更快写完、更容易变更需求。

有时也作为采用此种方法论的工具的代称，此类工具大多支援所见即所得的介面设计画面、显示相关原始码及说明文件，以及事件及例外处理的快速设定等等辅助使用者迅速完成所需功能的便捷机制。

概观

快速应用程式开发是一种涉及类似迭代式开发与软体原型（Software prototyping）技术的程序设计方法学。根据Jeffrey L. Whitten于2004年所下的定义，这是一种采用数种结构化分析与设计技术（特别是资料驱动（data-driven）型的资讯工程相关技术）与原型制作技术来加速软体系统开发的整合技术。

在快速应用程式开发中，结构化与原型制作的技术被用来定义使用者的需求并设计开发出最终执行的系统。开发的过程会以结构化技术开发初步的资料模型及企业流程模型（business process model）作为起步，下一个阶段会透过制作原型来验证需求并改善资料及流程模型。迭代式地重复这些阶段直到获得"足以建构新系统且包含商务需求以及技术设计的报告"为止。

快速应用程式开发的方法可能需要在功能与效能间取得一个平衡点，借此来加速应用程式的开发，并减少之后所需的维护成本。

历史

快速应用程式开发这个名词原先是用于描述一种由James Martin于1991年所提出的软件开发过程。这个方法涉及迭代式开发与建制原型的技术。最近这个词以及缩写则被泛指一般包含多样目标在加速应用程式开发的技术，像是网络应用框架与其他类型的软体框架。

快速应用程式开发是对应到1970至80年代间的非敏捷流程开发，例如说结构化系统分析与设计方法以及其他像是瀑布模型等。之前的方法论有一个问题是应用程式需要花费相当长的时间去建制，系统需求常在系统完成前就改变，导致作出不适用甚至是不能用的系统。另一个问题则是假设可以用一个有条理的需求分析阶段便能鉴别出所有重大的需求。根据过往的经验能充分的证明即使有各层面具备丰富经验的专业人士在专案中协助，能透过一个分析阶段就能鉴别需求的实例仍就非常的稀少。

由Brian Gallagher、Alex Balchin、Barry Boehm、Scott Shultz，以及James Martin等人于1980年代在IBM产生了设计出能达成快速应用程式开发这种方法的构想。并且于1991年将这些构思集结成书加以出版，书名为《快速应用程式开发》（Rapid Application Development）。

快速应用程式开发相关的效用

从传统基于交谈（session-based）的客户/伺服器发展转移到开放性无交谈（open session-less）及合作开发（像是Web 2.0）的过程上也增加了加快软体开发流程阶段迭代的需求。采用率持续成长中的开放原始码框架与核心商业化发展产品的结合对于许多开发人员来说，重振了找出快速应用程式开发方法论的银弹的兴趣。

尽管多数的快速应用程式开发方法论促进了代码复用、小组结构以及分散式系统开发，多数的快速应用程式开发实践者察觉到最终还是没有一个"快速"的方法论可以提供超越其他开发方法论的数量级改进。

各式各样的快速应用程式开发方法都有潜力提供一个良好的框架用让改进的程式品质加快产品开发的速度。但实作是否成功或有多大效益则通常取决于产品类型、排程、软件出版周期，以及企业文化。有趣的是，一些大型软体厂商如Microsoft以及IBM并不会广泛的采用快速应用程式开发在其核心产品大部分的开发上，主要还是依赖传统的瀑布方法论撘配一定程度的螺旋模型来进行开发。

下表列出了一些主要的快速应用程式开发方法以及他们的优劣。

各种快速应用程式开发的优缺点

	优点	缺点
敏捷 软体开发	借由短期间内以缩影软体专案的方式完成开发并且持续微量的更新产品来避免功能蔓延（Feature creep）的问题。	过短的迭代可能会没办法增加足够的功能，导致在到达最后的迭代前专案产生明显的延迟。敏捷强调即时通讯（最好是面对面），但在大型多团队分散式系统开发的情况下，如何达成这点反而是个问题。敏捷方法过程中产生很少的已撰写文件，因而需要大量的专案后文件。
极限编程	借由新需求的快速螺旋来减低变更需要花费的成本。多数的设计活动以渐进且即时的方式完成。	程式设计师被要求以成对的方式来进行工作，而这对于某些开发人员来说可能是很困难的。因为没有在前期作详细规划，可能会在较长的专案中花费更多精力在重新设计上。在业主在专案的执行过程中持续跟专案成员交互反馈，可能会有导致专案的单点失效的潜在风险以及整个团队压力的主要来源。
联合应用 程式开发	借由一系列名为联合应用程式开发会议的合作专题讨论会，在应用程式设计与开发的过程中透过客户的参与来了解顾客心声。	顾客可能会创造一个不现实的产品愿景，而且要求对产品额外镀金，率领团队不足或过度地开发功能。
精益 软体开发	创造简约的解决方案（例如，需求决定技术：依据需求决定所采用的技术）并提早提供较少功能的版本（好比"今日的80%远比明日的100%更好"的范式）	产品可能会因为核心功能不足或展示的整体品质过差而丧失其竞争优势。
快速应用 程式开发	促进强化合作气氛并动态收集相关需求。企业主会主动参与原型制作、撰写测试个案，以及实施单元测试。	需要依赖具有强大凝聚力的团队以及成员各自对专案的贡献程度。决策得仰赖特色功能规画团队以及与较低程度中央集权化的项目管理及工程权威达成共识的决策过程。
Scrum	改善团队先前被过重"行程"压摊的产能、调整工作优先程度的能力、检视被积压的工作并在一系列的短期迭代或冲刺中完成这些项目，并每日检查进度及维系彼此间的交流。	依赖可能缺乏社交影响力对障碍进行排除或传达冲刺目标的主管来进行协调的工作。并在依靠团队自我组织能力以及排斥传统中央集权"行程管制"的情况，内部彼此的权力对抗可能会瘫痪整个团队运作。

批评

由于快速应用程式开发是一种迭代式的过程，可能会让原型反复延续，而无法以令人满意的成品作结。这样的失误可以借由稳固、弹性，且正确使用的应用程式开发工具加以避免。这样的情况也被像是80/20法则或其他后敏捷的衍生方法所强调。

快速发展方法论的实际影响

当组织采用快速开发方法时，必须要注意避免角色与权责混淆以及开发团队内部或是团队与客户之间沟通不良。此外，特别是在客户缺席或是不能参与发展过程中的验证时，系统分析员应该以客户的角度参与验证，来借此确保能够适当的关注非功能性需求。此外，任何系统的改进都应该要完成详细且正式纪录的设计阶段。

延伸阅读

• James M. Kerr and Richard Hunter (1993). Inside RAD: How to Build a Fully-Functional System in 90 Days or Less, McGraw-Hill, ISBN 0070342237
• Steve McConnell (1996). Rapid Development: Taming Wild Software Schedules, Microsoft Press Books, ISBN 978-1556159008
• Ken Schwaber (1996). Agile Project Management with Scrum, Microsoft Press Books, ISBN 978-0735619937 [2] （页面存档备份，存于互联网档案馆）
• Steve McConnell (2003). Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers, Microsoft Press Books, ISBN 978-0321193674
• Dean Leffingwell (2007). Scaling Software Agility: Best Practices for Large Enterprises, Addison-Wesley Professional, ISBN 978-0321458193