软件工程/流程/快速应用程序开发简介
快速应用程序开发 (RAD) 指的是一种软件开发方法，它以快速原型设计为代价，减少了规划工作。使用 RAD 开发的软件的“规划”与软件本身的编写交织在一起。缺乏广泛的预先规划通常可以让软件编写得更快，并且更易于更改需求。
快速应用程序开发是一种软件开发方法，它涉及迭代开发和软件原型设计等方法。根据惠特曼 (2004) 的说法，它是各种结构化技术，尤其是数据驱动的信息工程与原型设计技术的融合，以加速软件系统开发。[1]
在快速应用程序开发中，结构化技术和原型设计特别用于定义用户的需求并设计最终系统。开发过程从使用结构化技术开发初步数据模型和业务流程模型开始。在下一阶段，使用原型设计验证需求，最终完善数据和流程模型。这些阶段被迭代地重复；进一步的开发导致“一个结合了业务需求和技术设计声明，用于构建新系统”。[1]
RAD 方法可能需要在功能和性能方面进行妥协，以换取更快的开发速度和更轻松的应用程序维护。
快速应用程序开发最初是一个术语，用于描述由詹姆斯·马丁在 1991 年提出的软件开发过程。马丁的方法涉及迭代开发和原型构建。最近，该术语及其缩略语已在更广泛的通用意义上使用，它涵盖了各种旨在加速应用程序开发的方法，例如使用各种类型的软件框架，例如 Web 应用程序框架。快速应用程序开发是对 1970 年代和 1980 年代开发的非敏捷流程的回应，例如结构化系统分析和设计方法以及其他瀑布模型。以前方法的一个问题是应用程序构建时间过长，以至于需求在系统完成之前就发生了变化，导致系统不完善甚至不可用。另一个问题是假设仅方法论的需求分析阶段就能识别所有关键需求。大量证据 [需要引用] 证明，即使在所有层级都拥有经验丰富的专业人员的项目中，情况也并非总是如此。
在吸收了布莱恩·加拉格尔、亚历克斯·巴尔钦、巴里·博厄姆和斯科特·舒尔茨的思想之后，詹姆斯·马丁在 1980 年代的 IBM 开发了快速应用程序开发方法，并在 1991 年出版了一本书《快速应用程序开发》将其正式化。
从传统的基于会话的客户端/服务器开发转向开放无会话和协作开发，例如 Web 2.0，已增加了对更快地迭代 SDLC 阶段的需要。[2] 这一点，加上核心商业开发中开源框架和产品的日益增多，已使许多开发人员重新燃起了对寻找银弹 RAD 方法的兴趣。
尽管大多数 RAD 方法促进了软件重用、小型团队结构和分布式系统开发，但大多数 RAD 从业人员认识到，最终，没有一种“快速”方法能够提供比其他任何开发方法高出一倍的改进。
所有类型的 RAD 都有可能为更快的产品开发提供良好的框架，并提高软件质量，但成功实施和收益通常取决于项目类型、时间表、软件发布周期和企业文化。可能还有趣的是，一些最大的软件供应商，如微软 [3] 和 IBM [4] 在其旗舰产品开发中没有广泛使用 RAD，并且在很大程度上仍然主要依赖于传统瀑布方法，并具有一定程度的螺旋式开发。[5]
此表包含一些主要类型 RAD 的高级摘要，以及它们的相对优势和劣势。
| 敏捷软件开发 (敏捷) | |
|---|---|
| 优点 | 通过以短时间间隔进行开发来最大程度地减少功能蔓延，从而产生小型软件项目，并以小型增量形式发布产品。 |
| 缺点 | 短迭代可能会添加的功能太少，导致最终迭代出现重大延迟。由于敏捷强调实时通信（最好是面对面），因此对于大型多团队分布式系统开发来说，使用它很成问题。敏捷方法产生的书面文档很少，需要大量项目后期文档。 |
| 极限编程 (XP) | |
| 优点 | 通过快速的新需求螺旋降低变更成本。大多数设计活动都是增量式和动态进行的。 |
| 缺点 | 程序员必须成对工作，这对某些人来说很困难。不会进行任何“详细设计”的前期工作，这可能会导致长期内更多重新设计工作。全职参与项目的业务负责人可能会成为项目的单点故障，以及团队的主要压力来源。 |
| 联合应用设计 (JAD) | |
| 优点 | 通过让客户参与一系列称为 JAD 会议的协作研讨会，来捕捉客户的声音，让他们参与应用程序的设计和开发。 |
| 缺点 | 客户可能会创建不切实际的产品愿景，并要求进行大量镀金，导致团队过度或不足开发功能。 |
| 精益软件开发 (LD) | |
| 优点 | 创建最小化解决方案（即需求决定技术），并在早期交付较少的功能；根据今天的 80% 比明天的 100% 更好的政策。 |
| 缺点 | 产品可能会由于核心功能不足而失去竞争优势，并且可能表现出较差的整体质量。 |
| 快速应用程序开发 (RAD) | |
| 优点 | 促进强大的协作氛围和动态的需求收集。业务所有者积极参与原型设计、编写测试用例和执行单元测试。 |
| 缺点 | 依赖于强大的凝聚力团队和个人对项目的承诺。决策依赖于功能功能团队和共识决策过程，PM 和工程权限程度较低。 |
| Scrum | |
| 优点 | 提高了以前因繁重的“流程”而瘫痪的团队的生产力，能够优先处理工作，使用待办事项列表来完成一系列短迭代或冲刺中的项目，每日度量进度和沟通。 |
| 缺点 | 依赖于一位可能缺乏消除障碍和交付冲刺目标的政治技能的专家的促进作用。由于依赖于自组织团队并拒绝传统的集中式“流程控制”，内部权力斗争可能会使团队瘫痪。 |
表 1：各种 RAD 类型的优缺点
由于快速应用程序开发是一个迭代和增量过程，因此它会导致一系列原型，这些原型从未在满意的生产应用程序中结束。如果应用程序开发工具健壮、灵活且得到恰当使用，可以避免此类故障。这在 2080 开发方法或其他后敏捷变体等方法中得到了解决。
当组织采用快速开发方法时，必须注意避免开发团队内部以及团队与客户之间出现角色和责任混淆以及沟通故障。此外，特别是在客户缺席或无法以权威方式参与开发过程的情况下，系统分析员应代表客户拥有此权限，以确保非功能需求的适当优先级。此外，在没有经过全面且正式记录的设计阶段的情况下，不应开发任何系统增量。[6]
- ↑ a b 惠特曼，杰弗里·L.；朗尼·D. 宾利，凯文·C. 迪特曼。（2004）。系统分析与设计方法。第 6 版。ISBN 025619906X。
- ↑ 毛雷尔和 S. 马特尔。（2002）。“极限编程：面向 Web 的应用程序的快速开发”。IEEE 互联网计算，6(1) 2002 年 1 月/2 月第 86-91 页。
- ↑ Andrew Begel，Nachiappan Nagappan。 "敏捷软件开发在工业环境中的应用和感知：一项探索性研究，Microsoft Research" (PDF). 检索于 2008-11-15.
- ↑ E. M. Maximilien 和 L. Williams。（2003）。“评估 IBM 的测试驱动开发”。软件工程国际会议论文集，波特兰，俄勒冈州，第 564-569 页，2003 年。
- ↑ M. Stephens，Rosenberg，D.（2003）。“极限编程重构：反对 XP 的论据”。Apress，2003 年。
- ↑ Gerber，Aurona；Van der Merwe，Alta；Alberts，Ronell；（2007），快速开发方法论的意义，CSITEd 2007，毛里求斯，2007 年 11 月 [1]
- Steve McConnell（1996）。快速开发：驯服狂野的软件时间表，Microsoft Press Books，ISBN 978-1556159008
- Kerr，James M.；Hunter，Richard（1993）。深入 RAD：如何在 90 天或更短时间内构建一个功能完备的系统。McGraw-Hill。 ISBN 0070342237.
- Ellen Gottesdiener（1995）。"RAD 现实：超越炒作，了解 RAD 的真正运作方式" 应用开发趋势
- Ken Schwaber（1996）。Scrum 敏捷项目管理，Microsoft Press Books，ISBN 978-0735619937
- Steve McConnell（2003）。专业软件开发：更短的时间表，更高质量的产品，更成功的项目，更出色的职业，Microsoft Press Books，ISBN 978-0321193674
- Dean Leffingwell（2007）。扩展软件敏捷性：大型企业的最佳实践，Addison-Wesley Professional，ISBN 978-0321458193