軟件工程 瀑布模型、原型模型、噴泉模型和V模型的優缺點及適用場景

1、瀑布模型

　　瀑布模型（Waterfall Model）是一個項目開發架構，開發過程是經過設計一系列階段順序展開的，從系統需求分析開始直到產品發佈和維護，每一個階段都會產生循環反饋，所以，若是有信息未被覆蓋或者發現了問題，那麼最好「返回」上一個階段並進行適當的修改，項目開發進程從一個階段「流動」到下一個階段，這也是瀑布模型名稱的由來。包括軟件工程開發、企業項目開發、產品生產以及市場銷售等構造瀑布模型。 
　　瀑布模型也稱軟件生存週期模型。它在軟件工程中佔有重要地位，它提供了軟件開發的基本框架，這比依靠「我的技藝」開發軟件好得多。它有利於大型軟件開發過程當中人員的組織、管理，有利於軟件開發方法和工具的研究與使用，從而提升了大型軟件項目開發的質量和效率。 
　　首先，對於絕大多數人來講，剛接手一個新項目的時候都會不自覺的選擇「瀑布模型」—-咱們跟客戶交談後指定需求分析，以後進行簡單的設計，以後編寫代碼，提交，完成。新手會不自覺的選擇這種方案，由於它直白，想到哪一步作到哪一步，須要作什麼就作什麼。可是，這在有些時候是要付出慘重的代價的。好比A擁有一家跑車公司，能夠給客戶自定義生產跑車。有一天一土豪來到A的公司，跟A商談了一個跑車項目，他們談好了車型，材料，馬力等等細節。以後，A帶着團隊作了6個月，作成了這架跑車，交給了土豪。但是土豪開了一天以後回來要求重作，緣由是當討論方案的時候，雙方都忘記給跑車安尾燈了！可是給跑車安裝尾燈，就要涉及到整個車尾的從新設計，就要把整輛車拆掉再從新組裝！ 
　　 這個模型顯然只適合已經成熟了的項目，團隊接手項目以後如庖丁解牛般行雲流水。當團隊接手了創新項目以後，顯然已經再也不適合用瀑布模型。

一、瀑布模型有如下優勢：

1）爲項目提供了按階段劃分的檢查點。 
2）當前一階段完成後，您只須要去關注後續階段。 
3）可在迭代模型中應用瀑布模型。 

二、瀑布模型有如下缺點：

1）在項目各個階段之間極少有反饋。 
2）只有在項目生命週期的後期才能看到結果。 
3）經過過多的強制完成日期和里程碑來跟蹤各個項目階段。

三、瀑布模型適用場所：

適合於結構化方法，也就是面向過程的軟件開發方法。 
軟件項目或產品選擇瀑布模型必須知足下列條件： 
　１)在開發時間內需求沒有或不多變化； 
　２)分析設計人員應對應用領域很熟悉； 
　３)低風險項目（對目標、環境很熟悉）； 
　４)用戶使用環境很穩定； 
　５)用戶除提出需求之外，不多參與開發工做。

2、原型模型

　　原型模型是先借用已有系統做爲原型模型，經過「樣品」不斷改進，使得最後的產品就是用戶所須要的。主要是經過向用戶提供原型獲取用戶的反饋，使開發出的軟件可以真正反映用戶的需求。同時，原型模型採用逐步求精的方法完善原型，使得原型可以「快速」開發，避免了像瀑布模型同樣在冗長的開發過程當中難以對用戶的反饋做出快速的響應。相對瀑布模型而言，原型模型更符合人們開發軟件的習慣，是目前較流行的一種實用軟件生存期模型

１、原型模型的優勢：

1）開發人員和用戶在「原型」上達成一致。這樣一來，能夠減小設計中的錯誤和開發中的風險，也減小了對用戶培訓的時間，而提升了系統的實用、正確性以及用戶的滿意程度。 
2）縮短了開發週期，加快了工程進度。 
3）下降成本。

二、原型模型的缺點:

1）當告訴用戶，還必須從新生產該產品時，用戶是很難接受的。這每每給工程繼續開展帶來不利因素。 
2）開發者爲了使一個原型快速運行起來，每每在實現過程當中採用這種手段。 
3） 不宜利用原型系統做爲最終產品。採用原型模型開發系統，用戶和開發者必須達成一致：原型被建造僅僅是用戶用來定義需求，以後便部分或所有拋棄，最終的軟件是要充分考慮了質量和可維護性等方面以後才被開發。

三、原型模型的適用場所：

　原型模型適用於那些不能預先確切定義需求的軟件系統的開發，更適用於那些項目組成員（包括分析員、設計員、程序員和用戶）不能很好的交流或者通訊的狀況下。

3、噴泉模型

　噴泉模型是一種以用戶需求爲動力，以對象爲驅動的模型，主要用於描述面向對象的軟件開發過程。該模型認爲軟件開發過程自下而上週期的各階段是相互重疊和屢次反覆的，就像水噴上去又能夠落下來，相似一個噴泉。各個開發階段沒有特定的次序要求，而且能夠交互進行，能夠在某個開發階段中隨時補充其餘任何開發階段中的遺漏。採用噴泉模型的軟件過程以下圖所示： 
 
