1、原型方法論- 關于軟件原型方法若干問題的討論關鍵字：原型，尊重客戶，原型評價，可視化，變更成本，開發團隊藍圖1 引子太多了！終于簽下合同->得到了“正式”的客戶提供的“需求書”的幾片紙->憑借自己的理解立即投入開發->“木已成舟”，生米終于熬成粥->用戶拒絕接受？->艱難地修改，反復修改，開發人員厭倦了，而用戶對系統用之無味，棄之可惜，遂成雞肋。->由此后期收款遙遙無期，軟件公司不再和用戶保持溝通->互相埋怨，扯皮由此而生。或者，一個項目拆成為多期，從而收取一部分款項，而很多的開發都作廢。這樣的案例真是何其多也！究其主要原因，與其說是沒有搞定關鍵客戶，

2、或者項目管理不當，不如說是沒有幫助客戶解決其問題，對客戶真正的需求研究不夠。實際上，原型方法是解決此類問題、確保項目成功的最佳途徑。我在寫此文的同時，也試圖尋找資料，不知道是本就沒有，還是自己所不幸而未找到。看來原型并沒有明確的標準，而目前不同軟件公司的理解和做法各不相同也就不奇怪了。但從軟件過程的角度來考察，原型法仍有著通用的優化的做法。本文試圖從作者的實踐經驗出發，對原型方法進行思考與探討。另外，本文是發散型的，在研究原型的同時，也討論了原型相關的內容。原型本質上有些象是拋磚引玉，而本文也旨在拋磚引玉，但無意于一概地論定什么。2 什么是原型2.1 原型的定義原型(prototype)即把系

3、統主要功能和接口通過快速開發制作為“軟件樣機”，以可視化的形式展現給用戶，及時征求用戶意見，從而明確無誤地確定用戶需求。同時，原型也可用于征求內部意見，作為分析和設計的接口之一，可方便于溝通。2.2 原型的主要價值原型法主要價值是可視化，強化溝通，降低風險，節省后期變更成本，提高項目成功率。一般來說，采用原型法后可以改進需求質量；雖然投入了較多先期的時間，但可以顯著減少后期變更的時間；原型投入的人力成本代價并不大，但可以節省后期成本；對于較大型的軟件來說，原型系統可以成為開發團隊的藍圖；另外，原型通過充分和客戶交流，還可以提高客戶滿意度。2.3 基本要求對原型的基本要求包括：* 體現主要的功能

4、；* 提供基本的界面風格；* 展示比較模糊的部分，以便于確認或進一步明確，防患于未然。* 原型最好是可運行的，至少在各主要功能模塊之間能夠建立相互連接。2.4 處理方法原型的處理方法基本上有2種不同類型，即拋棄型和演化型（不同的軟件工程書籍稱發不同，實質意義則類似）。可以拋棄原型，在取得的明確需求基礎上重新開始設計與開發；也可在原型的基礎上繼續開發。一般小項目不采用拋棄型原型，否則成本和代價似乎會偏高。2.5 表達工具原型的表達工具可以有很多，如果是演化型的原型，當然優先選用軟件本身的開發工具。否則還可以應用各種快速顯示的工具，例如，HTML，Powerpoint等等，只要能夠充分而形象地表達

5、就可以了。根據筆者的經驗，在原型系統中，可以采用一些與常規不同的做法，例如，可以在界面上比較顯著的地方寫明當前模塊或界面的主要目的，由哪些角色操作，能解決其什么問題。這么做可以使得用戶或開發團隊成員一開始就有非常清楚的概念；又如，對于決策分析，你可以直接把一些分析結果畫成圖，并且配上一些文字說明，這樣可以避免輸入大量初始數據，等等。3 原型在軟件過程的地位軟件的根本目的是實現用戶的需求，提供用戶日常使用，解決用戶工作中有所不便的問題，提高其工作效率，改進質量，加強管理控制，最終直接或間接地提高其效益。因此軟件開發本質上就是需求的處理和實現，而軟件原型對需求確定來說具有非常重要的意義。原型方法包

