開發模型概述

瀑布模型 

概念

線性模型, 全部模型中佔重要地位, 是全部模型的基礎

圖示

測試階段處於軟件實現後, 必須在代碼完成後預留足夠的時間進行測試活動, 不然測試不充分, 不少問題到項目後纔會暴露

優缺

優勢

▨ 開發各個階段清晰

▨ 強調早期計劃以及需求調查

▨ 適合需求穩定的產品開發

缺點

▨ 依賴早期的需求調查, 不適應需求的變化

▨ 單一流程不可逆

▨ 風險延續到後期才暴露, 失去及早糾錯的機會

▨ 前面未發現問題傳遞擴散到後期階段, 可能致使項目失敗

改良

沿用瀑布模型的線性思想, 細化各個階段, 在某些重要關注階段之間摻入迭代思想

快速原型模型 - 敏捷性開發 

概念

在開發真實系統前, 構造原型, 在此基礎上逐步進行並完成整個系統的開發

圖示

第一步建造一個原型, 實現用戶與系統的交互嗎用戶對原型進行評價, 進一步細化對開發的需求,

經過逐步的調整原型使用戶知足, 開發人員能夠肯定用戶真正的需求是什麼

第二步是第一步的基礎上開發出用戶滿意的軟件產品

優缺

優勢

▨ 克服瀑布模型的缺點, 更好的知足用戶的需求

▨ 減小因爲需求不明確致使的項目開發風險

▨ 適合預先不能明確需求的軟件系統的開發

缺點

▨ 不適合大型的系統的開發 (適合小型,靈活性高的系統)

▨ 前提擁有一個展現型的產品原型

▨ 必定程度上限制開發人員的創新

螺旋模型

概念

將開發分紅幾個螺旋週期, 每一個週期大體和瀑布模型相似

螺旋模型按照螺旋線旋轉, 在座標的4個象限進行活動,  

圖示

螺旋模型是基於風險分析來進行的, 所以要求架構師

優缺

優勢

▨ 做爲一種風險驅動方法體系, 必需要對每一個階段常常發生的風險進行分析

▨ 架構師的存在能夠極大的減小這部分你的風險

缺點

▨ 需求經驗豐富的架構師

▨ 過多的迭代次數會增長開發成本, 延遲提交時間

V模型

概念

一個具有表明意義的測試模型, 做爲瀑布模型的變種, 標明測試過程自己存在的不一樣階段

從左到右描述了開發過程和測試過程階段性的對應關係  

圖示

▨ 需求分析 - 用戶需求, 業務需求, 需求規格說明書

▨ 概要設計 - 系統架構, 模塊劃分, 模塊和模塊之間的接口

▨ 詳細設計 - 模塊內部實現的邏輯和方法

▨ 編碼 - 實現上述設計

▨ 單元測試 - 檢測代碼開發是否符合詳細設計的要求

▨ 集成測試 - 檢測當前測試的組成部分是否可以完成並結合在一塊兒

▨ 系統測試 - 檢測已集成在一塊兒的產品是否符合規格說明書的要求

▨ 驗收測試 - 檢測產品是否符合最終用戶的需求, 以及迭代

優缺

優勢

▨ 包含底層測試以及高層測試

　　▨ 底層測試 : 檢驗源碼質量測試 - 單元測試

　　▨ 高層測試 : 檢驗整個系統的需求 - 系統測試

▨ 清楚的標識開發的階段

▨ 採用自上向下的逐步求精的方式將開發劃分不一樣階段, 每一個階段分工明確, 所以便於控制開發

缺點

▨ 測試階段較爲靠後, 以前問他產生修改不便

▨ 做爲瀑布模型的變種, 需求變化, 須要返工

W模型 - 雙V模型

概念

開發一個 V, 測試一個V組成 W 模型

測試伴隨着整個開發週期, 並且測試的對象不只僅是程序

需求以及設計一樣要測試

圖示

 

優缺

優勢

▨ 開發強調測試伴隨整個軟件開發週期

▨ 測試對象不只僅是程序, 需求和設計也要測試

▨ 更早的接入測試, 能夠發現開發初期的缺陷, 更低成本的進行缺陷修復

▨ 一樣分階段工做, 便於控制項目過程

缺點

▨ 代碼已經在測試以前, 不方便代碼的測試工做

▨ 對於當前不少項目, 執行過程當中不產生文檔, W模型沒法適用

▨ 使用起來複雜度高, 對於需求和設計的測試要求很高, 實踐起來困難 

H模型  - 瞭解便可

概念

 測試徹底獨立, 造成一個徹底的流程, 同時將測試轉唄和測試執行清晰表現出來

圖示

 

▨ 測試流程  

　　▨ 測試準備 - 全部的測試活動的準備, 判斷是否到測試就緒點

　　▨ 測試就緒點 - 測試准入準則, 及是否開始執行測試的條件

　　▨ 測試執行 - 具體的執行測試的程序

▨ 其餘流程 - 具體開發中的流程, 如: 設計流程

優缺

優勢

▨ 揭示軟件測試中除測試執行外, 還有不少工做

▨ 軟件測試徹底獨立, 貫穿整個生命週期, 與其餘流程併發執行

▨ 軟件測試活動能夠儘早準備, 儘早執行, 具有很強的靈活性

▨ 軟件測試能夠根據被測物的不一樣而分層次, 分階段, 分次序的執行

▨  可迭代

缺點 - 缺點較爲致命 

▨ 管理要求高

▨ 技能要求高

▨ 測試就休點分許困難

▨ 對整個項目組人員要求很是高