軟件工程之軟件開發模型類型

軟件工程之軟件開發模型類型

1.邊作邊改模型

2.瀑布模型

3.演化模型

4.增量模型

5.螺旋模型

6.噴泉模型

7.敏捷模型-SCRUM

各類模型的優勢和缺點

　　瀑布模型 文檔驅動 系統可能不知足客戶的需求

　　快速原型模型 關注知足客戶需求 可能致使系統設計差、效率低，難於維護

　　增量模型 開發早期反饋及時，易於維護 須要開放式體系結構，可能會設計差、效率低

螺旋模型 風險驅動 風險分析人員須要有經驗且通過充分訓練

1邊作邊改模型（Build-and-Fix Model）

　　國內許多軟件公司都是使用"邊作邊改"模型來開發的。在這種模型中，既沒有規格說明，也沒有通過設計，軟件隨着客戶的須要一次又一次地不斷被修改. 在這個模型中，開發人員拿到項目當即根據需求編寫程序，調試經過後生成軟件的第一個版本。在提供給用戶使用後，若是程序出現錯誤，或者用戶提出新的要求，開發人員從新修改代碼，直到用戶滿意爲止。

　　這是一種相似做坊的開發方式，對編寫幾百行的小程序來講還不錯，但這種方法對任何規模的開發來講都是不能使人滿意的，其主要問題在於：

　　（1） 缺乏規劃和設計環節，軟件的結構隨着不斷的修改愈來愈糟，致使沒法繼續修改；

　　（2） 忽略需求環節，給軟件開發帶來很大的風險；

（3） 沒有考慮測試和程序的可維護性，也沒有任何文檔，軟件的維護十分困難。

2瀑布模型（Waterfall Model）

1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是惟一被普遍採用的軟件開發模型。 瀑布模型將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接

的固定次序，如同瀑布流水，逐級下落。

 

在瀑布模型中，軟件開發的各項活動嚴格按照線性方式進行，當前活動接受上一

項活動的工做結果，實施完成所需的工做內容。當前活動的工做結果須要進行驗證，若是驗證經過，則該結果做爲下一項活動的輸入，繼續進行下一項活動，不然返回修改。

　　瀑布模型強調文檔的做用，並要求每一個階段都要仔細驗證。可是，這種模型的線性過程太理想化，已再也不適合現代的軟件開發模式，幾乎被業界拋棄，其主要問題在於：

　　（1） 各個階段的劃分徹底固定，階段之間產生大量的文檔，極大地增長了工做量；

　　（2） 因爲開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增長了開發的風險；

　　（3） 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

咱們應該認識到，"線性"是人們最容易掌握並能熟練應用的思想方法。當人們碰到一個複雜的"非線性"問題時，老是想方設法地將其分解或轉化爲一系列簡 單的線性問題，而後逐個解決。一個軟件系統的總體多是複雜的，而單個子程序老是簡單的，能夠用線性的方式來實現，不然幹活就太累了。線性是一種簡潔，簡 潔就是美。當咱們領會了線性的精神，就不要再呆板地套用線性模型的外表，而應該用活它。例如增量模型實質就是分段的線性模型，螺旋模型則是接連的彎曲了的線性模型，在其它模型中也可以找到線性模型的影子

new

　　早在20世紀50年代末期，軟件領域中就出現了迭代模型。最先的迭代過程可能被描述爲「分段模型（stagewise model）」。迭代模型是RUP推薦的週期模型。被定義爲：迭代包括產生產品發佈（穩定、可執行的產品版本）的所有開發活動和要使用該發佈必需的全部其餘外圍元素。在某種程度上，開發迭代是一次完整地通過全部工做流程的過程：需求、分析設計、實施和測試工做流程。實質上，它相似小型的瀑布式項目。RUP 認爲，全部的階段均可以細分爲迭代。每一次的迭代都會產生一個能夠發佈的產品，這個產品是最終產品的一個子集。

什麼是迭代模型

　　在現代過程方法XP（eXtreme Programming，極限編程）、RUP無一例外地都推薦、主張採用能顯著減小風險的迭代模型。美國國防部本來提倡瀑布過程和觀點，在發現那麼多采用 了瀑布模型的失敗的項目以後，不但放棄了對它的要求，並且從1994年的報告開始，積極地鼓勵採用更加現代化的迭代模型來取代瀑布模型作法。同時，中國中 科院也提倡選用迭代模型。

迭代模型的選擇

　　對衆多的開發模型和過程方法，及權威機構的見解，企業應選擇什麼樣的開發模型，應慎重對從如下幾方面進行考慮：

