目錄
1. 邊做邊改模型（Build-and-Fix-Model）
在這種模型中，既沒有規格說明，也沒有經過設計，軟件隨著客戶的需要一次又一次地不斷被修改。在這個模型中，開發人員拿到項目立即根據需求編寫程序，調試通過后生成軟件的第一個版本。在提供給用戶使用后，如果程序出現錯誤，或者用戶提出新的要求，開發人員重新修改代碼，直到用戶和測試等等滿意為止。
優點：
這是一種類似作坊的開發方式，邊做邊改模型的優點毫無疑問就是前期出成效快。
缺點：
對編寫邏輯不需要太嚴謹的小程序來說還可以對付得過去，但這種方法對任何規模的開發來說都是不能令人滿意的。
原因在于
2. 瀑布模式（-Model）
特點:
適合于一些大型穩定的項目
優點:
缺點:缺乏靈活性，太過線性理想化，不適合現代軟件開發
當一個新系統的開發存在多個完全不相關的獨立需求的功能開發的時候,這個時候也可以選擇將整個開發過程按獨立的需求來分為多個小瀑布進行操作.這種方式的最大問題就是沒有一個完全總體的設計,架構設計人員無法在洞悉了所有需求后從系統的可擴展性,復用等方面總體規劃.
BTW：
很多人往往會以進度約束而不選擇瀑布模型,這往往是一個錯誤的觀點.導致這種情況的一個關鍵因素往往是概念需求階段人力不足.因此在概念需求階段人力能 夠得到充分保證的情況下,瀑布模型和迭代模型在開發周期上并不會存在太大的差別.反而是很多項目對于迭代或敏捷模型用不好,為了趕進度在前期需求不明確, 沒有經過一個總體的架構設計情況下就開始編碼,后期出現大量的返工而嚴重影響進度.
在項目管理中有一種壓縮進度的方法叫趕工,因此瀑布模型的另外改進處就在適當的重疊各個階段過程,達到資源的有效利用.比如我們通過討論,會議確定的實現方式就可以開始執導下一個階段的工作而不一定完全等到相關的交付物文檔化出來.
3. 螺旋模型（-Model）
1988年，巴利·玻姆(Barry Boehm)正式發表了軟件系統開發的“螺旋模型”，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統。
螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動：
（1）制定計劃：確定軟件目標軟件工程中常用的軟件開發模型，選定實施方案，弄清項目開發的限制條件；
（2）風險分析：分析評估所選方案，考慮如何識別和消除風險；
（3）實施工程：實施軟件開發和驗證；
（4）客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
特點:
優點:
缺點:
很難讓用戶確信這種演化方法的結果是可以控制的.建設周期長,而軟件技術發展比較快,所以經常出現軟件開發完畢后,和當前的技術水平有了較大的差距,無法滿足當前用戶需求.
每輪循環包含六個步驟:
確定目標,可選項（替代方案）,以及強制條件（約束條件）識別并化解風險評估可選項開發并測試當前階段規劃下一階段確定進入下一階段的方法步驟.
模型:
BTW：
螺旋模型實現了隨著項目成本投入不斷增加,風險逐漸減小.以幫我我們加強項目的管理和跟蹤,在每次迭代結束后都需要對產出物進行評估和驗證,當發現無法繼續進行下去時可以及早的終止項目.
螺旋模型復雜的地方在于盡責,專心和知識淵博的管理.因為對于每一次迭代我們要制定出清晰的目標,分析出相關的關鍵風險和計劃中可以驗證和測試的交付物并不是一件容易的事情.
螺旋模型的每一次迭代只包含了瀑布模型的某一個或兩個階段.如第二次迭代重點是需求,第三次迭代是總體設計和后續設計開發計劃等.因此這是和RUP（ ，統一軟件開發過程）提倡 的迭代模型是有區別的,RUP的每一次迭代都會包含需求,設計,開發和測試等各個階段的活動.RUP迭代的目的在于逐步求精而不是僅僅完成瀑布模型某一階 段的工作.
4. 快速原型模型（Rapid--Model）
快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價軟件工程中常用的軟件開發模型，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什么；第二步則在第一步的基礎上開發客戶滿意的軟件產品。
顯然，快速原型方法可以克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發風險，具有顯著的效果。原型的關鍵在于盡可能快速地建造出軟件原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構并不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。
快速原型模型有點整合“邊做邊改”與“瀑布模型”優點的意味。
優點：
缺點：
原型類型:
原型的運用方式:
模型:
5. 增量和迭代模型
增量迭代是RUP統一過程常采用的軟件開發生命周期模型.增量和迭代有區別但兩者又經常一起使用.所以這里要先解釋下增量和迭代的概念。假設現在要開發 A,B,C,D四個大的業務功能,每個功能都需要開發兩周的時間.則對于增量方法而言可以將四個功能分為兩次增量來完成,第一個增量完成A,B功能,第二 次增量完成C,D功能;而對于迭代開發來將則是分兩次迭代來開發,第一次迭代完成A,B,C,D四個基本業務功能但不含復雜的業務邏輯,而第二個功能再逐 漸細化補充完整相關的業務邏輯.在第一個月過去后采用增量開始時候A,B全部開發完成而C,D還一點都沒有動;而采用迭代開發的時候A,B,C,D四個的 基礎功能都已經完成.
5.1 增量模型（-Model）
在增量模型中，軟件被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成。
增量模型在各個階段并不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟件開發可以較好地適應變化，客戶可以不斷地看到所開發的軟件，從而降低開發風險。但是，增量模型也存在以下缺陷：
由于各個構件是逐漸并入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構。在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過程的控制失去整體性。
在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用后，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布后不斷重復，直到產生最終的完善產品。
例如，使用增量模型開發字處理軟件。可以考慮，第一個增量發布基本的文件管理、編輯和文檔生成功能，第二個增量發布更加完善的編輯和文檔生成功能，第三個增量實現拼寫和文法檢查功能，第四個增量完成高級的頁面布局功能。
優點：
缺點：
5.2 迭代模型（-Model）（迭代增量式開發/迭代進化式開發）
在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小項目，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。采用這種方法，開發工作可以在需求被完整地確定之前啟動，并在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，并開始新一輪的迭代。
迭代和版本的區別，可理解如下：迭代一般指某版本的生產過程，包括從需求分析到測試完成；版本一般指某階段軟件開發的結果，一個可交付使用的產品。
優點：
6. 噴泉模型（-Model）
以用戶需求為動力，以對象為驅動的模型，主要用于采用對象技術的軟件開發項目
噴泉模型與傳統的結構化生存期比較，具有更多的增量和迭代性質，生存期的各個階段可以相互重疊和多次反復，而且在項目的整個生存期中還可以嵌入子生存期。就像水噴上去又可以落下來，可以落在中間，也可以落在最底部。
噴泉模型不像瀑布模型那樣,需要分析活動結束后才開始設計活動,設計活動結束后才開始編碼活動.該模型的各個階段沒有明顯的界限,開發人員可以同步進行開發.
優點:
缺點:
7. 演化模型（-Model）
思想:
主要針對事先不能完整定義需求的軟件開發。用戶可以給出待開發系統的核心需求，并且當看到核心需求實現后，能夠有效地提出反饋，以支持系統的最終設計和實現。軟件開發人員根據用戶的需求，首先開發核心系統。當該核心系統投入運行后，用戶試用之，完成他們的工作，并提出精化系統、增強系統能力的需求。軟件開發人員根據用戶的反饋，實施開發的迭代過程。第一迭代過程均由需求、設計、編碼、測試、集成等階段組成，為整個系統增加一個可定義的、可管理的子集。
在開發模式上采取分批循環開發的辦法，每循環開發一部分的功能，它們成為這個產品的原型的新增功能。于是，設計就不斷地演化出新的系統。實際上，這個模型可看作是重復執行的多個“瀑布模型”。
“演化模型”要求開發人員有能力把項目的產品需求分解為不同組，以便分批循環開發。這種分組并不是絕對隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。有經驗指出，每個開發循環以六周到八周為適當的長度。
優點:
缺點:
8. 敏捷開發模型（Agile--Model）
敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。
敏捷開發小組主要的工作方式：
敏捷開發的4個核心思想：
敏捷軟件開發要注意項目規模，規模增長，團隊交流成本就上去了，因此敏捷軟件開發暫時適合不是特別大的團隊開發，比較適合一個組的團隊使用。
9. 智能模型（四代技術4GL）
智能模型擁有一組工具（如數據查詢、報表生成、數據處理、屏幕定義、代碼生成、高層圖形功能及電子表格等），每個工具都能使開發人員在高層次上定義軟件的某些特性，并把開發人員定義的這些軟件自動地生成為源代碼。這種方法需要四代語言（4GL）的支持。4GL不同于三代語言，其主要特征是用戶界面極端友好，即使沒有受過訓練的非專業程序員，也能用它編寫程序；它是一種聲明式、交互式和非過程性編程語言。4GL還具有高效的程序代碼、智能缺省假設、完備的數據庫和應用程序生成器。目前市場上流行的4GL（如等）都不同程度地具有上述特征。但4GL目前主要限于事務信息系統的中、小型應用程序的開發。
10. 混合模型（-Model）
過程開發模型又叫混合模型（ model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟件開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。
部分對比的模型方法：
模型名稱
技術特點
適用范圍
瀑布模型
簡單，分階段，階段間存在因果關系，
各個階段完成后都有評審，允許反饋，不支持
用戶參與，要求預先確定需求
需求易于完善定義且不易變更的軟件系統
快速原型模型
不要求需求預先完備定義，支持用戶參與，
支持需求的漸進式完善和確認，能夠適應用戶需求的變化
需求復雜、難以確定、動態變化的軟件系統
增量模型
軟件產品是被增量式地一塊塊開發的，
允許開發活動并行和重疊
技術風險較大、用戶需求較為穩定的軟件系統
迭代模型
不要求一次性地開發出完整的軟件系統，將軟件
開發視為一個逐步獲取用廣需求、完善軟件產品的過程
需求難以確定、不斷變更的軟件系統
螺旋模型
結合瀑布模型、快速原型模型和迭代模
型的思想，并引進了風險分析活動
需求難以獲取和確定、軟件開發風險較大的軟件系統
客戶想要的 vs 客戶實際預算：漫畫解讀軟件開發模式
參考資料：