噴泉模型是一種以用戶需求為動力,以對象為驅動的模型,主要用于描述面向對象的軟件開發過程。該模型認為軟件開發過程自下而上周期的各階段是相互重疊和多次反復的,就像水噴上去又可以落下來,類似一個噴泉。各個開發階段沒有特定的次序要求,并且可以交互進行,可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。采用噴泉模型的軟件過程如下圖所示:
噴泉模型主要用于面向對象的軟件項目,軟件的某個部分通常被重復多次,相關對象在每次迭代中隨之加入漸進的軟件成分。各活動之間無明顯邊界,例如設計和實現之間沒有明顯的邊界,這也稱為“噴泉模型的無間隙性”。由于對象概念的引入,表達分析、設計及實現等活動只用對象類和關系,從而可以較容易地實現活動的迭代和無間隙。
噴泉模型是由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的模塊時,測試人員邊進行單元測試和集成測試,邊進行系統測試用例設計以及系統測試需要的測試環境設計。完成所有子系統時,開始進行系統測試
評論(0)