原文大部分內容來自https://blog.csdn.net/zjuwxx/article/details/97252039 （感謝博主）同時加入了第5點 噴泉模型
一 瀑布模型
1.1 什麼是瀑布模型
1970年溫斯頓.羅伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被廣泛採用的軟件開發模型
瀑布模型將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落
瀑布模型是最早出現的軟件開發模型，在軟件工程中佔有重要的地位，它提供了軟件開發的基本框架。其過程是從上一項活動接收該項活動的工作對象作爲輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，並作爲輸出傳給下一項活動
從本質來講，它是一個軟件開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到產品發佈和維護，每個階段都會產生循環反饋，因此，如果有信息未被覆蓋或者發現了問題，那麼最好 “返回”上一個階段並進行適當的修改，開發進程從一個階段“流動”到下一個階段，這也是瀑布開發名稱的由來
對於經常變化的項目而言，瀑布模型毫無價值
1.2 特點
1、階段間具有順序性和依賴性
該階段具有兩重含義
- 必須等前一階段的工作完成後，才能開始後一階段的工作
- 前一階段的輸出文檔就是後一階段的輸入文檔，因此只有前一階段的輸出文檔正確，後一階段的工作才能獲得正確的結果
2、推遲實現的觀點
對於規模較大的軟件項目來說，往往編碼開始的越早，最終完成開發所需時間越長。因爲前面階段的工作沒做或做的不紮實，過早地考慮進行程序實現，往往導致大量返工，有時甚至發生無法彌補的問題
瀑布模型在編碼之前設置了系統分析與系統設計的各個階段，分析與設計階段的基本任務規定，在這兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現
清楚的區分邏輯設計與物理設計，儘可能推遲程序的物理實現，是按照瀑布模型開發軟件的一條重要的指導思想
3、質量保證的觀點
爲了保證所開發的軟件的質量，在瀑布模型的每一個階段都應堅持兩個重要做法
- 每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務
- 每個階段結束前都要對所完成的文檔進行評審，以便儘早發現問題，改正錯誤
傳統的瀑布模型過於理想化，實際的瀑布模型是帶"反饋環"的。如圖所示（圖中實線箭頭表示開發過程，虛線箭頭表示維護過程），當在後面階段發現前面階段的錯誤時，需要沿圖中左側的反饋線返回前面的階段，修正前面階段的產品後再回來繼續完成後面階段的任務
瀑布模型是文檔驅動的模型，遵守這個約束可使軟件維護變得比較容易一些，從而顯著降低軟件預算
1.3 優缺點
優點：
- 爲項目提供了按階段劃分的檢查點
- 當前一階段完成後，您只需要去關注後續階段
- 可在迭代模型中應用瀑布模型
缺點：
- 不適合需求模糊或需求經常變動的系統
- 由於開銷的逐步升級問題，它不希望存在早期階段的反饋
- 在一個系統完成以前，它無法預測一個新系統引入一個機構的影響
- 在用戶可能需要較長等待時間來獲得一個可供使用的系統，也許會給用戶的信任程度帶來影響和打擊
- 最終產品往往反映用戶的初始需求而不是最終需求
1.4 客戶需求
對項目而言，是否使用這一模型主要取決於是否能理解客戶的需求以及在項目的進程中這些需求的變化程度；對於經常變化的項目而言，瀑布模型毫無價值，可以考慮其他的架構來進行項目管理，比如螺旋模型
瀑布模型強調文檔的作用，並要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟件開發模式，幾乎被業界拋棄，其主要問題在於：
- 各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量
- 由於開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險
- 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果
按照瀑布模型的階段劃分，軟件測試可以分爲單元測試，集成測試，系統測試
二 快速原型模型
2.1 什麼是快速原型模型
快速原型是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集
快速原型模型是增量模型的另一種形式，在開發真實系統之前，迅速建造一個可以運行的軟件原型 ，以便理解和澄清問題，在該原型的基礎上，逐漸完成整個系統的開發工作
它允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型，該原型向用戶展示待開發軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發人員據此對軟件進行修改完善，直至用戶滿意認可之後，進行軟件的完整實現及測試、維護
2.2 優缺點
優點
- 克服瀑布模型的缺點，減少由於軟件需求不明確帶來的開發風險
- 適合預先不能確切定義需求的軟件系統的開發
缺點
- 所選用的開發技術和工具不一定符合主流的發展；快速建立起來的系統結構加上連續的修改可能會導致產品質量低下
- 使用前提是要有一個展示性的產品原型，一定程度上可能會限制開發人員的創新
2.3 快速原型模型的思想產生、原理及運用方式
1、思想產生
在需求分析階段得到完全、一致、準確、合理的需求說明十分困難
獲得一組基本需求說明後，就快速地使其“實現”，通過原型反饋，加深對系統的理解滿足用戶基本要求，使用戶在試用後對需求說明進行補充和精確化，從而獲得合理完整、現實可行的需求說明
再把快速原型思想用到軟件開發的其他階段，向軟件開發的全過程擴展
先用相對少的成本，較短的週期開發一個簡單的、但可以運行的系統原型向用戶演示或讓用戶試用，以便及早澄清並檢驗一些主要設計策略，在此基礎上再開發實際的軟件系統
2、原理
利用原型輔助軟件開發
經過簡單快速分析快速實現一個原型，用戶與開發者在試用原型過程中加強通信與反饋，通過反覆評價和改進原型，減少誤解，彌補漏洞，最終提高軟件質量
3、運用方式
由於運用原型的目的和方式不同，在使用原型時也採取不同的策略
- 拋棄策略：將原型用於開發過程的某個階段，促使該階段的開發結果更加完整、準確、一致、可靠，該階段結束後，原型隨之作廢。探索型和實驗型就是採用此策略的
- 附加策略：將原型用於開發的全過程，原型由最基本的核心開始，逐步增加新的功能和新的需求，反覆修改反覆擴充，最後發展爲用戶滿意的最終系統，演化型快速原型就是採用此策略
採用何種形式、何種策略運用快速原型主要取決於軟件項目的特點、可供支持的原型開發工具和技術等，根據實際情況的特點決定
2.4 類型
在軟件開發中，原型是軟件的一個早期可運行的版本，它反映最終系統的部分重要特性
探索型
- 這種原型目的是要弄清對目標系統的要求，確定所希望的特性，並探討多種方案的可行性
實驗型
- 這種原型用於大規模開發和實現之前，考覈方案是否合適，規格說明是否可靠
進化型
- 這種原型的目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統
2.5 開發步驟
1、快速分析
在分析人員與用戶密切配合下，迅速確定系統的基本需求，根據原型需要體現的特徵描述基本需求以滿足開發原型的需要
2、構造原型
在快速分析的基礎上，根據基本需求說明儘快實現一個可行的系統
要求具有強有力的軟件工具的支持，並忽略最終系統在某些細節上的要求，主要考慮原型系統能夠充分反映所要評價的特性
3、運行原型
發現問題，消除誤解，開發者與用戶充分協調
4、評價原型
在運行的基礎上，考覈評價原型的特性，分析運行效果是否滿足用戶的願望，糾正過去交互中的誤解與分析中的錯誤，增添新的要求，並滿足因環境變化或用戶的新想法引起的系統要求變動，提出全面的修改意見
5、修改
- 根據評價原型的活動結果進行修改
- 若原型未滿足需求說明的要求，說明對需求說明存在不一致的理解或實現方案不夠合理，根據明確的要求迅速修改原型
- 快速原型模型不帶反饋環，軟件產品的開發基本上是線性順序進行的
- 快速原型的本質是"快速"。開發人員應儘可能地建造出原型系統，以加速軟件開發過程，節約軟件開發成本
- 原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄
三 增量模型
3.1 什麼是增量模型
增量模型也稱漸增模型。使用增量模型開發軟件時，把軟件產品作爲一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，並且能夠完成特定的功能
使用增量模型時，第一個增量構件往往實現軟件的基本需求，提供最核心的功能
把軟件產品分解成增量構件時，唯一必須遵守的約束條件是，當把新構件集成到現有構件中時，所形成的產品必須是可測試的
- 瀑布模型或快速原型模型目標是一次就把一個滿足所有需求的產品提交給用戶
- 增量模型把整個軟件產品分解成許多個增量構件，分批地逐步向用戶提交產品
3.2 特點
把瀑布模型的順序特徵與快速原型法的迭代特徵相結合
將軟件看作一系列相互聯繫的增量，在開發過程的各次迭代中，每次完成其中的一個增量
風險更大的增量模型
- 確定用戶需求後就着手擬定第一個構件的規格說明文檔，完成後規格說明組轉向第二個構件的規格說明文檔，同時設計組開始涉及第一個構件
- 使用該方法將不同的構件並行構建，可能加快工程進度，但將冒構建無法集成到一起的風險
3.3 優缺點
優點
- 能在較短的時間內向用戶提交可完成部分工作的產品
- 將待開發的軟件系統模塊化，可以分批次地提交軟件產品，使用戶可以及時瞭解軟件項目的進展
- 以組件爲單位進行開發降低了軟件開發的風險。一個開發週期內的錯誤不會影響到整個軟件系統
- 開發順序靈活。開發人員可以對組件的實現順序進行優先級排序，先完成需求穩定的核心組件。當組件的優先級發生變化時，還能及時地對實現順序進行調整
缺點
- 由於各個構件是逐漸併入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構
- 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化爲邊做邊改模型，從而是軟件過程的控制失去整體性
- 如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析，這種模型將功能細化後分別開發的方法較適應於需求經常改變的軟件開發過程
3.4 作用
1、開發初期的需求定義只是用來確定軟件的基本結構，使得開發初期用戶只需要對軟件需求進行大概的描述；而對於需求的細節性描述，則可以延遲到增量構件開發時進行，以增量構件爲單位逐個地進行需求補充。這種方式能夠有效適應用戶需求的變更
2、軟件系統可以按照增量構件的功能安排開發的優先順序，並逐個實現和交付使用。不僅有利於用戶儘早用上系統，能夠更好地適應新的軟件環境，而且在以增量方式使用系統的過程中，還能獲得對軟件系統後續構件的需求經驗
3、軟件系統是逐漸擴展的，因此開發者可以通過對諸多構件的開發，逐步積累開發經驗。實際上，增量式開發還有利於技術複用，前面構件中設計的算法、採用的技術策略、編寫的源碼等，都可以應用到後面將要創建的增量構件中去
4、增量式開發有利於從總體上降低軟件項目的技術風險。個別的構件或許不能使用，但一般不會影響到整個系統的正常工作
5、實際上，在採用增量模型時，具有最高優先權的核心增量構件將會被最先交付，而隨着後續構件不斷被集成進系統，這個核心構件將會受到最多次數的測試。這意味着軟件系統最重要的心臟部分將具有最高的可靠性，這將使得整個軟件系統更具健壯性
四 螺旋模型
4.1 什麼是螺旋模型
螺旋模型是一種演化軟件開發過程模型，它兼顧了快速原型的迭代特徵以及瀑布模型的系統化與嚴格監控。螺旋模型最大的特點在於引入了其他模型不具備的風險分析，使軟件在無法排除重大風險時有機會停止，以減小損失。同時，在每個迭代階段構建原型是螺旋模型用以減小風險的途徑
螺旋模型是快速原型模型以進化的開發方式爲中心，在每個項目階段使用瀑布模型法。該模型的每一個週期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層次。用螺旋模型的軟件過程如下
簡化的螺旋模型
完整的數據模型
圖中帶箭頭的點劃線的長度代表當前累計的開發費用，螺旋線的角度值代表開發進度，螺旋線的每個週期對應於一個開發階段
圖中的四個象限代表了以下活動
- 制定計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件
- 風險分析：分析評估所選方案，考慮如何識別和消除風險
- 實施工程：實施軟件開發和驗證
- 客戶評估：評價開發工作，提出修正建議，制定下一步計劃
4.2 特點
螺旋模型在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目。每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定
螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險有所瞭解，繼而做出應有的反應，因此特別適用於龐大、複雜並具有高風險的系統
4.3 優缺點
優點
- 對可選方案和約束條件的強調有利於已有軟件的重用，也有助於把軟件質量作爲軟件開發的一個重要目標
- 減少了過多測試（浪費資金）或測試不足（產品故障多）所帶來的風險
- 在螺旋模型中維護只是模型的另一個週期，在維護和開發之間並沒有本質區別
缺點
- 採用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失
- 過多的迭代次數會增加開發成本，延遲提交時間
4.4 限制條件
- 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟件開發
- 如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟件項目
- 軟件開發人員應該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險
一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啓動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段
五 噴泉模型
5.1 什麼是噴泉模型
噴泉模型是一種以用戶需求爲動力，以對象爲驅動的模型，主要用於描述面向對象的軟件開發過程。該模型認爲軟件開發過程自下而上週期的各階段是相互迭代和無間隙的特性
噴泉模型主要用於採用對象技術的軟件開發項目。該模型認爲軟件開發過程自下而上週期的各階段是相互迭代和無間隙的特性。軟件的某個部分常常被重複工作多次，相關對象在每次迭代中隨之加入漸進的軟件成分。無間隙指在各項活動之間無明顯邊界，如分析和設計活動之間沒有明顯的界限，由於對象概念的引入，表達分析、設計、實現等活動只用對象類和關係，從而可以較爲容易地實現活動的迭代和無間隙，使其開發自然地包括複用。
變換型
1）思想：
從軟件需求的形式規格說明出發，經過一系列的程序變化，得到最終結果
2）特點：
有嚴格的數學理論和形式化的技術支持，單目前研究和實驗階段，不能實用
噴泉型
認爲軟件的各個週期是相互重疊的和多次反覆的
螺旋型
多次原型反覆並增加風險評估的開發模型。