　　一、RUP雖然內容極其豐富，定義了選起、精化、構建、產品化4個階段和業務建模、需求、分析設計、實現、測試、部署等9個工種，提供了一大堆的文檔模板，但極易讓人誤解是重型的過程，實施推廣有必定難度。

 　　二、再次，在質量管理方面：以實現系統架構、核心功能目標的迭代產品生的工做成果做爲質量控制重點。每次迭代進行系統集成、系統測試，達到對軟件質量的持續驗證。每次系統測試，須要迴歸測試前一次迭代遺留髮現的問題。每次迭代發佈的小版本組織客戶（包括內部客戶、外部客戶）進行評價，經過演示 操做等方式，評價該次迭代是否達到預約的目標，並以此爲依據來制定下一次迭代的目標。

 　　三、最後，在其餘方面：每次迭代成果須進行配置管理，版本控制很重要。在整個迭代過程當中風險無處不在，建議每週做一次風險跟蹤。同時經過重點關注進度、工做量、滿意度、缺陷等數據收集，關注每次迭代狀況。

 　　總之，選擇一個合適的生命週期模型，並應用正確的方法，對於任何軟件項目的成功是相當重要。企業在選擇開發模型應從項目時間要求、需求明確程度、風險情況等選擇合適的生命週期模型。

迭代模型的使用條件

　　一、在項目開發早期需求可能有所變化。

　　二、分析設計人員對應用領域很熟悉。

　　三、高風險項目。

　　四、用戶可不一樣程度地參與整個項目的開發過程。

　　五、使用面向對象的語言或統一建模語言（Unified Modeling Language，UML）。

　　六、使用CASE（Computer Aided Software Engineering，計算機輔助軟件工程）工具，如Rose（Rose是很是受歡迎的物件軟體開發工具。）。

　　七、具備高素質的項目管理者和軟件研發團隊。

迭代模型的優勢

　　與傳統的瀑布模型相比較，迭代過程具備如下優勢：

 　　1）下降了在一個增量上的開支風險。若是開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費。

 　　2）下降了產品沒法按照既定進度進入市場的風險。經過在開發早期就肯定風險，能夠儘早來解決而不至於在開發後期匆匆忙忙。

 　　3）加快了整個開發工做的進度。由於開發人員清楚問題的焦點所在，他們的工做會更有效率。

　　4）因爲用戶的需求並不能在一開始就做出徹底的界定，它們一般是在後續階段中不斷細化的。所以，迭代過程這種模式使適應需求的變化會更容易些。

螺旋模型（Spiral Model）

　　1988年，Barry Boehm正式發表了軟件系統開發的"螺旋模型"，它將瀑布模型和快速原型模型結合起來，強調了其餘模型所忽視的風險分析，特別適合於大型複雜的系統。 螺旋模型沿着螺線進行若干次迭代，圖中的四個象限表明瞭如下活動：

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

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

　　（3） 實施工程：實施軟件開發和驗證；

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

　　螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟件的重用，有助於將軟件質量做爲特殊目標融入產品開發之中。可是，螺旋模型也有必定的限制條件，具體以下：

　　（1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並作出相關反應是不容易的，所以，這種模型每每適應於內部的大規模軟件開發。

　　（2） 若是執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無心義，所以，螺旋模型只適合於大規模軟件項目。

　　（3） 軟件開發人員應該擅長尋找可能的風險，準確地分析風險，不然將會帶來更大的風險

一個階段首先是肯定該階段的目標，完成這些目標的選擇方案及其約束條件，而後從風險角度分析方案的開發策略，努力排除各類潛在的風險，有時須要經過建 造原型來完成。若是某些風險不能排除，該方案當即終止，不然啓動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。

增量模型（Incremental Model）

　　又稱演化模型。與建造大廈相同，軟件也是一步一步建造起來的。在增量模型中，軟件被做爲一系列的增量構件來設計、實現、集成和測試，每個構件是由多 種相互做用的模塊所造成的提供特定功能的代碼片斷構成. 增量模型在各個階段並不交付一個可運行的完整產品，而是交付知足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產 品，這樣作的好處是軟件開發能夠較好地適應變化，客戶能夠不斷地看到所開發的軟件，從而下降開發風險。可是，增量模型也存在如下缺陷：

　　（1） 因爲各個構件是逐漸併入已有的軟件體系結構中的，因此加入構件必須不破壞已構造好的系統部分，這須要軟件具有開放式的體系結構。

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

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

例如，使用增量模型開發字處理軟件。能夠考慮，第一個增量發佈基本的文件管理、編輯和文檔生成功能，第二個增量發佈更加完善的編輯和文檔生成功能，第三個增量實現拼寫和文法檢查功能，第四個增量完成高級的頁面佈局功能

