軟體工程之版本控制

1. 軟體工程之版本控制 Tribute

2. 今日主題 • 版本控制 • -----中場休息-------- • 軟體工程系統架構簡述 • -----中場休息-------- • 簡述CMMI Overview

3. 開始之前 • 問題一： • 我為什麼要聽這一場?( 被HaWay騙來) • 被課程名稱”騙”來(吸引我來上這門課) • 程式開發工作是不是遇到問題、瓶頸？ • 程式開發工作是不是沒有什麼效率？想提升效率而來？其他原因？ • 想在現在的環境中突破(留下來/離開)

4. 問題二： • 聽完這場後，我希望我能從中獲得什麼？ • 職場不是畜牧業，請不要用”飼料雞”的方式教育、學習。 • 聽完這門課程後，我們可不可以了解”工具”的真正 用意/用途。 • “軟體工程”是一條辛苦又漫長的道路。如何做到”學習愉快”、”知識/經驗/$$進袋”？ • 導入”版本控制”後，請記得做持續執行評估、追蹤。

5. 結束暖身:我們正式開始 • 我們以一個簡單的圖示來了解”傳統式”與”現在式”(指導入軟體工程流程)的工作型態的比較(見下圖)

6. 是不是一樣多呢?排列整齊的那一邊比較好計算呢?是不是一樣多呢?排列整齊的那一邊比較好計算呢? • 用上面的圖示來說明工作性質形態，我們很清楚的知道排列整齊的那一邊比較好計算。 • 但是仍然有80%的人，他的工作形態是屬較雜亂、不好計算的那一邊的。 • 為什麼要整理(流程化)？為什麼要管理？ • 「記得有一本書提到說：整理的目的，是為了方便日後的尋找，以避免日後事情急迫時，我們能從容的找尋、取得我們要的東西。而管理的目的，是為了讓所執行的過程、動作能更效率。」

7. 80：20 法則(柏雷多法則原理) 想想看，你是屬於那一類80/20?

8. 「艾森豪」法則 • 美國社懷特，艾森豪將軍指出，人們的精力，往往被緊急但較不重要的事情所佔用，而並未完全或儘可能的將時間與精力用在重要的事。 • 「艾森豪」法則演繹啟示：留多一點時間給重要的事情。

9. 「艾森豪」法則規劃矩陣

10. 60：20：20彈性原則

12. 協助瞭解：版本控制的意義 • 為什麼要做版本控制？(效率提升…等) • 與別人在同樣環境條件下一起競爭，你要怎麼比別人更具競爭優勢？(想要活著，就得先了解死亡) • 何時、何地(環境條件)要做版本控制？

13. Build any Version • Configuration Builder working with Version Manager can build any version PROD 1.3 1.2 1.1 1.0 1.3 1.2 1.1 1.0 1.3 1.2 1.1 1.0 1.3 1.2 1.1 1.0 1.3 1.2 1.1 1.0 1.3 1.2 1.1 1.0 BETA ALPHA BASE test.h foo.c io.c foo.h io.h test.c

14. RELEASE 2.0 1.7 1.6 1.5 1.5 1.4 1.4 1.4 RELEASE 1.5 1.3 1.3 RELEASE 1.0 1.2 1.2 1.1 1.1 Organise: Version Management 1.3 1.2 1.2 1.1 1.1 1.0 1.0 1.0 1.0 C.I. 1 C.I. 2 C.I. 3 C.I. X

15. 範例 • 範例一： 「以H開頭y結尾先生為例 (multi-girl friend process) 解釋單人多工版本控制」 • 範例二： 「以我的”遺書”為例 解釋版本控制與工作交接的關係」

16. 休息一下

17. 給予資訊：軟體工程系統架構 • 軟體工程系統架構組成的元件有那些? • 80/20 ：每一個最小單位投入比，可達最佳的產能比。 • 如何針對每個Project 去做適合的目標設定？ • 提供”方法”而不是”答案”；提供”釣竿”而不是”漁獲”。

18. SW完整的建構管理解決方案 • 交付管理 • Release • Management • (VM + CB) 版本管理 Version Management (Version Manager) SW CM • 建置管理 • Build • Management • (Configuration Builder) 變更管理 Issue Management (Tracker)

19. Oracle, Sybase, etc. Tracker (Issue management) SW CM Process Overview Version Manager (Version control, Release management) Configuration Builder (Build scripting tool)

