軟體開發模型（SSD9 Life-Cycle Methodologies ）

文章來源http://hi.baidu.com/%D0%D0%D7%DF%D4%DA%BF%D5%D6%D0/blog/item/7bbb261bc20988f2af513319.html

1. 編碼修補模型（Build-and-Fix Model）

實現產品既沒有需求或規格說明書也沒有設計方面的嘗試，開發人員簡單的將代碼拼湊在一起，軟體隨著客戶的需要一次又一次地不斷被修改. 在這個模型中，開發人員拿到項目立即根據需求編寫程式，調試通過後產生軟體的第一個版本。在提供給使用者使用後，如果程式出現錯誤，或者使用者提出新的要求，開發人員重新修改代碼，直到使用者滿意為止。 這是一種類似作坊的開發方式，對編寫幾百行的小程式來說還不錯，但這種方法對任何規模的開發來說都是不能令人滿意的，其主要問題在於：

　　（1） 缺少規劃和設計環節，軟體的結構隨著不斷的修改越來越糟，導致無法繼續修改；
　　（2） 忽略需求環節，給軟體開發帶來很大的風險；
　　（3） 沒有考慮測試和程式的可維護性，也沒有任何文檔，軟體的維護十分困難。

2.瀑布模型（Waterfall Model）

瀑布模型將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。在任何階段的文檔完成並且該階段產品被客戶和SQA小組認可前，該階段都是沒有完成的。每個階段都包含測試，他是靠文檔驅動的，強調文檔的作用，並要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟體開發模式，幾乎被業界拋棄，其主要問題在於：

　　（1） 各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；
　　（2） 由於開發模型是線性，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；
　　（3） 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

3.快速原型模型（RAPId Prototype Model）

第一步是建立快速原型，讓使用者或客戶試用，如果客戶認為滿足大多數要求，開發人員就擬定規格文檔。第二步則在第一步的基礎上開發客戶滿意的軟體產品。快速原型的關鍵在於儘可能快速地建造出軟體原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構並不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。

4.增量模型（Incremental Model）

在增量模型中，軟體被作為一系列的增量構件來設計、實現、整合和測試，每一個構件是由多種相互作用的模組所形成的提供特定功能的程式碼片段構成.。增量模型在各個階段並不交付一個可啟動並執行完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟體開發可以較好地適應變化，客戶可以不斷地看到所開發的軟體，從而降低開發風險。但是，增量模型也存在以下缺陷：

　　（1） 由於各個構件是逐漸併入已有的軟體體繫結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體繫結構。
　　（2） 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟體過程的控制失去整體性。

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

5.同步--穩定模型（Synchronize-and-Stabilize Model）也被稱為微軟模式

將工作分為3或4個構件，每個構件由小組單獨完成，每天工作結束，把部分完成的組件放在一起，測試和調試得到的產品（同步）。在每個構件結束時進行穩定化工作，修補至今遺留的錯誤，並將該構件凍結（即規格不再修改）。這種模型只在微軟公司取得成功。

6.螺旋模型（Spiral Model）

它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型複雜的系統。可以簡單的將他看做是每個階段前帶有風險分析的瀑布模型，在開始每個階段前努力減少風險，如果不能減少重大風險，則該項目停止。螺旋模型由風險驅動，強調可選方案和約束條件從而支援軟體的重用，有助於將軟體品質作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：

　　（1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟體開發。
　　（2） 如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟體項目。
　　（3） 軟體開發人員應該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險 。

7.噴泉模型（Object-Oriented Life-Cycle Models）

噴泉模型與傳統的結構化生存期比較，具有更多的增量和迭代性質，生存期的各個階段可以相互重疊和多次反覆，而且在項目的整個生存期中還可以嵌入子生存期。就像水噴上去又可以落下來，可以落在中間，也可以落在最底部。 該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟體項目開發效率，節省開發時間，適應於物件導向的軟體開發過程。由於噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利於項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種資訊、需求與資料的情況。

各模型的比較（Comparison of the Models）

Life-Cycle Model	Strengths	Weaknesses
Build-and-Fix	Fine for short programs that do not require maintenance	Totally unsatisfactory for nontrivial programs
Waterfall	Disciplined; Document-driven	Product may not meet customer needs
Rapid Prototyping	Ensures product will meet client's needs	Temptation to reuse code that should be reimplemented instead
Incremental	Maximized early return on investment; Promotes maintainability	Requires open architecture; May degenerate into build-and-fix
Synchronize-and-Stabilize	Future users' needs are met; Ensures components can be integrated	Has not been widely used outside Microsoft
Spiral	Incorporates features of all the models above	Can be used only for large-scale, in-house projects; Developers must be competent in risk management
Object-Oriented	Supports iteration within phases, parallelism between phases	May degenerate into CABTAB