軟體工程五大模型
瀑布模型
1.里程碑或基線驅動。2.過程逆轉性很差或者說不可逆轉。逆轉可能會延誤工期,增加成本,造成損失
1.開發階段清晰,便於評審、審計、跟蹤、管理和控制。
1.不可逆或很難可逆。2.問題會積累,錯誤會傳遞發散擴大,導致成本和質量失控。
1.在開發時間內需求不變化或很少變化。2.分析設計人員對此領域非常熟悉。3.低風險專案。4.使用者使用環境穩定(如系統軟體,工具軟體)
快速原型模型
1.容易適應需求的變化
1.克服瀑布模型的缺點,減少由於軟體需求不明確帶來的開發風險。
1.所使用的開發工具和技術不一定符合主流的發展;快速建立起來的系統架構加上連續的修改可能會導致產品質量低下。
1.需求不明確或複雜系統。2.使用者無法自主提出應用需求。
增量模型
1.軟體由一系列增量構件組成
1.人員分配靈活,剛開始不用投入大量人力資源。如果核心產品很受歡迎,則可增加人力實現下一個增量。當配備人員不能在設定的時間內完成產品時,它提供了一種先推進核心產品的途徑,這樣即可先發部分功能給客戶,對客戶起到鎮靜劑作用。2.增量能夠有計劃的管理技術風險。
1.由於各個構件是逐漸併入已有的軟體體系結構中,所以加入構件必須不破壞已構造好的系統部分,這需要軟體具備開放式的體系結構。2.在開發過程中,需求變化是不可避免的,增量的靈活性可以使其適應這種變化的能力大大優於瀑布和快速原型模型,但也容易退化為邊改邊做模型,從而使軟體過程的控制失去整體性。3.如果增量包之間存在相交的情況且未很好處理,則必須做全盤系統分析,這種模型將功能細化後分別開發的方法較適應於需求經常改變的軟體開發過程
1.系統容易拆分。2.開發人力比較少。3.特別適用於商業軟體(如QQ,網遊)
螺旋模型
1.是一種週期性的方法進行系統開發。2.有許多“中間版本”。3.每個週期都包括需求定義、風險分析、工程實現和評審4個階段
1.設計上靈活,可在專案各個階段進行變更。2.以小的分段來構建大型系統,使成本計算變得簡單容易。3.客戶始終參與每個階段的開發,保證了專案不偏離正確方向以及專案的可控性。
1.建設週期長,而軟體技術更新比較快,所以經常出現軟體開發結束後,和當前的技術水平有了很大的差距,無法滿足當前使用者需求。
1.系統龐大,風險高。2.需求不太明確。
噴泉模型
1.該模型的各個階段沒有明顯的界限,開發人員可以同步進行開發。
1.提高軟體專案開發效率,節省開發時間,適用於面向物件的軟體開發過程。
1.由於噴泉模型在各個開發階段是重疊的,因此在開發過程中需要大量的開發人員,因此不利於專案的管理。2.要求嚴格管理文件,使得稽核難度加大,尤其是面對可能隨時加入的各種資訊、需求與資料的情況。
1.面向物件的軟體開發過程
詳細介紹如下:
瀑布模式
特點:
- 階段間具有順序性和依賴性:
- 前一階段完成後,才能開始後一階段
- 前一階段的輸出文字為後一階段的輸入文字
- 推遲實現的觀點
- 質量保證:
- 每個階段必須交付出合格的文件
- 對文件進行稽核
缺點:
- 開始需要把需求做到最全
- 懼怕使用者測試中的反饋,懼怕需求變更
- mux
螺旋模型
限制條件:
- 適應於內部的大規模軟體開發:螺旋模型強調風險分析,許多客戶都無法接受和相信這種分析因此
- 適合於大規模軟體專案(執行風險分析將大大影響專案的利潤,進行風險分析就毫無意義)
- 軟體開發人員應該擅長尋找可能的風險,準確地分析風險,否則將會帶來更大的風險
優點:
- 設計上的靈活性,可以在專案的各個階段進行變更.
- 以小的分段來構建大型系統,使成本計算變得簡單容易
- 客戶始終參為保證了專案不偏離正確方向以及專案的可控性
- 客戶始終掌握專案的最新資訊,從而他或她能夠和管理層有效地互動.
- 客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品.
缺點:
很難讓使用者確信這種演化方法的結果是可以控制的.建設週期長,而軟體技術發展比較快,所以經常出現軟體開發完畢後,和當前的技術水平有了較大的差距,無法滿足當前使用者需求.
核心:
在於您不需要在剛開始的時候就把所有事情都定義的清清楚楚.在定義最重要的功能時,去實現它,然後聽取客戶的意見,之後再進入到下一個階段.如此不斷輪迴重複,直到得到您滿意的最終產品
每輪迴圈包含如下六個步驟:
- 確定目標,可選項,以及強制條件
- 識別並化解風險
- 評估可選項
- 開發並測試當前階段
- 規劃下一階段
- 確定進入下一階段的方法步驟.
模型:
快速原型模型
優缺點:
- 優點: 克服瀑布模型的缺點,減少由於軟體需求不明確帶來的開發風險。
- 缺點: 所選用的開發技術和工具不一定符合主流的發展;快速建立起來的系統結構加上連續的修改可能會導致產品質量低下。
原型型別:
- 探索型原型: 目的是要型清使用者的需求,確定所期望的特性,並探索各種方案的可行性。它主要針對開發目標模糊,
- 實驗型原型: 主要用於設計階段,考核;實現方案是否合適,能否實陋
- 演化型原型: 主要用於及早向用戶提交一個原型系統,該原型系統或者包含系統的框架,或者包含系統的主要功能,在得到使用者的認可後,將原型系統不斷擴充演變為最終的軟體系統
原型的運用方式:
- 拋棄策略是將原型用於開發過程的某個階段,促使該階段的開發結果更加完整、準確、一致、可靠,該階段結束後,原型隨之作廢。探索型和實驗型就是採用此策略的。
- 附加策略是將原型用於開發的全過程,原型由最基本的核心開始,逐步增加新的功能和新的需求,反覆修改反覆擴充,最後發展為使用者滿意的最終系統,演化型快速原型就是採用此策略
模型:
增量模型
構件思想:
- 第一構件完成軟體提供的基本最核心的功能
- 後面的增構件是為了第一構件提供服務提供功能的
- 而且避免吧難題退後,首先完成的應該是高風險和重要部分
困難:
每個新的構件整合到現有的軟體結構中必須破壞原來以開發的產品,所以必須定義很好的介面
優點:
- 短時間內向使用者提供可完成部分工作的產品
- 逐步增加產品功能可以使使用者有時間瞭解和適應新產品
- 開放結構的軟體擁有的維護性明顯好於封閉結構的軟體
缺陷:
- 容易退化為邊做邊改模型,從而使軟體過程的控制失去整體性
- 如果增量包之間存在相交的情況且未很好處理,則必須做全盤系統分析
模型:
噴泉模型
優點:
噴泉模型不像瀑布模型那樣,需要分析活動結束後才開始設計活動,設計活動結束後才開始編碼活動.該模型的各個階段沒有明顯的界限,開發人員可以同步進行開發.其優點是可以提高軟體專案開發效率,節省開發時間,適應於面向物件的軟體開發過程.
缺點:
由於噴泉模型在各個開發階段是重疊的,因此在開發過程中需要大量的開發人員,因此不利於專案的管理.此外這種模型要求嚴格管理文件,使得稽核的難度加大,尤其是面對可能隨時加入各種資訊、需求與資料的情況.
模型:
演化模型
思想:
演化模型主要針對事先不能完整定義需求的軟體開發.使用者可以給出待開發系統的核心需求,並且當看到核心需求實現後,能夠有效地提出反饋,以支援系統的最終設計和實現
開發順序:
- 根據使用者的核心需求,設計,編碼,測試,後提交使用者
- 精化:根據以能滿足使用者核心需求的核心繫統上,增加使用者反饋的其他全部功能
優點:
- 任何功能一經開發就能進入測試以便驗證是否符合產品需求
- 開發中的經驗教訓能反饋應用於本產品的下一個迴圈過程,大大提高質量與效率
- 開發中的經驗教訓能反饋應用於本產品的下一個迴圈過程,大大提高質量與效率
- 大大有助於早期建立產品開發的配置管理
缺點:
- 主要需求開始並不完全弄清楚的話,會給總體設計帶來困難及削弱產品設計的完整性,並因而影響產品效能的優化及產品的可維護性
- 缺乏嚴格過程管理的話,這生命週期模型很可能退化為“試-錯-改”模式
- 不加控制地讓使用者接觸開發中尚未測試穩定的功能,可能對開發人員及使用者都產生負面的影響