20. 1 3 Trent reports describe changes in issue field values over time. ModulesReports describe which issues are related to which source files. 2 4 DistributionReports describe Categories of issues in terms of the percentage they represent of a specified group Of issues. PVCS Metrics is an application shipped with PVCS Tracker which facilitates reporting data on the web. 5 This feature in administrator tool generates custom view of the database according to SQL Statement. Report Assistant Tracker Report

21. Workflow Overview • Defects • Change Requests Review and Assign by Manager Submit by tester Solve by Developer Verify by QA Notify Notify Notify Discovery Investigation Resolution Verification (Submit SCR) (Update SCR) (Update SCR) (Update SCR) • Automate Workflow • Keep track of status • Produce report Decision Making and Process Improvement Reports

22. 軟體工程建構管理相關之問題 • 版本管理問題： • 目前系統有那些項目？ • 版本狀況？修改記錄？ • 存取管制？同時修改？ • 系統版本管理問題： • 系統交付版本記錄？ • 組成項目與版本狀況？ • 問題追蹤與管理問題： • 問題處理狀況追蹤與管制？ • 相關人員主動通知？ • 無法產生圖表了解產品品質狀況？ • 無法追溯問題修改之程式及版本？ • 系統組態建置(Build)問題： • 無法Build正確的系統版本？

23. 阿迪茲雙S職涯黃全規劃曲線(見下圖)

24. 休息一下

25. 簡述CMMI Overview • 軟體開發能力評鑑 • CMM與CMMI的一些差異 • CMMI是壓垮軟體工業的最後一根稻草嗎? • CMMI沒有人性，雞排工程師的哀歌

26. Outline • CMM brief • Process is the focus • 5 Maturity Levels • Assessment

27. 什麼是CMM • CMM: 能力成熟度模型 (Capability Maturity Model) • CMM vs. ISO 9000 • Kinds of CMM • SW-CMM: for Software Organization • SE-CMM: for System Engineering Organization • IPD-CMM: for Integrated Product Development • CMMI: Integration of SW/SE/IPPD • P-CMM: for human asset in IT • …

28. CMM的演變 • 二十幾年來,美國很多政府機構和公司都發現很多買來的軟體無法符合他們的需求而且無法掌握品質 • 1984年, CMU (Carnegie Mellon University)在美國國防部的支持下成立了SEI (Software Engineering Institute) • 1986年, SEI 開始制訂一套標準用來幫助軟體公司改善軟體流程; 1991年, SW-CMM v1.0問世 • 1993年, SW-CMM v1.1問世, 成為世界上應用最廣泛的CMM • 2000年, SEI 將SW-CMM, EIA 731 (from SE-CMM), IPD-CMM整合為CMMI

29. CMM的用途 • 評價組織與流程的能力與成熟度所用的基準 • 提昇組織與流程的能力與成熟度所用的進程

30. 5 Maturity Levels in CMMI • Initial • Managed • Defined • Quantitatively Managed • Optimizing

31. Process Improvement Focus

32. Level 1 (Initial)的特徵 • 沒有流程或是流程的穩定性很差，甚至是混亂 • 組織雖然還是可以完成計畫，但通常會進度落後，超出預算 • 組織的成功完全仰賴某些成員的職能及英雄表現，除非相同職能的人員存在，否則成功的計畫無法再次出現 • 因此在Level 1的組織中，所謂 Process Capability 只能用來評價每個人，而非組織

33. Level 2 (Managed)的特徵 • 建立起計畫管理的政策及實踐這些政策的程序 • 組織已有了基本的計畫管理與控制 • 計畫的管理人員會追蹤的成本、時程與功能 • Process Capability：Disciplined; 因為計畫的規劃與追蹤都是穩定的，計畫的進行是在有效的管控之下。成功的經驗可以不斷地重複，但是當異常狀況發生時，卻無法有效地反應

34. Level 3 (Defined)的特徵 • 有一個團隊會專責制定組織的標準流程 • 組織的標準流程會因計畫而修改成特定計畫使用的流程 • 有一個教育訓練計畫來確保manager及技術人員有正確的知識及技巧來滿足被指派的角色 • 組織內的成員已瞭解流程中的權責劃分及作業 • Process Capability：Standard & Consistent; 工程及管理的作業均已標準化，組織也有足夠的能力因應突發狀況

