軟件生命周期模型

 模型：定義了生命周期中要做的各項工作的規范和順序。

瀑布模型

 

重點環節：

1、需求分析：需求規格文檔

 

2、總體設計：概要設計文檔

 

3、詳細設計：詳細設計文檔

 

4、編碼：寫代碼

 

5、測試：在編碼完成后進行

優點：順序清晰

缺點：

1、由於開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發風險

2、如果軟件規模大，需求難以一次到位

V 模型

 

實現：順序

測試：階段划分

單元測試：測試單模塊代碼（開發做）

 

集成測試：測模塊間的接口

 

系統測試：測試整體的系統

 

驗收測試：用戶參與的測試

 

項目驗收測試：客戶驗收項目

產品驗收測試：

阿爾法（α）測試：可控(公司內部)

貝塔（β）測試：不可控（公司外部的用戶進行公測）

實現意義

V模型是軟件開發瀑布模型的變種，它反映了測試活動與分析和設計的關系 。

從左到右，描述了基本的開發過程和測試行為，非常明確地標明了測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關系 。

左邊依次下降的是開發過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。

用戶需求 驗收測試

需求分析和系統設計 確認測試和系統測試

概要設計 集成測試

詳細設計 單元測試

編碼

V模型問題

1.測試是開發之后的一個階段。

2.測試的對象就是程序本身。

3.實際應用中容易導致需求階段的錯誤一直到最后系統測試階段才被發現。

4.整個軟件產品的過程質量保證完全依賴於開發人員的能力和對工作的責任心，而且上一步的結果必須是充分和正確的，如果任何一個環節出了問題，則必將嚴重的影響整個工程的質量和預期進度。

雙V模型W 模型

 

W模型由Evolutif公司提出，相對於V模型，W模型增加了軟件各開發階段中應同步進行的驗證和確認活動。W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關系。 W模型強調：測試伴隨着整個軟件開發周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利於盡早地全面的發現問題。例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利於及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。 但W模型也存在局限性。在W模型中，需求、設計、編碼等活動被視為串行的，同時，測試和開發活動也保持着一種線性的前后關系，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發模型。對於當前軟件開發復雜多變的情況，W模型並不能解除測試管理面臨着困惑。

H模型

H模型中， 軟件測試過程活動完全獨立，貫穿於整個產品的周期，與其他流程並發地進行，某個測試點准備就緒時，就可以從測試准備階段進行到測試執行階段。軟件測試可以盡早的進行，並且可以根據被測物的不同而分層次進行。

 

這個示意圖演示了在整個生產周期中某個層次上的一次測試“微循環”。圖中標注的其它流程可以是任意的開發流程，例如設計流程或者編碼流程。也就是說， 只要測試條件成熟了，測試准備活動完成了，測試執行活動就可以進行了。

H模型揭示了一個原理：軟件測試是一個獨立的流程，貫穿產品整個生命周期，與其他流程並發地進行。H模型指出軟件測試要盡早准備， 盡早執行。不同的測試活動可以是按照某個次序先后進行的，但也可能是反復的，只要某個測試達到准備就緒點，測試執行活動就可以開展。

X模型

X模型也是對V模型的改進，X模型提出針對單獨的程序片段進行相互分離的編碼和測試，此后通過頻繁的交接，通過集成最終合成為可執行的程序。X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終成為可執行的程序，然后再對這些可執行程序進行測試。已通過集成測試的成品可以進行封裝並提交給用戶，也可以作為更大規模和范圍內集成的一部分。多根並行的曲線表示變更可以在各個部分發生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計划的特殊類型的測試，這一方式往往能幫助有經驗的測試人員在測試計划之外發現更多的軟件錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。

 

 

 

敏捷開發模型

在瀑布開發模式的基礎上進行了改進，最新從國外傳播入國內，它還沒有成熟，很多的開發團隊都處於實踐、探索的階段。

概念

簡單的說，敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。

特點

敏捷最大的特色是迭代式開發。

敏捷開發最主要的特點就是：以人為核心、循序漸進。不再是非常詳細的文檔的編寫，強調人與人面對面的交流;把一個項目分成許多的周期，每個周期都有自己需要完成的任務，並且是一定要完成。

管理工具

teambition

模型圖

 

1、我們首先需要確定一個Product Backlog（產品需求列表），這個是由PO負責的；

2、有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計划會議） 來從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間周期是1~4個星期，然后把這個Story進行細化，形成一個Sprint Backlog；

3、Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；

4、在Scrum Team完成計划會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鍾左右，每個人都必須發言，並且要向所有成員當面匯報你昨天完成了什么，並且向所有成員承諾你今天要完成什么，同時遇到不能解決的問題也可以提出，每個人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）；

5、做到每日集成，也就是每天都要有一個可以成功編譯、並且可以演示的版本。

6、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老板也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產品。

7、最后就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；

流程圖

 

 

流程上主要是以下七點：

　　1、詳細的產品需求列表，排定優先級，這些便需要產品經理來完成的工作，同時一般會有研發、UI、運營等人的配合;

　　2、工作量的評估：這一項需要技術人員的支持，同時也需要產品經理，內容就是溝通各方面的資源、權衡技術難度，制定詳細的規划;

　　3、計划會議：這里是迭代的目標以及時間，同時把每一個大的任務細化到每個小任務——2、3天完成;

　　4、站立會議：每日開站立會議，每個人說明自己昨天完成了什么任務，今天要做什么，把已經完成的任務從未完成區域放在燃盡圖的已完成區域;

　　5、做到每日集成，每天都有一個成功編譯、並且可以演示的版本;

　　6、當一次迭代完成的時候，組織演示會議，也叫評審會議，邀請部門經理等管理者參加;

　　7、總結：輪流發言、討論需要改進的地方，放入下一輪產品的需求中。

優缺點

優點：　　

1、迭代快，開發周期短;

　　2、不再耗費大量的時間來寫文檔，而是人與人面對面交流，只寫一些必要的文檔;

　　3、分工詳細，每天都輸出成果，客戶能夠看得到，會信任項目團隊;

　　4、溝通多，容易發現問題，同時能夠激起團隊的協作、奮斗精神;

缺點：

　　1、人與人之間的信任是非常重要的環節，但是這個比較難完成，技術團隊的成員可能技術能力差別大，同時也有互相競爭，又或者是項目團隊的成員有所保留，不願意這樣的溝通;

　　2、團隊在開發期間的任務多、壓力大，需要時刻保持“興奮”，一般很難做到。