一、瀑布模型
優點
1）為專案提供了按階段劃分的檢查點。
2）當前一階段完成後，您只需要去關注後續階段。
3）可在迭代模型中應用瀑布模型。
瀑布模型有以下缺點：
1）在專案各個階段之間極少有反饋。
2）只有在專案生命週期的後期才能看到結果。
3）透過過多的強制完成日期和里程碑來跟蹤各個專案階段。
二、快速原型模型
快速原型模型需要迅速建造一個可以執行的軟體原型 ，以便理解和澄清問題，使開發人員與使用者達成共識，最終在確定的客戶需求基礎上開發客戶滿意的軟體產品。
快速原型模型允許在需求分析階段對軟體的需求進行初步而非完全的分析和定義，快速設計開發出軟體系統的原型，該原型向用戶展示待開發軟體的全部或部分功能和效能；使用者對該原型進行測試評定，給出具體改進意見以豐富細化軟體需求；開發人員據此對軟體進行修改完善，直至使用者滿意認可之後，進行軟體的完整實現及測試、維護。
快速原型是利用原型輔助軟體開發的一種新思想。經過簡單快速分析，快速實現一個原型，使用者與開發者在試用原型過程中加強通訊與反饋，透過反覆評價和改進原型，減少誤解，彌補漏洞，適應變化，最終提高軟體質量。
1） 克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險。
缺點
1） 所選用的開發技術和工具不一定符合主流的發展；
2）快速建立起來的系統結構加上連續的修改可能會導致產品質量低下；
三、螺旋模型

1）設計上的靈活性,可以在專案的各個階段進行變更
2）以小的分段來構建大型系統,使成本計算變得簡單容易。
3）客戶始終參與每個階段的開發,保證了專案不偏離正確方向以及專案的可控性。
4）隨著專案推進,客戶始終掌握專案的最新資訊 , 從而他或她能夠和管理層有效地互動。
5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。
很難讓使用者確信這種演化方法的結果是可以控制的。
建設週期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前使用者需求。
四、增量模型
•整個專案的資金不會被提前消耗，因為首先開發和交付了主要功能和高風險功能。 •每個增量交付一個可操作的產品。
•每次增量交付過程中獲取的經驗，有利於後面的改進，客戶也有機會對建立好的模型作出反應。
•採用連續增量的方式，可把使用者經驗融入到細化的產品，這比完全重新開發要便宜得多。
•“分而治之”的策略，使問題分解成可管理的小部分，避免開發團隊由於長時間的需求任務而感到淚喪。
•透過同一個團隊的工作來交付每個增量，保持所有團隊處於工作狀態，減少了員工的工作量，工作分佈曲線透過專案中的時間階段被拉平。
•每次增量交付的結為，可以重新修訂成本和進度的風險。
•便於根據市場作出反應。
•降低了失敗和更改需求的風險。
•更易於控制使用者需求，因為每次曾兩開發的時間很短。
•由於不是一步跳到未來，所以使用者能逐步適應新技術。
•切實的專案進展，有利於進度控制。
•風險分佈到幾個更小的增量中，而不是集中於一個大型開發中。
•由於使用者能夠從早期的增量中瞭解系統，所以更加理解後面增量中的需求。 增量模型有以下缺點
•若軟體可拆卸度不高，開發人員全域性把握水平不高，使用者不同意分階段提交產品，或者開發人員過剩，都不適宜。
一、瀑布模型
優點
1）為專案提供了按階段劃分的檢查點。
2）當前一階段完成後，您只需要去關注後續階段。
3）可在迭代模型中應用瀑布模型。
瀑布模型有以下缺點：
1）在專案各個階段之間極少有反饋。
2）只有在專案生命週期的後期才能看到結果。
3）透過過多的強制完成日期和里程碑來跟蹤各個專案階段。
二、快速原型模型
快速原型模型需要迅速建造一個可以執行的軟體原型 ，以便理解和澄清問題，使開發人員與使用者達成共識，最終在確定的客戶需求基礎上開發客戶滿意的軟體產品。
快速原型模型允許在需求分析階段對軟體的需求進行初步而非完全的分析和定義，快速設計開發出軟體系統的原型，該原型向用戶展示待開發軟體的全部或部分功能和效能；使用者對該原型進行測試評定，給出具體改進意見以豐富細化軟體需求；開發人員據此對軟體進行修改完善，直至使用者滿意認可之後，進行軟體的完整實現及測試、維護。
快速原型是利用原型輔助軟體開發的一種新思想。經過簡單快速分析，快速實現一個原型，使用者與開發者在試用原型過程中加強通訊與反饋，透過反覆評價和改進原型，減少誤解，彌補漏洞，適應變化，最終提高軟體質量。
優點
1） 克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險。
缺點
1） 所選用的開發技術和工具不一定符合主流的發展；
2）快速建立起來的系統結構加上連續的修改可能會導致產品質量低下；
三、螺旋模型

優點
1）設計上的靈活性,可以在專案的各個階段進行變更
2）以小的分段來構建大型系統,使成本計算變得簡單容易。
3）客戶始終參與每個階段的開發,保證了專案不偏離正確方向以及專案的可控性。
4）隨著專案推進,客戶始終掌握專案的最新資訊 , 從而他或她能夠和管理層有效地互動。
5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。
缺點
很難讓使用者確信這種演化方法的結果是可以控制的。
建設週期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前使用者需求。
四、增量模型
優點
•整個專案的資金不會被提前消耗，因為首先開發和交付了主要功能和高風險功能。 •每個增量交付一個可操作的產品。
•每次增量交付過程中獲取的經驗，有利於後面的改進，客戶也有機會對建立好的模型作出反應。
•採用連續增量的方式，可把使用者經驗融入到細化的產品，這比完全重新開發要便宜得多。
•“分而治之”的策略，使問題分解成可管理的小部分，避免開發團隊由於長時間的需求任務而感到淚喪。
•透過同一個團隊的工作來交付每個增量，保持所有團隊處於工作狀態，減少了員工的工作量，工作分佈曲線透過專案中的時間階段被拉平。
•每次增量交付的結為，可以重新修訂成本和進度的風險。
•便於根據市場作出反應。
•降低了失敗和更改需求的風險。
•更易於控制使用者需求，因為每次曾兩開發的時間很短。
•由於不是一步跳到未來，所以使用者能逐步適應新技術。
•切實的專案進展，有利於進度控制。
•風險分佈到幾個更小的增量中，而不是集中於一個大型開發中。
•由於使用者能夠從早期的增量中瞭解系統，所以更加理解後面增量中的需求。 增量模型有以下缺點
•若軟體可拆卸度不高，開發人員全域性把握水平不高，使用者不同意分階段提交產品，或者開發人員過剩，都不適宜。