　　噴泉模型主要用於面向對象的軟件項目，軟件的某個部分一般被重複屢次，相關對象在每次迭代中隨之加入漸進的軟件成分。各活動之間無明顯邊界，例如設計和實現之間沒有明顯的邊界，這也稱爲「噴泉模型的無間隙性」。因爲對象概念的引入，表達分析、設計及實現等活動只用對象類和關係，從而能夠較容易地實現活動的迭代和無間隙。 
　　噴泉模型是由B．H．Sollers和J．M．Edwards於1990年提出的一種新的開發模型。噴泉模型主要用於採用面向對象技術的軟件開發項目，噴泉一詞自己就體現了迭代和無間隙的特徵。無間隙指在各項活動之間無明顯邊界，如分析、設計和編碼之間沒有明顯的界限。在編碼以前再進行需求分析和設計，期間添加有關功能，使系統得以演化。噴泉模型在系統某個部分經常被重複工做屢次，相關對象在每次迭代中隨之加入漸進的系統。因爲對象概念的引入，需求分析、設計、實現等活動只用對象類和關係來表達，從而能夠較爲容易地實現活動的迭代和無間隙，而且使得開發過程天然地包括複用。

一、噴泉模型的優勢：

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

２、噴泉模型的缺點：

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

３、噴泉模型適用場所：

　適應於面向對象的軟件開發過程。 
　詳情能夠參考：噴泉模型（Fountain Model）智庫百科　中的實例

4、V模型

　　RAD（Rap Application Development，快速應用開發）模型是軟件開發過程當中的一個重要模型，因爲其模型構圖形似字母V，因此又稱軟件開發的V模型。 
　　 它經過開發和測試同時進行的方式來縮短開發週期，提升開發效率。V模型大致能夠劃分爲如下幾個不一樣的階段步驟：需求分析、概要設計、詳細設計、軟件編碼、單元測試、集成測試、系統測試、驗收測試。對概要設計中表述的各模塊進行深刻分析，對各模塊組合進行分析等，這一階段要求達到僞代碼級別，已經把程序的具體實現的功能，現象等描述出來。

１、需求分析 
　　即首先要明確客戶須要的是什麼，須要軟件做成什麼樣子，須要有那幾項功能，這一點上比較關鍵的是分析師和客戶溝通時的理解能力與交互性。要求分析師能準確的把客戶所須要達到的功能，實現方式，等表述出來，給出分析結果，寫出需求規格說明書。 
２、概要設計 
　　主要是架構的實現，指搭建架構、表述各模塊功能、模塊接口鏈接和數據傳遞的實現等項事務。 
３、詳細設計 
　　對概要設計中表述的各模塊進行深刻分析，對各模塊組合進行分析等，這一階段要求達到僞代碼級別，已經把程序的具體實現的功能，現象等描述出來。其中須要包含數據庫設計說明。 
４軟件編碼 
　　按照詳細設計好的模塊功能表，編程人員編寫出實際的代碼。 
５單元測試 
　　按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，爲的是確保各單元模塊被正確的編譯，單元的具體劃分按不一樣的單位與不一樣的軟件有不一樣，好比有具體到模塊的測試，也有具體到類，函數的測試等。 
６集成測試 
　　通過了單元測試後，將各單元組合成完整的體系，主要測試各模塊間組合後的功能實現狀況，以及模塊接口鏈接的成功與否，數據傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。根據集成測試計劃，一邊將模塊或其餘軟件單位組合成系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。 
７系統測試 
　　通過了單元測試和集成測試之後，咱們要把軟件系統搭建起來，按照軟件規格說明書中所要求，測試軟件其性能功能等是否和用戶需求相符合，在系統中運行是否存在漏洞，等。 
８驗收測試 
　　主要就是用戶在拿到軟件的時候，在使用現場，會根據前邊所提到的需求，以及規格說明書來作相應測試，以肯定軟件達到符合效果的。

１、Ｖ模型的優勢：

1）縮短開發週期 
2）提升開發效率

二、V模型的缺點：

　　V模型僅僅把測試過程做爲在需求分析、系統設計及編碼以後的一個階段，忽視了測試對需求分析,系統設計的驗證，需求的知足狀況一直到後期的驗收測試才被驗證。 
　　解決的思路是，當一個軟件開發的時候，研發人員和測試人員須要同時工做，測試在軟件作需求分析的同時就會有測試用例的跟蹤，這樣，能夠儘快找出程序錯誤和需求偏離，從而更高效的提升程序質量，最大可能的減小成本，同時知足用戶的實際軟件需求。

３、V模型適用場所：

　 模式是一種傳統軟件開發模型，通常適用於一些傳統信息系統應用的開發，而一些高性能高風險的系統、互聯網軟件，或一個系統難以被具體模塊化的時候，就比較難作成V模式所需的各類構件，須要更強調迭代的開發模型或者敏捷開發模型。