軟件工程概論 6- 統一過程與敏捷過程學習課件_第1頁
軟件工程概論 6- 統一過程與敏捷過程學習課件_第2頁
軟件工程概論 6- 統一過程與敏捷過程學習課件_第3頁
軟件工程概論 6- 統一過程與敏捷過程學習課件_第4頁
軟件工程概論 6- 統一過程與敏捷過程學習課件_第5頁
已閱讀5頁,還剩27頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

哈爾濱工業大學軟件學院第6章統一過程與敏捷過程楊大易2015/12/30本章內容6.1統一過程6.2敏捷過程6.3極限編程6.4Scrum6.5本章小結6.6思考問題哈爾濱工業大學軟件學院16.1統一過程

軟件開發方法的演進哈爾濱工業大學軟件學院26.1統一過程

RUP過程的二維表示

橫軸表示時間:劃分為階段和迭代

縱軸表示過程組件:開發各階段的任務

時間軸:4個順序階段

初始階段(Inception)

細化階段(Elaboration)

構造階段(Construction)

交付階段(Transition)

每個階段又分為若干個迭代(Iteration)哈爾濱工業大學軟件學院36.1統一過程

過程組件軸:9個工作流

核心過程工作流??????業務建模(BusinessModeling)需求(Requirement)分析與設計(Analysis&Design)實現(Implementation)測試(Test)部署(Deployment)

核心支持工作流?項目管理(ProjectManagement)?配置和變更管理(ConfigurationandChangeManagement)?環境(Environment)哈爾濱工業大學軟件學院46.1統一過程

統一過程(RUP:RationalUnifiedProcess)哈爾濱工業大學軟件學院56.1統一過程

統一過程提供了在開發組織中分派任務和責任的紀律化方法;

統一過程目標是在可預見的日程和預算前提下,確保滿足最終用戶需求的高質量產品;

統一過程模型是一種用例驅動,以體系結構為核心,迭代及增量的軟件過程框架,由UML方法和工具支持。統一過程模型與瀑布模型、原型模型和增量模型等相比有哪些差異?哈爾濱工業大學軟件學院66.2敏捷過程

提出敏捷過程的背景

許多公司軟件團隊陷入了不斷增長的過程泥潭

為矯正某些官僚煩瑣的軟件過程

2001年2月,17個方法學家達成一致并發起成立敏捷軟件開發聯盟

軟件開發宣言

軟件團隊具有快速工作、快速響應變化的能力

4條基本價值觀+12條原則哈爾濱工業大學軟件學院76.2敏捷過程

敏捷宣言的價值觀敏捷軟件開發宣言我們正在通過親身實踐以及幫助他人實踐,揭示更好的軟件開發方法。通過這項工作,我們認為:個體和交互可以工作的軟件客戶合作響應變化勝過勝過勝過勝過過程和工具面面俱到的文檔合同談判遵循計劃雖然右項也具有價值,但我們認為左項具有更大的價值。KentBeckMikeBeedleArieVanBennekumAlistairCockburnWardCunninghamMartinFowlerJamesGrenningJimHighsmithAndrewHuntRonJeffriesJonKernBrianMarickRobertC.MartinSteveMellorKenSchwaberJeffSutherlandDaveThomas哈爾濱工業大學軟件學院86.2敏捷過程(1)個體和交互勝過過程和工具

人是軟件項目獲得成功最為重要的因素;

合作、溝通以及交互能力要比單純的軟件編程能力更為重要。(2)可以工作的軟件勝過面面俱到的文檔

軟件開發的主要目標:交付給用戶可以工作的軟件而不是文檔;

軟件開發的主要和中心活動是創建可以工作的軟件,直到迫切需要并且意義重大時,才進行文檔編制。哈爾濱工業大學軟件學院96.2敏捷過程(3)客戶合作勝過合同談判

客戶不可能做到一次性地將他們的需求完整清晰地表述在合同當中;

