軟件工程——瀑布模型、快速原型模型、增量模型、螺旋模型

一、瀑布模型

1.1 什么是瀑布模型

1970年溫斯頓.羅伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被廣泛采用的軟件開發模型

瀑布模型將軟件生命周期划分為制定計划、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落

瀑布模型是最早出現的軟件開發模型，在軟件工程中占有重要的地位，它提供了軟件開發的基本框架。其過程是，從上一項活動接收的工作對象作為當前項活動的輸入，利用這一輸入實施當前項活動以給出工作成果，並作為輸出傳給下一項活動

從本質來講，它是一個軟件開發架構。開發過程通過一系列階段順序展開，從系統需求分析開始到產品發布和維護，每個階段都會產生循環反饋，因此如果有信息未被覆蓋或者發現了問題，那么最好 “返回”上一個階段並進行適當的修改。開發進程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來

對於經常變化的項目而言，瀑布模型毫無價值

1.2 特點

1.2.1 階段間具有順序性和依賴性

順序性：必須等前一階段的工作完成后，才能開始后一階段的工作

依賴性：前一階段的輸出文檔是后一階段的輸入文檔。只有前一階段的輸出文檔正確，后一階段的工作才能獲得正確的結果

1.2.2 推遲實現的觀點

對於規模較大的軟件項目來說，往往編碼開始的越早，最終完成開發所需的時間越長。前面階段的工作沒做或做的不扎實，過早地考慮進行程序實現，往往導致大量返工，有時甚至產生無法彌補的問題

瀑布模型在編碼之前設置了系統分析與系統設計階段，它們的基本任務是主要考慮目標系統的邏輯模型而不涉及軟件的物理實現

清楚的區分邏輯設計與物理設計，盡可能推遲程序的物理實現，是按照瀑布模型開發軟件的一條重要的指導思想

1.2.3 質量保證的觀點

為了保證所開發的軟件的質量，在瀑布模型的每一個階段都應堅持兩個重要做法

1. 每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務

2. 每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤

傳統的瀑布模型過於理想化，實際的瀑布模型是帶"反饋環"的。如圖所示（圖中實線箭頭表示開發過程，虛線箭頭表示維護過程），當在后面階段發現前面階段的錯誤時，需要沿圖中左側的反饋線返回前面的階段，修正前面階段的產品后再回來繼續完成后面階段的任務

瀑布模型是文檔驅動的模型，遵守這個約束可使軟件維護變得比較容易一些，從而顯著降低軟件預算

1.3 優缺點

優點

• 為項目提供了按階段划分的檢查點

• 當前一階段完成后，您只需要去關注后續階段

• 可在迭代模型中應用瀑布模型

缺點

• 不適合需求模糊或需求經常變動的系統

• 由於開銷的逐步升級問題，它不希望存在早期階段的反饋

• 在一個系統完成以前，它無法預測一個新系統引入一個機構的影響

• 在用戶可能需要較長等待時間來獲得一個可供使用的系統，也許會給用戶的信任程度帶來影響和打擊

• 最終產品往往反映用戶的初始需求而不是最終需求

 

二、快速原型模型

2.1 什么是快速原型模型

快速原型是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集

快速原型模型是增量模型的另一種形式，在開發真實系統之前，迅速建造一個可以運行的軟件原型 ，以便理解和澄清問題，在該原型的基礎上，逐漸完成整個系統的開發工作

它允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型，該原型向用戶展示待開發軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發人員據此對軟件進行修改完善，直至用戶滿意認可之后進行軟件的完整實現及測試、維護

2.2 優缺點

優點

• 克服瀑布模型的缺點，減少由於軟件需求不明確帶來的開發風險

• 適合預先不能確切定義需求的軟件系統的開發

缺點

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

• 使用前提是要有一個展示性的產品原型，一定程度上可能會限制開發人員的創新

2.3 快速原型模型的思想產生、原理及運用方式

1、思想產生

在需求分析階段得到完全、一致、准確、合理的需求說明十分困難

獲得一組基本需求說明后，就快速地將其“實現”。通過原型反饋，加深對系統的理解來滿足用戶基本要求，使用戶在試用后對需求說明進行補充和精確化，從而獲得合理完整、現實可行的需求說明。再把快速原型思想用到軟件開發的其他階段，向軟件開發的全過程擴展

先用相對少的成本、較短的周期開發一個簡單但可以運行的系統原型向用戶演示或者讓用戶試用，及早澄清並檢驗一些主要設計策略，在此基礎上再開發實際的軟件系統

2、原理

利用原型輔助軟件開發

經過簡單快速分析快速實現一個原型，用戶與開發者在試用原型過程中加強通信與反饋，通過反復評價和改進原型，減少誤解，彌補漏洞，最終提高軟件質量

3、運用方式

由於運用原型的目的和方式不同，在使用原型時也采取不同的策略

• 拋棄策略：將原型用於開發過程的某個階段，促使該階段的開發結果更加完整、准確、一致、可靠，該階段結束后原型隨之作廢。探索型快速原型和實驗型快速原型就是采用此策略

