軟體過程改善 (Software Process Improvement)

1. 軟體過程改善 (Software Process Improvement) 課程設計與講授人：林泰龍 使用時間：八小時

2. Module-2 能力成熟度模型(CMM)

3. 軟體工程學院的歷史與軟體能力成熟度模型 (CMM) • 1982年美國國防部成本立聯合專案小組檢討國防部內的軟體問題。 • 軟體工程學院(SEI)的成立，即為其檢討報告的待辦事項之一。 • 1984年十二月卡內基美隆大學在美國國防部的指導下成立SEI。 • 其設立的目的在探討有關於已在國防部中營運之軟體的改善需求。 • 由SEI為DoD及業界發展軟體過程成熟度模型。

4. 軟體工程學院的歷史與軟體能力成熟度模型 (CMM) • 1986年，在美國空軍的要求下，SEI啟動軟體能力評估(SCE)專案。 • SCE是一套供籌獲單位評鑑軟體廠商能力的方法。 • 1991年SEI創立了能力成熟度模型(CMM)。 • CMM是以先前的經驗及軟體過程成熟度模型為基礎建立的。

5. CMM是什麼? 全面品質管理與CMM • CMM是以循序漸進的方式建立組織的過程能力。 • CMM的每一等級所提供的，是更上一層樓的基礎。 • CMM是持續改善的路線圖。 • 等級的概念是奠定在過去60年所建立的過程管理概念的原理上。 • 這些原理是由舒華特、戴明及裘蘭等人個別發展出來的。

6. CMM是什麼? 全面品質管理與CMM CMM成熟度框架的概念係取材自克洛斯比(Philip Crosby’s) 在「品質是免費的」(Quality is Free)一書中所提出的品質管理成熟度方格座標(maturity grid)。 • 此方格座標是在當時任職於IBM之瓦茲‧韓弗瑞(Watts Humphrey)的指導下，由隆‧勞狄斯(Ron Radice)改編納入軟體過程中。 • 1986年韓弗瑞將此成熟度模型帶到SEI，在SEI經過萃煉後，適用於軟體業界。

7. CMM是什麼? 全面品質管理與CMM CMM其實是全面品質管理(TQM)之過程改善概念的應用。 組織 專案 A 專案 B 專案 C TQM 硬體 軟體 CMM

8. CMM是以模型為基礎的改善 • CMM是軟體過程改善的模型。 • 雖然模型是實體世界的簡化，但卻有著許多的利益。 • 它可以為軟體過程建立共同溝通的語言。 • 在組織與參與者之間塑造共有共享的願景。

9. CMM是以模型為基礎的改善 • 是建立在由軟體界所挑選出來之從業人員，所共同合作所訂出來的過程及常規之上。 • 在提供有關軟體過程改善活動，排定優先次序作法的框架。 • 經由訂定執行可靠與一致之評鑑的框架，以提供軟體過程量測方法。 • CMM讓組織與其他使用CMM做為過程改善機制的組織做比較。

10. CMM是以模型為基礎的改善 因為有好處，所以也有風險 • CMM不是銀彈，無法解決所有的問題。 • 模型是簡化了的實體世界，所以，無法觸及實體世界中軟體開發的各個構面。 • 本模型經由共識而建立，可能與其他人對軟體過程改善的觀點或想法不是很契合。

11. CMM是以模型為基礎的改善 • CMM應予解讀與裁適以迎合組織事業目標之需要。 • CMM只是一項工具，因此，需要有常識的人，以有常識的方式運用。 • 需要運用良好的判斷力。

12. CMM的應用 評量 • 評鑑(自我改善) • 軟體過程評鑑(Software Process Assessments, SPA) • 內部過程改善(Internal Process Improvement, IPI) • 過渡期概況檔案(Interim Profile, IP) • 評估(選商、合約監督) 過程改善工作負荷

13. 評鑑vs.評估

14. 能力成熟度模型(CMM) 之 術語介紹

15. CMM術語 • 軟體過程(Software process)：人們用以開發及維護軟體及相關產品(例如，專案計畫、設計文件、程式碼、測試個案及使用手冊)的一組作業、方法、常規(practice)及轉換作業。當組織成熟的時候，軟體過程就會較完善，並且更能被整個組織無誤地執行。 • 軟體過程能力(Software process capability)：在描述依據軟體過程執行，可達成之預期成果的範圍。組織的軟體過程能力，提供了預測組織下一個軟體專案可能結果的方法。

