不幸的是，許多產品都是使用“邊做邊改”的模式開發的。在這種模式下，既沒有規範，也沒有設計，軟件隨著客戶的需求壹次又壹次的不斷修改。
在這種模式下，開發人員拿到項目後立即根據需求編寫程序，調試後生成軟件的第壹個版本。提供給用戶後，如果程序出現錯誤或者用戶提出新的需求，開發者會再次修改代碼，直到用戶滿意為止。
這是壹種作坊式的開發方法，對於寫幾百行的小程序來說還不錯，但是這種方法對於任何規模的開發都不盡如人意。主要問題如下:
(1)缺乏規劃設計環節，軟件的結構隨著不斷修改越來越差，無法繼續修改；
(2)忽視需求環節給軟件開發帶來很大風險；
(3)不考慮測試和程序的可維護性，沒有任何文檔，維護軟件是非常困難的。
2.瀑布模型
溫斯頓·羅伊斯(Winston Royce)在1970提出了著名的瀑布模型，直到20世紀80年代初，它還是唯壹被廣泛使用的軟件開發模型。
在瀑布模型中，如圖所示，軟件生命周期分為規劃、需求分析、軟件設計、編程、軟件測試和運維等六個基本活動，並規定了它們自上而下連接的固定順序，像瀑布壹樣，壹步步落下。
在瀑布模型中，軟件開發的所有活動都是嚴格以線性方式進行的，當前活動接受前壹個活動的工作結果，並實現所需的工作內容。需要驗證當前活動的工作結果。如果通過驗證，結果將作為下壹個活動的輸入，繼續下壹個活動；否則，它將被修改。
瀑布模型強調文檔的作用，需要在每個階段進行仔細的驗證。但是這種模型的線性過程過於理想化，已經不適合現代軟件開發模式，幾乎被業界所拋棄。它的主要問題是:
(1)每個階段的劃分是完全固定的，階段之間產生大量的文檔，大大增加了工作量；
(2)由於開發模型是線性的，用戶直到整個過程結束才能看到開發結果，增加了開發的風險；
(3)早期的錯誤可能要到開發後期的測試階段才能發現，會帶來嚴重的後果。
要認識到“線性”是最容易掌握和熟練運用的思維方法。當人們遇到壹個復雜的“非線性”問題時，總會想盡辦法將其分解或轉化為壹系列簡單的線性問題，然後逐壹求解。壹個軟件系統的整體可能是復雜的，而單個子程序總是簡單的，可以用線性的方式實現，否則工作起來會太累。線性是壹種簡單，簡單就是美。當我們理解線性的精神時，我們不應該機械地套用線性模型的外觀，而是生動地使用它。比如增量模型本質上是分段線性模型，而螺旋模型是連續曲線線性模型，在其他模型中也能找到線性模型的影子。
3.快速原型模型(快速原型模型)
快速原型模型(Rapid prototype model)的第壹步是構建壹個快速原型，實現客戶或未來用戶與系統的交互，用戶或客戶會對原型進行評估，進壹步細化待開發軟件的需求。通過逐步調整原型以滿足客戶的要求，開發人員可以確定客戶的真正需求是什麽；第二步是在第壹步的基礎上開發客戶滿意的軟件產品。
顯然，快速原型法可以克服瀑布模型的缺點，降低軟件需求不明確帶來的開發風險，效果顯著。快速原型制作的關鍵是盡可能快地構建軟件原型。壹旦確定了客戶的真實需求，構建好的原型就會被丟棄。因此，原型系統的內部結構並不重要。重要的是，原型必須快速建立，然後快速修改，以反映客戶的需求。
4.增量模型
也被稱為進化模型。就像蓋大樓壹樣，軟件是壹步壹步建起來的。在增量模型中，軟件是作為壹系列增量組件來設計、實現、集成和測試的，每個組件都由代碼片段組成，這些代碼片段提供由各種交互模塊形成的特定功能。
增量模型並不交付可以在每個階段運行的完整產品，而是交付可以滿足客戶需求的產品子集。整個產品分成幾個組件，開發者壹個壹個交付產品。這樣做的好處是軟件開發可以更好地適應變化，客戶可以不斷地看到開發出來的軟件，從而降低開發風險。然而，增量模型也有以下缺陷:
(1)由於每個組件都是逐漸融合到已有的軟件架構中的，所以添加組件壹定不能破壞已構建的系統部分，這就要求軟件具有開放的架構。
(2)在發展過程中，需求的變化是不可避免的。增量模型的靈活性可以使其比瀑布模型和快速原型模型模型更好地適應這種變化，但也容易退化為邊做邊改模型，從而失去軟件過程控制的完整性。
使用增量模型時，第壹個增量往往是實現基本需求的核心產品。核心產品交付給用戶後，經過評估形成下壹步的增量開發計劃，包括核心產品的修改和壹些新功能的發布。這壹過程在每次增量發布後重復進行，直到生產出最終的完美產品。
比如用增量模型開發文字處理軟件。可以認為第壹個增量發布基本的文件管理、編輯和文檔生成功能，第二個增量發布更完善的編輯和文檔生成功能，第三個增量實現拼寫和語法檢查功能，第四個增量完成高級頁面布局功能。
5.螺旋模型
1988年，Barry Boehm正式發表了軟件系統開發的“螺旋模型”，將瀑布模型與快速原型模型相結合，強調了其他模型所忽略的風險分析，特別適用於大型復雜系統。
如圖所示，螺旋模型沿著螺旋進行多次叠代，圖中的四個象限代表以下活動:
(1)規劃:確定軟件目標，選擇實施方案，明確項目開發的約束條件；
(2)風險分析:對選定的方案進行分析和評價，考慮如何識別和消除風險；
(3)實施項目:實施軟件開發和驗證；
(4)客戶評估:對開發工作進行評估，提出修改建議，制定下壹步計劃。
螺旋模型是風險驅動的，強調支持軟件復用的備選方案和約束，有助於將軟件質量作為壹個特殊目標融入產品開發。但是，螺旋模型也有某些限制，如下所示:
(1)螺旋模型強調風險分析，但要讓很多客戶接受並相信這種分析並做出相關反應並不容易。因此，這種模型通常適合於內部的大型軟件開發。
(2)如果風險分析的執行會極大地影響項目的利潤，那麽進行風險分析是沒有意義的。因此，螺旋模型只適用於大型軟件項目。
(3)軟件開發人員要善於發現可能的風險，準確分析風險，否則會帶來更大的風險。
壹個階段首先是確定階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險的角度分析方案的發展策略，盡量消除各種潛在的風險，有時是通過構建原型。如果某些風險無法消除，該方案將立即終止，否則將開始下壹步開發。最後，評估這壹階段的成果，設計下壹階段。
6.噴泉模型(也稱為面向對象生存期模型，OO模型)
與傳統的結構化生命周期相比，噴泉模型具有更多的增量和叠代性質，生命周期的每個階段可以多次重疊和重復，子生命可以嵌入到項目的整個生命周期中。就像噴在上面的水會掉下來壹樣，可以掉在中間，也可以掉在底部。
7.智能模型(第四代技術(4GL))
智能模型有壹套工具(如數據查詢、報告生成、數據處理、屏幕定義、代碼生成、高級圖形功能和電子表格等。)，而且每個工具都可以讓開發者在高層次上定義軟件的壹些特性，自動生成這些開發者定義的軟件作為源代碼。
這種方法需要四代語言的支持(4GL)。4GL不同於第三代語言，它的主要特點是用戶界面極其友好，所以即使沒有經過培訓的非專業程序員，也可以用它來編寫程序。它是壹種聲明式、交互式和非過程化的編程語言。4GL也有高效的程序代碼，智能默認假設，完整的數據庫和應用程序生成器。目前，4GL(如Foxpro等。)市場上流行的都不同程度地具備上述特征。但4GL目前主要局限於交易信息系統中小型應用程序的開發。
8.混合模型
過程開發模型也稱為混合模型，或元模型。它將幾個不同的模型組合成壹個混合模型，允許項目沿著最有效的路徑發展。這就是過程開發模型(或混合模型)。事實上，壹些軟件開發公司使用幾種不同的開發方法來形成自己的混合模型。各種模型的比較每壹個軟件開發組織都應該選擇壹個適合本組織的軟件開發模型，並且應該隨著當前正在開發的具體產品特性而變化，從而減少所選模型的缺點，充分利用其優點。下表列出了幾種常見模型的優缺點。各種型號的優缺點:
模型瀑布模型文檔驅動系統的優缺點可能無法滿足客戶的需求。快速原型模型對滿足客戶需求的關註可能會導致系統設計不佳和效率低下，並且難以維護增量模型。早期反饋及時且易於維護，這需要開放的架構，並可能導致糟糕的設計和低效率。螺旋模型風險驅動的風險分析師需要經驗豐富，訓練有素。
9.RUP模型
RUP(Rational統壹過程)模型是由Rational公司提出的壹套開發過程模型，是面向對象軟件工程的通用業務過程。它描述了壹系列相關的軟件工程過程，這些過程具有相同的結構，即相同的過程框架。RUP提供了壹種在開發組織中分配任務和職責的標準化方法，其目標是確保在可預測的時間表和預算內開發出滿足最終用戶需求的高質量軟件。RUP有兩個軸，其中壹個是時間軸，是動態的。另壹個軸是工作流軸，它是靜態的。在時間軸上，RUP分為四個階段:初始階段、詳細階段、建設階段和發布階段。叠代的概念用於每個階段。在工作流程軸上，RUP設計了六個核心工作流程和三個核心支持工作流程。核心工作流包括:業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支持工作流包括:環境工作流、項目管理工作流以及配置和變更管理工作流。RUP匯集了現代軟件開發許多方面的最佳經驗，並提供了壹種靈活的形式來滿足各種項目和組織的需求。作為壹個業務模型，它有非常詳細的過程指南和模板。但由於模型的復雜性，掌握模型的成本很高。特別是對項目經理提出了更高的要求。
它具有以下特點:
(1)增量叠代，每次叠代遵循瀑布模型，可以在前期控制和解決風險；
(2)模型的復雜性要求項目經理具有很強的管理能力。
10.IPD模型
IPD(Integrated Product Development，集成產品開發)過程是IBM提出的壹套集成產品開發過程，非常適用於復雜的大型開發項目，尤其是涉及軟硬件結合的項目。
IPD從整個產品的角度，綜合考慮從系統工程、研發(硬件、軟件、結構工業設計、測試、數據開發等所有流程。)、制造、上市融資、采購、技術支持等。這是壹個端到端的過程。
在IPD過程中，有六個階段(概念階段、規劃階段、開發階段、驗證階段、發布階段和生命周期階段)，四個決策評審點(概念階段決策評審點、規劃階段決策評審點、可用性決策評審點和生命周期終止決策評審點)和六個技術評審點。
IPD過程是壹個帶有瀑布模型影子的階段模型。這個模型通過使用壹個全面復雜的過程來分解壹個龐大復雜的系統並降低風險。該模式在壹定程度上是通過工藝成本來提高整個產品的質量，獲得市場份額。因為流程沒有定義如何回滾流程的機制，所以不適合需求變化頻繁的項目。而且對於壹些小項目來說，不是很適合用這個流程。