常見軟體開發模型對比：瀑布、迭代、螺旋、敏捷
一、瀑布模型
核心思想：瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
重要地位：它提供了軟體開發的基本框架。其過程是從上一項活動接收該項活動的工作物件作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，並作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。對於經常變化的專案而言，瀑布模型毫無價值。
模型優點
1、為專案提供了按階段劃分的檢查點。 2、當前一階段完成後，您只需要去關注後續階段。 3、可在迭代模型中應用瀑布模型。 4、它提供了一個模板，這個模板使得分析、設計、編碼、測試和支援的方法可以在該模板下有一個共同的指導。模型缺點
1、各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量。 2、由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。 3、通過過多的強制完成日期和里程碑來跟蹤各個專案階段。 4、瀑布模型的突出缺點是不適應使用者需求的變化。二、迭代模型
模型說明
早在20世紀50年代末期，軟體領域中就出現了迭代模型。最早的迭代過程可能被描述為“分段模型（stagewise model）”。迭代模型是RUP推薦的週期模型。被定義為：迭代包括產生產品釋出（穩定、可執行的產品版本）的全部開發活動和要使用該釋出必需的所有其他外圍元素。在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程。實質上，它類似小型的瀑布式專案。RUP認為，所有的階段都可以細分為迭代。每一次的迭代都會產生一個可以釋出的產品，這個產品是最終產品的一個子集。
模型優點
與傳統的瀑布模型相比較，迭代過程具有以下優點： 1、降低了在一個增量上的開支風險。如果開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費。 2、降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以儘早來解決而不至於在開發後期匆匆忙忙。 3、加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。 4、由於使用者的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。 模型缺點 在專案早期開發可能有所變化 ，對於開發人員的要求較高，需有一個高素質的專案管理者和一個高技術水平的開發團隊三、螺旋模型
模型說明
1988年，巴利·玻姆(Barry Boehm)正式發表了軟體系統開發的“螺旋模型”，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型複雜的系統。
螺旋模型是一種演化軟體開發過程模型，它兼顧了快速原型的迭代的特徵以及瀑布模型的系統化與嚴格監控。螺旋模型最大的特點在於引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減小損失。同時，在每個迭代階段構建原型是螺旋模型用以減小風險的途徑。螺旋模型更適合大型的昂貴的系統級的軟體應用。
螺旋模型採用一種週期性的方法來進行系統開發。這會導致開發出眾多的中間版本。使用它，專案經理在早期就能夠為客戶實證某些概念。該模型是快速原型法，以進化的開發方式為中心，在每個專案階段使用瀑布模型法。這種模型的每一個週期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟體開發過程每迭代一次，軟體開發又前進一個層次。螺旋模型基本做法是在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟體專案分解成一個個小專案。每個小專案都標識一個或多個主要風險，直到所有的主要風險因素都被確定。
螺旋模型基本做法是在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟體專案分解成一個個小專案。每個小專案都標識一個或多個主要風險，直到所有的主要風險因素都被確定。
螺旋模型強調風險分析，使得開發人員和使用者對每個演化層出現的風險有所瞭解，繼而做出應有的反應，因此特別適用於龐大、複雜並具有高風險的系統。對於這些系統，風險是軟體開發不可忽視且潛在的不利因素，它可能在不同程度上損害軟體開發過程，影響軟體產品的質量。減小軟體風險的目標是在造成危害之前，及時對風險進行識別及分析，決定採取何種對策，進而消除或減少風險的損害。
模型優點
1、設計上的靈活性,可以在專案的各個階段進行變更
2、以小的分段來構建大型系統,使成本計算變得簡單容易。
3、客戶始終參與每個階段的開發,保證了專案不偏離正確方向以及專案的可控性。
4、隨著專案推進,客戶始終掌握專案的最新資訊 , 從而他或她能夠和管理層有效地互動。
5、客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。
模型缺點
很難讓使用者確信這種演化方法的結果是可以控制的。建設週期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前使用者需求。
四、敏捷模型
敏捷模型以迭代模型為理論基礎。
敏捷模型的概念比較廣，包含：XP、Scrum、FDD、DSDM、Crystal、ASD等等開發方法。或者說，敏捷模型是這些輕量級軟體開發方法的一個統稱。
模型說明
敏捷開發模式是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於”非敏捷”，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的程式碼編寫和團隊組織方法，也更注重做為軟體開發中人的作用。
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。
軟體敏捷開發宣言中提出了以下12個原則：
1、持續、儘早交付有價值的軟體以滿足客戶，是我們優先要做的首要任務。
2、擁抱需求變更，甚至是在開發的後期。敏捷過程利用變更為客戶帶來競爭優勢。
3、頻繁交付可執行的軟體，從幾周到幾個月，交付時間越短越好。
4、在整個專案過程中，業務人員和開發人員必須每天在一起工作。
5、激發每個團隊成員的積極性來打造專案。為他們提供所需的環境與支援，並且信任他們可以完成工作。
6、在一個開發團隊內部最有效的傳遞資訊的方式是面對面的交流。
7、可執行的軟體是進度的首要檢驗物件。
8、敏捷過程倡導可持續發展。贊助商，開發人員和使用者應該儘可能保持一致的步伐。
9、保持關注先進的技術與設計會增強敏捷性。
10、儘量用藝術化來簡單闡述未完成的工作是很有必要的。
11、最好的架構，需求，和設計出自於自我組織管理的團隊。
12、每隔一段時間，回顧反思如何讓團隊變得更高效，並相應地調整其行為。
模型優點
1、迭代快，開發週期短；
2、不再耗費大量的時間來寫文件，而是人與人面對面交流，只寫一些必要的文件；
3、分工詳細，每天都輸出成果，客戶能夠看得到，會信任專案團隊；
4、溝通多，容易發現問題，同時能夠激起團隊的協作、奮鬥；
模型缺點
1、人與人之間的信任是非常重要的環節，但是這個比較難完成，技術團隊的成員可能技術能力差別大，同時也有互相競爭，又或者是專案團隊的成員有所保留，不願意這樣的溝通；
2、團隊在開發期間的任務多、壓力大，需要時刻保持“興奮”，一般很難做到。
五、四者對比區別
傳統的瀑布模型，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每一個開發階段都要做到最好。
特別是前期階段，設計的越完美，提交後的成本損失就越少。
迭代模型，不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來為目的，以最短的時間，
最少的損失先完成一個“不完美的成果物”直至提交。然後再通過客戶或使用者的反饋資訊，在這個“不完美的成果物”上逐步進行完善。
螺旋模型，很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的迴圈之前，都必須首先進行風險評估。
敏捷模型，相比迭代式開發兩者都強調在較短的開發週期提交軟體，但是，敏捷開發的週期可能更短，並且更加強調隊伍中的高度協作。
敏捷開發有時候被誤認為是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。
適應性的方法集中在快速適應現實的變化。當專案的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化.