4 原型方法的一般過程
基于原型方法在整個需求過程中的地位，我們需要把原型法和需求處理放在一起進行討論。在上圖中已經清楚地描述了原型的處理過程，值得一提的是，原型不僅用于給用戶或者最終用戶進行評議，同時完全可以在公司內部組織評議，看看我們周圍吧，多數程序員對技術的興趣遠遠高于對需求的興趣，因此其對系統的理解并不會比市場人員或者項目經理理解的深多少。這里的公司內部人員角色可以包括很多，系統分析員/程序員自身、項目經理、部門經理、用戶代表、領域專家、測試人員等等，不同的角色往往會在其不同立場對系統提出中肯的意見來。
另外值得注意的是界面設計的引入。我們認為將界面風格在原型階段即進行基本確定是一種優化的做法，因為軟件前期對界面的確定可以避免后期開發時對界面進行統一調整所帶來的不必要的成本花費，良好的界面也可以使客戶增加對系統的好感，當然，但愿用戶不要只是欣賞界面而忽略了他們對系統功能的思考。要知道，如果僅僅是讓用戶看到美觀的界面，那么整個原型幾乎是白做了。
5 使用原型方法的相關問題探討
5.1 為什么要采用原型法？
原型對一個項目取得成功具有重要的意義。俗話說：隔行如隔山，實際上軟件公司很難保證其制作的軟件正好就是用戶所需要的，用戶也很難一次性把其真實的要求完全提交，開始階段提出的往往只是對系統的期望，和比較模糊的設想而已。而原型系統為用戶提供了一個靶子，看著原型系統，用戶往往就能進一步提出他們的真正想法。顯然軟件公司明確用戶需求的最佳方式就是為用戶提供原型并由用戶進行評價。
也許，跳過原型可以節省時間和前期成本，但你應該注意到，跳過原型的話，后期變更的成本會明顯增加。
5.2 為什么在需求說明書之外需要原型？
1）眼見為實，文字具有歧義性，不同的人理解都不相同；
2）最終用戶往往在看到一套可運行的系統的基礎上，才可能提出其真實的意見，如果到最終提交時才看到這樣的系統就為時太晚。這也是以前無數軟件開發留下的教訓；
3）便于發現問題，及時糾正；
4）便于進一步展開，并取得用戶的細節需求；
5）體現原型的其它功能：便于公司內部如經理、市場部等對軟件提出意見，便于開發人員對整個產品達成統一認識，等等。對內部人員來說，同樣地，一套形象的原型也遠勝過一堆專業術語文字；也就是說，原型對軟件公司內部也十分重要。這些評價工作無形之中改進了項目質量。
5.3 原型方法有什么風險？
任何方法都是有利有弊，在我們可以探討一下原型方法可能存在的風險。以下是一般軟件公司所擔心的風險：需要付出前期進度和人力成本；由于程序員對問題的不了解而效率低下，受客戶牽制而在原型上反復修改；因為倉促設計而做不利于進一步在其基礎上繼續開發；由于過早展示原型給客戶，使得客戶可能提高其期望值，并提出更多離譜的要求，等等。
值得一提的是原型方法的主要價值之一就是盡早揭示軟件中可能存在的風險及不確定因素，尤其是關于用戶需求一致性方面的風險。
5.4 原型方法和其它方法或過程的關系如何，是否一致？
生命周期法中并不包括原型，或者說沒有明確提供原型的概念和定義。原型可以認為是需求分析中的一個子部分。另外，應該說原型方法是對生命周期法的有益補充和完善。
RUP中是最優化的統一軟件過程，但RUP中似乎沒有提到原型，RUP的核心過程是在迭代中精化。我個人的見解是，原型非常類似于第一次迭代的過程和結果。實際上，如果把原型看作為第一輪交付的成果，那么原型的很多不利之處，諸如花費前期成本等等，這些擔心都將變得不復存在。
XP方法對原型非常推崇，這是因為XP方法非常強調需求的重要性，甚至要求客戶參與開發過程。但原型方法和XP也有區別。XP是分批交付，先做一個幾個功能點的版本，完成后再每個開發周期往上面加其它功能點，而原型法一般要求做出比較完整，能覆蓋主要功能點的粗略的版本。XP方法仁者見仁，智者見智，不一而舉。
5.5 如何避免項目團隊做原型的時候出現部分人員閑置？
在項目管理中，對人力資源的調配應和項目進展相匹配。實際上在用戶接觸到原型制作的同時，可以進行項目計劃、架構設計、技術培訓以及技術難點攻關等等。
如果從廣義上理解原型的話，架構設計者甚至可以設計出一種用戶開發團隊使用的所謂框架原型，包含了主要的設計成分、模板和示例。
比較理想的結果是，當原型完成后，需求分析、架構設計和界面風格設計都趨于完成，從這一點可以看到，原型方法可以作為快速軟件開發的重要手段。
5.6 如果避免項目在原型上停滯不前？
應使用有經驗的開發人員，避免因為程序員不熟悉業務而延誤進度；不要在界面設計上猶豫不決而占據時間；如果用戶對原型提出了很多意見，其中部分比較明確的意見可以在開發過程中進行實現；和客戶的交流應該簡潔明了，而不是似是而非；另外，原型方法在項目過程中占據的時間應該在項目計劃中保留出來，而不僅僅是隱含在需求調研與分析的一個部分。
5.7 如何避免用戶看了原型后漫無邊際地提要求？
首先，應該充分尊重客戶，想想其它行業的服務質量吧。有沒有聽說過這樣的說法，項目管理也是客戶滿意度的管理；軟件是一種對客戶的關懷，等等。確實，客戶提出的思路可能和你已經形成的思路不同，一下子打亂了你的思路，也許項目經理并不介意，但這確是讓設計者特別心煩的事情。如果確有把握，或者你可以不做到原型中去。有時候，即使原型很完美，用戶也會額外地提出一些意見，這也是人之常情。但不管怎樣，你不能認為用戶根本不懂軟件，讓他們到時用就行了，抱這樣想法的多半會付出代價。
其次應該進行坦誠協商，多數用戶其實都是通情達理的。如果你在簽訂合同時答應滿足任何要求，而此時又無法忍受用戶的要求，那么孰是孰非應是題外之意了。一般來說，比較合理的做法可以通過增加費用、延長進度或者把需求實現分階段來提交，以保持工作的延續性。對有些軟件，尤其是信息管理系統來說，客戶的實施時間其實并不是主要的，客戶最需要的不是及時，而是合用。
其實，客戶有著很多種類型，確實，個別客戶會參考同類產品來提要求，極個別用戶并不真正懂得計算機技術而對技術路線、技術手段等提出其意見，等等。但我們為什么還可以反過來想一下，如果是等到軟件全部提交的時候，這部分用戶仍有會提出同樣的意見。提早暴露并解決分歧，對雙方睹是有利的。如果軟件公司明知可能存在矛盾，仍然先做好，然后等到用戶提出反對后，再提出補充收費，如果喜歡，也無話可說。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
