軟體開發模型(software development model)

軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構架構。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目開發的基礎

1.瀑布模型(waterfall model)

瀑布模型將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。從本質來講，它是一個軟體開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好 “返回”上一個階段並進行適當的修改，開發進程從一個階段“流動”到下一個階段，這也是瀑布開發名稱的由來。

特點：

1. 階段間具有順序性和依賴性。

2. 延遲程式的物理實現。

3. 品質保證：每個階段必須完成規定的文檔；每個階段結束前完成文檔審查,及早改正錯誤。

4. 易於組織，易於管理：因為你可以預先完成所有計劃。

5. 是一種嚴格線性、按階段順序的、逐步細化的過程模型（開發模式）

適用場合：

1. 當有一個穩定的產品定義和很容易被理解的技術解決方案時，純瀑布模型特別合適。

2. 當你對一個定義得很好的版本進行維護或將一個產品移植到一個新的平台上，瀑布模型也特別合適。

3. 對於那些容易理解但很複雜的項目，採用純瀑布模型比較合適，因為可以用順序方法處理問題。

4. 在品質需求高於成本需求和進度需求的時候，它尤為出色。

5. 當開發隊伍的技術力量比較弱或者缺乏經驗時，瀑布模型更為適合。

缺陷：

1. 在項目開始的時候，使用者常常難以清楚地給出所有需求；使用者與開發人員對需求理解存在差異。

2. 實際的項目很少按照順序模型進行。

3. 缺乏靈活性：因為瀑布模型確定了需求分析的絕對重要性，但是在實踐中要想獲得完善的需求說明是非常困難的，導致“阻塞狀態”。反饋資訊慢，開發週期長。

4. 雖然存在不少缺陷，瀑布模型經常被嘲笑為“舊式的”，但是在需求被很好地理解的情況下，仍然是一種合理的方法。

2.快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一個快速原型，實現客戶或未來的使用者與系統的互動，使用者或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。一旦確定了客戶的真正需求，所建造的原型將被丟棄因此，原型系統的內部結構並不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。

特點：

快速原型方法可以克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險，具有顯著的效果。原型模型比瀑布模型更符合人們認識事物的過程和規律，是一種較實用的開發架構。

適用場合：

它適合於那些不能預先確切定義需求的軟體系統的開發，更適合於那些項目群組成員（包括分析員、設計員、程式員和使用者）不能很好交流或通訊有困難的情況。

缺陷：

所選用的開發技術和工具不一定符合主流的發展；快速建立起來的系統結構加上連續的修改可能會導致產品品質低下

3.增量模型（Incremental Model）

與建造大廈相同，軟體也是一步一步建造起來的。在增量模型中，軟體被作為一系列的增量構件來設計、實現、整合和測試，每一個構件是由多種相互作用的模組所形成的提供特定功能的程式碼片段構成。

增量模型在各個階段並不交付一個可啟動並執行完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟體開發可以較好地適應變化，客戶可以不斷地看到所開發的軟體，從而降低開發風險。

特點：

增量模型的特點是引進了增量包的概念，無須等到所有需求都出來，只要某個需求的增量包出來即可進行開發。雖然某個增量包可能還需要進一步適應客戶的需求並且更改，但只要這個增量包足夠小，其影響對整個項目來說是可以承受的。

適用場合：

在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付使用者使用後，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布後不斷重複，直到產生最終的完善產品。

缺陷：

1. 由於各個構件是逐漸併入已有的軟體體繫結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體繫結構。

2. 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟體過程的控制失去整體性。

4.螺旋模型（Spiral Model）

螺旋模型將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型複雜的系統。圖中的四個象限代表了以下活動：

1. 制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件；

2. 風險分析：分析評估所選方案，考慮如何識別和消除風險；

3. 實施工程：實施軟體開發和驗證；

4. 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

特點：

螺旋模型由風險驅動，強調可選方案和約束條件從而支援軟體的重用，有助於將軟體品質作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。

適用場合：

1. 內部的大規模軟體開發:螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的。

2. 大規模軟體項目:如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義。

缺陷：

1. 軟體開發人員應該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險

2. 很難讓使用者確信這種演化方法的結果是可以控制的。建設周期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足目前使用者需求

5.V-Model

V模型是一種對瀑布模型進行擴充的軟體開發過程。它不採用向下移動的線性方式，而是在編碼階段完成後進程發生變化，形成典型的V形。V -模型表明了軟體開發生命週期的每一階段及其相關的測試階段之間的關係。

特點：

把軟體生命週期中基本活動的垂直關係平行的關聯起來,開發活動和測試活動幾乎同時的開始. 這兩個並行的動態過程就會極大的較少bug和error出現的幾率.單元測試所檢測代碼的開發是否符合詳細設計的要求。整合測試所檢測此前測試過的各組成部分是否能完好地結合到一起。系統測試所檢測已整合在一起的產品是否符合系統規格說明書的要求。而驗收測試則檢測產品是否符合終端使用者的需求。

適用場合：

適用瀑布模型的場合

缺陷：

1. 把測試過程作為在需求分析、系統設計及編碼之後的一個階段

2. 忽視了測試對需求分析,系統設計的驗證，一直到後期的驗收測試才被發現。

總結

模型	優點	缺點
瀑布模型	文檔驅動	系統可能不滿足客戶的需求
快速原型模型	關注滿足客戶需求	可能導致系統設計差、效率低，難於維護
增量模型	開發早期反饋及時，易於維護	需要開放式體繫結構，可能會設計差、效率低
螺旋模型	風險驅動	風險分析人員需要有經驗且經過充分訓練