关于项目过程能力基线的几个讨论
說到過程能力基線，了解CMM/CMMI的人都不會陌生。一般是指組織的過程能力基線，通過數字反映了組織的能力。比如一個組織的生產率是每人月生產代碼行2000行。當然現在一般用功能點來計生產率，比如每人月平均生產8.5個功能點，西格瑪是多少。
但是如果在項目一級上提出項目的過程能力，就讓我犯難了。當前的思路是從項目的大目標來分解。
項目的大目標一般有一按期發布，二缺陷要少。
從 工期上而言，有不少組織采用掙值管理的，完成可以采用掙值中的CPI和SPI來管理，這樣不僅管理了工期，成本也得到了管理。但是我所在組織沒有采用掙值 管理。只有工期偏差。每階段都有實際的工期偏差，每周的工期偏差是當時的預計值。雖然沒有掙值更為準確，但足以為項目提供支持。這樣利用每周和每階段的工 期偏差可以生成項目工期偏差的過程能力。
從缺陷上而言，我當前還沒有想到合適的辦法。由于每階段的工作產品不一樣，每個工作產品的規模度量也不一樣，比如開發計劃書是按頁數的。需求分析是按功能點數量的。這樣想來，每個階段都有的度量只有工作量是合適的。同行評審缺限數量與工作量的比值是每個階段都可比的嗎？
這好象很有疑問。誰能告訴我，如何在項目中就缺陷控制生成控制圖？
---------
在CMMI5過程改進中，Baseline和Baseline model是兩道很難逾越的“坎”。
缺陷控制圖是Baseline和Baseline control的方法之一。其中的難點還在于組織級是否已建立缺陷的Baseline（包括質量區間）。我想我們遇到的難點是，如何識別工作產品，并建立缺陷分類，以建立基線。
一般來講，我們可以從CMMI V1.2 項目5個階段著手，從開發中、交付前和交付后，對“評審發現的缺陷”、“測試發現的缺陷”和“系統運行中的缺陷”進行分類管理，其中“評審發現的缺陷”主要是“業務解決方案”、“技術解決方案”、“代碼”等中間產品。
同時，缺陷密度一般是缺陷數量和項目規模的比值較為合理。按照第二代FPA（Function Point Anaylis）方法，我們可以忽略“缺陷的顆粒度”干擾因素（據說經過數據統計，顆粒度綜合印象系數分布在1附近），用FPA方法統計項目規模，從而得 到無主觀因素干擾的“缺陷密度”。
歡迎交流。MSN：yangfl761123@hotmail.com
-------------
上面 Carl 回答了一些，我這里補充一些。
Process Performance Baseline 和 Process Performance Model 是兩個很重要的過程改進的標志。
Process Performance Baseline 可以理解為 過程在某個方面的 Benchmark，是以后項目用來參考和對照的，它是一個范圍值，在低成熟度級別的（如ML2 和 ML3）項目管理中，我們經常用的 threshold （閾值）跟這個意思類似，但是threshold 更多的依賴于項目經理和成員的經驗，是比較 主觀的；但是Process Performance Baseline 是個比較客觀的值，它是需要一定量的 相同性質的（homogeneous）數據通過統計方法得到的。這個值的得到需要時間（也就間接告訴我們 達到 4級 是需要時間的），也就是需要不少類似項目數據支持，從而提高了過程的客觀性和透明度（數據管理），也提高了項目管理能力，所以這個概念是在 四級（不論是 ML還是 CL）中提出，這也才真正體現“過程控制”的概念，如果把 ML2和 3 認為只是工程概念。
對于 缺陷來講，我建議首先 分項目類型，目的是采樣數據時能夠滿足數據的要求之一（homogeneous），然后 建立 phase containment，對各種缺陷數據進行再分類，同時主要 缺陷引入（injection）和消除（removal）概念，這些數據在識別過程問題和提高過程能力方面很重要，（CAR和四級都要求剔除 過程中的問題，不同的在于common cause 和 special cause，）；然后根據各個項目不同工作產品的規模（如 頁數、FPs、模塊數、測試用例數等）進行 normalize，就可以得到該項目的不同產品缺陷律，這樣與同類可以比較，數據多了，也可以考慮建立 baseline。一般的方法是數據少時就用平均法，多了就要用一些專業的control chart 來描述，對軟件來講，這個 baseline 永遠是相對客觀的，因為你總在不停的改正你的過程，原因是你的項目不會等你的過程穩定了才去調整你的過程，別忘了過程改進的目的是為了項目管理，是為了達 到一個 的核心目的 － control，這個就是所有管理的終極目標。
一個公司對 同一個過程的 baseline 可以有多個，別忘了 裁剪在這里仍然是適合的，因為這個的情況的根本（common cause）是背后不同的項目類型決定了這個數據。
只是薄見而已。
---------------
Process Performance Baseline（PPB） 和 Process Performance Model（PPM） 是兩個很重要的過程改進的標志。
Process Performance Baseline 可以理解為 過程在某個方面的 Benchmark，是以后項目用來參考和對照的，它是一個范圍值，在低成熟度級別的（如ML2 和 ML3）項目管理中，我們經常用的 threshold （閾值）跟這個意思類似，但是threshold 更多的依賴于項目經理和成員的經驗，是比較 主觀的；但是Process Performance Baseline 是個比較客觀的值，它是需要一定量的 相同性質的（homogeneous）數據通過統計方法得到的。這個值的得到需要時間（也就間接告訴我們 達到 4級 是需要時間的），也就是需要不少類似項目數據支持，從而提高了過程的客觀性和透明度（數據管理），也提高了項目管理能力，所以這個概念是在 四級（不論是 ML還是 CL）中提出，這也才真正體現“過程控制”的概念，如果把 ML2和 3 認為只是工程概念。
對于各種PPB，它的建立過程類似，都是要進行數據收集、分類（這個非常關鍵，按項目類型是主要的一個分類）和處理，這個可以參考MA 中的SPs。
對于 缺陷來講，我建議首先 分項目類型，目的是采樣數據時能夠滿足數據的要求之一（homogeneous），然后 建立 phase containment，對各種缺陷數據進行再分類，同時主要 缺陷引入（injection）和消除（removal）概念，這些數據在識別過程問題和提高過程能力方面很重要，（CAR和四級都要求剔除 過程中的問題，不同的在于common cause 和 special cause，）；然后根據各個項目不同工作產品的規模（如 頁數、FPs、模塊數、測試用例數等）進行 normalize，就可以得到該項目的不同產品缺陷律，這樣與同類可以比較，數據多了，也可以考慮建立 baseline。一般的方法是數據少時就用平均法，多了就要用一些專業的control chart 來描述，對軟件來講，這個 baseline 永遠是相對客觀的，因為你總在不停的改正你的過程，原因是你的項目不會等你的過程穩定了才去調整你的過程，別忘了過程改進的目的是為了項目管理，是為了達 到一個 的核心目的 － control，這個就是所有管理的終極目標。
一個公司對 同一個過程的 baseline 可以有多個，別忘了 裁剪在這里仍然是適合的，因為這個的情況的根本（common cause）是背后不同的項目類型決定了這個數據。
總結
以上是生活随笔為你收集整理的关于项目过程能力基线的几个讨论的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： IBM Rational上海大会印象
- 下一篇： csdn，我真的来了。