16. CMM術語 • 軟體過程成熟度(Software process maturity)：是一個範疇，到達此一範疇時，指定之過程有明確的定義、受到管理、評估、與控制，並且具有效果。成熟度隱含能力方面成長的潛力，並意指組織之軟體過程的豐富性，以及將軟體過程應用在組織所有專案上的一致性。

17. CMM術語 • 關鍵過程領域(Key Process Area, KPA)：是一組相關的作業項目，當集體執行時，可以達成一組，在建立過程能力上，相當重要的目標。這些關鍵過程領域被定義到單一的成熟度等級上。這些關鍵過程領域，是由SEI鑑別之主要積木(building blocks)(建構事物的基本單元)，以協助斷定組織的軟體過程能力，以及理解前進至更高的成熟度等級所需的改善。

18. CMM術語 • 關鍵常規（Key Practice)：協助關鍵過程領域實行與訂為制度的基礎建設與作業項目。 • 基礎建設(Infrastructure)：組織或制度的基礎框架，包括：組織結構、政策、標準、訓練、設施、以及工具等，可以支持組織或制度繼續地運作。

19. CMM術語 • 受到管理與受到管制(Managed and Controlled)：識別與定義不屬於基準的軟體工作產品的過程，由於不屬於基準，因此就不會納入構型管理，但這些工作產品在專案中必須受到管制，俾能以紀律嚴明的方式處理。「受到管理與受到管制」意指在某一時期(過去或現在)所使用的工作產品的版本是已知的(亦即，版本控管)，而變更是以受到控管的方式整合起來(亦即，變更管制)。

20. CMM術語 • 訂規(institutionalization)：對方法、常規、以及程序提供支援之基礎建設與文化的建立，使之成為持續執行業務的方式，即使原來定義這些方法、常規、以及程序的人離開公司之後亦然。

21. 能力成熟度模型(CMM) 之 等級與共同特徵

22. 成熟度等級 成熟度等級 關鍵過程領域 關鍵過程領域 共同特徵 共同特徵 關鍵常規 關鍵常規 CMM的結構 包括 象徵 過程能力 (由共同特徵)組成 達成 目標 詳述 包括 實行或訂規 描寫 基礎建設 或作業

23. Optimizing (5) 持續改善的過程 追求卓越 Managed (4) 可預測的過程 嚴密控管 標準、一致的過程 Defined (3) 輪廓鮮明 有條不紊的過程 Repeatable (2) 反覆重現 Initial (1) 霧中航行 軟體過程成熟度的五個等級

24. 第一級 • 組織無法為軟體的開發與維護提供穩定的環境。其成功則端賴異於常人的經理人，以及經驗豐富、有戰鬥力的軟體團隊。 • 第一級中的成功組織，是依靠組織中人員的稱職與英雄式表現。因此，在第一級上，能力是個人而非組織的特質。 • 在第一級中無任何的關鍵過程領域

25. 第二級 • 用以管理軟體專案的政策，以及執行這些政策的程序已經建立。新專案的規劃與管理，是以類似的專案的經驗來實施。 • 軟體需求與開發出來滿足這些需求的工作產品，均與基準相符，且其完整性受到控管。 • 第二級組織的過程，可能會因專案特性而有所差異。成就第二級，在組織上需求乃是，具備導引專案建立適切管理過程的政策。 • 第二級組織的軟體過程能力，可以總結為「有條不紊」，因為軟體專案的規劃與追蹤處於穩定狀態，先前的成功可以反覆重現。

26. 第二級的關鍵過程領域 第二級的關鍵過程領域共有六項： • 需求管理(Requirements Management)：目的在於建立客戶，與軟體專案將詳述之客戶需求的軟體專案，兩者間的共同性理解。與客戶間的此種一致，乃是軟體專案規劃與管理的基礎。 • 軟體專案規劃(Software Project Planning)：目的在建立執行軟體工程與管理軟體專案的合理計畫。這些計畫乃是管理軟體專案的必要基石。 • 軟體專案追蹤與監督(Software Project Tracking and Oversight)：目的在建立對實際進度之充分可見度，俾使管理階層能在軟體專案績效明顯偏離軟體計畫時，採取有效的措施。 • 軟體下包管理(Software Subcontract Management)：目的在選擇合格的軟體下包商，並有效管理之。 • 軟體品質保證(Software Quality Assurance)：目的在提供管理階層，對軟體專案及產品產製所採行過程的適切可見度。 • 軟體構型管理(Software Configuration Management)：目的乃是在整個專案軟體生命週期中，建立與維護軟體專案之產品的完整性。

