[說明一下： 這文章本來是一個叫blueski的人寫的， 我在一個系統分析員朋友那里發現的�？吹臅r候讓我非常深入，因為他說的和我做的基本上完全是一樣的，，太一樣了。這個人可能和我現在的工作時一樣的。。 所以就自己修改了些 增加了些發給大家一起討論討論 ]
1 引子
競爭對手太多了！終于簽下合同-->得到了“正式”的客戶提供的“需求書”的幾片紙-->憑借自己的理解立即投入開發-->“木已成舟”，生米終于熬成粥-->用戶拒絕接受？-->艱難地修改，反復修改，開發人員厭倦了，而用戶對系統用之無味，棄之可惜，遂成雞肋。-- >由此后期收款遙遙無期，軟件公司不再和用戶保持溝通-->互相埋怨，扯皮由此而生�；蛘�，一個項目拆成為多期，從而收取一部分款項，而很多的開發都作廢。這樣的案例真是何其多也！
究其主要原因，與其說是沒有搞定關鍵客戶，或者項目管理不當，不如說是沒有幫助客戶解決其問題，對客戶真正的需求研究不夠。實際上，原型方法是解決此類問題、確保項目成功的最佳途徑。
我在寫此文的同時，也試圖尋找資料，不知道是本就沒有，還是自己所不幸而未找到�？磥碓筒]有明確的標準，而目前不同軟件公司的理解和做法各不相同也就不奇怪了。但從軟件過程的角度來考察，原型法仍有著通用的優化的做法。本文試圖從作者的實踐經驗出發，對原型方法進行思考與探討。
另外，本文是發散型的，在研究原型的同時，也討論了原型相關的諶蕁Ｔ捅局噬嫌行┫笫橋鬃┮�，而本文覀}莢諗鬃┮�，但螕烩诱浕钢Z羋鄱ㄊ裁礎?lt;/P>
2 什么是原型
2.1 原型的定義
原型(prototype)即把系統主要功能和接口通過快速開發制作為“軟件樣機”，以可視化的形式展現給用戶，及時征求用戶意見，從而明確無誤地確定用戶需求。同時，原型也可用于征求內部意見，作為分析和設計的接口之一，可方便于溝通。
2.2 原型的主要價值
原型法主要價值是可視化，強化溝通，降低風險，節省后期變更成本，提高項目成功率。一般來說，采用原型法后可以改進需求質量；雖然投入了較多先期的時間，但可以顯著減少后期變更的時間；原型投入的人力成本代價并不大，但可以節省后期成本；對于較大型的軟件來說，原型系統可以成為開發團隊的藍圖；另外，原型通過充分和客戶交流，還可以提高客戶滿意度。
2.3 基本要求
對原型的基本要求包括：
* 體現主要的功能；
* 提供基本的界面風格；
* 展示比較模糊的部分，以便于確認或進一步明確，防患于未然。
* 原型最好是可運行的，至少在各主要功能模塊之間能夠建立相互連接。
2.4 處理方法
原型的處理方法基本上有2種不同類型，即拋棄型和演化型（不同的軟件工程書籍稱發不同，實質意義則類似）�？梢話仐壴�，在取得的明確需求基礎上重新開始設計與開發；也可在原型的基礎上繼續開發。一般小項目不采用拋棄型原型，否則成本和代價似乎會偏高。
2.5 表達工具
原型的表達工具可以有很多，如果是演化型的原型，當然優先選用軟件本身的開發工具。否則還可以應用各種快速顯示的工具，例如，HTML，Powerpoint等等，只要能夠充分而形象地表達就可以了。
根據筆者的經驗，在原型系統中，可以采用一些與常規不同的做法，例如，可以在界面上比較顯著的地方寫明當前模塊或界面的主要目的，由哪些角色操作，能解決其什么問題。這么做可以使得用戶或開發團隊成員一開始就有非常清楚的概念；又如，對于決策分析，你可以直接把一些分析結果畫成圖，并且配上一些文字說明，這樣可以避免輸入大量初始數據，等等。
3 原型在軟件過程的地位
軟件的根本目的是實現用戶的需求，提供用戶日常使用，解決用戶工作中有所不便的問題，提高其工作效率，改進質量，加強管理控制，最終直接或間接地提高其效益。因此軟件開發本質上就是需求的處理和實現，而軟件原型對需求確定來說具有非常重要的意義。原型方法包括2個基本過程，即原型制作和原型評價。
如果從需求角度看軟件過程，我們不妨可以把軟件過程這樣劃分：
3.1 需求收集和分析
搜集需求得到需求說明書，了解軟件要做什么，做成什么樣，解決用戶什么問題。
這時候軟件公司以書面文檔方式提出，例如需求問詢表等。
3.2 提供原型并進行評價
制定原型開發計劃，根據用戶需求及不確定的高風險部分進行原型開發，在內部進行原型評價，請客戶進行原型評價，以保證確實反映了用戶的真正想法。
3.3 實現需求
當前的軟件開發過程常常采用迭代方式進行開發，逐步求精，以降低風險和成本。對迭代的次數，每次迭代的里程碑，要實現的目標，及可提交的成果必須有可驗證的清晰的計劃。項目管理是一種藝術，迭代規劃及里程碑定義都是一種挑戰、一種藝術，但項目管理不在本文討論范圍。
3.4 需求變更
需求變更是正常的，也是難免的，應允許用戶和開發團隊自身對需求進行變更。變更處理的關鍵在于跟蹤和控制，如何使產生的影響應得到控制，這屬于配置管理的內容，也不在本文討論范圍。
原型在軟件過程中的定位如下圖所示：
javascript:if(this.width>screen.width-333)this.width=screen.width-333"> 圖1 軟件原型的定位
實際上我們可以把原型看得更為廣義一些。任何用戶或者內部演示的材料，都可以看作為原型。例如，如果你的產品是某種通用的或者行業解決方案，雖然你其實還沒有產品，但先做出一個原型，再加一個漂亮的白皮書，就可以在市場上進行預銷售了。
對于拋棄型和演化型原型來說，也不是絕對的。演化型原型中必然會不斷拋棄一些內容，而拋棄型原型，盡管在完成歷史使命后不再使用，但很多思想以及部分設計還是可以繼承的。
4 原型方法的一般過程
基于原型方法在整個需求過程中的地位，我們需要把原型法和需求處理放在一起進行討論。采用原型法的一般過程如下圖所示：
圖2：原型法的處理過程
在上圖中已經清楚地描述了原型的處理過程，值得一提的是，原型不僅用于給用戶或者最終用戶進行評議，同時完全可以在公司內部組織評議，看看我們周圍吧，多數程序員對技術的興趣遠遠高于對需求的興趣，因此其對系統的理解并不會比市場人員或者項目經理理解的深多少。這里的公司內部人員角色可以包括很多，系統分析員/程序員自身、項目經理、部門經理、用戶代表、領域專家、測試人員等等，不同的角色往往會在其不同立場對系統提出中肯的意見來。
另外值得注意的是界面設計的引入。我們認為將界面風格在原型階段即進行基本確定是一種優化的做法，因為軟件前期對界面的確定可以避免后期開發時對界面進行統一調整所帶來的不必要的成本花費，良好的界面也可以使客戶增加對系統的好感，當然，但愿用戶不要只是欣賞界面而忽略了他們對系統功能的思考。要知道，如果僅僅是讓用戶看到美觀的界面，那么整個原型幾乎是白做了。
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 如何避免用戶看了原型后漫無邊際地提要求？
首先，應該充分尊重客戶，想想其它行業的服務質量吧。有沒有聽說過這樣的說法，項目管理也是客戶滿意度的管理；軟件是一種對客戶的關懷，等等。確實，客戶提出的思路可能和你已經形成的思路不同，一下子打亂了你的思路，也許項目經理并不介意，但這確是讓設計者特別心煩的事情。如果確有把握，或者你可以不做到原型中去。有時候，即使原型很完美，用戶也會額外地提出一些意見，這也是人之常情。但不管怎樣，你不能認為用戶根本不懂軟件，讓他們到時用就行了，抱這樣想法的多半會付出代價。
其次應該進行坦誠協商，多數用戶其實都是通情達理的。如果你在簽訂合同時答應滿足任何要求，而此時又無法忍受用戶的要求，那么孰是孰非應是題外之意了。一般來說，比較合理的做法可以通過增加費用、延長進度或者把需求實現分階段來提交，以保持工作的延續性。對有些軟件，尤其是信息管理系統來說，客戶的實施時間其實并不是主要的，客戶最需要的不是及時，而是合用。
其實，客戶有著很多種類型，確實，個別客戶會參考同類產品來提要求，極個別用戶并不真正懂得計算機技術而對技術路線、技術手段等提出其意見，等等。但我們為什么還可以反過來想一下，如果是等到軟件全部提交的時候，這部分用戶仍有會提出同樣的意見。提早暴露并解決分歧，對雙方睹是有利的。如果軟件公司明知可能存在矛盾，仍然先做好，然后等到用戶提出反對后，再提出補充收費，如果喜歡，也無話可說。
總之，原型應本著對軟件需求的基本理解來做，這樣才能預防不一致性的發生。尤其應該針對不清楚的地方制作原型，從而盡量暴露問題，引發用戶的聯想，不能回避問題，掩蓋問題（以免用戶提出太多的想法），很多問題雖然一時掩蓋了，但最終還是要發生的。
5.8 如何避免在原型基礎上繼續開發時的可維護性降低？
問題是這樣的，制作原型時常希望快速提供原型，往往不及對軟件結構或者數據庫進行細致設計。所以在此基礎上繼續設計和開發的話，有必要在開發前先進行調整。同時，在設計原型前就有必要確定，該原型是要拋棄的，還是要演化要繼承的。對于要演化的原型，其設計不能過于粗略，顯然這直接影響到今后的開發成本。
6 小結
原型方法是可視化的方法，已成為快速軟件開發常用的手段。軟件公司或部門一旦得到了原型方法的回報，就會堅持使用。原型不是絕對必要，但非常有意義。
論壇里幾個朋友的討論：
==============================================
dozer：
寫的不錯。
在產品開發的過程中，原型是團隊內部探索思路、有效溝通、檢測usability的強大工具。在項目開發過程中，是非常有用的溝通手段，也是挖掘需求的有效手段，特別是對于那些用戶需求不明確的客戶，這種手段比較有效。
制作原型的手段有多種，除了常見的VB等之外，Flash也是很有效的手段，Powerpoint也可以作為工具之一，powerpoint做的好的話，也可以做一定交互性的原型，但不如Flash靈活和強大。我個人比較推崇Flash,用Flash制作交互性很強的prototype..甚至可以做到以假亂真的地步..而且，制作prototyping，并不需要很多時間。如果用Flash來做，如果不是制作那種動態反映數據的原型，就我來說，從設計到制作，一個人在短時間內，就可以搞定。
不過，在這幾年的實踐中，我在使用原型的過程中，也碰到一些問題。
1.首先應明確prototype的目的是什么，是用于給客戶做demo，還是內部溝通，還是通過它獲取用戶需求？ 不同的目的，會意味著不同的要求
2.在prototype中，是否需要進來接近于真實？我想還是要根據需要而定，我們曾經犯過一個錯誤，我在用flash制作產品概念原型時，過于追求細節，甚至把按鈕的disabled/enabled等各種狀態都做出來。處理這些細節，花了很多時間，事后總結根本就不必要。
3.制作經驗越多，耗時越少。一開始做Flash prototype時,沒有怎么通過編程方式去制作，結果到后來效率低，很耗時，難以維護，后來很多一些操作通過編程方式去實現，效率提高了很多。
4.原型出來后，如何利用好它，跟用戶溝通，是需要特別注意的地方。在實踐中，發現跟用戶溝通時間不狗，不充分的話，盡管有原型，但也存在用戶并沒有完全理解的情況。
5.如果是讓用戶試用的高保真原型，似乎用VB等工具，更有效一些。盡管Flash也可以制作可以動態添加、刪除數據，接近于真實程序的原型，但似乎還不是特別方便，比如，制作可以拖拉的spliter效果，在Flash中沒有現成的組件，只能自己做。當然，這跟我的編程能力也有關。
========================================================
Juui：
其實我們首先要清晰的是一個概念問題： 界面原形只是用來充分的更形象化的說明spec、確定需求，并非產品的demo!
用flash我個人也比較喜歡， 但是要看是在什么階段提供的這個原形了，如果是在spec尚未制定，或者用戶需求尚未確定的情況下我還是比較喜歡用PPT，因為那樣更加的方便客戶自己去修改（某些時候客戶自己修改的才是他最滿意的，這個時候他也會很有成就感），，
還有就是 ： 切勿在界面原形上投入過多經歷和糾纏過多細節！，那樣就等于你給鏡子里的自己化妝一樣，也許用影子更加的合適，因為原形就是一個影子，只是一個系統的對照和表示別非軟件演示！。。。
但是prototye作為DEMO會有很多局限的地方， 其實大部分的軟件都應該有專門的演示demo 作為推銷所有。
我覺得咱們的討論沒有針對性的話就沒有實質性，因為不同的軟件需要演示的重點不一樣。 比如我以前一直在做的稽核監控，我們的演示還需要演示其數據處理，即時監控和即時匯總。。prototye遠遠不是個了。而且推銷所有的deno應該和給客戶方演示的demo是不一樣。
當然有些軟件如果能夠把prototye做的夠深的話 一樣是可以做為推銷的演示demo用。 但是剛才我說到的是軟件開發前期的原形演示，其主要功能是討論具體需求，所有這個原形不會是很深的。
============================================================
ffffff：我覺得這種prototype是因項目而意的，做到什么程度用什么工具其實更多是取決于sales的意見，二人的意見并不矛盾，其實還有種prototype是給公司內部看的，做成什么樣，是靠ui和dev的一些約定完成的。
Prototype和Demo我覺得最大的還是在功能上的區別
前者主要是用來完善具體的系統功能需求，而最終的Demo更多的已經是一個比較功能完善的演示版系統。
從我現在所參與的項目來說，現在更多的還是在前期的Prototype的設計開發上，我自己所完成的工作主要集中在界面UI方面，下次有機會再好好整理一下這段時間的工作心得吧。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
