噴泉模型

出自 MBA智库百科(https://wiki.mbalib.com/)

噴泉模型（Fountain Model）

　　噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用於描述面向對象的軟體開發過程。該模型認為軟體開發過程自下而上周期的各階段是相互重疊和多次反覆的，就像水噴上去又可以落下來，類似一個噴泉。各個開發階段沒有特定的次序要求，並且可以交互進行，可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。採用噴泉模型的軟體過程如下圖所示：

　　噴泉模型主要用於面向對象的軟體項目，軟體的某個部分通常被重覆多次，相關對象在每次迭代中隨之加入漸進的軟體成分。各活動之間無明顯邊界，例如設計和實現之間沒有明顯的邊界，這也稱為“噴泉模型的無間隙性”。由於對象概念的引入，表達分析、設計及實現等活動只用對象類和關係，從而可以較容易地實現活動的迭代和無間隙。

　　噴泉模型是由B．H．Sollers和J．M．Edwards於1990年提出的一種新的開發模型。噴泉模型主要用於採用面向對象技術的軟體開發項目，噴泉一詞本身就體現了迭代和無間隙的特征。無間隙指在各項活動之間無明顯邊界，如分析、設計和編碼之間沒有明顯的界限。在編碼之前再進行需求分析和設計，期間添加有關功能，使系統得以演化。噴泉模型在系統某個部分常常被重覆工作多次，相關對象在每次迭代中隨之加入漸進的系統。由於對象概念的引入，需求分析、設計、實現等活動只用對象類和關係來表達，從而可以較為容易地實現活動的迭代和無間隙，並且使得開發過程自然地包括復用。

　　1、噴泉模型的優點

　　噴泉模型不像瀑布模型那樣，需要分析活動結束後才開始設計活動，設計活動結束後才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟體項目開發效率，節省開發時間，適應於面向對象的軟體開發過程。

　　2、噴泉模型的缺點

　　由於噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利於項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。

　　1.傳統的噴泉模型

　　傳統的噴泉模型如下圖所示，目前主要應用於面向對象的軟體開發中 。該模型的主要特點是認為軟體開發的各個階段是相互重疊和多次反覆的，從圖中可以看出，軟體開發的規格說明階段、設計階段、編碼階段和測試階段可以交疊在一起，同時進行。這體現了各個開發過程的並行關係。噴泉的水可以噴上去又可以落下來，水既可以落在中間，也可以落在底部。這一點在模型中表現為各個測試階段的並行。噴泉的水不停的噴發、墜落，代表著開發和測試階段的複雜性和重覆性。

　　2.改進的噴泉模型

　　在傳統噴泉模型的基礎上，提出了改進的噴泉模型，如下圖所示。以噴泉模型為基礎，可以實現儘早的、全面的展開測試，同時將測試工作進行迭代。另外，改進的噴泉將需求納入，使得模型完全實現了整個開發過程的無邊界、交互性。

　　該模型每一次測試過程包括四個階段。

　　第一階段為測試需求階段，包括提取和驗證需求。這一階段的測試主要是採用靜態測試。

　　第二階段為測試分析階段，又分為制定測試計劃、測試設計與開發兩個步驟。測試計劃包括確定測試策略和測試系統，預估測試工作量等。測試設計與開發包括開發測試用例，驗證並調試測試等。

　　第三階段為測試執行階段，強調測試人員和開發人員的配合。該階段的測試方法包括單元測試、集成測試、系統測試及驗收測試。除了對程式進行測試外，還要對文檔等進行測試。記錄測試結果並寫出測試總結報告，為下一輪的迭代測試打基礎。

　　第四階段為測試維護階段。開發者的維護包括修複顧客操作和為滿足不斷變化的顧客需求而對產品功能進行增強時發現的缺陷；測試組的維護意味著對缺陷的修複進行驗證，測試增強了的功能以及產品的新發佈版本上運行回歸測試以確保修改前的產品具有的功能不因產品的新變化而被破壞。

　　從模型圖中可以看出，該模型除具有傳統噴泉模型的優點外，還體現了以下特點：

　　(1)布式特點當軟體結束計劃階段，分佈在不同地域的軟體開發小組可以根據計劃，在不同或者相同的時間啟動項目開發。

　　(2)測試的充分軟體測試中測試用例的覆蓋率直接決定了軟體測試的質量。改進的噴泉模型大大擴大了設計和選取測試用例的範圍，可以從包括程式、文檔等所有可以使用的信息中獲得，提高了測試用例的覆蓋率，保證測試的充分性和完全性。

　　(3)完全實現了測試和開發的同步，以及各個過程內各個階段之間的同步。真正實現了“全過程”測試，提高了軟體測試的質量。

　　在給一個中型製造企業開發物流管理信息系統的過程中，使用改進模型。這個物流管理信息系統基於C／S和B／S混合架構，一共分為六大子系統，目的是解決企業內部存在的“信息孤島”問題，實現企業內部信息共用，幫助企業提高信息化水平。按照以往經驗，開發一個物流管理信息系統，其中有一半的時間是進行各類測試。在開發這個系統時，所面臨的問題主要有以下幾點：

　　(1)企業的需求非常不固定，經常變化。

　　(2)由於企業的規模不大，資金有限，要求在規定的時間內必須完成開發。

　　(3)系統必須能正常運行，要求測試的完備性。

　　該系統開發小組一共四個成員，基於上述三個問題，採用了改進的噴泉模型進行軟體測試，一個編程，一個測試，開發與測試同步。本文以信息系統中的倉庫子系統為例，介紹如何使用該測試模型來解決以上問題。倉庫子系統結構如圖5所示。

　　圖中一共分為三層，上層、中間層和底層，實際還有一層，稱為頂層。底層採用單元測試，中間層和上層採用集成測試，頂層採用系統測試。在整個系統開發過程中，嚴格按照測試模型進行測試和開發。具體步驟和做法為：

　　(1)順層開發階段，對應模型中的顧客分析。主要是對需求的確定和驗證。在確定用戶需求時，根據企業需求不穩定的現狀，把企業的需求進行分類，共分為三類：穩定的，不穩定的和極不穩定的。

　　利用這些需求完成最初的需求說明書，根據測試模型，測試人員開始進行設計驗收測試用例。對於極不穩定的需求編製成一份文檔，併進行確認，在以後的開發過程中邊開發邊對這些需求進行更改。

　　(2)當開發進行到概要設計(圖中的上層)時，對應測試模型中的系統分析階段。按照測試模型，採用邊開發邊測試的辦法。根據上一階段已經通過驗收測試的需求說明書，將整個系統分成了六大子系統，銷售子系統、採購子系統、倉庫子系統、生產子系統、財務子系統和伺服器子系統。此時，測試人員結束驗收測試用例的設計，而進入集成測試用例的設計。

　　(3)詳細設計階段，對應測試模型的子系統分析。首先把倉庫分成系統管理、入庫管理、出庫管理、調撥管理、庫存統計和輔助管理六個模塊，這個過程測試人員繼續執行測試用例的設計。然後進入測試模型中的模塊分析階段，即開發人員根據需求文檔進行更細小的模塊劃分。系統管理這個模塊由四個更小的模塊組成，入庫管理、出庫管理、調撥管理、庫存統計和輔助管理同樣進行了更細的劃分。在這一過程中，需求中的不穩定因素被確定下來，測試人員結束集成測試用例設計，轉而開發單元測試用例設計，測試人員大概能完成3／4的集成測試用例設計，並開始對文檔進行驗收測試，記錄測試結果，反饋給開發人員，使其可以及時修改需求中出現的錯誤。

　　(4)代碼編寫階段。開發人員根據詳細設計的結果，從底層開始進行代碼開發。測試人員繼續進行單元測試用例的設計，測試用例的獲取範圍也擴大，可以從程式中選擇。例如完成庫存管理單元時，開發人員繼續開發下一個小單元，測試人員則開始進行單元測試，並把測試後的結果反饋給開發人員，這樣開發人員能及時地改正錯誤。當開發人員完成系統管理，開發入庫管理時，測試人員對系統管理進行集成測試，並同時進行單元測試。同樣將測試結果及時反饋給開發人員。當整個倉庫子系統完成了2／3的模塊時，測試人員邊進行單元測試和集成測試，邊進行系統測試用例設計以及系統測試需要的測試環境設計。完成所有子系統時，開始進行系統測試。

　　在最後執行的驗收測試中發現的錯誤，先確定子系統，再確定模塊，最後直接回到需求中查找錯誤，並執行回歸測試。下表是測試過程中的一個測試實例。

　　為了能更清楚的說明改進的噴泉模型的優勢，我們把該模型每個階段測試的結果和舊有模型進行了比對，如表2所示，併進行了圖形分析，如下圖所示。

　　表2 新舊模型測試結果對比

　　從表2和上圖中可以看出，由於新模型實現了開發與測試並行，各個開發和測試階段的並行，擴大了測試用例的覆蓋率，而且軟體中出現的錯誤在前期就能及時發現，不僅保證了測試的有效性和完備性，同時大大降低了測試在軟體中的費用。