27. AC.1 審查獲配的需求 AC.3 管制對獲配需求的變更 SW-CMM Level 2 需求管理 CO.1 組織政策 經過審查 並書面化的 獲配需求 AB.2 書面化的 系統需求， 需求變更 經過審查 並書面化的 獲配需求變更 AB.3 充分的資源 啟動準則 AB.1 系統需求的職責 結束準則 AC.2 運用獲配需求 AB.4 訓練 Requirement Management

28. AC.1 參與建議書擬訂小組 AC.3 參與全盤專案規劃 AC.4 與高層共同審查承諾 AC.5 鑑別軟體生命週期 AC.6-7 擬訂SDP並書面化 AC.8 鑑別工作產品 AC.9-12 估算規模、成本、工作量、關鍵電腦資源、時程 AC.13 鑑別風險 AC.14 鑑別設施 AC.15 紀錄規劃資料 SW-CMM Level 2 軟體專案規劃 • SDP估算 • 估算風險 • 工作產品承諾 • 設施 CO.2 組織政策 AB.1 工作條款 AB.3 充分的資源 • 規劃資料 • 估算資料 • 假設事項 AB.4-5 訓練 啟動準則 CO.1 專案軟體經理 AB.2 對於SDP的職責 AC.2 早期的規劃 Software Project Planning

29. AC.1 SDP中所列的追蹤作業 AC.2 視需要修訂SDP AC.3-4 就承諾的變更進行審查與溝通 AC.5-9 追蹤進展—規模、成本、工作量、關鍵的電腦資源 AC.10 對風險進行管理 AC.11 紀錄量測與重新規劃用資料 AC.12-13 舉行審查會—包括內部與正式的審查會 SW-CMM Level 2 軟體專案追蹤與監督 • 修訂後的SDP • 修訂後的估 • 算項目 • 修訂後風險 • 項目 • 修訂後的承 • 諾事項 CO.2 組織政策 AB.1 SDP 資料紀錄 AB.3 充分的資源 各項審查會 的待辦事項 AB.4-5 訓練、 適應性解說 啟動準則 CO.1 專案軟體經理 AB.1 奉核定的SDP AB.2 指定的工作產品 Software Project Tracking and Oversight

30. AC.1 定訂要下包的工作 AC.2 選擇下包商 AC.3 管理下包合約 AC.4 核定下包商的SDP AC.5 追蹤下包商的工作進展 AC.6 管制對下包工作的變更 AC.7-9 與下包商召開審查會—包括狀況報告、技術性、正式的 AC.10 監督SQA作業 AC.11 監督SCM作業 AC.12 舉行驗收測試 AC.13 評估下包商的績效 SW-CMM Level 2 下包合約商 軟體下包管理 下包合約SOW CO.1 組織政策 下包商SDP 狀況報告 AB.1 充分的資源 各審查會 待辦事項 SQA報告 SCM報告 AB.2-3 訓練、 適應性解說 驗收測試報告 啟動準則 CO.2 下包合約經理 外包產品 Software Subcontract Management

31. AC.7 解決變異的問題 AC.8 與客戶舉行審查會 AC.1-2 SQA計畫書研訂與執行 AC.3 參與計畫書、標準、程序的調製 AC.4 審查作業 AC.5 稽核[工作產品] AC.6 向軟體工程小組報告 SW-CMM Level 2 軟體品質保證 CO.1 組織政策 SQA計畫書 審查會與 稽核的報告 AB.2 充分的資源 變異報告 AB.3-4 訓練、 適應性解說 啟動準則 AB.1 SQA 小組 Software Quality Assurance

32. AC.6 管制對基準的變更 AC.7 建構發行版本 AC.8 紀錄構型的狀況 AC.9 撰寫SCM報告 AC.10 對基準進行稽核 AC.1-2 訂定SCM計畫書 AC.3 建立構型管理館系統 AC.4 鑑別將納入SCM管理的工作產品 AC.5 管理[變更要求書及問題報告單] SW-CMM Level 2 軟體構型管理 SCM計畫書 CO.1 組織政策 構型紀錄 AB.1 SCCB SCM報告、 稽核報告 AB.2 SCM群組 AB.3 充分的資源 基準 AB.4-5 訓練、 適應性解說 發行(版本) Software Configuration Management