• 附加策略：將原型用於開發的全過程，原型由最基本的核心開始，逐步增加新的功能和新的需求，反復修改反復擴充，最后發展為用戶滿意的最終系統。演化型快速原型就是采用此策略

采用何種形式、何種策略運用快速原型主要取決於軟件項目的特點、可供支持的原型開發工具和技術等，根據實際情況的特點決定

2.4 開發步驟

1、快速分析

在分析人員與用戶密切配合下，迅速確定系統的基本需求，根據原型需要體現的特征描述基本需求以滿足開發原型的需要

2、構造原型

在快速分析的基礎上，根據基本需求說明盡快實現一個可行的系統

要求具有強有力的軟件工具的支持，並忽略最終系統在某些細節上的要求，主要考慮原型系統能夠充分反映所要評價的特性

3、運行原型

發現問題，消除誤解，開發者與用戶充分協調

4、評價原型

在運行的基礎上，考核評價原型的特性，分析運行效果是否滿足用戶的願望，糾正過去交互中的誤解與分析中的錯誤，增添新的要求，並滿足因環境變化或用戶的新想法引起的系統要求變動，提出全面的修改意見

5、修改

根據評價原型的活動結果進行修改

若原型未滿足需求說明的要求，說明對需求說明存在不一致的理解或實現方案不夠合理，根據明確的要求迅速修改原型

快速原型模型不帶反饋環，軟件產品的開發基本上是線性順序進行的

快速原型的本質是"快速"。開發人員應盡可能地建造出原型系統，以加速軟件開發過程，節約軟件開發成本

原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄

 

三、增量模型

3.1什么是增量模型

增量模型也稱漸增模型

使用增量模型開發軟件時把軟件產品作為一系列的增量構件來設計、編碼、集成和測試，每個構件由多個相互作用的模塊構成，並且能夠完成特定的功能

使用增量模型時，第一個增量構件往往實現軟件的基本需求，提供最核心的功能

把軟件產品分解成增量構件時，唯一必須遵守的約束條件是，當把新構件集成到現有構件中時，所形成的產品必須是可測試的

瀑布模型或快速原型模型目標是一次就把一個滿足所有需求的產品提交給用戶

增量模型把整個軟件產品分解成許多個增量構件，分批地逐步向用戶提交產品

3.2特點

把瀑布模型的順序特征與快速原型法的迭代特征相結合

將軟件看作一系列相互聯系的增量，在開發過程的各次迭代中，每次完成其中的一個增量

風險更大的增量模型

確定用戶需求后就着手擬定第一個構件的規格說明文檔，完成后規格說明組轉向第二個構件的規格說明文檔，同時設計組開始涉及第一個構件

使用該方法將不同的構件並行構建，可能加快工程進度，但將冒構建無法集成到一起的風險

3.3優缺點

優點

• 能在較短的時間內向用戶提交可完成部分工作的產品

• 將待開發的軟件系統模塊化，可以分批次地提交軟件產品，使用戶可以及時了解軟件項目的進展

• 以組件為單位進行開發降低了軟件開發的風險。一個開發周期內的錯誤不會影響到整個軟件系統

• 開發順序靈活。開發人員可以對組件的實現順序進行優先級排序，先完成需求穩定的核心組件。當組件的優先級發生變化時，還能及時地對實現順序進行調整

缺點

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

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

• 如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析，這種模型將功能細化后分別開發的方法較適應於需求經常改變的軟件開發過程

 

四、螺旋模型

4.1 什么是螺旋模型

螺旋模型是一種演化軟件開發過程模型，它兼顧了快速原型的迭代特征以及瀑布模型的系統化與嚴格監控

螺旋模型最大的特點在於引入了其他模型不具備的風險分析，使軟件在無法排除重大風險時有機會停止，以減小損失。在每個迭代階段構建原型是螺旋模型用以減小風險的途徑

螺旋模型是快速原型模型以進化的開發方式為中心，在每個項目階段使用瀑布模型法。該模型的每一個周期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層次。用螺旋模型的軟件過程如下

簡化的螺旋模型

完整的數據模型

圖中帶箭頭的點划線的長度代表當前累計的開發費用，螺旋線的角度值代表開發進度，螺旋線的每個周期對應於一個開發階段

圖中的四個象限代表了以下活動

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

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

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

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

4.2特點

螺旋模型在“瀑布模型”的每一個開發階段前引入非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目，每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定

螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險有所了解，繼而做出應有的反應，因此特別適用於龐大、復雜並具有高風險的系統

4.3優缺點

優點

• 對可選方案和約束條件的強調有利於已有軟件的重用，也有助於把軟件質量作為軟件開發的一個重要目標

• 減少了過多測試（浪費資金）或測試不足（產品故障多）所帶來的風險

• 在螺旋模型中維護只是模型的另一個周期，在維護和開發之間並沒有本質區別

缺點

• 采用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失

• 過多的迭代次數會增加開發成本，延遲提交時間

4.4限制條件

一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然后從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最后評價該階段的結果，並設計下一個階段

• 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此這種模型往往適應於內部的大規模軟件開發

• 如果執行風險分析將大大影響項目的利潤，那么進行風險分析毫無意義，因此螺旋模型只適合於大規模軟件項目

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

•