瀑布模型

該模型是由上至下一次性完成整個項目的開發方式。該模型一共分為6個階段，如圖所示：

在瀑布模型的開發過程中需要嚴格的按照這條線執行，只有完成當前階段之后才能夠進行下一階段的開發任務。

優點

該模型劃分出了每個階段的檢查點，當一個階段開發完成之后，開發人員的精力可以全部的投入下個階段，有利于提高開發效率，便于項目的管理。

比較適用于前期的軟件開發與小型軟件系統的開發中。缺點

無法評估項目進度。因為不知道哪個階段會造成項目的延期

無法適應用戶的需求變更，只能等到項目完成后，用戶才能夠看到項目結果快速原型模型

快速原型模型與瀑布模型相反，項目初期根據用戶的需求快速構建一個可以運行的系統原型，之后向用戶展示，由用戶進行審核，提出意見，然后逐步豐富項目需求。當需求真正確定后，才正式進行項目開發。模型如圖所示：

優點

解決需求不明確帶來的風險，適用于不能提前確定項目需求的項目缺點

不利于開發人員對產品進行擴展迭代模型

迭代模型又被稱作為增量模型或演化模型，它將一個完整的軟件拆分成不同的組件，之后對每個組件進行逐步的開發測試，每當完成一個組件就會向客戶進行展示，讓客戶確認該組件功能與性能是否達到要求，最終確定無誤，將組件集成到軟件體系結構中。整個開發工作被分為為一系列短期、簡單的小項目，稱為一系列迭代，每一個迭代都需要經過需求分析、軟件設計、編碼、測試這幾項過程，其開發過程如圖所示：

優點

第一個可交付版本的軟件所需的成本與時間較小

能夠適應客戶的需求變更，當需求變化時，只需要修改某一個組件即可。缺點

如果對用戶需求的變更沒有整體的規劃，可能會變化為“邊做邊開發”的模式。

最終集成各個組件時，可能會出現集成失敗的風險。噴泉模型

該模型主要采用面向對象技術。當客戶需求基本類似時，在開發過程中可以采用面向對象的開發方式，將相同的模塊全部封裝起來，以便于下次功能開發時使用。模型如圖所示：

優點

支持軟件重用，并且開發過程無間隙性，分析、設計編碼無明顯邊界，可交叉迭代進行。使軟件在無法排除重大風險時有機會停止，以減小損失。缺點

由于噴泉模型在各個階段是重疊的，即每個對象都有分析、設計和編碼階段，所以需要大量開發人員。

大量開發人員不利于項目的管理。

該模型需要嚴格管理文檔，會增加審核的難度增大。螺旋模型

螺旋模型融合了瀑布模型，快速原型模型，該模型最大的特點就是引入了其他模型所沒有的風險分析。

螺旋模型將開發過程都分為幾個螺旋周期，每個螺旋周期大致和瀑布模型相符合，在每個周期開始之前都會進行風險分析。在每個迭代階段構建原型是螺旋模型用以減小風險的途徑。模型如圖所示：

該模型共有四個象限，每個象限的含義如下：

制訂計劃：確定軟件目標，制訂實施方案，并且列出項目開發的限制條件。

風險分析：評價所制訂的實施方案，識別風險并消除風險。

實施工程：開發產品并進行驗證。

客戶評估：客戶對產品進行審核評估，提出修正建議，制訂下一步計劃。優點

螺旋模型強調風險分析，對每個演化層出現的風險都所了解，繼而做出應有反應。因此特別適合用于龐大、復雜并且具有高風險的系統。螺旋模型支持用戶需求的動態變化有助于提高產品的適應能力。缺點

過多的迭代次數會增加開發成本，延遲提交時間。敏捷模型

在現代社會的開發中，由于業務會經常快速的變化，因此會導致在軟件開發之前經常是無法得到詳細完整的開發需求，沒有完整的開發需求，傳統的軟件開發模型也就無法適用。

敏捷開發模型的提出就是為了解決該問題。該模型以客戶的需求為核心，采用迭代，循序漸進的方法進行開發。

軟件項目在構建初期會被拆分為多個相互聯系而又獨立運行的子項目，然后迭代完成各個子項目。開發過程中，各個子項目都要經過開發測試。當客戶有需求變更時，敏捷模型能夠迅速地對某個子項目做出修改以滿足客戶的需求。在這個過程中，軟件一直處于可使用狀態。

該模型更重視人在軟件開發中的作用。軟件開發過程中，各個部門需要緊密的合作溝通，為適應軟件需求的頻繁改變，客戶可以全程參與到開發過程中。

敏捷開發模型的價值與原則

個體和交互重于過程和工具

可用軟件重于完備文檔

客戶協作重于合同談判

響應變化重于遵循計劃優點

用戶很快可以看到一個基線架構版的產品

敏捷注重市場快速反應能力，客戶前期滿意度高。缺點

注重人員的溝通

忽略文檔的重要性

如果項目人員流動大太，會增加項目維護難度

軟件之前版本的可重現性、可回溯性較低

對于較大的項目，人員越多，面對面的有效溝通越困難。因此，該模型適用于小型項目的開發。

責任編輯：haq