6、括2個基本過程，即原型制作和原型評價。如果從需求角度看軟件過程，我們不妨可以把軟件過程這樣劃分：3.1 需求收集和分析搜集需求得到需求說明書，了解軟件要做什么，做成什么樣，解決用戶什么問題。這時候軟件公司以書面文檔方式提出，例如需求問詢表等。3.2 提供原型并進行評價制定原型開發計劃，根據用戶需求及不確定的高風險部分進行原型開發，在內部進行原型評價，請客戶進行原型評價，以保證確實反映了用戶的真正想法。3.3 實現需求當前的軟件開發過程常常采用迭代方式進行開發，逐步求精，以降低風險和成本。對迭代的次數，每次迭代的里程碑，要實現的目標，及可提交的成果必須有可驗證的清晰的計劃。項目管理是一種藝術，迭

7、代規劃及里程碑定義都是一種挑戰、一種藝術，但項目管理不在本文討論范圍。3.4 需求變更需求變更是正常的，也是難免的，應允許用戶和開發團隊自身對需求進行變更。變更處理的關鍵在于跟蹤和控制，如何使產生的影響應得到控制，這屬于配置管理的內容，也不在本文討論范圍。原型在軟件過程中的定位如下圖所示：圖1 軟件原型的定位實際上我們可以把原型看得更為廣義一些。任何用戶或者內部演示的材料，都可以看作為原型。例如，如果你的產品是某種通用的或者行業解決方案，雖然你其實還沒有產品，但先做出一個原型，再加一個漂亮的白皮書，就可以在市場上進行預銷售了。對于拋棄型和演化型原型來說，也不是絕對的。演化型原型中必然會不斷拋棄

8、一些內容，而拋棄型原型，盡管在完成歷史使命后不再使用，但很多思想以及部分設計還是可以繼承的。4 原型方法的一般過程基于原型方法在整個需求過程中的地位，我們需要把原型法和需求處理放在一起進行討論。采用原型法的一般過程如下圖所示：圖2：原型法的處理過程在上圖中已經清楚地描述了原型的處理過程，值得一提的是，原型不僅用于給用戶或者最終用戶進行評議，同時完全可以在公司內部組織評議，看看我們周圍吧，多數程序員對技術的興趣遠遠高于對需求的興趣，因此其對系統的理解并不會比市場人員或者項目經理理解的深多少。這里的公司內部人員角色可以包括很多，系統分析員/程序員自身、項目經理、部門經理、用戶代表、領域專家、測試人

9、員等等，不同的角色往往會在其不同立場對系統提出中肯的意見來。另外值得注意的是界面設計的引入。我們認為將界面風格在原型階段即進行基本確定是一種優化的做法，因為軟件前期對界面的確定可以避免后期開發時對界面進行統一調整所帶來的不必要的成本花費，良好的界面也可以使客戶增加對系統的好感，當然，但愿用戶不要只是欣賞界面而忽略了他們對系統功能的思考。要知道，如果僅僅是讓用戶看到美觀的界面，那么整個原型幾乎是白做了。 5 使用原型方法的相關問題探討5.1 為什么要采用原型法？原型對一個項目取得成功具有重要的意義。俗話說：隔行如隔山，實際上軟件公司很難保證其制作的軟件正好就是用戶所需要的，用戶也很難一次性把其真

10、實的要求完全提交，開始階段提出的往往只是對系統的期望，和比較模糊的設想而已。而原型系統為用戶提供了一個靶子，看著原型系統，用戶往往就能進一步提出他們的真正想法。顯然軟件公司明確用戶需求的最佳方式就是為用戶提供原型并由用戶進行評價。也許，跳過原型可以節省時間和前期成本，但你應該注意到，跳過原型的話，后期變更的成本會明顯增加。5.2 為什么在需求說明書之外需要原型？1）眼見為實，文字具有歧義性，不同的人理解都不相同；2）最終用戶往往在看到一套可運行的系統的基礎上，才可能提出其真實的意見，如果到最終提交時才看到這樣的系統就為時太晚。這也是以前無數軟件開發留下的教訓；3）便于發現問題，及時糾正；4）便

11、于進一步展開，并取得用戶的細節需求；5）體現原型的其它功能：便于公司內部如經理、市場部等對軟件提出意見，便于開發人員對整個產品達成統一認識，等等。對內部人員來說，同樣地，一套形象的原型也遠勝過一堆專業術語文字；也就是說，原型對軟件公司內部也十分重要。這些評價工作無形之中改進了項目質量。5.3 原型方法有什么風險？任何方法都是有利有弊，在我們可以探討一下原型方法可能存在的風險。以下是一般軟件公司所擔心的風險：需要付出前期進度和人力成本；由于程序員對問題的不了解而效率低下，受客戶牽制而在原型上反復修改；因為倉促設計而做不利于進一步在其基礎上繼續開發；由于過早展示原型給客戶，使得客戶可能提高其期望值

