瀑布模式框架
特色:工具
- 階段間具備順序性和依賴性:
- 前一階段完成後,才能開始後一階段
- 前一階段的輸出作爲後一階段的輸入
- 推遲實現的觀點
- 質量保證:
缺點:性能
- 開始須要把需求作到最全
- 害怕用戶測試中的反饋,害怕需求變動
螺旋模型
限制條件:測試
- 適應於內部的大規模軟件開發:螺旋模型強調風險分析,許多客戶都沒法接受和相信這種分析所以
- 適合於大規模軟件項目(執行風險分析將大大影響項目的利潤,進行風險分析就毫無心義)
- 軟件開發人員應該擅長尋找可能的風險,準確地分析風險,不然將會帶來更大的風險
優勢:優化
- 設計上的靈活性,能夠在項目的各個階段進行變動.
- 以小的分段來構建大型系統,使成本計算變得簡單容易
- 客戶始終參爲保證了項目不偏離正確方向以及項目的可控性
- 客戶始終掌握項目的最新信息,從而他或她可以和管理層有效地交互.
- 客戶承認這種公司內部的開發方式帶來的良好的溝通和高質量的產品.
缺點:編碼
很難讓用戶確信這種演化方法的結果是能夠控制的.建設週期長,而軟件技術發展比較快,因此常常出現軟件開發完畢後,和當前的技術水平有了較大的差距,沒法知足當前用戶需求.設計
核心:對象
在於您不須要在剛開始的時候就把全部事情都定義的清清楚楚.在定義最重要的功能時,去實現它,而後聽取客戶的意見,以後再進入到下一個階段.如此不斷輪迴重複,直到獲得您滿意的最終產品blog
每輪循環包含以下六個步驟:接口
- 肯定目標,可選項,以及強制條件
- 識別並化解風險
- 評估可選項
- 開發並測試當前階段
- 規劃下一階段
- 肯定進入下一階段的方法步驟.
模型:
快速原型模型
優缺點:
- 優勢: 克服瀑布模型的缺點,減小因爲軟件需求不明確帶來的開發風險。
- 缺點: 所選用的開發技術和工具不必定符合主流的發展;快速創建起來的系統結構加上連續的修改可能會致使產品質量低下。
原型類型:
- 探索型原型: 目的是要型清用戶的需求,肯定所指望的特性,並探索各類方案的可行性。它主要針對開發目標模糊,
- 實驗型原型: 主要用於設計階段,考覈;實現方案是否合適,可否實陋
- 演化型原型: 主要用於及早向用戶提交一個原型系統,該原型系統或者包含系統的框架,或者包含系統的主要功能,在獲得用戶的承認後,將原型系統不斷擴充演變爲最終的軟件系統
原型的運用方式:
- 拋棄策略是將原型用於開發過程的某個階段,促使該階段的開發結果更加完整、準確、一致、可靠,該階段結束後,原型隨之做廢。探索型和實驗型就是採用此策略的。
- 附加策略是將原型用於開發的全過程,原型由最基本的核心開始,逐步增長新的功能和新的需求,反覆修改反覆擴充,最後發展爲用戶滿意的最終系統,演化型快速原型就是採用此策略
模型:
增量模型
構件思想:
- 第一構件完成軟件提供的基本最核心的功能
- 後面的增構件是爲了第一構件提供服務提供功能的
- 並且避免吧難題退後,首先完成的應該是高風險和重要部分
困難:
每一個新的構件集成到現有的軟件結構中必須破壞原來以開發的產品,因此必須定義很好的接口
優勢:
- 短期內向用戶提供可完成部分工做的產品
- 逐步增長產品功能可使用戶有時間瞭解和適應新產品
- 開放結構的軟件擁有的維護性明顯好於封閉結構的軟件
缺陷:
- 容易退化爲邊作邊改模型,從而使軟件過程的控制失去總體性
- 若是增量包之間存在相交的狀況且未很好處理,則必須作全盤系統分析
模型:
噴泉模型
優勢:
噴泉模型不像瀑布模型那樣,須要分析活動結束後纔開始設計活動,設計活動結束後纔開始編碼活動.該模型的各個階段沒有明顯的界限,開發人員能夠同步進行開發.其優勢是能夠提升軟件項目開發效率,節省開發時間,適應於面向對象的軟件開發過程.
缺點:
因爲噴泉模型在各個開發階段是重疊的,所以在開發過程當中須要大量的開發人員,所以不利於項目的管理.此外這種模型要求嚴格管理文檔,使得審覈的難度加大,尤爲是面對可能隨時加入各類信息、需求與資料的狀況.
模型:
演化模型
思想:
演化模型主要針對事先不能完整定義需求的軟件開發.用戶能夠給出待開發系統的核心需求,而且當看到核心需求實現後,可以有效地提出反饋,以支持系統的最終設計和實現
開發順序:
- 根據用戶的核心需求,設計,編碼,測試,後提交用戶
- 精化:根據以能知足用戶核心需求的核心繫統上,增長用戶反饋的其餘所有功能
優勢:
- 任何功能一經開發就能進入測試以便驗證是否符合產品需求
- 開發中的經驗教訓能反饋應用於本產品的下一個循環過程,大大提升質量與效率
- 開發中的經驗教訓能反饋應用於本產品的下一個循環過程,大大提升質量與效率
- 大大有助於早期創建產品開發的配置管理
缺點:
- 主要需求開始並不徹底弄清楚的話,會給整體設計帶來困難及削弱產品設計的完整性,並於是影響產品性能的優化及產品的可維護性
- 缺少嚴格過程管理的話,這生命週期模型極可能退化爲「試-錯-改」模式
- 不加控制地讓用戶接觸開發中還沒有測試穩定的功能,可能對開發人員及用戶都產生負面的影響