在20世紀80年代之前，瀑布模型是最早也是應用最廣泛的軟體過程模型，現在它仍然是軟體工程中應用得最廣泛的過程模型。瀑布模型提供了軟體開發的基本架構，其過程是接收上一項活動的工作結果作為輸入，然後實施該項活動應完成的工作，并将該項活動的工作結果作為輸出傳給下一項活動。同時，在開始下一個階段的活動之前需要評審該項活動的實施，若确認，則繼續下一項活動；否則傳回前面，甚至更前面的活動。
瀑布模型将軟體生存周期劃分為軟體計劃、需求分析、軟體設計、軟體實作、軟體測試、運作與維護這6個階段，規定了它們自上而下、互相銜接的固定次序，如同瀑布流水逐級下落。
從本質來講瀑布模型是一個軟體開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到産品釋出及維護，每個階段都會産生循環回報，是以，如果有資訊未被覆寫或者發現了問題，那麼最好 “傳回”上一個階段并進行适當的修改，開發程序從一個階段“流動”到下一個階段，這也是“瀑布”模型名稱的由來。瀑布模型的軟體過程如圖3-1所示。
瀑布模型各個階段産生的文檔是維護軟體産品必不可少的，沒有文檔的軟體幾乎是不可能維護的。瀑布模型中的文檔限制，使軟體維護變得更加容易。由于絕大部分軟體預算都花費在軟體維護上，是以，使軟體易于維護就能顯著降低軟體預算。按照傳統的瀑布模型開發軟體，有下述的幾個特點。
順序性和依賴性。瀑布模型的各個階段之間存在着這樣的關系：後一階段的工作必須等前一階段的工作完成之後才能開始。前一階段的輸出文檔就是後一階段的輸入文檔，是以，隻有前一階段的輸出文檔正确，後一階段的工作才能獲得正确的結果。
推遲實作。對于規模較大的軟體項目來說，往往編碼開始得越早，最終完成開發工作所需要的時間反而越長。主要原因是前面階段的工作沒做或做得不到位，過早地進行下一階段的工作，往往導緻大量返工，有時甚至發生無法彌補的問題，帶來災難性後果。瀑布模型在編碼之前設定了系統分析與系統設計的各個階段，分析與設計階段的基本任務規定，在這兩個階段主要考慮目标系統的邏輯模型，不涉及軟體的程式設計實作。清楚地區分邏輯設計與實體設計，盡可能推遲程式的程式設計實作，是按照瀑布模型開發軟體的一條重要的指導思想。
品質保證。為保證軟體的品質，瀑布模型的每個階段都應完成規定的文檔，隻有交出合格的文檔才算完成該階段的任務。完整、準确的合格文檔不僅是軟體開發時期各類人員之間互相通信的媒介，也是運作時期對軟體進行維護的重要依據。其次，在每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題、改正錯誤。事實上，越是早期階段犯下的錯誤，暴露出來的時間就越晚，排除故障、改正錯誤所需付出的代價也越高。
瀑布模型着重強調文檔的作用，并要求每個階段都要仔細驗證。但這種模型的線性過程太理想化，已不再适合現代化軟體開發的模式，其主要問題在于：
各個階段的劃分完全固定，階段之間産生大量的文檔，極大地增加了工作量。事實證明，一旦一個使用者開始使用一個軟體，在他的頭腦中關于該軟體應該做什麼的想法就會或多或少地發生變化，這就使得最初提出的需求變得不完全适用了。
由于開發模型是線性的，使用者隻有等到整個過程的末期才能見到開發成果，進而增加了開發的風險；客戶要等到開發周期的晚期才能看到程式運作的測試版本，而在這時發現大的錯誤時，其後果可能是災難性的；實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的疊代是間接的，這很容易由微小的變化造成大的混亂。
增量模型（incremental model）也稱為漸增模型，是在項目的開發過程中以一系列的增量方式開發系統。在增量模型中，軟體被作為一系列的增量構件來設計、實作、內建和測試，每一個構件由多種互相作用的子產品所形成的提供特定功能的代碼片段構成。
增量方式包括增量開發和增量送出。增量開發是指在項目開發周期内，在一定的時間間隔内開發部分工作軟體；增量送出是指在項目開發周期内，在一定的時間間隔内以增量方式向使用者送出工作軟體和文檔。
總體開發與增量構造模型
它在瀑布模型基礎上，對一些階段進行整體開發，如分析與設計階段，對另一些階段進行增量開發，如編碼和測試階段。前面的分析與設計階段按瀑布模型進行整體開發，後面的編碼與測試階段按增量方式開發。
總體開發與增量構造模型融合了瀑布模型的基本成分和原型實作模型的疊代特征，采用随時間的進展而交錯的線性序列，每一個線性序列産生軟體的一個可釋出的“增量”，如圖3-2所示。
當使用增量模型時，第一個增量往往是核心的産品，即第一個增量實作了基本的需求，但很多補充的特征還沒有釋出。客戶對每一個增量的使用和評估作為下一個增量釋出的新特征和功能，這個過程在每一個增量釋出後不斷重複，直到産生最終的完善産品。
總體開發與增量構造模型強調每一個增量均釋出一個可操作的産品。
增量開發與增量送出模型
它在瀑布模型的基礎上，所有階段都進行增量開發，也就是說不僅是增量開發，也是增量送出。這種模型融合了線性順序模型的基本成分和原型實作模型的疊代特征。
增量開發與增量送出模型采用随着日程時間的進展而交錯的線性序列。每一個線性序列産生軟體的一個可釋出的“增量”。當使用演化增量送出模型時，第一個增量往往是核心的産品，也就是說第一個增量實作了基本的需求，但很多補充的特征還沒有釋出。客戶對每一個增量的使用和評估，都作為下一個增量釋出的新特征和功能。這個過程在每一個增量釋出後不斷重複，直到産生最終的完善産品。增量開發與增量送出模型強調每一個增量均要釋出一個可運作的産品。
增量模型在各個階段并不傳遞一個可運作的完整産品，而是傳遞滿足客戶需求的可運作産品的一個子集。整個産品被分解成若幹個構件，開發人員逐個傳遞産品，這樣軟體開發可以很好地适應變化，客戶可以不斷地看到所開發的軟體，進而降低開發風險。但是，增量模型也存在以下缺陷：
各個構件是逐漸并入已有的軟體體系結構中的，是以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構。
在實際的軟體開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其适應這種變化的能力大大優于瀑布模型，但也很容易退化為邊做邊改模型，進而使軟體過程的控制失去整體性。
螺旋模型（spiral model）是由barry boehm正式提出的模型，它将瀑布模型和快速原型模型結合起來，不僅展現了兩個模型的優點，而且還強調了其他模型均忽略的風險分析，特别适合于大型複雜的系統。
螺旋模型的每一個周期都包括需求定義、風險分析、工程實作和評審4個階段，由這4個階段進行疊代。軟體開發過程每疊代一次，軟體開發又前進一個層次。螺旋模型的軟體過程如圖3-3所示。
螺旋模型在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識别、風險分析和風險控制，它把軟體項目分解成一個個小項目。每個小項目都辨別一個或多個主要風險，直到所有的主要風險因素都被确定。該模型沿着螺旋線進行若幹次疊代，圖3-3中的4個象限分别代表了以下活動：
制訂計劃：确定軟體目标，標明實施方案，确定項目開發的限制條件。
風險分析：評估所選方案，考慮如何識别和消除風險。
實施工程：實施軟體開發和驗證。
客戶評估：評價開發工作，提出修正建議，制訂下一步計劃。
螺旋模型有許多優點：
對可選方案和限制條件的強調有利于已有軟體的重用，也有助于把軟體品質作為軟體開發的一個重要目标。
減少了過多測試（浪費資金）或測試不足（産品故障多）所帶來的風險。
在螺旋模型中維護隻是模型的另一個周期，在維護和開發之間并沒有本質差別。
與瀑布模型相比，螺旋模型支援使用者需求的動态變化，為使用者參與軟體開發的所有關鍵決策提供了友善，有助于提高目标軟體的适應能力，為項目管理人員及時調整管理決策提供了便利，進而降低了軟體開發風險。
螺旋模型由風險驅動，強調可選方案和限制條件進而支援軟體的重用，幫助我們将軟體品質作為特殊目标融入産品開發之中。但螺旋模型也有一定的限制條件：螺旋模型強調風險分析，使得開發人員和使用者對每個演化層出現的風險有所了解，繼而做出應有的反應，是以特别适用于複雜并具有高風險的系統。對于這些系統，風險是軟體開發不可忽視且潛在的不利因素，它可能在不同程度上損害軟體開發過程，影響軟體産品的品質。減小軟體風險的目标是在造成危害之前，及時對風險進行識别及分析，決定采取何種對策，進而減少或消除風險的損害。風險驅動是螺旋模型的主要優勢，但在一定情況下這也可能是它的一個弱點。軟體開發人員應該擅長尋找可能的風險，準确地分析風險，否則将會帶來更大的風險。
另一方面，如果執行風險分析将明顯影響項目的利潤，那麼進行風險分析就需要慎重，是以，螺旋模型隻适合于大規模軟體項目。事實上，項目越大，風險也越大，是以，進行風險分析的必要性也越大。此外，隻有内部開發的項目，才能在風險過大時中止項目。