快速原型模型（Rapid Prototype Model）

　　 

　　快速原型模型的第一步是建造一個快速原型，實現客戶或將來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。 經過逐步調整原型使其知足客戶的要求，開發人員能夠肯定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟件產品。

　　顯然，快速原型方法能夠克服瀑布模型的缺點，減小因爲軟件需求不明確帶來的開發風險，具備顯著的效果。

快速原型的關鍵在於儘量快速地建造出軟件原型，一旦肯定了客戶的真正需求，所建造的原型將被丟棄。所以，原型系統的內部結構並不重要，重要的是必須迅速創建原型，隨之迅速修改原型，以反映客戶的需求。

敏捷軟件開發模型--SCRUM

一 什麼是Scrum?

Scrum (英式橄欖球爭球隊), 軟件開發模型是敏捷開發的一種，在最近的一兩年內逐漸流行起來。

Scrum的基本假設是：

開發軟件就像開發新產品，沒法一開始就能定義軟件產品最終的規程，過程當中須要研發、創意、嘗試錯誤，因此沒有一種固定的流程能夠保證專案成功。Scrum 將軟件開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具有的最佳典範與技術，具備高度自主權，緊密地溝通合做，以高度彈性解決各類挑戰，確保天天、每一個階段都朝向目標有明確的推動。

Scrum 開發流程一般以 30 天(或者更短的一段時間)爲一個階段，由客戶提供新產品的需求規格開始，開發團隊與客戶於每個階段開始時挑選該完成的規格部分，開發團隊必須盡力於 30 天后交付成果，團隊天天用 15 分鐘開會檢查每一個成員的進度與計劃，瞭解所遭遇的困難並設法排除。

二 Scrum較傳統開發模型的優勢

Scrum模型的一個顯著特色就是響應變化，它可以儘快地響應變化。下面的圖片使用傳統的軟件開發模型(瀑布模型、螺旋模型或迭代模型)。隨着系統因素（內部和外部因素）的複雜度增長，項目成功的可能性就迅速下降。


下圖是Scrum模型和傳統模型的對比：

      

三 Scrum模型

一)  有關Scrum的幾個名詞

backlog: 能夠預知的全部任務， 包括功能性的和非功能性的全部任務。

sprint:一次跌代開發的時間週期，通常最多以30天爲一個週期.在這段時間內，開發團隊須要完成一個制定的backlog,而且最終成果是一個增量的，能夠交付的產品。

sprint backlog:一個sprint週期內所須要完成的任務。

scrumMaster: 負責監督整個Scrum進程，修訂計劃的一個團隊成員。

time-box: 一個用於開會時間段。好比每一個daily scrum meeting的time-box爲15分鐘。

sprint planning meeting: 在啓動每一個sprint前召開。通常爲一天時間（8小時）。該會議須要制定的任務是：產品Owner和團隊成員將backlog分解成小的功能模塊,  決定在即將進行的sprint裏須要完成多少小功能模塊，肯定好這個Product Backlog的任務優先級。另外，該會議還需詳細地討論如何可以按照需求完成這些小功能模塊。制定的這些模塊的工做量以小時計算。

Daily Scrum meeting：開發團隊成員召開，通常爲15分鐘。每一個開發成員須要向ScrumMaster彙報三個項目：今天完成了什麼？　是否遇到了障礙？　即將要作什麼？經過該會議，團隊成員能夠相互瞭解項目進度。

Sprint review meeting：在每一個Sprint結束後，這個Team將這個Sprint的工做成果演示給Product Owner和其餘相關的人員。通常該會議爲４小時。

Sprint retrospective meeting：對剛結束的Sprint進行總結。會議的參與人員爲團隊開發的內部人員。通常該會議爲３小時。

二）實施Scrum的過程簡單介紹

1) 將整個產品的backlog分解成Sprint Backlog,這個Sprint Backlog是按照目前的人力物力條件能夠完成的。
2) 召開sprint planning meeting，劃分，肯定這個Sprint內須要完成的任務，標註任務的優先級並分配給每一個成員。注意這裏的任務是以小時計算的，並非按人天計算。
3) 進入sprint開發週期，在這個週期內，天天須要召開Daily Scrum meeting。
4) 整個sprint週期結束，召開Sprint review meeting，將成果演示給Product Owner.
5) 團隊成員最後召開Sprint retrospective meeting，總結問題和經驗。
6) 這樣周而復始，按照一樣的步驟進行下一次Sprint.

整個過程以下圖所示：