軟體工程之軟體開發模型類型
1.邊做邊改模型
2.瀑布模型
3.演化模型
4.增量模型
5.螺旋模型
6.噴泉模型
7.靈活模型-SCRUM
瀑布模型 文檔驅動 系統可能不滿足客戶的需求
快速原型模型 關注滿足客戶需求 可能導緻系統設計差、效率低，難于維護
增量模型 開發早期回報及時，易于維護 需要開放式體系結構，可能會設計差、效率低
螺旋模型 風險驅動 風險分析人員需要有經驗且經過充分訓練
國内許多軟體公司都是使用"邊做邊改"模型來開發的。在這種模型中，既沒有規格說明，也沒有經過設計，軟體随着客戶的需要一次又一次地不斷被修改. 在這個模型中，開發人員拿到項目立即根據需求編寫程式，調試通過後生成軟體的第一個版本。在提供給使用者使用後，如果程式出現錯誤，或者使用者提出新的要求，開發人員重新修改代碼，直到使用者滿意為止。
這是一種類似作坊的開發方式，對編寫幾百行的小程式來說還不錯，但這種方法對任何規模的開發來說都是不能令人滿意的，其主要問題在于：
（1） 缺少規劃和設計環節，軟體的結構随着不斷的修改越來越糟，導緻無法繼續修改；
（2） 忽略需求環節，給軟體開發帶來很大的風險；
（3） 沒有考慮測試和程式的可維護性，也沒有任何文檔，軟體的維護十分困難。
1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被廣泛采用的軟體開發模型。 瀑布模型将軟體生命周期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運作維護等六個基本活動，并且規定了它們自上而下、互相銜接
的固定次序，如同瀑布流水，逐級下落。
在瀑布模型中，軟體開發的各項活動嚴格按照線性方式進行，目前活動接受上一
項活動的工作結果，實施完成所需的工作内容。目前活動的工作結果需要進行驗證，如果驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則傳回修改。
瀑布模型強調文檔的作用，并要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再适合現代的軟體開發模式，幾乎被業界抛棄，其主要問題在于：
（1） 各個階段的劃分完全固定，階段之間産生大量的文檔，極大地增加了工作量；
（2） 由于開發模型是線性的，使用者隻有等到整個過程的末期才能見到開發成果，進而增加了開發的風險；
（3） 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。
我們應該認識到，"線性"是人們最容易掌握并能熟練應用的思想方法。當人們碰到一個複雜的"非線性"問題時，總是千方百計地将其分解或轉化為一系列簡 單的線性問題，然後逐個解決。一個軟體系統的整體可能是複雜的，而單個子程式總是簡單的，可以用線性的方式來實作，否則幹活就太累了。線性是一種簡潔，簡 潔就是美。當我們領會了線性的精神，就不要再呆闆地套用線性模型的外表，而應該用活它。例如增量模型實質就是分段的線性模型，螺旋模型則是接連的彎曲了的線性模型，在其它模型中也能夠找到線性模型的影子
new
早在20世紀50年代末期，軟體領域中就出現了疊代模型。最早的疊代過程可能被描述為“分段模型（stagewise model）”。疊代模型是RUP推薦的周期模型。被定義為：疊代包括産生産品釋出（穩定、可執行的産品版本）的全部開發活動和要使用該釋出必需的所有其他外圍元素。在某種程度上，開發疊代是一次完整地經過所有工作流程的過程：需求、分析設計、實施和測試工作流程。實質上，它類似小型的瀑布式項目。RUP 認為，所有的階段都可以細分為疊代。每一次的疊代都會産生一個可以釋出的産品，這個産品是最終産品的一個子集。
在現代過程方法XP（eXtreme Programming，極限程式設計）、RUP無一例外地都推薦、主張采用能顯著減少風險的疊代模型。美國國防部原本提倡瀑布過程和觀點，在發現那麼多采用 了瀑布模型的失敗的項目之後，不但放棄了對它的要求，而且從1994年的報告開始，積極地鼓勵采用更加現代化的疊代模型來取代瀑布模型做法。同時，中國中 科院也提倡選用疊代模型。
對衆多的開發模型和過程方法，及權威機構的看法，企業應選擇什麼樣的開發模型，應慎重對從以下幾方面進行考慮：
1、RUP雖然内容極其豐富，定義了選起、精化、建構、産品化4個階段和業務模組化、需求、分析設計、實作、測試、部署等9個工種，提供了一大堆的文檔模闆，但極易讓人誤解是重型的過程，實施推廣有一定難度。
2、再次，在品質管理方面：以實作系統架構、核心功能目标的疊代産品生的工作成果作為品質控制重點。每次疊代進行系統內建、系統測試，達到對軟體品質的持續驗證。每次系統測試，需要回歸測試前一次疊代遺留發現的問題。每次疊代釋出的小版本組織客戶（包括内部客戶、外部客戶）進行評價，通過示範 操作等方式，評價該次疊代是否達到預定的目标，并以此為依據來制定下一次疊代的目标。
3、最後，在其他方面：每次疊代成果須進行配置管理，版本控制很重要。在整個疊代過程中風險無處不在，建議每周作一次風險跟蹤。同時通過重點關注進度、工作量、滿意度、缺陷等資料收集，關注每次疊代情況。
總之，選擇一個合适的生命周期模型，并應用正确的方法，對于任何軟體項目的成功是至關重要。企業在選擇開發模型應從項目時間要求、需求明确程度、風險狀況等選擇合适的生命周期模型。
1、在項目開發早期需求可能有所變化。
2、分析設計人員對應用領域很熟悉。
3、高風險項目。
4、使用者可不同程度地參與整個項目的開發過程。
5、使用面向對象的語言或統一模組化語言（Unified Modeling Language，UML）。
6、使用CASE（Computer Aided Software Engineering，計算機輔助軟體工程）工具，如Rose（Rose是非常受歡迎的物件軟體開發工具。）。
7、具有高素質的項目管理者和軟體研發團隊。
與傳統的瀑布模型相比較，疊代過程具有以下優點：
1）降低了在一個增量上的開支風險。如果開發人員重複某個疊代，那麼損失隻是這一個開發有誤的疊代的花費。
2）降低了産品無法按照既定進度進入市場的風險。通過在開發早期就确定風險，可以盡早來解決而不至于在開發後期匆匆忙忙。
3）加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。
4）由于使用者的需求并不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。是以，疊代過程這種模式使适應需求的變化會更容易些。
1988年，Barry Boehm正式發表了軟體系統開發的"螺旋模型"，它将瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特别适合于大型複雜的系統。 螺旋模型沿着螺線進行若幹次疊代，圖中的四個象限代表了以下活動：
（1） 制定計劃：确定軟體目标，標明實施方案，弄清項目開發的限制條件；
（2） 風險分析：分析評估所選方案，考慮如何識别和消除風險；
（3） 實施工程：實施軟體開發和驗證；
（4） 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
螺旋模型由風險驅動，強調可選方案和限制條件進而支援軟體的重用，有助于将軟體品質作為特殊目标融入産品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：
（1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，并做出相關反應是不容易的，是以，這種模型往往适應于内部的大規模軟體開發。
（2） 如果執行風險分析将大大影響項目的利潤，那麼進行風險分析毫無意義，是以，螺旋模型隻适合于大規模軟體項目。
（3） 軟體開發人員應該擅長尋找可能的風險，準确地分析風險，否則将會帶來更大的風險
一個階段首先是确定該階段的目标，完成這些目标的選擇方案及其限制條件，然後從風險角度分析方案的開發政策，努力排除各種潛在的風險，有時需要通過建 造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，并設計下一個階段。
又稱演化模型。與建造大廈相同，軟體也是一步一步建造起來的。在增量模型中，軟體被作為一系列的增量構件來設計、實作、內建和測試，每一個構件是由多 種互相作用的子產品所形成的提供特定功能的代碼片段構成. 增量模型在各個階段并不傳遞一個可運作的完整産品，而是傳遞滿足客戶需求的一個子集的可運作産品。整個産品被分解成若幹個構件，開發人員逐個構件地傳遞産 品，這樣做的好處是軟體開發可以較好地适應變化，客戶可以不斷地看到所開發的軟體，進而降低開發風險。但是，增量模型也存在以下缺陷：
（1） 由于各個構件是逐漸并入已有的軟體體系結構中的，是以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構。
（2） 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其适應這種變化的能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，進而是軟體過程的控制失去整體性。
在使用增量模型時，第一個增量往往是實作基本需求的核心産品。核心産品傳遞使用者使用後，經過評價形成下一個增量的開發計劃，它包括對核心産品的修改和一些新功能的釋出。這個過程在每個增量釋出後不斷重複，直到産生最終的完善産品。
例如，使用增量模型開發字處理軟體。可以考慮，第一個增量釋出基本的檔案管理、編輯和文檔生成功能，第二個增量釋出更加完善的編輯和文檔生成功能，第三個增量實作拼寫和文法檢查功能，第四個增量完成進階的頁面布局功能
快速原型模型的第一步是建造一個快速原型，實作客戶或未來的使用者與系統的互動，使用者或客戶對原型進行評價，進一步細化待開發軟體的需求。 通過逐漸調整原型使其滿足客戶的要求，開發人員可以确定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體産品。
顯然，快速原型方法可以克服瀑布模型的缺點，減少由于軟體需求不明确帶來的開發風險，具有顯著的效果。
快速原型的關鍵在于盡可能快速地建造出軟體原型，一旦确定了客戶的真正需求，所建造的原型将被丢棄。是以，原型系統的内部結構并不重要，重要的是必須迅速建立原型，随之迅速修改原型，以反映客戶的需求。
靈活軟體開發模型—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.
整個過程如下圖所示