一、瀑布模型

　　瀑布模型（Waterfall Model）是一個項目開發(fā)架構(gòu)，開發(fā)過程是通過設(shè)計一系列階段順序展開的，從系統(tǒng)需求分析開始直到產(chǎn)品發(fā)布和維護，每個階段都會產(chǎn)生循環(huán)反饋，因此，如果有信息未被覆蓋或者發(fā)現(xiàn)了問題，那么最好“返回”上一個階段并進行適當?shù)男薷?#xff0c;項目開發(fā)進程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。包括軟件工程開發(fā)、企業(yè)項目開發(fā)、產(chǎn)品生產(chǎn)以及市場銷售等構(gòu)造瀑布模型。
　　瀑布模型也稱軟件生存周期模型。它在軟件工程中占有重要地位，它提供了軟件開發(fā)的基本框架，這比依靠“個人技藝”開發(fā)軟件好得多。它有利于大型軟件開發(fā)過程中人員的組織、管理，有利于軟件開發(fā)方法和工具的研究與使用，從而提高了大型軟件項目開發(fā)的質(zhì)量和效率。
　　首先，對于絕大多數(shù)人來說，剛接手一個新項目的時候都會不自覺的選擇“瀑布模型”—-我們跟客戶交談后指定需求分析，之后進行簡單的設(shè)計，之后編寫代碼，提交，完成。新手會不自覺的選擇這種方案，因為它直白，想到哪一步做到哪一步，需要做什么就做什么。但是，這在有些時候是要付出慘重的代價的。比如A擁有一家跑車公司，可以給客戶自定義生產(chǎn)跑車。有一天一土豪來到A的公司，跟A商談了一個跑車項目，他們談好了車型，材料，馬力等等細節(jié)。之后，A帶著團隊做了6個月，做成了這架跑車，交給了土豪。可是土豪開了一天之后回來要求重做，原因是當討論方案的時候，雙方都忘記給跑車安尾燈了！但是給跑車安裝尾燈，就要涉及到整個車尾的重新設(shè)計，就要把整輛車拆掉再重新組裝！
　　 這個模型顯然只適合已經(jīng)成熟了的項目，團隊接手項目之后如庖丁解牛般行云流水。當團隊接手了創(chuàng)新項目之后，顯然已經(jīng)不再適合用瀑布模型。

1、瀑布模型有以下優(yōu)點：

1）為項目提供了按階段劃分的檢查點。
2）當前一階段完成后，您只需要去關(guān)注后續(xù)階段。
3）可在迭代模型中應(yīng)用瀑布模型。

2、瀑布模型有以下缺點：

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

3、瀑布模型適用場所：

適合于結(jié)構(gòu)化方法，也就是面向過程的軟件開發(fā)方法。
軟件項目或產(chǎn)品選擇瀑布模型必須滿足下列條件：
　１)在開發(fā)時間內(nèi)需求沒有或很少變化；
　２)分析設(shè)計人員應(yīng)對應(yīng)用領(lǐng)域很熟悉；
　３)低風(fēng)險項目（對目標、環(huán)境很熟悉）；
　４)用戶使用環(huán)境很穩(wěn)定；
　５)用戶除提出需求以外，很少參與開發(fā)工作。

二、原型模型

　　原型模型是先借用已有系統(tǒng)作為原型模型，通過“樣品”不斷改進，使得最后的產(chǎn)品就是用戶所需要的。主要是通過向用戶提供原型獲取用戶的反饋，使開發(fā)出的軟件能夠真正反映用戶的需求。同時，原型模型采用逐步求精的方法完善原型，使得原型能夠“快速”開發(fā)，避免了像瀑布模型一樣在冗長的開發(fā)過程中難以對用戶的反饋作出快速的響應(yīng)。相對瀑布模型而言，原型模型更符合人們開發(fā)軟件的習(xí)慣，是目前較流行的一種實用軟件生存期模型

１、原型模型的優(yōu)點：

1）開發(fā)人員和用戶在“原型”上達成一致。這樣一來，可以減少設(shè)計中的錯誤和開發(fā)中的風(fēng)險，也減少了對用戶培訓(xùn)的時間，而提高了系統(tǒng)的實用、正確性以及用戶的滿意程度。
2）縮短了開發(fā)周期，加快了工程進度。
3）降低成本。

2、原型模型的缺點:

1）當告訴用戶，還必須重新生產(chǎn)該產(chǎn)品時，用戶是很難接受的。這往往給工程繼續(xù)開展帶來不利因素。
2）開發(fā)者為了使一個原型快速運行起來，往往在實現(xiàn)過程中采用這種手段。
3） 不宜利用原型系統(tǒng)作為最終產(chǎn)品。采用原型模型開發(fā)系統(tǒng)，用戶和開發(fā)者必須達成一致：原型被建造僅僅是用戶用來定義需求，之后便部分或全部拋棄，最終的軟件是要充分考慮了質(zhì)量和可維護性等方面之后才被開發(fā)。

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

