太多了！終于簽下合同-->得到了“正式”的客戶提供的“需求書”的幾片紙-->憑借自己的理解立即投入開發-->“木已成舟”，生米終于熬成粥-->用戶拒絕接受？-->艱難地修改，反復修改，開發人員厭倦了，而用戶對系統用之無味，棄之可惜，遂成雞肋。-->由此后期收款遙遙無期，軟件公司不再和用戶保持溝通-->互相埋怨，扯皮由此而生。或者，一個項目拆成為多期，從而收取一部分款項，而很多的開發都作廢。這樣的案例真是何其多也！

　　究其主要原因，與其說是沒有搞定關鍵客戶，或者項目管理不當，不如說是沒有幫助客戶解決其問題，對客戶真正的需求研究不夠。實際上，原型方法是解決此類問題、確保項目成功的最佳途徑。 我在寫此文的同時，也試圖尋找資料，不知道是本就沒有，還是自己所不幸而未找到。看來原型并沒有明確的標準，而目前不同軟件公司的理解和做法各不相同也就不奇怪了。但從軟件過程的角度來考察，原型法仍有著通用的優化的做法。試圖從的實踐經驗出發，對原型方法進行思考與探討。

　　另外，是發散型的，在研究原型的同時，也討論了原型相關的內容。原型本質上有些象是拋磚引玉，而也旨在拋磚引玉，但無意于一概地論定什么。

　　2 什么是原型

原型(prototype)即把系統主要功能和接口通過快速開發制作為“軟件樣機”，以可視化的形式展現給用戶，及時征求用戶意見，從而明確無誤地確定用戶需求。同時，原型也可用于征求內部意見，作為分析和設計的接口之一，可方便于溝通。mda.com

原型法主要價值是可視化，強化溝通，降低風險，節省后期變更成本，提高項目成功率。一般來說，采用原型法后可以改進需求質量；雖然投入了較多先期的時間，但可以顯著減少后期變更的時間；原型投入的人力成本代價并不大，但可以節省后期成本；對于較大型的軟件來說，原型系統可以成為開發團隊的藍圖；另外，原型通過充分和客戶交流，還可以提高客戶滿意度。

　　對原型的基本要求包括：

　　* 體現主要的功能；
　　* 提供基本的界面風格；
　　* 展示比較模糊的部分，以便于確認或進一步明確，防患于未然。
　　* 原型最好是可運行的，至少在各主要功能模塊之間能夠建立相互連接。

原型的處理方法基本上有2種不同類型，即拋棄型和演化型（不同的軟件工程書籍稱發不同，實質意義則類似）。可以拋棄原型，在取得的明確需求基礎上重新開始設計與開發；也可在原型的基礎上繼續開發。一般小項目不采用拋棄型原型，否則成本和代價似乎會偏高。

原型的表達工具可以有很多，如果是演化型的原型，當然優先選用軟件本身的開發工具。否則還可以應用各種快速顯示的工具，例如，HTML，Powerpoint等等，只要能夠充分而形象地表達就可以了。

　　根據筆者的經驗，在原型系統中，可以采用一些與常規不同的做法，例如，可以在界面上比較顯著的地方寫明當前模塊或界面的主要目的，由哪些角色操作，能解決其什么問題。這么做可以使得用戶或開發團隊成員一開始就有非常清楚的概念；又如，對于決策分析，你可以直接把一些分析結果畫成圖，并且配上一些文字說明，這樣可以避免輸入大量初始數據，等等。

　　3 原型在軟件過程的地位

　　軟件的根本目的是實現用戶的需求，提供用戶日常使用，解決用戶工作中有所不便的問題，提高其工作效率，改進質量，加強管理控制，最終直接或間接地提高其效益。因此軟件開發本質上就是需求的處理和實現，而軟件原型對需求確定來說具有非常重要的意義。原型方法包括2個基本過程，即原型制作和原型評價。

　　如果從需求角度看軟件過程，我們不妨可以把軟件過程這樣劃分：

搜集需求得到需求說明書，了解軟件要做什么，做成什么樣，解決用戶什么問題。 這時候軟件公司以書面文檔方式提出，例如需求問詢表等。

制定原型開發計劃，根據用戶需求及不確定的高風險部分進行原型開發，在內部進行原型評價，請客戶進行原型評價，以保證確實反映了用戶的真正想法。

當前的軟件開發過程常常采用迭代方式進行開發，逐步求精，以降低風險和成本。對迭代的次數，每次迭代的里程碑，要實現的目標，及可提交的成果必須有可驗證的清晰的計劃。項目管理是一種藝術，迭代規劃及里程碑定義都是一種挑戰、一種藝術，但項目管理不在討論范圍。

需求變更是正常的，也是難免的，應允許用戶和開發團隊自身對需求進行變更。變更處理的關鍵在于跟蹤和控制，如何使產生的影響應得到控制，這屬于配置管理的內容，也不在討論范圍。

原型在軟件過程中的定位如下圖所示

圖1 軟件原型的定位

　　實際上我們可以把原型看得更為廣義一些。任何用戶或者內部演示的材料，都可以看作為原型。例如，如果你的產品是某種通用的或者行業解決方案，雖然你其實還沒有產品，但先做出一個原型，再加一個漂亮的白皮書，就可以在市場上進行預銷售了。