天天看點

軟考難點—軟體開發模型(借鑒)

一、瀑布模型

 定義:瀑布模型即生存周期模型,其核心思想是按工序将問題化簡、将功能的實作與設計分開,便于分工協作,即采用結構化的分析與設計方法将邏輯實作與實體實作分開。

結構:瀑布模型将軟體生命周期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運作維護等六個基本活動,并且規定了它們自上而下、互相銜接的固定次序,如同瀑布流水,逐級下落。

軟考難點—軟體開發模型(借鑒)
軟考難點—軟體開發模型(借鑒)
軟考難點—軟體開發模型(借鑒)

特點:在瀑布模型中,軟體開發的各項活動嚴格按照線性方式進行,目前活動接受上一項活動的工作結果影響,實施完成所需的工作内容。

缺點:1、各個階段的劃分完全固定,階段之間産生大量的文檔,極大地增加了工作量。

2、由于開發模型是線性的,使用者隻有等到整個過程的末期才能見到開發成果,進而增加了開發的風險。

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

二、增量模型

 定義:又稱演化模型。增量模型融合了瀑布模型的基本成分(重複應用)和原型實作的疊代特征,該模型采用随着日程時間的進展而交錯的線性序列,每一個線性序列産生軟體的一個可釋出的“增量”。

特點:當使用增量模型時,第一個增量往往是核心的産品,即第一個增量實作了基本的需求,但很多補充的特征還沒有釋出。客戶對每一個增量的使用和評估都作為下一個增量釋出的新特征和功能,這個過程在每一個增量釋出後不斷重複,知道産生了最終的完善産品。增量模型強調每一個增量均釋出一個可操作的産品。

軟考難點—軟體開發模型(借鑒)

優點:在增量模型中,軟體被作為一系列的增量建構來設計、實作、內建和測試,每一個構件是由多種互相作用的子產品所形成的提供特定功能的代碼片段構成。

整個産品被分解成若幹個構件,開發人員逐個構件地傳遞産品,這樣做的好處是軟體開發可以較好地适應變化,客戶可以不斷地看到所開發的軟體,進而降低開發風險。

 三、螺旋模型

定義:1988年,Barry Boehm正是發表了軟體系統開發的“螺旋模型”,它将瀑布模型和快速原型模型結合起來,強調了其他模型所忽視的風險分析,特别适合于大型複雜的系統。

疊代方式:螺旋模型沿着螺線進行若幹疊代。

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

2、風險分析:分析評估所選方案,考慮如何識别和消除風險。

3、實施工程:實施軟體開發和驗證。

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

軟考難點—軟體開發模型(借鑒)

優點:螺旋模型誇大風險闡發,使得開發職員以及使用者對每個演化層出現的風險有所了解,繼而做出應有的反應,是以特别适用于龐大、複雜并具備高風險的系統。

缺點:1、采用該模型需要具備相當豐富的風險評估經驗以及專門知識,在風險較大的項目開發中,如果沒有貨及時辨別風險,勢必造成重大損失。

2、過多的疊代回數會增長開發成本,延遲送出時間。

四、噴泉模型

定義:噴泉模型是一種以使用者需求為動力,以對象為驅動的模型,首先要用于描述面向對象的如阿健開發曆程。該模型認為軟體開發曆程自下而上周期的各階段是彼此重疊以及屢次反複的,就像水噴上去又可以落下來,近似一個噴泉。

特點:各開發階段沒有特定的次序要求,并且可以互動進行,可以再某個開發階段中随時增補其他不論什麼開發階段中的遺漏。噴泉模型與傳統的結構化生存期比較,具有更多的增量和疊代性質,而且在項目的整個生存期中還可以嵌入子生存期。

軟考難點—軟體開發模型(借鑒)

優點:是可以提高軟體項目開發效率,節省開發時間,順應于面向對象的軟體開發曆程。

缺點:由于噴泉模型在各個開發階段是重疊的,是以在開發曆程中需要大量的開發職員,是以失敗于項目的辦理。此外這種模型要求嚴格的辦理文檔,使得審查核定的困難程度加大,尤其是面臨可能随時插手各類資訊、需求與資料的情況。

五、原型模型——樣品模型

原型模式的主要思想:先借用已有系統作為原型模型,通過樣品不斷改進,使得最後的産品就是使用者所需要的。

原型模式通過向使用者提供原型擷取使用者的回報,使開發出的軟體能夠真正的反映使用者的需求。同時,原型模式采用逐漸求精的方法完善原型,使得原型能夠快速開發,避免了像瀑布模型一樣在冗長的開發過程中難以對使用者的回報做出快速的響應。相對瀑布模型而言,原型模式更符合人們開發軟體的習慣,是目前較為流行的一種實用軟體生存期模型。

特點:

1、開發人員和使用者在原型上達成一緻。這樣一來,可以減少設計中的錯誤和開發中的風險,也減少了對使用者教育訓練的時間,而提高了系統的實用、正确以及使用者的滿意程度。

2、縮短了開發周期,加快了工程進度。

3、降低成本。

缺點:當告訴使用者,還必須重新生産該産品時,使用者是很難接受的。這往往給工程繼續開展帶來不利因素。開發者為了使一個原型快速運作起來,往往在實作過程中采用這種手段。不易利用原型系統作為最終産品。采用原型模式開發系統,使用者和開發者必須達成一緻:原型被建造僅僅是使用者來定義需求,之後便部分或全部抛棄,最終的軟體是要充分考慮了品質和可維護性等方面之後才會被開發。

幾種模式的對比:

模型 優點 缺點
瀑布模型 文檔驅動 系統可能不滿足客戶的需求
快速原型模型 關注滿足客戶需求 可能導緻系統設計差、效率低,難于維護
增量模型 開發早期回報及時,易于維護 需要開放式體系結構,可能會設計差、效率低
螺旋模型 風險驅動 風險分析人員需要有經驗且經過充分訓練

繼續閱讀