原型化方法，即Prototyping，為彌補瀑布模型的不足而產生的。
基本介紹
- 中文名：原型化方法
- 外文名：Prototyping
產生過程：
傳統軟體生存期模型的典型代表是“瀑布模型"。這種模型將軟體生存期劃分為若干階段，根據不同階段工作的特點，運用不同的方法、技術和工具來完成該階段的任務。軟體人員遵循嚴格的規範，在每一階段工作結束時都要進行嚴格的階段評審和確認，以得到該階段的一致、完整、正確和無多義性的文檔，把這些文檔作為階段結束的標誌“凍結"起來，並以它們作為下一階段工作的基礎，從而保證軟體的質量。
傳統思想之所以強調每一階段的嚴格性，尤其是開發初期要有良好的軟體規格說明，主要是源於過去軟體開發的經驗教訓，即在開發的後期或運行維護期間，修改不完善的規格說明要付出巨大的代價。因此人們投入極大的努力來加強各階段活動的嚴格性，特別是前期的需求分析階段，希望得到完善的規格說明以減少後期難以估量的經濟損失。
但是，很難得到一個完整準確的規格說明。特別是對於一些大型的軟體項目，在開發的早期用戶往往對系統只有一個模糊的想法，很難完全準確地表達對系統的全面要求，軟體人員對於所要解決的套用問題認識更是模糊不清。經過詳細的討論和分析，也許能得到一份較好的規格說明，但卻很難期望該規格說明能將系統的各個方面都描述得完整、準確、一致，並與實際環境相符。很難通過它在邏輯上推斷出(不是在實際運行中判斷評價)系統運行的效果，以此達到各方對系統的共同理解。隨著開發工作向前推進，用戶可能會產生新的要求，或因環境變化，要求系統也能隨之變化；開發者又可能在設計與實現的過程中遇到一些沒有預料到的實際困難，需要以改變需求來解脫困境。因此規格說明難以完善、需求的變更、以及通信中的模糊和誤解，都會成為軟體開發順利推進的障礙。儘管在傳統軟體生存期管理中通過加強評審和確認，全面測試來緩解上述問題，但不能從根本上解決這些問題。
為了解決這些問題，逐漸形成了軟體系統的快速原型的概念。在形成一組基本需求之後，通過快速分析方法構造出待建的原型版本，然後根據顧客在使用原型的過程中提出的意見對原型進行修改，從而得到原型的更新版本，這一過程重複進行，直至得到滿足顧客需求的系統。
總體來說，原型化方法是用戶和軟體開發人員之間進行的一種互動過程，適用於需求不確定性高的系統。它從用戶界面的開發入手，首先形成系統界面原型，用戶運行用戶界面原型，並就同意什麼和不同意什麼提出意見，它是一種自外向內型的設計過程。
