快速原型模型
出自 MBA智库百科(https://wiki.mbalib.com/)
快速原型模型（Rapid Prototype Model）
目錄 |
原型是指模擬某種產品的原始模型，在其他產業中經常使用。軟體開發中的原型是軟體的一個早期可運行的版本，它反映了最終系統的重要特性。
快速原型模型又稱原型模型，它是增量模型的另一種形式；它是在開發真實系統之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統的開發工作。例如，客戶需要一個ATM機軟體，可以先設計一個僅包含刷卡、密碼檢測、數據輸入和賬單列印的原型軟體提供給客戶，此時還不包括網路處理與資料庫存取以及數據應急、故障處理等服務。快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。
快速原型模型的思想產生、原理及運用方式 [1]
1、快速原型模型思想的產生
由於種種原因，在需求分析階段得到完全、一致、準確、合理的需求說明是很困難的，在獲得一組基本需求說明後，就快速地使其“實現”，通過原型反饋，加深對系統的理解，並滿足用戶基本要求，使用戶在試用過程中受到啟發，對需求說明進行補充和精確化，消除不協調的系統需求，逐步確定各種需求，從而獲得合理、協調一致、無歧義的、完整的、現實可行的需求說明。又把快速原型思想用到軟體開發的其他階段，向軟體開發的全過程擴展。即先用相對少的成本，較短的周期開發一個簡單的、但可以運行的系統原型向用戶演示或讓用戶試用，以便及早澄清並檢驗一些主要設計策略，在此基礎上再開發實際的軟體系統。
2、快速原型模型的原理
快速原型是利用原型輔助軟體開發的一種新思想。經過簡單快速分析，快速實現一個原型，用戶與開發者在試用原型過程中加強通信與反饋，通過反覆評價和改進原型，減少誤解，彌補漏洞，適應變化，最終提高軟體質量。
3、原型運用方式
由於運用原型的目的和方式不同，在使用原型時也採取不同的策略，有拋棄策略和附加策略。
①拋棄策略是將原型用於開發過程的某個階段，促使該階段的開髮結果更加完整、準確、一致、可靠，該階段結束後，原型隨之作廢。探索型和實驗型就是採用此策略的。
②附加策略是將原型用於開發的全過程，原型由最基本的核心開始，逐步增加新的功能和新的需求，反覆修改反覆擴充，最後發展為用戶滿意的最終系統，演化型快速原型就是採用此策略。
採用何種形式、何種策略運用快速原型主要取決於軟體項目的特點、人員素質、可供支持的原型開發工具和技術等，這需要根據實際情況的特點來決定。
根據原型的不同作用,有三類原型模型:
1、探索型原理
這種類型的原型是把原型用於開發的需求分析階段，目的是要型清用戶的需求，確定所期望的特性，並探索各種方案的可行性。它主要針對開發目標模糊，用戶與開發都對項目都缺乏經驗的情況，通過對原型的開發來明確用戶的需求。
2、實驗型原型
這種原型主要用於設計階段，考核；實現方案是否合適，能否實陋。對於一個大型系統，若對設計方案心中沒有把握時，可通過這種原型來證實設計方案的正確性。
3、演化型原型
這種原型主要用於及早向用戶提交一個原型系統，該原型系統或者包含系統的框架，或者包含系統的主要功能，在得到用戶的認可後，將原型系統不斷擴充演變為最終的軟體系統。它將原型的思想擴展到軟體開發的全過程。
1、快速分析
在分析人員與用戶密切配合下，迅速確定系統的基本需求，根據原型所要體現的特征描述基本需求以滿足開發原型的需要。
2、構造原型
在快速分析的基礎上，根據基本需求說明儘快實現一個可行的系統。這裡要求具有強有力的軟體工具的支持，並忽略最終系統在某些細節上的要求，如安全性、堅固性、例外處理等等，主要考慮原型系統能夠充分反映所要評價的特性，而暫時刪除一切次要內容。
3、運行原型
這是發現問題、消除誤解、開發者與用戶充分協調的一個步驟。
4、評價原型
在運行的基礎上，考核評價原型的特性，分析運行效果是否滿足用戶的願望，糾正過去交互中的誤解與分析中的錯誤，增添新的要求，並滿足因環境變化或用戶的新想法引起的系統要求變動，提出全面的修改意見。
5、修改
根據評價原型的活動結果進行修改。若原型未滿足需求說明的要求，說明對需求說明存在不一致的理解或實現方案不夠合理，則根據明確的要求迅速修改原型。
快速原型的開發技術和開發環境[1]
為了節省開發原型的費用，實現快速地分析，迅速構造出所需的原型，應採用一些特殊的有別於通常軟體開發時使用的技術和工具。
1．構造原型的技術
(1)可執行的規格說明。
(2)基於腳本的設計。
(3)採用非常高級語言或專門語言。
(4)能重用軟體。
2．構造原型的建議
(1)暫不考慮速度、空間等性能效率方面的要求。
(2)暫不考慮錯誤恢復和處理。
(3)可降低可靠性和軟體質量標準。
(4)原型界面部分要設計得簡單易學，最好能與最終系統的界面相容。
(5)根據不同的軟體類型和應用領域，可使用不同風格的高級語言來構造原型。
3．原型的開發環境
除了上述的構造原型的技術和建議外，還應該有開發環境來輔助原型的開發。
(1)互動式系統。能快速響應使用者的要求。
(2)資料庫管理系統。能夠提供更多工具，可以定義、建立、查詢、加工信息資源。
(3)通用輸入／輸出軟體。容易使用的數據編輯，屏幕格式化軟體等對原型設計和開發都有很大的幫助。
(4)重用代碼庫。可減少重覆勞動。
各種軟體過程模型的特點[2]
不同的軟體過程模型對軟體開發過程有不同的理解和認識，支持不同的軟體項目和開發組織。下表對比和分析了各個軟體過程模型的特點及其適用的軟體項目類型。
各種軟體過程模型的特點
| 模型名稱 | 技術特點 | 適用範圍 |
|---|---|---|
| 瀑布模型 | 簡單，分階段，階段間存在因果關係，
各個階段完成後都有評審，允許反饋，不支持 用戶參與，要求預先確定需求 | 需求易於完善定義且不易變更的軟體系統 |
| 快速原型模型 | 不要求需求預先完備定義，支持用戶參與，
支持需求的漸進式完善和確認，能夠適應用戶需求的變化 | 需求複雜、難以確定、動態變化的軟體系統 |
| 增量模型 | 軟體產品是被增量式地一塊塊開發的，
允許開發活動並行和重疊 | 技術風險較大、用戶需求較為穩定的軟體系統 |
| 迭代模型 | 不要求一次性地開發出完整的軟體系統，將軟體
開發視為一個逐步獲取用廣需求、完善軟體產品的過程 | 需求難以確定、不斷變更的軟體系統 |
| 螺旋模型 | 結合瀑布模型、快速原型模型和迭代模
型的思想，並引進了風險分析活動 | 需求難以獲取和確定、軟體開發風險較大的軟體系統 |
| RUP | 可改造、擴展和剪裁：可以對它進行設計、
開發、維護和發佈；強調迭代開發 | 複雜和需求難以獲取和確定的軟體系統；
軟體開發項目組擁有豐富的軟體開發和管理經驗 |
錯別字太多啦， 這是要考研我們的容錯能力呢嗎？