天天看點

軟體開發模型總結歸納(瀑布模型、螺旋模型、疊代模型、增量模型、靈活模型)

文章目錄

        • 0. 軟體的生命周期
        • 1. 瀑布模型
        • 2. 螺旋模型
        • 3. 疊代模型
        • 4. 增量模型
        • 5. 靈活模型

0. 軟體的生命周期

  軟體的生命周期是指從軟體産品的設想開始到軟體不在使用而結束的時間。

  軟體的生命周期分為6個階段,即需求分析、計劃、設計、編碼、測試、運作維護。

1. 瀑布模型

軟體開發模型總結歸納(瀑布模型、螺旋模型、疊代模型、增量模型、靈活模型)

  瀑布模型是最早出現的軟體開發模型,是所有其他軟體開發模型的基礎架構。與軟體的生命周期不同的是,它缺少了軟體運作維護階段。

描述: 每個階段都隻執行一次,是以是線性順序的軟體開發模型。

  正是由于每個階段隻執行一次,是以前面的需求分析和設計尤為重要。

優點:

  1. 為項目提供了按階段劃分的檢查點,強調開發的階段性。
  2. 強調早期的計劃及需求調查。
  3. 強調産品測試。

缺點:

  1. 在各個階段之間極少有回報。
  2. 隻有在項目周期的後期才能看到結果,是以風險往往至後期的測試階段才顯露,是以失去了及早的糾正過程。
  3. 單一流程,開發中的經驗教訓不能回報應用于本産品的過程。

适用項目: 需求比較明确且變更很少的項目。

2. 螺旋模型

一般在軟體開發初期階段需求不是很明确時,采用漸進式的開發模型。螺旋模型是漸進式開發模型的代表之一。

軟體開發模型總結歸納(瀑布模型、螺旋模型、疊代模型、增量模型、靈活模型)

描述: 以原型為基礎沿螺線旋轉、每轉一圈都經過計劃/風險分析/實施/評估等過程且得到相應新版本、經過若幹次螺旋上升得到最終版本。

螺旋模型沿着螺旋線進行若幹次疊代,圖中的四個象限代表了一下活動:

(1)制定計劃:确定軟體目标,標明實施方案,弄清項目開發的限制條件;

(2)風險分析:分析評估所選方案,考慮如何識别和清楚風險;

(3)實施工程:實施軟體開發和驗證;

(4)客戶評估:評價開發工作,提出修正建議,制定下一步計劃。

  疊代開發的模式給軟體測試帶來了新的要求,它不允許有一段獨立的測試時間和階段,測試必須跟着開發的疊代而疊代,是以回歸測試的很重要。

優點:

  1. 強調嚴格的風險分析,但要求許多客戶接受和相信這種分析,并做出相關反應是不容易的,是以,這種模型往往适用于規模龐大,風險大的項目。
  2. 強調各個開發階段的品質。
  3. 這種的開發模式會提供機會探讨項目是否有價值繼續下去。

缺點:

  1. 由于引入了非常嚴格的風險識别、風險分析和風險控制,将會大大消耗人力、資源,如果嚴重的影響了項目的利潤,風險分析将毫無意義。
  2. 軟體開發人員應該擅長尋找可能的風險,準确地分析風險,否則将會帶來更大的風險。
  3. 軟體建設周期長,但軟體技術發展比較快,是以可能會和目前的技術水準有較大的的差距,無法滿足目前使用者需求。

适用項目: 對新近開發,需求不明确的情況下,适合用螺旋模型進行開發,便于風險控制和需求變更。

3. 疊代模型

軟體開發模型總結歸納(瀑布模型、螺旋模型、疊代模型、增量模型、靈活模型)

  開發疊代是一次完整地經過所有工作流程的過程:(至少包括)需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上,疊代模型是類似小型的瀑布式項目。

每一個疊代都會産生一個可以釋出的産品,這個産品是最終産品的一個子集。

描述:

4. 一次疊代過程包括了所有軟體開發流程。

5. 每一次疊代均産生一個可釋出的産品。

6. 該産品為最終産品的一個子集。

适用項目: 适合于事先不能完整定義産品的所有需求,計劃多期開發的項目。

4. 增量模型

軟體開發模型總結歸納(瀑布模型、螺旋模型、疊代模型、增量模型、靈活模型)

描述:

  1. 采用随時間進展而交錯的線性序列。
  2. 每個序列産生一個可釋出的增量。
  3. 每一個增量産生一個可操作的産品。
  4. 第一個增量是核心産品。

優點: 開始時不用投入大量人力資源,可以事先推出核心産品以穩定使用者,可以有計劃的管理技術風險。

缺點: 需要開放式體系結構,可能會産生設計效果差、開發效率低的情況。

适合項目: 需求經常發生改變的軟體開發過程。

增量和疊代模型的差別:

  增量是逐塊建造的概念,例如:畫一幅人物畫,我們可以先畫人的頭部,再畫身體,再畫手腳……。

  疊代是反複求精的概念,例如:同樣是畫人物畫,我們可以先畫整體輪廓,在勾勒出基本雛形,再細化、着色……。

5. 靈活模型

描述: 靈活模型是一種輕量、高效、低風險、更強調團隊協作和溝通的開發方式,适合于中小型開發團隊,客戶需求模糊或多變。

特點:

  • 強調人與人之間的溝通。
  • 輕文檔(弱化文檔,但不是不需要文檔)
  • 客戶需要全程參與
  • 需求可以的變化