快速原型模型

快速原型模型需要迅速建造一個可以運行的軟體原型 ，以便理解和澄清問題，使開發人員與用戶達成共識，最終在確定的客戶需求基礎上開發客戶滿意的軟體產品。 快速原型模型允許在需求分析階段對軟體的需求進行初步而非完全的分析和定義，快速設計開發出軟體系統的原型，該原型向用戶展示待開發軟體的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟體需求；開發人員據此對軟體進行修改完善，直至用戶滿意認可之後，進行軟體的完整實現及測試、維護。

基本介紹

• 中文名：快速原型模型
• 外文名：Rapid Prototype Model

模型簡述

原型是指模擬某種產品的原始模型，在其他產業中經常使用。軟體開發中的原型是軟體的一個早期可運行的版本，它反映了最終系統的重要特性。

快速原型模型又稱原型模型，它是增量模型的另一種形式；它是在開發真實系統之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統的開發工作。快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的互動，用戶或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。

優缺點

優點：克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險。

這種模型適合預先不能確切定義需求的軟體系統的開發。

缺點：所選用的開發技術和工具不一定符合主流的發展；快速建立起來的系統結構加上連續的修改可能會導致產品質量低下。

使用這個模型的前提是要有一個展示性的產品原型，因此在一定程度上可能會限制開發人員的創新。

產生原理

思想的產生

由於種種原因，在需求分析階段得到完全、一致、準確、合理的需求說明是很困難的，在獲得一組基本需求說明後，就快速地使其“實現”，通過原型反饋，加深對系統的理解，並滿足用戶基本要求，使用戶在試用過程中受到啟發，對需求說明進行補充和精確化，消除不協調的系統需求，逐步確定各種需求，從而獲得合理、協調一致、無歧義的、完整的、現實可行的需求說明。又把快速原型思想用到軟體開發的其他階段，向軟體開發的全過程擴展。即先用相對少的成本，較短的周期開發一個簡單的、但可以運行的系統原型向用戶演示或讓用戶試用，以便及早澄清並檢驗一些主要設計策略，在此基礎上再開發實際的軟體系統。

原理

快速原型是利用原型輔助軟體開發的一種新思想。經過簡單快速分析，快速實現一個原型，用戶與開發者在試用原型過程中加強通信與反饋，通過反覆評價和改進原型，減少誤解，彌補漏洞，適應變化，最終提高軟體質量。

模型類型

探索型原型

這種類型的原型是把原型用於開發的需求分析階段，目的是要弄清用戶的需求，確定所期望的特性，並探索各種方案的可行性。它主要針對開發目標模糊，用戶與開發都對項目都缺乏經驗的情況，通過對原型的開發來明確用戶的需求。

實驗型原型

這種原型主要用於設計階段，考核實現方案是否合適，能否實現。對於一個大型系統，若對設計方案心中沒有把握時，可通過這種原型來證實設計方案的正確性。

演化型原型

這種原型主要用於及早向用戶提交一個原型系統，該原型系統或者包含系統的框架，或者包含系統的主要功能，在得到用戶的認可後，將原型系統不斷擴充演變為最終的軟體系統。它將原型的思想擴展到軟體開發的全過程。

運用方式

由於運用原型的目的和方式不同，在使用原型時也採取不同的策略，有拋棄策略和附加策略。

1、拋棄策略是將原型用於開發過程的某個階段，促使該階段的開發結果更加完整、準確、一致、可靠，該階段結束後，原型隨之作廢。探索型和實驗型就是採用此策略的。

2、附加策略是將原型用於開發的全過程，原型由最基本的核心開始，逐步增加新的功能和新的需求，反覆修改反覆擴充，最後發展為用戶滿意的最終系統，演化型快速原型就是採用此策略。

採用何種形式、何種策略運用快速原型主要取決於軟體項目的特點、人員素質、可供支持的原型開發工具和技術等，這要根據實際情況的特點來決定。

開發步驟

快速分析

在分析人員與用戶密切配合下，迅速確定系統的基本需求，根據原型所要體現的特徵描述基本需求以滿足開發原型的需要。

構造原型

在快速分析的基礎上，根據基本需求說明儘快實現一個可行的系統。這裡要求具有強有力的軟體工具的支持，並忽略最終系統在某些細節上的要求，如安全性、堅固性、例外處理等等，主要考慮原型系統能夠充分反映所要評價的特性，而暫時刪除一切次要內容。

運行原型

這是發現問題、消除誤解、開發者與用戶充分協調的一個步驟。

評價原型

在運行的基礎上，考核評價原型的特性，分析運行效果是否滿足用戶的願望，糾正過去互動中的誤解與分析中的錯誤，增添新的要求，並滿足因環境變化或用戶的新想法引起的系統要求變動，提出全面的修改意見。

修改

根據評價原型的活動結果進行修改。若原型未滿足需求說明的要求，說明對需求說明存在不一致的理解或實現方案不夠合理，則根據明確的要求迅速修改原型。

模型對比

傳統的瀑布模型本質上是一種線性順序模型，存在著比較明顯的缺點，各階段之間存在著嚴格的順序性和依賴性，特別是強調預先定義需求的重要性，在著手進行具體的開發工作之前，必須通過需求分析預先定義並“凍結”軟體需求，然後再一步一步的實現這些需求。但是實際項目很少是遵循著這種線性順序進行的。在系統建立之前很難只依靠分析就確定出一套完整、準確、一致和有效的用戶需求，這種預先定義需求的方法更不能適套用戶需求不斷變化的情況。

用戶的不斷變化的需求具體表現在:。

(1)需求是可變的。某些套用軟體的需求與外部環境、經營內容等密切相關，因此需求是隨時變化的，按照這樣預先指定的需求開發軟體，當軟體開發出來的時候就往往已經過時，不符合用戶的需要。

(2)需求是模糊的。對於大多數的套用系統，例如管理信息系統，其需求往往很難預先準確的定義，也就是說，預先定義需求的策略所做出的假設，只對某些軟體成立，對多數軟體並不成立。許多用戶對他們的需求最初只有模糊的概念，想要求一個對需求只有初步構想的人準確無誤的說出全部需求，顯然是不切實際的。

(3)用戶和開發者溝通困難。大多數用戶和專業領域的專家不熱悉計算機和軟體開發技術，軟體開發人員也往往不熟悉用戶的專業領域，因此，開發人員和用戶之間很難做到完全溝通和相互理解，在需求分析階段做出的用戶需求常常是不完整、不準確的。

傳統的瀑布模型很難適應需求可變、模糊不定的軟體系統的開發，而且在開發過程中，用戶很難參與進去，只有到開發結束才能看到整個軟體系統。這種理想的、線性的開發過程，缺乏靈活性，不適合實際的開發過程。

而快速原型模型的提出，可以較好的解決瀑布模型的局限性，通過建立原型，可以更好的和客戶進行溝通，解決對一些模糊需求的澄清，並且對需求的變化有較強的適應能力。原型模型可以減少技術、套用的風險，縮短開發時間，減少費用，提高生產率，通過實際運行原型，提供了用戶直接評價系統的方法，促使用戶主動參與開發活動，加強了信息的反饋，促進了各類人員的協調交流，減少誤解，能夠適應需求的變化，最終有效提高軟體系統的質量。