軟體開發模型

瀑布模型

將生命週期中的各個活動規定為以線性順序連結的若干階段的模型，包括需求分析、設計、編碼、測試、執行與維護，它規定由前至後的順序次序，就像瀑布流水一樣逐級下落

小明來解說：小明的媽媽要小明去買東西（薯片，爆米花，烤紅薯，糖炒栗子），瀑布模型就是，小明在家裡的時候問他的媽媽都需要買什麼，然後記在了小本本上，最後只拿著小本本去買東西，然後一次性買回來帶給媽媽，如果他的媽媽突然之間想吃糖葫蘆，但是小明出門的時候只帶了小本本，沒有帶手機，所以他的媽媽就不能吃到糖葫蘆了，而恰巧賣糖炒栗子的人今天沒有出攤，小明沒有買到糖炒栗子，那回家的時候就還要和媽媽解釋一下，而且也不能變通。

瀑布模型強調文件的作用，並要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟體開發模式，缺點如下：
（1） 各個階段的劃分完全固定，階段之間產生大量的文件，增加了工作量。
（2） 開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險。
（3） 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

增量模型

增量模型的第一個要求是需要模組化，在開發的過程中將每個模組作為一個增量元件，從而分批次地分析、設計、編碼和測試這些增量元件，增量模型是一個遞增的過程，相比較瀑布模型而言，增量模型的開發人員不需要一次性地把整個軟體產品提交給使用者，而是可以分批次進行提交。
小明來解說：增量模型就是小明將媽媽的需求都記在小本本上，然後一家一家的去買，先買了糖炒栗子帶回家，再買了烤紅薯回家，一直到所有東西都買好之後再一起帶給媽媽，如果期間媽媽有想要的東西可以隨時告訴小明，讓小明再去買

2、完成總體設計之後，開始進行對增量構件的需求細化並進行開發。

3、完成了某一個增量的開發後進行彙集到系統中去，然後開發下一個增量

演化模型（原型模型、螺旋模型）

演化模型是通過迭代來實現軟體開發的過程，演化模型特別適合用於對軟體需求缺乏準確認識的情況，也就是需求不明確的情況

原型模型

原型模型也叫做樣品模型
它通過向用戶提供原型獲取使用者的反饋，使開發出的軟體能夠真正反映使用者的需求。用逐步求精的方法進行完善，使得原型能夠“快速”開發，避免了像瀑布模型一樣在冗長的開發過程中難以對使用者的反饋作出快速的響應。相對瀑布模型而言，原型模型更符合人們開發軟體的習慣，是目前較流行的一種實用軟體生存期模型。

螺旋模型

螺旋模型是將瀑布模型和演化模型結合起來的，加入了兩種模型都忽略的風險分析，主要分為四個步驟
1.做計劃：確定目標，實施方案，確定專案開發的條件
2.風險分析：分析方案，識別風險，消除風險
3.實施工程：實施軟體開發，驗證階段性的產品
4.使用者評估：使用者評價並提出建議，建立下一階段開發計劃

噴泉模型

噴泉模型是以使用者的需求為動力，一物件作為驅動的模型，適合於面向物件的開發方法
該模型認為軟體開發過程自下而上週期的各階段是相互迭代和無間隙的特性
優點：
瀑布模型是需要分析活動結束後才開始設計活動，設計活動結束後才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發，所以可以提高軟體專案開發效率，節省開發時間
缺點：
開發過程中需要大量的開發人員，不利於專案管理。要求嚴格管理文件，從而使稽核的難度加大，尤其是面對可能隨時加入各種資訊、需求與資料的情況。

基於構件的開發模型

基於構建的開發是指利用預先包裝的構件來構造應用系統，構建可以是組織內部開發的構建，也可以是商品化成品軟體構件。基於構建的開發模型具有許多螺旋模型的特點，但它本質上是演化模型，需要以迭代的方式構建軟體，不同點：基於構建的開發模型採用與先打包的軟體構件開發

形式化方法模型

形式化方法是建立在嚴格數學基礎上的一種軟體開發方法，其主要活動是生成計算機軟體形式化的數學規格說明

統一過程模型

是“用力和風險驅動，一架構為中心，迭代並且增量”的開發過程
主要有四個階段
1）起始階段
專案初創活動，構想文件，初始專案術語表，初始業務用例，初始風險評估，專案計劃等等
2）精化階段
在理解了最初的領域範圍之後進行需求分析和架構演進，產生用力模型，補充需求等等
3）構建階段
關注系統的構建，產生實現模型
4）移交階段：產品釋出

敏捷方法

目標：儘可能早地、持續地對有價值的軟體的交付
1.極限程式設計–XP
價值觀：溝通、簡單、反饋、勇氣
原則：快速反饋，簡單性假設，逐步修改，提倡更改和優質工作
2.水晶法(Crystal)
水晶法認為每個不同的專案都需要不通的策略、約定和方法論，認為人對軟體質量有重要的影響，軟體質量隨開發人員素質的提高而提高
3.並列爭求法(Scrum)
用迭代的方法，把每30天一次的迭代看做一次衝刺，並按需求的優先順序來實現產品