標籤:軟體開發模型
軟體工程 -- 開發模型目錄
瀑布模式
螺旋模型
快速原型模式
增量模式
噴泉模型
演化模型
瀑布模式
特點:
階段間具有順序性和依賴性:
前一階段完成後,才能開始後一階段
前一階段的輸出文本為後一階段的輸入文本
延遲實現的觀點
品質保證:
缺點:
開始需要把需求做到最全
懼怕使用者測試中的反饋,懼怕需求變更
mux
650) this.width=650;" src="http://pic002.cnblogs.com/images/2012/387401/2012070519091925.jpg" style="border:0px;" />
螺旋模型
限制條件:
適應於內部的大規模軟體開發:螺旋模型強調風險分析,許多客戶都無法接受和相信這種分析因此
適合於大規模軟體項目(執行風險分析將大大影響項目的利潤,進行風險分析就毫無意義)
軟體開發人員應該擅長尋找可能的風險,準確地分析風險,否則將會帶來更大的風險
優點:
設計上的靈活性,可以在項目的各個階段進行變更.
以小的分段來構建大型系統,使成本計算變得簡單容易
客戶始終參為保證了項目不偏離正確方向以及項目的可控性
客戶始終掌握項目的最新資訊,從而他或她能夠和管理層有效地互動.
客戶認可這種公司內部的開發方式帶來的良好的溝通和高品質的產品.
缺點:
很難讓使用者確信這種演化方法的結果是可以控制的.建設周期長,而軟體技術發展比較快,所以經常出現軟體開發完畢後,和當前的技術水平有了較大的差距,無法滿足目前使用者需求.
核心:
在於您不需要在剛開始的時候就把所有事情都定義的清清楚楚.在定義最重要的功能時,去實現它,然後聽取客戶的意見,之後再進入到下一個階段.如此不斷輪迴重複,直到得到您滿意的最終產品
每輪迴圈包含如下六個步驟:
確定目標,可選項,以及強制條件
識別並化解風險
評估可選項
開發並測試當前階段
規划下一階段
確定進入下一階段的方法步驟.
模型:
650) this.width=650;" src="http://pic002.cnblogs.com/images/2012/387401/2012070608353465.png" style="border:0px;" />
快速原型模型
優缺點:
原型類型:
探索型原型: 目的是要型清使用者的需求,確定所期望的特性,並探索各種方案的可行性。它主要針對開發目標模糊,
實驗型原型: 主要用於設計階段,考核;實現方案是否合適,能否實陋
演化型原型: 主要用於及早向使用者提交一個原型系統,該原型系統或者包含系統的架構,或者包含系統的主要功能,在得到使用者的認可後,將原型系統不斷擴充演變為最終的軟體系統
原型的運用方式:
拋棄策略是將原型用於開發過程的某個階段,促使該階段的開發結果更加完整、準確、一致、可靠,該階段結束後,原型隨之作廢。探索型和實驗型就是採用此策略的。
附加策略是將原型用於開發的全過程,原型由最基本的核心開始,逐步增加新的功能和新的需求,反覆修改反覆擴充,最後發展為使用者滿意的最終系統,演化型快速原型就是採用此策略
模型:
650) this.width=650;" src="http://pic002.cnblogs.com/images/2012/387401/2012070608541115.jpg" style="border:0px;" />
增量模型
構件思想:
困難:
每個新的構件整合到現有的軟體結構中必須破壞原來以開發的產品,所以必須定義很好的介面
優點:
缺陷:
模型:
650) this.width=650;" src="http://pic002.cnblogs.com/images/2012/387401/2012070608542475.png" style="border:0px;" />
噴泉模型
優點:
噴泉模型不像瀑布模型那樣,需要分析活動結束後才開始設計活動,設計活動結束後才開始編碼活動.該模型的各個階段沒有明顯的界限,開發人員可以同步進行開發.其優點是可以提高軟體項目開發效率,節省開發時間,適應於物件導向的軟體開發過程.
缺點:
由於噴泉模型在各個開發階段是重疊的,因此在開發過程中需要大量的開發人員,因此不利於項目的管理.此外這種模型要求嚴格管理文檔,使得審核的難度加大,尤其是面對可能隨時加入各種資訊、需求與資料的情況.
模型:
650) this.width=650;" src="http://pic002.cnblogs.com/images/2012/387401/2012070609053663.jpg" style="border:0px;" />
演化模型
思想:
演化模型主要針對事先不能完整定義需求的軟體開發.使用者可以給出待開發系統的核心需求,並且當看到核心需求實現後,能夠有效地提出反饋,以支援系統的最終設計和實現
開發順序:
根據使用者的核心需求,設計,編碼,測試,後提交使用者
精化:根據以能滿足使用者核心需求的核心系統上,增加使用者反饋的其他全部功能
優點:
任何功能一經開發就能進入測試以便驗證是否符合產品需求
開發中的經驗教訓能反饋應用於本產品的下一個迴圈過程,大大提高品質與效率
開發中的經驗教訓能反饋應用於本產品的下一個迴圈過程,大大提高品質與效率
大大有助於早期建立產品開發的組態管理
缺點:
主要需求開始並不完全弄清楚的話,會給總體設計帶來困難及削弱產品設計的完整性,並因而影響產品效能的最佳化及產品的可維護性
缺乏嚴格過程管理的話,這生命週期模型很可能退化為“試-錯-改”模式
不加控制地讓使用者接觸開發中尚未測試穩定的功能,可能對開發人員及使用者都產生負面的影響