2.4 快速原型化方法

通常，原型是指模擬某種產品的原始模型。在軟件開發中，原型是一個軟件早期可運行的版本，它反映最終系統的部分重要特性。如果在獲得一組基本需求說明后，通過快速分析構造出一個小型軟件系統，滿足用戶的基本要求，使得用戶可在試用原型系統的過程中可以親身感受并受到啟發，做出反應和評價，然后開發者根據用戶的意見對原型加以改進。隨著不斷試驗、糾錯、使用、評價和修改，獲得新的原型版本，如此周而復始，逐步減少分析和通信中的誤解，彌補不足之處，進一步確定各種需求細節，適應需求的變更，從而提高最終產品的質量。利用原型化技術，可為軟件的開發提供一種完整、靈活、近似動態的規格說明方法。

2.4.1 原型的分類

軟件原型化方法是在研究需求分析階段的方法和技術中產生的，它主要針對傳統方法面臨的困難，因此，也面向軟件開發的其他階段。由于軟件項目的特點和運行原型的目的不同，原型有3種不同的作用類型。

（1）探索型。這種原型的目的是要弄清對目標系統的要求，確定所希望的特性，并探討多種方案的可行性。它主要針對開發目標模糊，用戶和開發者對項目都缺乏經驗的情況。

（2）實驗型。這種原型用于大規模開發和實現之前，應考核方案是否合適，規格說明是否可靠。

（3）演化型。這種原型的目的不在于改進規格說明，而是將系統建造得易于變化，在改進原型的過程中，逐步將原型演化成最終系統。它將原型化方法的思想擴展到軟件開發的全過程，適于滿足需求的變動。

由于運用原型的目的和方式不同，在使用原型時可采取以下兩種不同的策略：

（1）廢棄策略。先構造一個功能簡單而且質量要求不高的模型系統，針對這個模型系統反復進行分析修改，形成比較好的設計思想，據此設計出更加完整、準確、一致、可靠的最終系統。系統構造完成后，原來的模型系統就廢棄不用了。探索型和實驗型的原型一般屬于這種策略。

（2）追加策略。先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心，然后通過不斷擴充修改，逐步追加新要求，最后發展為最終系統。它對應演化型的原型。

采用什么形式、什么策略主要取決于軟件項目的特點，以及支持原型開發的工具和技術。要根據實際情況的特點加以決策。

原型系統不同于最終系統，它需要快速實現，投入運行。因此，必須注意功能和性能上的取舍。可以忽略一切暫時不必關心的部分，力求原型的快速實現。但要能充分體現原型的作用，滿足評價原型的需求。要根據構造原型的目的，明確規定對原型進行考核和評價的內容，如界面形式、系統結構、功能或模擬性能等。構造出來的原型可能是一個忽略了某些細節或功能的整體系統結構，也可以僅僅是一個局部，如用戶界面、部分功能算法程序或數據庫模式等。總之，在使用原型化方法進行軟件開發之前，必須明確使用原型的目的，從而決定分析與構造內容的取舍。

2.4.2 原型類型的選擇

1984 年，Boar 提出一系列選擇原型化方法的因素。如果是在需求分析階段要使用原型化方法，必須從系統結構、邏輯結構、用戶特征、應用約束、項目管理和項目環境等多方面來考慮，以決定是否采用原型化方法。

（1）系統結構。聯機事務處理系統，相互關聯的應用系統適合用原型化方法，而批處理、批修改等結構不適宜用原型化方法。

（2）邏輯結構。有結構的系統，如操作支持系統、管理信息系統、記錄管理系統等適合用原型化方法，而基于大量算法的系統不適宜用原型化方法。

（3）用戶特征。不滿足于預先做系統定義說明，愿意為定義和修改原型投資，不易肯定詳細需求，愿意承擔決策的責任，準備積極參與的用戶是適合使用原型的用戶。