開發團隊與客戶緊密協作,為開發團隊和客戶的協同工作方式提供指導的合同是最好的合同。(4)響應變化勝過遵循計劃

變化是軟件開發中存在的現實;

響應變化的有效途徑之一是制定靈活可塑的計劃。敏捷過程中的哪些做法與傳統軟件工程觀念不同?哈爾濱工業大學軟件學院106.2敏捷過程

敏捷開發的12條原則(1)最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意;(2)即使到了開發的后期,也歡迎改變需求,敏捷過程利用變化來為客戶創造競爭優勢;(3)經常性交付可以工作的軟件,交付的間隔可以從幾個星期到幾個月,交付的時間間隔越短越好;(4)在整個項目開發期間,商務人員和開發人員必須天天都工作在一起;(5)圍繞被激勵起來的個體來構建項目,給他們提供所需的環境和支持,并且信任他們能夠完成工作;哈爾濱工業大學軟件學院116.2敏捷過程(6)在團隊內部,最具有效果并且富有效率的傳遞信息的方法,就是面對面的交談;(7)工作的軟件是首要的進度度量標準;(8)敏捷過程提倡可持續的開發速度,責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度;(9)不斷關注優秀設計技能和好的設計會增強敏捷能力;(10)簡單:使未完成的工作最大化的藝術是根本的;(11)最好的構架、需求和設計出自于自組織的團隊;(12)每隔一定時間,團隊會在如何才能更有效地工作方面進行反省,然后相應地對自己的行為進行調整。哈爾濱工業大學軟件學院126.2敏捷過程

統一過程與敏捷過程

統一過程:提供的是理想開發環境下軟件過程的一種完整且完美的模式。

敏捷過程:針對商業環境下通常具有有限資源和有限時間約束的小型項目提出了一些獨具特色的、操作性較強的解決方案。

敏捷過程在人員、方法、產品等方面的論述遠不及統一過程全面詳細。

敏捷過程可作為對統一過程的補充和完善。哈爾濱工業大學軟件學院136.3極限編程

極限編程(XP:ExtremeProgramming)

一個輕量級的、靈巧的敏捷開發方法;

大部分實踐與敏捷過程的價值觀和原則一致,并對敏捷過程進一步發展和補充,如結對編程、隱喻等。

極限編程過程哈爾濱工業大學軟件學院146.3極限編程

極限編程的四個價值目標

溝通:敏捷方法采用了一些實踐來強制溝通,如結對編程、策劃游戲、驗收測試等;

簡單:今天做的簡單一些,然后明天需要時再花些時間進行改進,比今天做的復雜但以后再也用不到要好。

反饋:加強與用戶的反饋,反饋越多,溝通越容易。

勇氣:快速的進入開發階段,并在必要時果斷對系統進行重構。哈爾濱工業大學軟件學院156.3極限編程

極限編程的實踐要點(1)結對編程:由兩個開發人員在同一臺電腦上共同編寫解決同一問題的代碼,通常一個人負責編碼,而另一個負責保證代碼的正確性與可讀性;(2)客戶作為團隊成員:要求至少有一名實際的客戶代表在整個項目開發周期和團隊開發人員在一起緊密地工作;(3)短交付周期:每兩周交付一次可以工作的軟件;(4)測試驅動開發:在編碼開始之前,首先將測試寫好,而后再進行編碼,直至所有測試都得以通過;(5)集體所有權:開發小組的每個成員都有更改代碼的權利,所有的人對于全部代碼負責;哈爾濱工業大學軟件學院166.3極限編程(6)可持續的開發速度:開發人員每周工作時間不超過40小時,加班不得連續超過兩周,否則反而會影響生產率;(7)開放的工作空間:項目的所有參與者(開發人員、測試人員、客戶等)一起工作在一個開放的場所中;(8)簡單的設計:設計恰好與計劃在本次迭代中要完成的用戶素材相匹配,不考慮未來的用戶素材;(9)重構:重新調整、優化系統結構以減少復雜性、消除冗余、增加靈活性和提高性能;(10)隱喻:整個系統聯系在一起的全局視圖、系統的未來影像,描述系統如何運作、新的功能以何種方式加入到系統。哈爾濱工業大學軟件學院176.4Scrum

