4 原型方法的一般過程
基于原型方法在整個需求過程中的地位，我們需要把原型法和需求處理放在一起進行討論。
在上圖中已經(jīng)清楚地描述了原型的處理過程，值得一提的是，原型不僅用于給用戶或者最終用戶進行評議，同時完全可以在公司內部組織評議，看看我們周圍吧，多數(shù)程序員對技術的興趣遠遠高于對需求的興趣，因此其對系統(tǒng)的理解并不會比市場人員或者項目經(jīng)理理解的深多少。這里的公司內部人員角色可以包括很多，系統(tǒng)分析員/程序員自身、項目經(jīng)理、部門經(jīng)理、用戶代表、領域專家、測試人員等等，不同的角色往往會在其不同立場對系統(tǒng)提出中肯的意見來。
另外值得注意的是界面設計的引入。我們認為將界面風格在原型階段即進行基本確定是一種優(yōu)化的做法，因為軟件前期對界面的確定可以避免后期開發(fā)時對界面進行統(tǒng)一調整所帶來的不必要的成本花費，良好的界面也可以使客戶增加對系統(tǒng)的好感，當然，但愿用戶不要只是欣賞界面而忽略了他們對系統(tǒng)功能的思考。要知道，如果僅僅是讓用戶看到美觀的界面，那么整個原型幾乎是白做了。
5 使用原型方法的相關問題探討
5.1 為什么要采用原型法？
原型對一個項目取得成功具有重要的意義。俗話說：隔行如隔山，實際上軟件公司很難保證其制作的軟件正好就是用戶所需要的，用戶也很難一次性把其真實的要求完全提交，開始階段提出的往往只是對系統(tǒng)的期望，和比較模糊的設想而已。而原型系統(tǒng)為用戶提供了一個靶子，看著原型系統(tǒng)，用戶往往就能進一步提出他們的真正想法。顯然軟件公司明確用戶需求的最佳方式就是為用戶提供原型并由用戶進行評價。
也許，跳過原型可以節(jié)省時間和前期成本，但你應該注意到，跳過原型的話，后期變更的成本會明顯增加。
5.2 為什么在需求說明書之外需要原型？
1）眼見為實，文字具有歧義性，不同的人理解都不相同；
2）最終用戶往往在看到一套可運行的系統(tǒng)的基礎上，才可能提出其真實的意見，如果到最終提交時才看到這樣的系統(tǒng)就為時太晚。這也是以前無數(shù)軟件開發(fā)留下的教訓；
3）便于發(fā)現(xiàn)問題，及時糾正；
4）便于進一步展開，并取得用戶的細節(jié)需求；
5）體現(xiàn)原型的其它功能：便于公司內部如經(jīng)理、市場部等對軟件提出意見，便于開發(fā)人員對整個產品達成統(tǒng)一認識，等等。對內部人員來說，同樣地，一套形象的原型也遠勝過一堆專業(yè)術語文字；也就是說，原型對軟件公司內部也十分重要。這些評價工作無形之中改進了項目質量。
5.3 原型方法有什么風險？
任何方法都是有利有弊，在我們可以探討一下原型方法可能存在的風險。以下是一般軟件公司所擔心的風險：需要付出前期進度和人力成本；由于程序員對問題的不了解而效率低下，受客戶牽制而在原型上反復修改；因為倉促設計而做不利于進一步在其基礎上繼續(xù)開發(fā)；由于過早展示原型給客戶，使得客戶可能提高其期望值，并提出更多離譜的要求，等等。
值得一提的是原型方法的主要價值之一就是盡早揭示軟件中可能存在的風險及不確定因素，尤其是關于用戶需求一致性方面的風險。
5.4 原型方法和其它方法或過程的關系如何，是否一致？
生命周期法中并不包括原型，或者說沒有明確提供原型的概念和定義。原型可以認為是需求分析中的一個子部分。另外，應該說原型方法是對生命周期法的有益補充和完善。
RUP中是最優(yōu)化的統(tǒng)一軟件過程，但RUP中似乎沒有提到原型，RUP的核心過程是在迭代中精化。我個人的見解是，原型非常類似于第一次迭代的過程和結果。實際上，如果把原型看作為第一輪交付的成果，那么原型的很多不利之處，諸如花費前期成本等等，這些擔心都將變得不復存在。
XP方法對原型非常推崇，這是因為XP方法非常強調需求的重要性