現在大多數實施cmm/cmmi的企業都具備了2級或者3級的成熟度；通俗來講，通過cmmi 3級就意味著企業已經定義了各個流程，如果再向高階別發展則主要是資料說話，決策、改進等等活動都依賴於之前收集的歷史資料。比如針對4級我們需要建立ppbs（process performance baselines）和ppms（process performance models）；在體系上更多的用資料說話，實現體系控制管理的量化、精細。到了5級則是把控制曲線壓扁，使之更穩定和優化。
我們不難發現自始至終度量都是貫穿其中的一條線；在最新版的cmmi dev 1.2中（sei 2023年8月發布）度量是2級當中的乙個過程域， 我們的度量其實是在低階別的時候就開始了，之後的能力成熟度提公升則是在此基礎上的積累、分析、形成基線、納入量化改進控制等等一系列的過程。
那麼究竟需要度量些什麼呢，這個取決於企業或者組織的實際情況，歸根結底你的cmmi是為了你的商業目標而服務的，不然再怎麼腳踏實地的改進也是價值不高或者無用功太多。因此首先應該根據企業實際情況的分析來確定；當然在這個時候確定的還不是最低層次的度量資料，先要確定度量哪些大的方面，然後細分出indicator，要表徵indicator就必然的需要具體的度量項，這個時候你就可以拉出你們企業需要的度量項的清單了，當然，不能忽視的還有你的統計分析方法； 用這些統計分析方法使你的資料為你的過程服務，把「死」的資料變成「活」的改進和決策支撐。
雖然我作為team leader正在致力於所在企業cmmi5的改進，但是由於種種原因，例項不能與大家分享；只好作簡要說明（推薦讀一下《software measures and the cmm》，雖然內容有些早，但是有啟發）：
大體上度量主要集中在產品、質量、體系三個方面，再向下分就會有schedule, cost, efforts等等，但是注意，到這裡還不是最底層次，比如schedule 又可以細分為planned, actual, variance等等的基本度量項，而不同型別的度量項又需要不同的統計分析方法、圖等幫助分析，比如上面例子中又多用 gantt和pert。針對關鍵原因則又需要使用pareto; 通過這種自頂向下的分析，我們可以把原有度量中不完善的部分補齊並使整個度量體系為組織服務，並忽略掉那些沒有用處的資料。
CMMI 度量與分析MA 2級
特定目標與特定實踐 sg 1 使度量與分析活動協調一致 sp1.1 建立度量目標 sp1.2 明確說明度量項 sp1.3 明確說明資料收集與儲存的規程 sp1.4明確說明分析規程 sg 2 提供度量結果 sp2.1 獲得度量資料 sp2.2 分析度量資料 sp2.3 儲存資料與結果 sp2.4 溝通...
軟體專案度量中主要的度量指標
軟體度量是軟體過程改進的基礎，如果沒有對目前的狀態作出度量，那麼就談不上作改進，當然如果沒有對改進後的過程作度量比較，也無法知道過程改進的效果。那麼，在軟體專案的度量中應該主要度量哪些指標呢？對於乙個組織，要對組織內的所有專案進行度量，則可以從幾個主要指標入手，如 軟體專案規模 size 工作量 e...
CMMI中GG的 實施
1.對於pa中gg這一方面，在二級中是如何實現gg2，在 中是否要求完全實現gg 2和gg3。gp2.1為了策劃和執行，要有乙個方針，我公司在ossp 01 policy 巨集智科技公司章程中定義 gp2.2 要求策劃該過程，要求實施pa的計畫，可以在專案計畫中包含 gp2.3 要求提供資源，比如人...