12、，并提出更多離譜的要求，等等。值得一提的是原型方法的主要價值之一就是盡早揭示軟件中可能存在的風險及不確定因素，尤其是關于用戶需求一致性方面的風險。5.4 原型方法和其它方法或過程的關系如何，是否一致？生命周期法中并不包括原型，或者說沒有明確提供原型的概念和定義。原型可以認為是需求分析中的一個子部分。另外，應該說原型方法是對生命周期法的有益補充和完善。RUP中是最優化的統一軟件過程，但RUP中似乎沒有提到原型，RUP的核心過程是在迭代中精化。我個人的見解是，原型非常類似于第一次迭代的過程和結果。實際上，如果把原型看作為第一輪交付的成果，那么原型的很多不利之處，諸如花費前期成本等等，這些擔心都將變

13、得不復存在。XP方法對原型非常推崇，這是因為XP方法非常強調需求的重要性，甚至要求客戶參與開發過程。但原型方法和XP也有區別。XP是分批交付，先做一個幾個功能點的版本，完成后再每個開發周期往上面加其它功能點，而原型法一般要求做出比較完整，能覆蓋主要功能點的粗略的版本。XP方法仁者見仁，智者見智，不一而舉。5.5 如何避免項目團隊做原型的時候出現部分人員閑置？在項目管理中，對人力資源的調配應和項目進展相匹配。實際上在用戶接觸到原型制作的同時，可以進行項目計劃、架構設計、技術培訓以及技術難點攻關等等。如果從廣義上理解原型的話，架構設計者甚至可以設計出一種用戶開發團隊使用的所謂框架原型，包含了主要的

14、設計成分、模板和示例。比較理想的結果是，當原型完成后，需求分析、架構設計和界面風格設計都趨于完成，從這一點可以看到，原型方法可以作為快速軟件開發的重要手段。5.6 如果避免項目在原型上停滯不前？應使用有經驗的開發人員，避免因為程序員不熟悉業務而延誤進度；不要在界面設計上猶豫不決而占據時間；如果用戶對原型提出了很多意見，其中部分比較明確的意見可以在開發過程中進行實現；和客戶的交流應該簡潔明了，而不是似是而非；另外，原型方法在項目過程中占據的時間應該在項目計劃中保留出來，而不僅僅是隱含在需求調研與分析的一個部分。5.7 如何避免用戶看了原型后漫無邊際地提要求？首先，應該充分尊重客戶，想想其它行業的

15、服務質量吧。有沒有聽說過這樣的說法，項目管理也是客戶滿意度的管理；軟件是一種對客戶的關懷，等等。確實，客戶提出的思路可能和你已經形成的思路不同，一下子打亂了你的思路，也許項目經理并不介意，但這確是讓設計者特別心煩的事情。如果確有把握，或者你可以不做到原型中去。有時候，即使原型很完美，用戶也會額外地提出一些意見，這也是人之常情。但不管怎樣，你不能認為用戶根本不懂軟件，讓他們到時用就行了，抱這樣想法的多半會付出代價。其次應該進行坦誠協商，多數用戶其實都是通情達理的。如果你在簽訂合同時答應滿足任何要求，而此時又無法忍受用戶的要求，那么孰是孰非應是題外之意了。一般來說，比較合理的做法可以通過增加費用、

16、延長進度或者把需求實現分階段來提交，以保持工作的延續性。對有些軟件，尤其是信息管理系統來說，客戶的實施時間其實并不是主要的，客戶最需要的不是及時，而是合用。其實，客戶有著很多種類型，確實，個別客戶會參考同類產品來提要求，極個別用戶并不真正懂得計算機技術而對技術路線、技術手段等提出其意見，等等。但我們為什么還可以反過來想一下，如果是等到軟件全部提交的時候，這部分用戶仍有會提出同樣的意見。提早暴露并解決分歧，對雙方睹是有利的。如果軟件公司明知可能存在矛盾，仍然先做好，然后等到用戶提出反對后，再提出補充收費，如果喜歡，也無話可說。總之，原型應本著對軟件需求的基本理解來做，這樣才能預防不一致性的發生。尤其應該針對不清楚的地方制作原型，從而盡量暴露問題，引發用戶的聯想，不能回避問題，掩蓋問題（以免用戶提出太多的想法），很多問題雖然一時掩蓋