35. Level 4 (Quantitatively Managed) 的特徵 • 產品及流程均已設定了量化的品質目標 • 流程的所有相關作業都可透過量測的方式得到量化的生產力與品質指標，可供蒐集與分析 • 流程中任何導致例外狀況的變因，均可透過量測的數據辨識出來，加以去除 • Process Capability：Being Quantifiable & Predictable; 因為整個流程都可被量測，組織能夠預測出可能發生的異常狀況

36. Level 5 (Optimizing)的特徵 • 整個組織把重點放在持續地改善流程 • 為了防止Defect的產生，組織可以找出流程的缺點並加以改良 • 藉由加強現有流程與技術或採用新流程與技術使流程不斷地改進 • Process Capability：Continuously Improving; 整個組織都在不斷地努力改進流程，以避免異常狀況的發生，也因此改進了流程的效能

38. Toward High Maturity Level • Increase the predictability of cost, effort, schedule and quality • Decrease the average of cost, effort and schedule

39. Process Area(PA) • 在Level 2~5, 每一個Level都有若干個PAs做為組織流程改善的重點

40. PAs in Level 2 (Managed) • Requirement Management • 管理產品與產品元件的需求規格，確保需求規格、計畫規劃與計畫產出的一致性 • Project Planning • 為計畫中工程部分與管理部分的活動做出規劃 • Project Monitoring and Control • 提高計畫進度的透明度以便成效不彰時採取措施 • Supplier Agreement Management • 選擇並管理合適的供應商

41. PAs in Level 2 (Managed) • Measurement and Analysis • 因應管理階層的需求，而提供與維護數據的量測與相關分析 • Process and Product Quality Assurance • 為運作中的流程及產品提供足夠的透明度以便品質的掌控 • Configuration Management • 在產品的生命週期內，建立並維護產品的整體性與一致性

42. PAs in Level 3 (Defined) • Requirement Development • 建立與分析客戶對產品及產品元件的需求 • Technical Solution • 發展、設計、實作出滿足需求的產品 • Product Integration • 將各個產品的元件組合成正常運作的產品 • Verification • 驗證所做的產品是否符合所制訂的需求

43. PAs in Level 3 (Defined) • Validation • 確認產品滿足客戶所設想的使用方式、功能與環境 • Organization Process Focus • 建立組織中各項流程在各單位的權責與作業項目 • Organization Process Definition • 發展並維護組織所有的流程

44. PAs in Level 3 (Defined) • Organization Training 提供教育訓練使所有的成員均有足夠的知識與技能完成所負責的作業項目 • Integrated Project Management • 針對IPPD的計畫，建立共同的計畫規劃與掌控 • Risk Management • 鑑別出潛在的問題，並規劃因應的措施

45. PAs in Level 3 (Defined) • Decision Analysis and Resolution • 採用系統化的步驟來分析各項決策 • Organization Environment for Integration • 針對IPPD的計畫，提供負責的人員與組織 • Integrated Teaming • 整合各個部門的流程，形成一個相互合作的團隊

46. PAs in Level 4 (Quantitatively Managed) • Organizational Process Performance • 建立並維護組織流程效能的量化指標 • Quantitative Project Management • 建立量化的方式來作計畫的規劃與掌控

47. PAs in Level 5 (Optimizing) • Organizational Innovation and Deployment • 選擇並實施新的技術(工具，方法或流程)以改進組織流程 • Causal Analysis and Resolution • 找出瑕疵或問題出現的原因，並採取行動來避免

48. Assessment • Assessment is not the focus, but Improvement is • Assessment的成本: • 約為期兩週 • 約數百萬台幣的費用 • Assessment的方式： • Assessment team的組成：Assessors + Assessed team members • 形式：文件審閱與面談 • 文件審閱的目的在瞭解有哪些流程已被定義 • 面談的目的在瞭解流程執行的情況

49. CMMI vs. ISO 9000 • ISO 9000關注的是： • 是否有足夠的流程 • 是否已將流程定義清楚 • CMMI還關心：流程是否有被確實地執行 • 雖然ISO 9000所制訂的流程包含了大部分CMMI L2~3的PAs，但實際上通過ISO 9000 認證的公司能通過CMMI L2或3的情況還是很少(Roselyn: 2/27)

50. Conclusion • The major problems of SW/SE/IPPD projects are managerial not technical • CMMI is a short cut to high quality • CMMI makes “Software Factories” possible!!