Scrum基本假設

開發軟件就像是開發新產品,無法一開始就能定義最終產品的規程,過程中需要研發、創意、嘗試錯誤,所以沒有一種固定的流程可以保證項目成功。

Scrum將軟件開發團隊比擬成橄欖球隊

有明確的最高目標

熟悉開發流程中所需具備的最佳典范與技術

具有高度自主權,緊密地溝通合作

以高度彈性解決各種挑戰

確保每天、每個階段都朝向目標有明確的推進哈爾濱工業大學軟件學院186.4Scrum

Scrum團隊

7人組成。團隊不止是一個程序員隊伍,它由各種背景下的不同角色組合而成,包括商業分析者,設計師,程序員和測試者等。

ProductOwner:負責最大化項目投資回報。領導團隊估算ProductBacklog,對UserStories/requirements具有最終的權力。

ScrumMaster:幫助ProductOwner選擇最優價值的ProductBacklog,確保Scrum實踐得到執行,最大化團隊的生產率。哈爾濱工業大學軟件學院196.4Scrum

Scrum過程哈爾濱工業大學軟件學院206.4Scrum

Scrum任務劃分

ProductBacklog:具有優先級的需求列表,并對每個需求進行了粗略的估算。ProductBacklog是不斷完善優化的。

SprintBacklog:細化高優先級任務,任務分解不超過16小時。哈爾濱工業大學軟件學院216.4Scrum

Sprint策劃會議

限時8小時,分成2部分,各4個小時

第一部分,挑選ProdectBacklog

第二部分,準備SprintBacklog

產品負責人要提前在會議前準備好產品Backlog

團隊可提出建議,但是由ProductOwner制定ProductBacklog

團隊負責從Productowner制定的ProductBacklog中挑選出期望在當前Sprint內完成的工作哈爾濱工業大學軟件學院226.4Scrum

Sprint策劃會議:第一部分

挑選增量ProductBacklog

確定ProductBacklog的工作量和優先級

成員一致認可Sprint目標和ProductBacklog

Sprint策劃會議:第二部分

團隊成員將選定ProductBacklog細分

制定SprintBacklog,包括任務、任務估計、任務分工哈爾濱工業大學軟件學院236.4Scrum

Sprint運行

Sprint周期內開發可交付的產品

Sprint內包括設計、編碼、測試、編寫文檔等工作

在Sprint期間其他人不可向團隊下達通知、指令、評論和方向指示,團隊完全進行自我管理

一旦Sprint開始了,只能由Scrum團隊增加或刪除SprintBacklog中的任務

團隊成員每日參加Scrum會議哈爾濱工業大學軟件學院246.4Scrum

每日Scrum會議

限時15分鐘

每日早晨,同一地點

站立會議

所有成員必須參加

成員必須準時,否則懲罰

每個人給全體成員匯報工作進展

同步進展而不是解決問題哈爾濱工業大學軟件學院256.4Scrum

Scrum看板哈爾濱工業大學軟件學院266.4Scrum

燃盡圖哈爾濱工業大學軟件學院276.4Scrum

Sprint評審

限時4小時

團隊向ProductOwner及其他利益相關者展示本次sprint完成的功能

不展示未完成的功能,不展示技術文檔

演示結束后調查利益相關者意見,記錄他們的意見、期望的變更等

基于反饋調整Backlog

可以在Sprint結束后確定是否還要繼續本產品的開發

不需要用ppt哈爾濱工業大學軟件學院286.4Scrum

Sprint回顧

限定在

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論