33. 第三級 • 在輪廓鮮明級上，整個組織的軟體開發與維護標準過程，均已文件化，而且，緊密地整合成不可分割的一體。此一標準過程，在整個CMM中，稱之為組織的標準軟體過程。 • 在第三級所建立的過程，係用來(並依需要變更)協助軟體經理人及技術人員，更有效地執行其工作。 • 建立軟體工程過程小組SEPG (software engineering process group) ，負責組織的軟體過程作業。

34. 第三級(續) • 專案裁適組織標準的軟體過程，以發展自身定義明確的軟體過程。 • 第三級組織的軟體過程能力，可以總結為「標準與一致」，因為軟體工程與管理作業兩方面都屬穩定且可以反覆重現。

35. 第三級的關鍵過程領域 第三級的關鍵過程領域共有七項： • 組織過程重點(Organization Process Focus)：目的乃是在建立軟體過程作業的組織職責，這些作業係用以改善整個組織的軟體過程能力。 • 組織過程定義(Organization Process Definition)：目的乃是在發展與維護一組可資運用之軟體過程資產(software process assets)，以改善所有專案的過程績效，並且提供為量化之過程管理定義有意義之資料的基礎。這些資產提供，可以透過訓練之類的機制訂定之穩固基礎。 • 訓練計畫(Training Program)：目的乃是要開發個人的技巧與知識，使其能有效地扮演其角色。訓練屬組織的職責，但當專案的需求很獨特時，軟體專案應辨識其所需之技巧，俾提供必要的訓練。 • 整合軟體管理(Integrated Software Management)：目的乃是在將軟體工程與管理作業，整合到緊密關聯、定義完成之軟體過程，此軟體過程係裁適自組織之標準軟體過程及相關的過程資產。此種裁適係植基於事業的環境與專案的技術需求。

36. 第三級的關鍵過程領域(續) • 軟體產品工程(Software Product Engineering)：目的乃是在絲毫不差地執行定義完善的工程過程，該項過程整合所有的軟體工程作業，以有效(有效率、有效果)地產製正確、相符的軟體產品。軟體產品工程在描述專案的技術作業，例如，需求分析、設計、編碼與測試等。 • 小組內部協調(Intergroup Coordination)：目的乃是在建立軟體工程小組，主動參與其他工程小組的方法，使專案更能有效地滿足客戶的需要。 • 同儕審查(Peer Reviews)：目的乃是在將缺陷，於早期、有效地從軟體產品中消除。其必然的效果，乃是對軟體產品，以及可預防的缺陷，能有較佳的認識。同儕審查是最重要而且有效的軟體工程方法，同儕審查可用檢視、結構化的排練、或是多種學院派審查方法來執行。

37. AC.6 協調[訓練的有關事項] AC.7 發送[過程資訊] AC.1 評鑑過程 AC.2 規劃[過程的改善] AC.3 協調[過程的改善] AC.4 協調[組織過程資料庫]的運用 AC.5 技術的評估與移轉 SW-CMM Level 3 組織過程重點 CO.1 組織政策 過程改善 計畫書 評鑑所見事實 AB.2 充分的資源 技術評估報告 AB.3-4 訓練、 適應性解說 訓練的需求 過程改善 狀況資訊 啟動準則 AB.1 過程小組 CO.2 資深管理階層的贊助 CO.3 資深管理階層的監督 Organization Process Focus

38. AC.1 研訂[組織的標準軟體過程] AC.2 書面化[軟體生命週期] AC.3 研訂[裁適指導綱要] AC.4 建立[組織的軟體過程資料庫] AC.5 建立[與過程相關之文件的收藏館] SW-CMM Level 3 組織過程定義 組織標準 軟體過程 CO.1 組織政策 軟體生命週期 AB.1 充分的資源 裁適指導綱要 組織的軟體 過程資料庫 AB.2 訓練、 適應性解說 與過程相關之 文件的收藏館 Organization Process Definition

39. SW-CMM Level 3 訓練計畫 CO.1 組織政策 組織訓練計畫 AC. 2 訂定[組織訓練計畫] AC.3 施訓 AC.4 編製[訓練課程] AC.5 建立[豁免程序] AC.6 維護訓練紀錄 AB.2 充分的資源 訓練課程 AB.4 適應性解說 豁免事項 AC.1 專案訓練計畫 訓練紀錄 AC.2 訓練需求 啟動準則 AB.1 訓練小組 AB.3 技能純熟的訓練師 Training Program

