以前的cmm的qa是只關心過程質量，由此也是眾多的諮詢師也是眾口一詞，對此也沒有置疑。還是在2023年在做cmm的時候我就覺得至少在國內這些過程還不成熟甚至沒有過程的軟體企業（通過了n級並不代表過**正的成熟）是難以實現的，最後導致的結果就是做cmm的時候qa在公司還比較重視，做完cmm了，qa在公司就難以生存，紛紛或跳槽、或轉到測試、配置和專案管理上去了。究其原因如下：
1. 過程畢竟還屬於「虛」的東西，虛的東西往往會風光一時，但是生命不會很長，尤其在以賺錢為目的的企業；
2. 虛的東西是缺少power的，沒有power，就難以發揮作用，搞過程的人都不能發揮作用，那過程還會發揮過程的力量嗎？
3. qa由於不關心產品質量，不關心技術，因此很多公司的qa個人的能力和地位在公司比較低，但是過程本身又需要更高層的人員。這種高不成低不就的尷尬在很多企業都存在的；
4. 在01年我做質量部門的頭的時候就提出qa不能只關心過程質量，而不關心產品質量，當時遭到了許多qa的反對，反對的原因就是這種要求對他們太高了，有人還因此離職了。現在看看cmmi，我似乎覺得美國人好像也覺得只玩虛的不行，因此cmmi對又加了乙個p產品。提出要關注產出物的質量、要知道問題的原因，這樣才能起到作用。當然這樣的ppqa就不僅僅只知道過程就可以的了，就需要有更多的專案管理的經驗、開發的經驗、具體技術的經驗。
記得98、99年我參加三峽專案的時候，加拿大公司的qa，我覺得那才是真正的qa，因為我剛進專案組第一次寫的乙個程式，現在還記得檔名是ra038的檔案，被她從檔案命名、變數定義、**注釋、程式邏輯以及業務邏輯的bug、以及異常處理統統指出來了（自我批判一下，剛畢業哪會寫的程式也確實比較爛），如果不是具有相當的開發經驗的人不會這麼到位的。害的我花了兩天開發的程式不得不修改了乙個星期，然後又把厚厚的英文開發規範仔細讀了一遍。
CMM與CMMI的比較
cmmi的全稱為 capability maturity model integration，即能力成熟度模型整合。自從1994年sei正式發布軟體cmm以來，相繼又開發出了系統工程 軟體採購 人力資源管理以及整合產品和過程開發方面的多個能力成熟度模型。雖然這些模型在許多組織都得到了良好的應用，但對...
CMM和CMMI過程域的比較分析
級別 cmm過程域 cmmi過程域 說明與比較 2 需求管理 軟體專案規劃 軟體專案追蹤與監控 軟體子合同管理 軟體質量保證 軟體配置管理 需求管理 專案計畫 專案監督和控制 商合同管理 過程和產品質量管理 配置管理 度量和分析 專案過程管理的基本內容，實際是組織中某個或某幾個團隊的過程能力，可以說...
基於CMM和CMMI的配置管理（一）
本文主要從cmm和cmmi的要求出發，介紹了標準主要涉及的配置管理內容，並對相應內容進行初步地說明，最後提供了乙個配置管理在專案實施的指南和乙個在組織中部署配置管理的模型。1配置管理內容的邏輯關係 在cmm和cmmi中，將配置管理的目的定義為 建立和維護產品的完整性 這個目標沒有提到對專案管理的支援...