軟件生存期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程，活動和任務的結構框架.
一、下面介紹幾種常見的軟件生存期模型的優缺點，及其適用范圍。
1、瀑布模型
瀑布模型將軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，并且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
優點：
（1）為項目提供了按階段劃分的檢查點，當前一個階段完成后，只需要關注后續階段。
（2）提供了軟件開發的基本框架，有利于大型軟件開發過程中人員的組織與管理
缺點：
（1）在軟件開發的初期階段就要求做出正確、全面、完整的需求分析對許多應用軟件來說是極其困難的。
（2）由于開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。
（3）早期的錯誤可能要等到開發后期才能發現，進而帶來嚴重后果。
適用范圍：瀑布模型是以文檔作為驅動，適合于軟件需求很明確的軟件項目即一般適用于功能明確、完整、無重大變化的軟件系統的開發，例如：操作系統、數據庫管理系統等系統軟件的開發，其應用有一定的局限性。
2、快速原型模型
快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什么；第二步則在第一步的基礎上開發客戶滿意的軟件產品。
優點：
（1）快速原型方法可以克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發風險，具有顯著的效果。
缺點：
（1）所選用的開發技術和工具不一定符合主流的發展；
（2）快速建立起來的系統結構加上連續的修改可能會導致產品質量低下。
（3）使用這個模型的前提是要有一個展示性的產品原型，因此在一定程度上可能會限制開發人員的創新。
適用范圍：
原型模型適合于那些不能確切定義需求的軟件系統的開發。
3、螺旋模型
螺旋模型，該模型運用快速原型法，以進化的開發方式為中心，在每個項目階段使用瀑布模型法，可以說它將瀑布模型和快速原型模型結合起來。這種模型的每一個周期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層次。
優點：
（1）強調嚴格的全過程風險管理。
（2）強調各開發階段的質量。
（3）強調原型的可擴充性和可修改性，原型的進化貫穿整個軟件生存周期。
（4）為項目管理人員及時調整管理決策提供了方便，進而可降低開發風險。
缺點：
（1）很難讓用戶確信這種演化方法的結果是可以控制的。建設周期長，而軟件技術發展比較快，所以經常出現軟件開發完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。
（2）使用該模型需要有相當豐富的風險評估經驗和專門知識，要求開發隊伍水平較高。
適用范圍：螺旋模型只適合于大規模的軟件項目。
增量模型
增量模型在各個階段并不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品。在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用后，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布后不斷重復，直到產生最終的完善產品。
優點：
（1）軟件開發可以較好地適應變化，客戶可以不斷地看到所開發的軟件，從而降低開發風險
缺陷：
（1）由于各個構件是逐漸并入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構。
（2）在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過程的控制失去整體性。
適用范圍：
（1）進行已有產品升級或新版本開發，增量模型是非常適合的；（2）對完成期限嚴格要求的產品，可以使用增量模型；（3）對所開發的領域比較熟悉而且已有原型系統，增量模型也是非常適合的。
二、上述整理中發現，每種模型基本上都和“迭代”“增量”“原型”有著或多或少的聯系，下面談下一下三者的區別與聯系。
原型即先建立一個樣品系統（不全面的系統），然后供測試評價，再次優化。如果采用螺旋模型，每次迭代都會產生一個原型。
下面看一下迭代和增量的概念。
假設現在要開發A,B,C,D四個大的業務功能,每個功能都需要開發兩周的時間.則對于增量方法而言可以將四個功能分為兩次增量來完成,第一個增量完成A,B功能,第二次增量完成C,D功能;而對于迭代開發來將則是分兩次迭代來開發,第一次迭代完成A,B,C,D四個基本業務功能但不含復雜的業務邏輯,而第二個功能再逐漸細化補充完整相關的業務邏輯.在第一個月過去后采用增量開始時候A,B全部開發完成而C,D還一點都沒有動;而采用迭代開發的時候A,B,C,D四個的基礎功能都已經完成.
每次迭代基本上都包含了需求,設計和開發,測試等各個過程,而且每次迭代完成后都是一個可以交付的原型.也就是說迭代的結果是產生原型，然后再次迭代，再產生原型，知道原型滿足要求為止。迭代不是并行,在每次迭代過程中仍然要遵循需求->設計->開發的瀑布過程.迭代周期的長度跟項目的周期和規模有很大的關系.小型項目可以一周一次迭代,而對于大型項目則可以2-4周一次迭代.如果項目沒有一個很好的架構師,很難規劃出每次迭代的內容和要到達的目標,驗證相關的交付和產出.因此迭代模型雖然能夠很好的滿足與用戶的交付,需求的變化,但確是一個很難真正用好的模型.
就對風險的消除上,通過增量，迭代，原型都能夠很好地控制前期的風險并解決.但由“迭代產生原型”在這方面更有優勢.迭代模型更多的可以從總體方面去系統的思考問題,從最早就可以給出相對完善的框架或原型,后期的每次迭代都是針對上次迭代的逐步精化.
增量模型往往要求在軟件需求規格說明書全部出來后后續的設計開發再進行增量.同時每個增量也可以是獨立發布的小版本.由于系統的總體設計往往對一個系統的架構和可擴展性有重大的影響,因此我們推薦的增量最好是在架構設計完成后再開始進行增量,這樣可以更好的保證系統的健壯性和可擴展性.
三、關于選擇生命周期模型的最后的總結
1.在前期需求明確的情況下盡量采用瀑布模型或改進型的瀑布模型.
2.在用戶無信息系統使用經驗,需求分析人員技能不足情況下一定要借助原型.
3.在不確定性因素很多,很多東西前面無法計劃情況下盡量采用增量迭代和螺旋模型
4.在需求不穩定情況下盡量采用增量迭代模型
5.在資金和成本無法一次到位情況下可以采用增量模型,軟件產品分多個版本進行發布
6.對于完全多個獨立功能開發可以在需求階段就分功能并行,但每個功能內都應該遵循瀑布模型
7.對于全新系統的開發必須在總體設計完成后再開始增量或并行.
8.對于編碼人員經驗較少情況下建議不要采用敏捷或迭代等生命周期模型.
9.增量,迭代和原型可以綜合使用,但每一次增量或迭代都必須有明確的交付準則.
前面介紹的軟件生存期模型是針對軟件開發的某些問題和要求設計的，他們都有各自的優點和缺陷，在軟件工程實踐中，經常把幾種模型組合在一起配套使用，形成組合模型。每個軟件開發組織應該選擇適合于該組織的軟件開發模型，并且應該隨著當前正在開發的特定產品特性而變化，以減小所選模型的缺點，充分利用其優點。
初步理解與歸納，如有不足，請指出！
此文章來自于【】