40. AC.1 為個別專案裁適OSSP AC.2 修訂[經定義的軟體過程] AC.3 研訂[SDP] AC.4 依據[經定義的軟體過程]來管理 AC.5 運用[軟體過程資料庫] AC.6-8 管理[規模、工作量、成本、關鍵電腦資源] AC.9 管理[關鍵性相依關係] AC.10 管理[風險] AC.11 執行[定期審查] SW-CMM Level 3 整合式軟體管理 專案的經定義 軟體過程 CO.1 組織政策 SDP AB.1 充分的資源 修訂之規模 、工作量、 成本、 資源估算資料 AB.2-3 訓練 各審查會 待辦事項 Integrated Software Management

41. AC.1 整合[工具與方法] AC.2 分析[需求] AC.3 設計 AC.4 程式編碼 AC.5-7 測試—整合測試、系統測試、驗收測試 AC.8 書面化 AC.9 蒐集[缺陷資料] AC.10 保持[所有工作產品間的一致性] SW-CMM Level 3 軟體產品工程 軟體需求 CO.1 組織政策 軟體設計 程式碼 AB.1 充分的資源 測試計畫、 程序、個案 、紀錄 AB.2-4 訓練、 適應性解說 使用者手冊 追溯表 Software Product Engineering

42. AC.1 工程群組參與[系統需求的訂定] AC.2 工程群組協調[技術性作業] AC.3 擬訂[協調群組間工作]的計畫 AC.4 鑑別[關鍵性相依關係] AC.5 審查[輸入資料] AC.6 解決[群組間的議題] AC.7 蒐集[缺陷資料] AC.10 舉辦[定期的技術交流會議] SW-CMM Level 3 各群組間協調 系統需求 CO.1 組織政策 AB.1 充分的資源 群組間的 協調計畫 AB.2 相容的 支援工具 群組間 的承諾 AB.2-4 訓練、 適應性解說 各審查會 待辦事項 Intergroup Coordination

43. AC.1 規劃[同儕審查會] AC.2 執行[同儕審查] AC.3 紀錄[同儕審查會議資料] SW-CMM Level 3 同儕審查 CO.1 組織政策 同儕審查計畫 AB.1 充分的資源 同儕審查資料 AB.2-3 訓練 同儕審查會 待辦事項 AC.2 檢查表 Peer Reviews

44. 第四級 • 對軟體產品與過程兩者，設定了量化的品質目標。 • 專案以窄化過程績效的變異，使之落於可接受之量化界限之內，達成對產品與過程的控管。 • 第四級組織的軟體過程能力可以總結為「可量化與預測」，因為過程是在可測定的範圍內測定與運作的。

45. 第四級的關鍵過程領域 第四級的關鍵過程領域共有兩項： • 量化過程管理(Quantitative Process Management)：目的乃在以量化的方式控管軟體專案的過程績效。軟體過程績效代表依循軟體過程所獲致的實際結果。其重點在可測定的穩定過程中，辨識變異的特殊肇因，並適時矯正，驅使暫時性變異發生的環境。 • 軟體品質管理(Software Quality Management)：目的乃是在形成專案軟體產品品質的量化的認識，並達成指定的品質目標。

46. 第五級 • 在追求卓越級中，整個組織將焦點放在持續過程改善上。 • 第五級組織中的軟體專案團隊分析缺點以判斷其成因。對軟體過程實施評估，以防止已知缺點再次發生，所獲之經驗教訓可以傳播給其他的專案。 • 第五級組織的軟體過程能力，可以用「持續改善」來描述其特質，因為第五級組織持續努力尋求其過程能力改善的範圍，從而改善了專案的過程績效。

47. 第五級的關鍵過程領域 第五級的關鍵過程領域共有三項： • 缺陷預防(Defect Prevention)：目的乃是在識別缺陷的成因，並預防缺陷成因的發生。軟體專案要分析缺陷、識別其成因、以及變更其規定的軟體過程。 • 科技變革管理(Technology Change Management)：目的乃在識別有助益的新科技(即，工具、方法與過程)，並將之依序轉移到組織當中。科技變革管理的重點在於不斷變化的世界中，實行有效的創新。 • 過程變革管理(Process Change Management)：目的乃在對應用於組織中，以改善軟體品質、提高生產力、降低產品開發週期時間(cycle time)的軟體過程，持續進行改善。

48. SW-CMM共同特徵的重點領域

49. CMM各等級在相關事項上的提升 1

50. CMM各等級在相關事項上的提升 2