（4）應用約束。對已經運行系統的補充，不能用原型化方法。

（5）項目管理。只有項目負責人愿意使用原型化方法，才適合用原型化方法。

（6）項目環境。需求說明技術應當根據每個項目的實際環境來選擇。

當系統規模很大、要求復雜、系統服務不清晰時，在需求分析階段先開發一個系統原型是很值得的。特別是當性能要求較高時，在系統原型上先做一些試驗也是很必要的。

1992年，Andriole給出6個問題，用來幫助選擇原型化方法。表2.1指明了對這些問題的典型答案和對使用原型化方法的建議。

2.4.3 原型開發過程

1.原型構造要求

原型不同于最終的系統，兩者在功能范圍上的區別是最終系統要實現軟件需求的全部功能，而原型只實現經過選擇的部分功能。最終系統對每個軟件需求都要求詳細實現，而原型僅僅是為了試驗和演示用的，部分功能需求可以忽略或模擬實現。因此，在構造原型時，必須注意功能、性能的取舍，忽略一切暫時不關心的部分以加速原型的實現，同時又要充分體現原型的作用，滿足評價原型的要求。

2.原型的特征分類

根據原型的目的和方式不同，構造原型內容的取舍不同。在構造原型之前，必須明確使用原型的目的，從而解決分析和構造內容的取舍，還要根據構造原型的目的確定考核、評價原型的內容。

原型特征有如下類型：

（1）系統的界面形式，即用原型來解決系統人機交互界面的結構。

（2）系統的總體結構，即用原型來確定系統的體系結構。

（3）系統的主要處理功能和性能，即用原型來實現系統的主要功能和性能。

（4）數據庫模式，即用原型來確定系統的數據庫結構。

3.原型生存周期

原型的開發和使用過程稱為原型生存周期。圖 2.21（a）是原型生存周期的模型，圖2.21（b）是模型的細化。

1）快速分析

在分析人員和用戶的緊密配合下，快速確定軟件系統的基本要求。根據原型所要體現的特性（界面形式、處理功能、總體結構或模擬性能等），描述基本規格說明，以滿足開發原型的需要。

快速分析的關鍵是要注意選取分析和描述的內容，圍繞使用原型的目標，集中力量，確定局部的需求說明，從而盡快開始構造原型。當系統規模很大、要求復雜、系統服務不清晰時，在需求分析階段先開發一個系統原型是很值得的。特別是當性能要求比較高時，在系統原型上先做一些試驗也是很必要的。

2）構造原型

在快速分析的基礎上，根據基本規格說明，盡快實現一個可運行的系統。為此需要強有力的軟件工具的支持，如采用非常高級的語言實現原型，引入以數據庫為核心的開發工具等；并忽略最終系統在某些細節上的要求，如安全性、健壯性、異常處理等。此時應主要考慮原型系統應充分反映待評價的特性，暫時忽略一切次要內容。

例如，如果構造原型的目的是確定系統輸入界面的形式，可以利用輸入界面自動生成工具，由界面形式的描述和數據域的定義立即生成簡單的輸入模塊，而暫時不考慮參數檢查、值域檢查和后處理工作，從而盡快把原型提供給用戶使用。如果要利用原型確定系統的總體結構，可借助菜單生成器迅速實現系統的程序控制結構，而忽略轉儲、恢復等維護功能，使用戶能夠通過運行菜單來了解系統的總體結構。

初始原型的質量對于原型生存周期后續步驟的成敗是至關重要的。如果它有明顯的缺陷，會帶給用戶一種不好的思路；如果為追求完整而做得太大，就會增加修改的工作量。因此，應當有一個好的初始原型。

3）運行和評價原型

這是頻繁通信、發現問題、消除誤解的重要階段。其目的是驗證原型的正確程度，進而開發新的模型并修改原有的需求。它必須通過所有相關人員的檢查、評價和測試。

