軟體工程/流程/快速應用程式開發簡介
快速應用程式開發 (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