軟體生存期模型

軟體生存期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程，活動和任務的結構架構.

 

一、下面介紹幾種常見的軟體生存期模型的優缺點，及其適用範圍。

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.增量,迭代和原型可以綜合使用,但每一次增量或迭代都必須有明確的交付準則.

 

前面介紹的軟體生存期模型是針對軟體開發的某些問題和要求設計的，他們都有各自的優點和缺陷，在軟體工程實踐中，經常把幾種模型組合在一起配套使用，形成組合模型。每個軟體開發組織應該選擇適合於該組織的軟體開發模型，並且應該隨著當前正在開發的特定產品特性而變化，以減小所選模型的缺點，充分利用其優點。

 

初步理解與歸納，如有不足，請指出！