由于原型忽略了許多內容，它集中反映了要評價的特性，外觀看起來可能會有些殘缺不全。用戶要在開發者的指導下試用原型，在試用過程中考核評價原型的特性，分析其運行結果是否滿足規格說明的要求，以及規格說明的描述是否滿足用戶的愿望。糾正過去交互中的誤解和分析中的錯誤，增補新的要求，并為滿足因環境變化或用戶的新設想而引起的系統需求變動而提出的全面的修改意見。

為了鼓勵用戶評價原型，應當充分解釋原型的合理性，但不要為它辯護，以求能廣泛征求用戶的意見，在交互中達到完善。

在演示/評價/修改的迭代初期，達到的主要目的是：原型通過用戶進行驗收；總體檢查，找出隱含的錯誤；在操作原型時，使用戶感到熟悉和舒適。

而在迭代的后期，要達到的主要目的是：應發現丟失和不正確的功能；測試思路和提出建議；改善/系統界面。

開發者不應認為提供了完整的模型就等于系統的成功。因為即使開發過程完全正確，用戶還是可以提出一些有意義的修改意見，這不能看成對開發者的批評，而是在開發過程中的一種自然的現象。原型化的目標是鼓勵改進和創造，而不僅是保持某種設想。

4）修正和改進

根據修改意見進行修改。若原型運行的結果未能滿足規格說明中的需求，反映出對規格說明存在不一致的理解或實現方案不夠合理。若因為嚴重的理解錯誤而使正常操作的原型與用戶要求相違背時，有可能會產生廢品。如果發現是廢品應當立即放棄，不能湊合。大多數原型不合適的部分可以修正，以成為新模型的基礎。如果規格說明不準確（有多義性或者未反映用戶要求）、不完整（有遺漏）、不一致，或者需求有改變或增加，則應首先修改并確定規格說明，然后再重新構造或修改原型。

如果用修改原型的過程代替快速分析，就形成了原型開發的迭代過程。開發人員和用戶在一次次的迭代過程中不斷將原型完善，以接近系統的最終要求。

在修改原型的過程中會產生各種積極或消極的影響，為了控制這些影響，應當有一個詞典，用以定義應用的信息流及各個系統成分之間的關系。另外，在用戶積極參與的情況下，保留改進前后的兩個原型，一旦用戶需要可以退回，而且貫穿演示兩個可供選擇的對象有助于決策。

5）判定原型完成

經過修改或改進的原型，得到參與者的一致認可，則原型開發的迭代過程可以結束。為此，應判斷有關應用的實質是否已經掌握，迭代周期是否可以結束等。判定的結果有兩個不同的轉向，一個是繼續迭代驗證，另一個是進行詳細說明。

6）判斷原型細部是否說明

判斷組成原型的細部是否需要嚴格地加以說明。原型化方法允許對系統必要成分進行嚴格且詳細的說明。例如，將需求轉化為報表，給出統計數字等。這些不能通過模型進行說明的成分，必要的話，需要提供說明，并利用屏幕進行討論和確定。

7）原型細部的說明

對于那些不能通過原型說明的所有項目，仍需要通過文件加以說明。下面是一些較明顯的項目，如系統的輸入、系統的輸出、系統的轉化、系統的邏輯功能、數據庫組織、系統的可靠性、用戶地位等。原型化對完成嚴格的規格說明是有幫助的，如輸入、輸出記錄都可以通過屏幕進行統計和討論。

注釋：嚴格說明的成分要作為原型化方法的模型編入詞典，以得到一個統一且連貫的規格說明提供給開發過程。

8）判定原型效果

考察用戶新加入的需求信息和細部說明信息，看其對模型效果有什么影響？是否會影響模塊的有效性？如果模型效果受到影響，甚至導致模型失效，則要進行修正和改進。

9）整理原型和提供文檔

整理原型的目的是為進一步開發提供依據，原型的初期需求模型就是一個自動的文檔。