낪둦냳 ꒤뗘ꗁ냪ꑅꑑ꒭꙾ꑑꑇꓫcc.ee.ntu.edu.tw/~farn/courses/SE/CMMI.pdf ·...
35
CMMI
Transcript of 낪둦냳 ꒤뗘ꗁ냪ꑅꑑ꒭꙾ꑑꑇꓫcc.ee.ntu.edu.tw/~farn/courses/SE/CMMI.pdf ·...
CMMI簡介
高惠堂
中華民國九十五年十二月
CMMI背景說明• CMMI 全名為Capability Maturity Model
Integration (能力成熟度整合模式)• 由Canegie Mellon大學Software Engineering
Institute (SEI) 研發及對外授權• 是一個可幫助軟體發展者改善軟體流程能力與成熟度的模式
• 範圍涵蓋軟體工程(SW)、系統工程(SE)、整合的產品與流程發展(IPPD)及委外作業(SS)
版本
• Version V1.1– March 2002– CMMI-SE/SW/IPPD/SS–有中文版–三年到期後，要依V1.2版重新評鑑
• Version V1.2– August 2006– CMMI-DEV–每三年需重新評鑑
流程改善目標
• CMMI的主旨：組織流程改善• 流程改善必須對組織與業務有幫助 –不是為改善而改善
• 改善對不同的組織有不同的意義• 改善是長期且策略性的工作
–改善的時機？–期望的改變是什麼？–如何衡量所受的影響？包括效益及成本
流程改進的好處
• 改善時程與預算之預估能力• 改進設計週期• 增加生產力• 改善品質• 增進客戶滿意度• 改善員工士氣• 增加投資之回收• 減少因品質造成之成本
CMMI-SE/SW/IPPD/SSStaged
CMMI-SE/SW/IPPD/SSContinuous
CMMI軟體能力成熟度等級• Level 1：初始階段
–不確定的工作方式–没有固定流程、無法提供穩定環境、資源，無法估計人力，無法有效運用，經常超出專案時程及預算
–成功經驗無法重複，偶而會成功、大都只靠少數有經驗的人才能完成
• Level 2：已管理階段–建立了基本的專案管理過程。按部就班地發展系統、追蹤費用、根據專案進度表來進行發展。對於相似的專案，可以重覆使用以前的經驗及成果
• Level 3：已調適階段–軟體發展的工程活動和管理活動已標準化，且被集結成為一個組織的標準和流程資產
–所有軟體的發展和維護都在這個標準基礎上制定與執行
CMMI軟體能力成熟度等級(續)
• Level 4：已量化管理階段– 對於軟體發展過程和產品品質都有很好的歸納，產品成果和發展過程都可以用數量方式控制
– 可界定流程變異之特殊原因，並適當矯正該特殊原因的癥結，以防再度發生
– 強調對軟體發展過程及產品品質的定量管理• Level 5：最佳化階段
– 經由發展過程的定量回饋機制，不斷產生新的思想，並研擬新的技術來最佳化相關過程
– 組織及專案必須追求持續的、可度量的過程改進，包括缺失預防、技術更新管理和流程改造管理
CMMI流程領域
組織流程定義(OPD)組織流程績效(OPP)
需求發展(RD)產品整合(PI)確認(Val)
流程與產品品質保證 (PPQA)決策分析與解決方案(DAR)
專案監控(PMC)整合的專案管理(IPPD)量化專案管理(QPM)
組織流程專注(OPF)組織訓練(OT)組織創新與推展(OID)
流程管理(5)
需求管理(REQM)技術解決方案(TS)驗證(Ver)
工程(6)
建構管理(CM)度量與分析(MA)原因分析與解決方案(CAR)適於整合之組織環境(OEI)
支援(6)
專案規劃(PP)供應商協議管理(SAM)整合的團隊合作(IT)風險管理(RSKM)
專案管理(7)
流程領域類別
紅字： CMMI Level 2之流程 藍字：CMMI Level 3之流程綠字： CMMI Level 4之流程 紫字：CMMI Level 5之流程
模式組件
• 流程領域 (Process Area)–特定目標 (Specific Goal)
■特定執行方法 (Specific Practice)♦典型的工作產品 (Typical Work Product)♦細部執行方法 (Subpractice)
–一般目標 (Generic Goal)■一般執行方法 (Generic Practice)
♦細部執行方法 (Subpractice)♦詳細說明 (Elaboration)
CMMI規範各流程域之目標以“專案規劃(PP)”為例：
– SG 1 建立估計值建立並維護專案規劃參數的估計值■ SP 1.1估計專案範圍■ SP 1.2建立工作產品與工作項目屬性的估計值■ SP 1.3定義專案生命週期■ SP 1.4決定工作量與成本的估計值
– SG 2 發展專案計畫建立並維護專案計畫，以做為管理專案的基準■ SP 2.1建立預算和時程■ SP 2.2界定專案風險■ SP 2.3規劃資料管理■ SP 2.4規劃專案資源■ SP 2.5規劃所需知識和技能■ SP 2.6規劃關鍵人員之參與■ SP 2.7建立專案計畫
CMMI規範各流程領域之目標(續)
– SG 3 取得對計畫的承諾
建立並維護對專案計畫的承諾
■ SP 3.1 審查影響專案的各種計畫■ SP 3.2 調整工作和資源水準■ SP 3.3 取得計畫承諾
CMMI規範各流程領域之目標(續)– GG 2 制度化已管理的流程
■ GP 2.1建立組織政策■ GP 2.2規劃流程■ GP 2.3提供資源■ GP 2.4分配責任■ GP 2.5訓練人員■ GP 2.6管理建構■ GP 2.7界定並納入相關的關鍵人員■ GP 2.8監控流程■ GP 2.9客觀評估遵循程度■ GP 2.10與上層管理審查各狀況
– GG 3制度化已調適的流程■ GP 3.1建立已調適流程■ GP 3.2蒐集改善資訊
專案及專案負責人
• 專案≠合約• 專案是具有一定之資源，負有完成一特定任務，可以獨立運作之單位
• 專案負責人必需是組織內實際負責專案之運作，並對專案之成敗負直接之責任者
• CMMI專案劃分：–可以幾個性質類似的合約合併成為一個CMMI專案–一個合約可以分成幾個CMMI專案來執行
■不同地點■不同團隊■可獨立運作之子系統
CMMI評鑑方法
問卷、文件審查、訪談三者之一
一定要有訪談，問卷、文件二選一
問卷、文件審查、訪談三者
資料來源
1天1~3天4~10天評鑑天數
少中多所需蒐集的客觀證據數量(相對)
經過訓練且有經驗的人員
CMMI主評鑑員或經過訓練且有經驗的人員
CMMI主評鑑員
評鑑組負責人的資格需求
無無有評定等級的產生
少中多所需資源(相對)
少中大評鑑組規模(相對)
Class B Class CClass A特 徵
評鑑證據的類型
• 直接成果(Direct artifacts)– 實施執行方法時的明確輸出(如典型工作產品)
• 間接成果(Indirect artifact)– 實施執行方法的附帶成果，可證明其已執行(如會議紀錄、審查結果、日誌及報告)
• 確證(affirmation)– 口頭或書面的聲明，可證實或支持執行方法的實施(如訪談和問卷)
CMMI制式訓練
• 教育訓練課程：– Introduction to CMMI (3天)– Intermediate Concepts of CMMI (5天)– Instructor Training (3天)– SCAMPI Lead Appraiser Training (5天)
• 課程大綱可參考：http://www.sei.cmu.edu/cmmi/training/training.html
CMMI與軟體工程
CMMI的基礎
• CMMI模式是墊基於軟體工程與系統工程理論，只有要求(Requirements)，沒有程序(Processes)
• 程序是組織依其組織文化，加上對軟體工程的理解，配合業務型態而制訂的
• 只要合乎CMMI的要求，組織程序並不一定要完全遵照軟體工程理論
• 完全背離軟體工程理論，就無法達到CMMI的要求
軟體設計的程序化
• 程序的制訂要能夠驗證是否有遵照執行，軟體設計中有些是無法被驗證的
• 軟體設計的過程中，有許多可量化的事物無法訂出標準
• 軟體架構設計的良窳，關鍵在人，而非程序• 在軟體設計方面，CMMI的要求著重於需求與產品的一致性與完整性，以工作產品的驗證與追溯來確保設計方向
軟體設計流程
• CMMI是全面性的，包括專案管理、工程、支援與流程管理
• 軟體工程的部份是工程流程的六個流程領域• 軟體設計流程只能要求要有那些產出(What)，做那些驗證，無法要求如何設計(How)
• 可以訂出設計準則，但通常無法量化或驗證，只能做為提醒或參考之用
• 對軟體工程而言，CMMI是引導(Guideline)，是設計管理，不是流程
CMMI與軟體設計品質
CMMI的要求• CMMI只規範了工作流程需要符合那些要求，並沒有規定要如何去執行
• 執行的程序是由組織依據其業務型態、管理理念、技術領域、內部文化等因素來制訂適合於組織的作業流程
• 實際工作的執行並不是依照CMMI的規範在做事，而是遵照組織所訂定的作業流程
• 獲得某個評鑑等級，只表示所制訂的這些作業流程可以符合CMMI規範的所有要求，只能保證某些軟體品質要素
軟體品質要素
• 功能性(functionality) –執行所有必要功能的能力• 可靠性(reliability) –一致性與正確執行的能力• 維護性(maintainability) –容易修正的能力• 有效性(availability) –隨時可以進入操作的能力• 適應性(flexibility) –需求變更時容易被改寫的能力• 可移植性(portability) –在新的環境容易被修改的能力• 重複使用性(reusability) –在不同的應用中可以重複使用的能力
• 可測試性(testability) –容易且完整地測試的能力• 使用性(usability) –容易學習與使用的能力
品質要素種類
• 外顯的品質要素–可以經由客觀的檢驗方式來證明其所具有的特性–可以透過操作或測試來驗證的性質–任何人依據標準作業流程來執行其結果都一樣
• 內隱的品質要素–無法以標準作業流程來規範如何執行
–軟體設計品質的執行成效會因執行者的能力而異
–設計者的思考邏輯是無法以流程來規範的
–也無法以固定的程序來檢驗設計者分析的慎密程度
達成品質要素的基本要求
是部分內隱使用性
是外顯可測試性
是部分內隱重複使用性
是部分內隱可移植性
是部分內隱適應性
是外顯有效性
是部分內隱維護性
是部分外顯可靠性
是外顯功能性
設計者能力完善的流程CMMI要求種類品質要素
維護性
• 定義–要做任何變更時，同樣的修改，在整個系統中只需要改一個地方
• 做法–將相同程式碼的片段抽取出來成為程式庫(library)–以常數取代數字，除了廻圈的起始值或永遠不變的數值
–即使整個系統只用到一次的數值，也要用常數來定義
適應性• 定義
–需求變更時容易被改寫的能力• 做法
–執行需求發展時，儘量保持彈性–以常數來控制所有緩衝區、佇列、表格、陣列的長度–預留未來擴充的空間–優缺點：
■保持一致性■擴充時，只改常數值不改程式碼■增加一些工作量■多佔用一些可用資源
可移植性• 定義
–在不同的環境中可以重複使用的能力• 做法
–將硬體相關的程式碼抽取出來成為程式庫–將與作業系統相關的程式碼抽取出來成為程式庫–例如：
■插斷服務程式(ISR)■初始化程式(Initialization)■Run time library
重複使用性• 定義
–在不同的應用中可以提供他人重複使用的能力• 做法
–將一般功能的程式碼抽取出來成為程式庫–將外接界面的處理程式碼抽取出來成為程式庫–將共同功能的程式碼抽取出來成為程式庫–例如：
■佇列服務程式(Queue handling)■驅動程式(Driver)■逾時處理(Time-out)■錯誤訊息處理(Error message)■資料庫管理程式(Database management)
可靠性
• 定義–結果的一致性與正確執行的能力
• 做法–所有可能的狀況都要有對策–嚴謹踏實的整合測試–設計自我檢測機制–設計自我回復機制–設計自我啟動機制
使用性
• 定義–使用者容易學習與使用的能力
• 做法–充分瞭解使用者需求–瞭解使用者的企業文化與管理方式–要以使用者的立場來設計操作界面–防呆措施–例如：
■選單層次不要太多■已存在的資料不能要求使用者再輸入■使用者界面要簡單、有效
軟體產品的品質特性
• 某些品質特性不存在有程度上的差別，如功能性、有效性、可測試性
• 某些品質特性只有程度上的差別，卻無法定出可接受的門檻，如維護性、適應性、重複使用性
• 某些品質特性是有條件的接受，如可靠性• 某些品質特性是以人的感覺來評斷，如使用性• 某些品質特性可能永遠無法驗證，如可移植性、適應性
相關文件下載• CMMI publicationshttp://www.sei.cmu.edu/publications/publications.html• CMMI-DEV 1.2http://www.sei.cmu.edu/publications/documents/06.reports/
06tr008.html• 中文版http://www.sei.cmu.edu/cmmi/translations/trad-
chinese/models/• 中文版 SE/SW Version 1.1http://www.sei.cmu.edu/cmmi/translations/trad-
chinese/models/cmmi-se-sw-staged-v1.1-chinese.pdf