　原型模型適用于那些不能預(yù)先確切定義需求的軟件系統(tǒng)的開發(fā)，更適用于那些項目組成員（包括分析員、設(shè)計員、程序員和用戶）不能很好的交流或者通信的情況下。

三、噴泉模型

　噴泉模型是一種以用戶需求為動力，以對象為驅(qū)動的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。該模型認為軟件開發(fā)過程自下而上周期的各階段是相互重疊和多次反復(fù)的，就像水噴上去又可以落下來，類似一個噴泉。各個開發(fā)階段沒有特定的次序要求，并且可以交互進行，可以在某個開發(fā)階段中隨時補充其他任何開發(fā)階段中的遺漏。采用噴泉模型的軟件過程如下圖所示：

　　噴泉模型主要用于面向?qū)ο蟮能浖椖?#xff0c;軟件的某個部分通常被重復(fù)多次，相關(guān)對象在每次迭代中隨之加入漸進的軟件成分。各活動之間無明顯邊界，例如設(shè)計和實現(xiàn)之間沒有明顯的邊界，這也稱為“噴泉模型的無間隙性”。由于對象概念的引入，表達分析、設(shè)計及實現(xiàn)等活動只用對象類和關(guān)系，從而可以較容易地實現(xiàn)活動的迭代和無間隙。
　　噴泉模型是由B．H．Sollers和J．M．Edwards于1990年提出的一種新的開發(fā)模型。噴泉模型主要用于采用面向?qū)ο蠹夹g(shù)的軟件開發(fā)項目，噴泉一詞本身就體現(xiàn)了迭代和無間隙的特征。無間隙指在各項活動之間無明顯邊界，如分析、設(shè)計和編碼之間沒有明顯的界限。在編碼之前再進行需求分析和設(shè)計，期間添加有關(guān)功能，使系統(tǒng)得以演化。噴泉模型在系統(tǒng)某個部分常常被重復(fù)工作多次，相關(guān)對象在每次迭代中隨之加入漸進的系統(tǒng)。由于對象概念的引入，需求分析、設(shè)計、實現(xiàn)等活動只用對象類和關(guān)系來表達，從而可以較為容易地實現(xiàn)活動的迭代和無間隙，并且使得開發(fā)過程自然地包括復(fù)用。

1、噴泉模型的優(yōu)點：

　　噴泉模型不像瀑布模型那樣，需要分析活動結(jié)束后才開始設(shè)計活動，設(shè)計活動結(jié)束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。其優(yōu)點是可以提高軟件項目開發(fā)效率，節(jié)省開發(fā)時間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。

２、噴泉模型的缺點：

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

３、噴泉模型適用場所：

　適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。
　詳情可以參考：噴泉模型（Fountain Model）智庫百科　中的實例

四、V模型

　　RAD（Rap Application Development，快速應(yīng)用開發(fā)）模型是軟件開發(fā)過程中的一個重要模型，由于其模型構(gòu)圖形似字母V，所以又稱軟件開發(fā)的V模型。
　　 它通過開發(fā)和測試同時進行的方式來縮短開發(fā)周期，提高開發(fā)效率。V模型大體可以劃分為以下幾個不同的階段步驟：需求分析、概要設(shè)計、詳細設(shè)計、軟件編碼、單元測試、集成測試、系統(tǒng)測試、驗收測試。對概要設(shè)計中表述的各模塊進行深入分析，對各模塊組合進行分析等，這一階段要求達到偽代碼級別，已經(jīng)把程序的具體實現(xiàn)的功能，現(xiàn)象等描述出來。

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

１、Ｖ模型的優(yōu)點：

1）縮短開發(fā)周期
2）提高開發(fā)效率

2、V模型的缺點：

　　V模型僅僅把測試過程作為在需求分析、系統(tǒng)設(shè)計及編碼之后的一個階段，忽視了測試對需求分析,系統(tǒng)設(shè)計的驗證，需求的滿足情況一直到后期的驗收測試才被驗證。
　　解決的思路是，當一個軟件開發(fā)的時候，研發(fā)人員和測試人員需要同時工作，測試在軟件做需求分析的同時就會有測試用例的跟蹤，這樣，可以盡快找出程序錯誤和需求偏離，從而更高效的提高程序質(zhì)量，最大可能的減少成本，同時滿足用戶的實際軟件需求。

３、V模型適用場所：

　 模式是一種傳統(tǒng)軟件開發(fā)模型，一般適用于一些傳統(tǒng)信息系統(tǒng)應(yīng)用的開發(fā)，而一些高性能高風(fēng)險的系統(tǒng)、互聯(lián)網(wǎng)軟件，或一個系統(tǒng)難以被具體模塊化的時候，就比較難做成V模式所需的各種構(gòu)件，需要更強調(diào)迭代的開發(fā)模型或者敏捷開發(fā)模型。

總結(jié)

以上是生活随笔為你收集整理的软件工程 瀑布模型、原型模型、喷泉模型和V模型的优缺点及适用场景的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。