管理過程/缺陷管理
處於CMM第一級（或稱爲初始級）的軟件組織，對軟件缺陷的管理無章可循。工程師們只是在發現缺陷後，修改相應的軟件。通常，沒有人會去記錄自己發現的缺陷。也沒有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。而且，只有在下一輪測試中才有可能知道那些所謂已被糾正了的缺陷是否真的被糾正了，更重要的是糾正過程是否引入了新的缺陷。
所以這樣的軟件組織的項目交貨期（Release Date）表現出強烈的不可預測性。並且， 爲了獲得一個高質量的軟件產品（如果能夠的話），通常要在測試上花費大量的人力。
項目行爲
在CMM第二級（或稱爲可重複級）的軟件組織中，軟件項目會從自身的需要出發，制定本項目的缺陷管理過程。一個完備軟件缺陷管理過程通常會包括如下幾個方面：
（1）提交缺陷
（2）分析和定位缺陷
（3）提請修改相應的軟件
（4）修改相應的軟件
（5）驗證修改
項目組會完整地記錄開發過程中的缺陷，監控缺陷的修改過程，並驗證修改缺陷的結果。
組織行爲
CMM第三級（或稱爲已定義級）的軟件組織會彙集組織內部以前項目的經驗教訓，制定組織級的缺陷管理過程。並且，要求項目根據組織級的缺陷管理過程定製本項目的缺陷管理過程。
從而，整個軟件組織中的項目都遵循類似的過程來管理缺陷。好的缺陷管理實踐成爲所有項目的實踐，而教訓也爲所有項目所瞭解。更重要的是，隨着組織的不斷髮展完善，組織的過程會得到持續性的改進，所有項目的過程也都會相應的改進。
CMM第四級（或稱爲已管理級）的軟件組織會根據已收集的缺陷數據，採用SPC的方法建立軟件過程能力基線（Process CapabilityBaseline）。對於缺陷管理，可以缺陷密度爲例，過程能力基線通常包括期望（Mean），能力上限（Upper Control Limit，UCL），能力下限（Low Control Limit，LCL）。其中，"期望"描述了未來項目的缺陷密度的預期值，而UCL和LCL描述了未來項目的缺陷密度的合理變化範圍。
這樣的過程能力基線可以用來：(1)幫助未來的項目設立量化的項目質量目標；(2)理解和控制未來項目的實際結果。
以上圖爲例，在項目開始時，項目可以根據過程能力基線並結合本項目的實際情況來設立缺陷密度目標；而在項目的生命週期裏，可以使用這樣的過程行爲圖（Process Behaviour Chart）來理解和控制項目的實際的缺陷密度。當項目的實際缺陷密度在UCL和LCL之間波動時，可以理解爲項目的開發過程處於受控狀態。換言之，當項目的實際缺陷密度超越了UCL或LCL時，可認爲某異常的原因（Special Cause）導致了這一現象，必須進行分析並實施某種行動來防止該異常的原因再次發生，從而確保開發過程始終處於受控狀態。
持續優化編輯
與CMM第四級相比，CMM第五級（或稱爲持續優化級）更強調對組織的過程進行持續性改進，從而使過程能力得到不斷的提升。
就缺陷管理[1] 而言，軟件組織應當在量化理解其過程能力的基礎上，持續地改進組織級的開發過程、缺陷發現過程，引入新方法、新工具，加強經驗交流，從而實現缺陷預防（Defect Prevention）。
缺陷預防的着眼點在於缺陷的共性原因（Common Cause）。通過找尋、分析和處理缺陷的共性原因，實現缺陷預防。
當實施了缺陷預防，缺陷密度的過程行爲圖將可表現爲下圖的形式。
