1.瀑布模型
1.1 瀑布模型介紹
1970年溫斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被廣泛採用的軟體開發模型。
1.2 瀑布模型核心思想
瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
1.3 瀑布模型有以下優點
(1)為專案提供了按階段劃分的檢查點。
(2)當前一階段完成後，您只需要去關注後續階段。
(3)可在迭代模型中應用瀑布模型。
增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生一個可執行的版本,同時增加更多的功能。每次迭代必須經過質量和整合測試。
1.4 瀑布模型有以下缺點
(1)在專案各個階段之間極少有反饋。
(2)只有在專案生命週期的後期才能看到結果。
(3)通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
(4)瀑布模型的突出缺點是不適應使用者需求的變化。

2.迭代模型
2.1 什麼是迭代模型
在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：需求、分析設計、實施和測試工作流程。實質上，它類似小型的瀑布式專案。RUP認為，所有的階段都可以細分為迭代。每一次的迭代都會產生一個可以釋出的產品，這個產品是最終產品的一個子集。
2.2 迭代模型的使用條件
(1)在專案開發早期需求可能有所變化。
(2)分析設計人員對應用領域很熟悉。
(3)高風險專案。
(4)使用者可不同程度地參與整個專案的開發過程。
(5)使用面向物件的語言或統一建模語言（Unified Modeling Language，UML）。
(6)使用CASE（Computer Aided Software Engineering，計算機輔助軟體工程）工具，如Rose（Rose是非常受歡迎的物件軟體開發工具。）。
(7)具有高素質的專案管理者和軟體研發團隊。
2.3 迭代模型的優點
與傳統的瀑布模型相比較，迭代過程具有以下優點：
(1)降低了在一個增量上的開支風險。如果開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費。
(2)降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以儘早來解決而不至於在開發後期匆匆忙忙。
(3)加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。
(4)由於使用者的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。

3.敏捷開發模型
3.1 什麼是敏捷開發
是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。相對於“非敏捷”，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本。能夠很好地適應需求變化的程式碼編寫和團隊組織方法，也更注重軟體開發中人的作用。敏捷建模（Agile Modeling，AM）的價值觀包括了XP的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴充套件了第五個價值觀：謙遜。
3.2 敏捷開發特點
(1)人和互動 重於過程和工具。
(2)可以工作的軟體 重於求全而完備的文件。
(3)客戶協作重於合同談判。
(4)隨時應對變化重於循規蹈矩。
專案的敏捷開發,敏捷開發小組主要的工作方式可以歸納為：作為一個整體工作； 按短迭代週期工作； 每次迭代交付一些成果:關注業務優先順序； 檢查與調整。

最重要的因素恐怕是專案的規模。規模增長，面對面的溝通就愈加困難，
因此敏捷方法更適用於較小的隊伍，40、30、20、10人或者更少。
4.螺旋模型
詳見 http://baike.baidu.com/view/551040.htm
5.快速原型模型
詳見 http://baike.baidu.com/view/1449532.htm
6.幾種模型間的對比
傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每一個開發階段都要做到最好。
特別是前期階段，設計的越完美，提交後的成本損失就越少。

迭代式開發，不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來為目的，以最短的時間，
最少的損失先完成一個“不完美的成果物”直至提交。然後再通過客戶或使用者的反饋資訊，在這個“不完美的成果物”上逐步進行完善。

螺旋開發，很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的迴圈之前，都必須首先進行風險評估。

敏捷開發，相比迭代式開發兩者都強調在較短的開發週期提交軟體，但是，敏捷開發的週期可能更短，並且更加強調隊伍中的高度協作。
敏捷方法有時候被誤認為是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。
適應性的方法集中在快速適應現實的變化。當專案的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化。

參考文章：