模型簡述
原型是指模擬某種產品的原始模型，在其他產業中經常使用。軟體開發中的原型是軟體的一個早期可運行的版本，它反映了最終系統的重要特性。
快速原型模型又稱原型模型，它是增量模型的另一種形式；它是在開發真實系統之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統的開發工作。快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的互動，用戶或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。
優缺點
優點：克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險。
這種模型適合預先不能確切定義需求的軟體系統的開發。
缺點：所選用的開發技術和工具不一定符合主流的發展；快速建立起來的系統結構加上連續的修改可能會導致產品質量低下。
使用這個模型的前提是要有一個展示性的產品原型，因此在一定程度上可能會限制開發人員的創新。
產生原理
思想的產生
由於種種原因，在需求分析階段得到完全、一致、準確、合理的需求說明是很困難的，在獲得一組基本需求說明後，就快速地使其“實現”，通過原型反饋，加深對系統的理解，並滿足用戶基本要求，使用戶在試用過程中受到啟發，對需求說明進行補充和精確化，消除不協調的系統需求，逐步確定各種需求，從而獲得合理、協調一致、無歧義的、完整的、現實可行的需求說明。又把快速原型思想用到軟體開發的其他階段，向軟體開發的全過程擴展。即先用相對少的成本，較短的周期開發一個簡單的、但可以運行的系統原型向用戶演示或讓用戶試用，以便及早澄清並檢驗一些主要設計策略，在此基礎上再開發實際的軟體系統。
原理
快速原型是利用原型輔助軟體開發的一種新思想。經過簡單快速分析，快速實現一個原型，用戶與開發者在試用原型過程中加強通信與反饋，通過反覆評價和改進原型，減少誤解，彌補漏洞，適應變化，最終提高軟體質量。
模型類型
探索型原型
這種類型的原型是把原型用於開發的需求分析階段，目的是要弄清用戶的需求，確定所期望的特性，並探索各種方案的可行性。它主要針對開發目標模糊，用戶與開發都對項目都缺乏經驗的情況，通過對原型的開發來明確用戶的需求。
實驗型原型
這種原型主要用於設計階段，考核實現方案是否合適，能否實現。對於一個大型系統，若對設計方案心中沒有把握時，可通過這種原型來證實設計方案的正確性。
演化型原型
這種原型主要用於及早向用戶提交一個原型系統，該原型系統或者包含系統的框架，或者包含系統的主要功能，在得到用戶的認可後，將原型系統不斷擴充演變為最終的軟體系統。它將原型的思想擴展到軟體開發的全過程。
運用方式
由於運用原型的目的和方式不同，在使用原型時也採取不同的策略，有拋棄策略和附加策略。
1、拋棄策略是將原型用於開發過程的某個階段，促使該階段的開發結果更加完整、準確、一致、可靠，該階段結束後，原型隨之作廢。探索型和實驗型就是採用此策略的。
2、附加策略是將原型用於開發的全過程，原型由最基本的核心開始，逐步增加新的功能和新的需求，反覆修改反覆擴充，最後發展為用戶滿意的最終系統，演化型快速原型就是採用此策略。
採用何種形式、何種策略運用快速原型主要取決於軟體項目的特點、人員素質、可供支持的原型開發工具和技術等，這要根據實際情況的特點來決定。
開發步驟
快速分析
在分析人員與用戶密切配合下，迅速確定系統的基本需求，根據原型所要體現的特徵描述基本需求以滿足開發原型的需要。
構造原型
在快速分析的基礎上，根據基本需求說明儘快實現一個可行的系統。這裡要求具有強有力的軟體工具的支持，並忽略最終系統在某些細節上的要求，如安全性、堅固性、例外處理等等，主要考慮原型系統能夠充分反映所要評價的特性，而暫時刪除一切次要內容。
運行原型
這是發現問題、消除誤解、開發者與用戶充分協調的一個步驟。
評價原型
在運行的基礎上，考核評價原型的特性，分析運行效果是否滿足用戶的願望，糾正過去互動中的誤解與分析中的錯誤，增添新的要求，並滿足因環境變化或用戶的新想法引起的系統要求變動，提出全面的修改意見。
修改
根據評價原型的活動結果進行修改。若原型未滿足需求說明的要求，說明對需求說明存在不一致的理解或實現方案不夠合理，則根據明確的要求迅速修改原型。
模型對比
傳統的瀑布模型本質上是一種線性順序模型，存在著比較明顯的缺點，各階段之間存在著嚴格的順序性和依賴性，特別是強調預先定義需求的重要性，在著手進行具體的開發工作之前，必須通過需求分析預先定義並“凍結”軟體需求，然後再一步一步的實現這些需求。但是實際項目很少是遵循著這種線性順序進行的。在系統建立之前很難只依靠分析就確定出一套完整、準確、一致和有效的用戶需求，這種預先定義需求的方法更不能適套用戶需求不斷變化的情況。
用戶的不斷變化的需求具體表現在:。
(1)需求是可變的。某些套用軟體的需求與外部環境、經營內容等密切相關，因此需求是隨時變化的，按照這樣預先指定的需求開發軟體，當軟體開發出來的時候就往往已經過時，不符合用戶的需要。
(2)需求是模糊的。對於大多數的套用系統，例如管理信息系統，其需求往往很難預先準確的定義，也就是說，預先定義需求的策略所做出的假設，只對某些軟體成立，對多數軟體並不成立。許多用戶對他們的需求最初只有模糊的概念，想要求一個對需求只有初步構想的人準確無誤的說出全部需求，顯然是不切實際的。
(3)用戶和開發者溝通困難。大多數用戶和專業領域的專家不熱悉計算機和軟體開發技術，軟體開發人員也往往不熟悉用戶的專業領域，因此，開發人員和用戶之間很難做到完全溝通和相互理解，在需求分析階段做出的用戶需求常常是不完整、不準確的。
傳統的瀑布模型很難適應需求可變、模糊不定的軟體系統的開發，而且在開發過程中，用戶很難參與進去，只有到開發結束才能看到整個軟體系統。這種理想的、線性的開發過程，缺乏靈活性，不適合實際的開發過程。
而快速原型模型的提出，可以較好的解決瀑布模型的局限性，通過建立原型，可以更好的和客戶進行溝通，解決對一些模糊需求的澄清，並且對需求的變化有較強的適應能力。原型模型可以減少技術、套用的風險，縮短開發時間，減少費用，提高生產率，通過實際運行原型，提供了用戶直接評價系統的方法，促使用戶主動參與開發活動，加強了信息的反饋，促進了各類人員的協調交流，減少誤解，能夠適應需求的變化，最終有效提高軟體系統的質量。
