快速應用程式開發（原名：Rapid Application Development、縮寫：RAD）是指一種以最小幅度的規劃並迅速地將原形完成的軟體發展方法論。採用RAD進行軟體開發的規劃是和撰寫軟體本身交錯同時進行的。通常能在沒有大量預先規劃的情況下，讓軟體更快寫完、更容易變更需求。
 |
 | 此條目需要精通或熟悉相關主題的編者參與及協助編輯。 (2015年12月14日) |
有時也作為採用此種方法論的工具的代稱，此類工具大多支援所見即所得的介面設計畫面、顯示相關原始碼及說明文件，以及事件及例外處理的快速設定等等輔助使用者迅速完成所需功能的便捷機制。
概觀
快速應用程式開發是一種涉及類似迭代式開發與軟體原型（Software prototyping）技術的程序設計方法學。根據Jeffrey L. Whitten於2004年所下的定義，這是一種採用數種結構化分析與設計技術（特別是資料驅動（data-driven）型的資訊工程相關技術）與原型製作技術來加速軟體系統開發的整合技術。[1]
在快速應用程式開發中，結構化與原型製作的技術被用來定義使用者的需求並設計開發出最終執行的系統。開發的過程會以結構化技術開發初步的資料模型及企業流程模型（business process model）作為起步，下一個階段會透過製作原型來驗證需求並改善資料及流程模型。迭代式地重複這些階段直到獲得"足以建構新系統且包含商務需求以及技術設計的報告"為止。[2]
快速應用程式開發的方法可能需要在功能與效能間取得一個平衡點，藉此來加速應用程式的開發，並減少之後所需的維護成本。
歷史
快速應用程式開發這個名詞原先是用於描述一種由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）的過程上也增加了加快軟體開發流程階段迭代的需求[3]。採用率持續成長中的開放原始碼框架與核心商業化發展產品的結合對於許多開發人員來說，重振了找出快速應用程式開發方法論的銀彈的興趣。
儘管多數的快速應用程式開發方法論促進了代碼復用、小組結構以及分散式系統開發，多數的快速應用程式開發實踐者察覺到最終還是沒有一個"快速"的方法論可以提供超越其他開發方法論的數量級改進。
各式各樣的快速應用程式開發方法都有潛力提供一個良好的框架用讓改進的程式品質加快產品開發的速度。但實作是否成功或有多大效益則通常取決於產品類型、排程、軟件出版週期，以及企業文化。有趣的是，一些大型軟體廠商如Microsoft[4]以及IBM[5]並不會廣泛的採用快速應用程式開發在其核心產品大部分的開發上，主要還是依賴傳統的瀑布方法論撘配一定程度的螺旋模型來進行開發[6]。
下表列出了一些主要的快速應用程式開發方法以及他們的優劣。
| 優點 | 缺點 | |
|---|---|---|
| 敏捷 軟體開發 |
藉由短期間內以縮影軟體專案的方式完成開發並且持續微量的更新產品來避免功能蔓延（Feature creep）的問題。 | 過短的迭代可能會沒辦法增加足夠的功能，導致在到達最後的迭代前專案產生明顯的延遲。敏捷強調即時通訊（最好是面對面），但在大型多團隊分散式系統開發的情況下，如何達成這點反而是個問題。敏捷方法過程中產生很少的已撰寫文件，因而需要大量的專案後文件。 |
| 極限編程 | 藉由新需求的快速螺旋來減低變更需要花費的成本。多數的設計活動以漸進且即時的方式完成。 | 程式設計師被要求以成對的方式來進行工作，而這對於某些開發人員來說可能是很困難的。因為沒有在前期作詳細規劃，可能會在較長的專案中花費更多精力在重新設計上。在業主在專案的執行過程中持續跟專案成員交互反饋，可能會有導致專案的單點失效的潛在風險以及整個團隊壓力的主要來源。 |
| 聯合應用 程式開發 |
藉由一系列名為聯合應用程式開發會議的合作專題討論會，在應用程式設計與開發的過程中透過客戶的參與來瞭解顧客心聲。 | 顧客可能會創造一個不現實的產品願景，而且要求對產品額外鍍金，率領團隊不足或過度地開發功能。 |
| 精益 軟體開發 |
創造簡約的解決方案（例如，需求決定技術：依據需求決定所採用的技術）並提早提供較少功能的版本（好比"今日的80%遠比明日的100%更好"的範式） | 產品可能會因為核心功能不足或展示的整體品質過差而喪失其競爭優勢。 |
| 快速應用 程式開發 |
促進強化合作氣氛並動態收集相關需求。企業主會主動參與原型製作、撰寫測試個案，以及實施單元測試。 | 需要依賴具有強大凝聚力的團隊以及成員各自對專案的貢獻程度。決策得仰賴特色功能規畫團隊以及與較低程度中央集權化的項目管理及工程權威達成共識的決策過程。 |
| Scrum | 改善團隊先前被過重"行程"壓攤的產能、調整工作優先程度的能力、檢視被積壓的工作並在一系列的短期迭代或衝刺中完成這些項目，並每日檢查進度及維繫彼此間的交流。 | 依賴可能缺乏社交影響力對障礙進行排除或傳達衝刺目標的主管來進行協調的工作。並在依靠團隊自我組織能力以及排斥傳統中央集權"行程管制"的情況，內部彼此的權力對抗可能會癱瘓整個團隊運作。 |
批評
由於快速應用程式開發是一種迭代式的過程，可能會讓原型反覆延續，而無法以令人滿意的成品作結。這樣的失誤可以藉由穩固、彈性，且正確使用的應用程式開發工具加以避免。這樣的情況也被像是80/20法則或其他後敏捷的衍生方法所強調。
快速發展方法論的實際影響
當組織採用快速開發方法時，必須要注意避免角色與權責混淆以及開發團隊內部或是團隊與客戶之間溝通不良。此外，特別是在客戶缺席或是不能參與發展過程中的驗證時，系統分析員應該以客戶的角度參與驗證，來藉此確保能夠適當的關注非功能性需求。此外，任何系統的改進都應該要完成詳細且正式紀錄的設計階段[7]。
參考文獻
延伸閱讀
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
