一、CMMI 2.0 模型內容

CMMI2.0模型引入“能力域”和“實域”的概念，將CMMI13的開發(DEV)、服務(SVC)、采購(ACQ)和人力管理(PPL)等種模型中的所有實踐整合在一個模型中。CMMI2.0中共有12個能力域，這12個能力域被分為4類:Doing(執行)、Managing(管理)、Enabling(使能)和Improving(提高)。每個能力域中包含一組相關的實踐域。項目可以構建自己的自定義視圖。

二、過程改進的根本在于在組織文化中灌輸紀律。

這包括工作被理解、完成和改進的方式。下圖顯示了組織在實施過程改進時通常會經歷的過程紀律的四個階段。

三、下面重點說一下“確保質量”能力域，包括四個實踐域：需求開發和管理RDM、過程質量保證PQA、驗證和確認VV、同行評審PR。

1、需求開發和管理 RDM

2.0的RDM不是簡單的RD與ReqM的結合，從它對實踐域的解釋來看，它和前版這兩個過程域有以下大的變化：

變化1：需求的范圍不同。前版中需求只分為客戶需求和產品需求；2.0版中需求分為客戶需求、解決方案需求和接口或連接描述三種需求。其中解決方案需求代替了原來的產品需求，這同PI實踐域一樣，表明2.0版本不僅適應于軟件產品，也同樣適用于系統或服務；將接口需求與解決方案需求并列，也是一如PI實踐域那樣，表明2.0非常重視接口。

變化2：需求開發活動要在整個開發周期內一直進行，而不只是在設計之前。2.0中明確：在整個項目過程中持續識別和細化需求。

關鍵點

需求優先級、需求用例模型、業務對象模型、功能需求、非功能性需求

需求全周期跟蹤評估管理、需求評審管理、需求變更管理

與需求提供者就需求的含義達成共識（涉及需求有效性分析）

與項目參與者達成共識，即他們可以落實這些需求，減少延誤和返工

維護需求和活動、工作產品之間的雙向可追溯性，確保需求與解決方案之間的一致性，從而提高客戶滿意度

分層次評審、分階段評審、正式評審與非正式評審結合、需求評審檢查單、評審前的準備（核對評審的進入條件，比如提前糾正資料中的明顯問題、提前發資料給評審人員、要求評審人員提前閱讀并記錄問題)。

需求必要且充分，相關期望要平衡，管理承諾可追溯，場景分析確認清。

2、過程質量保證PQA

第 2 級

PQA 2.1 根據歷史質量數據開發、持續更新并遵循質量保證方法和計劃。

質量保證計劃可以簡單也可以完備，最簡單的QA計劃可以就是一頁紙，一張表。

PQA 2.2 在整個項目過程中，根據記錄的過程和適用標準客觀評價選定的已執行過程和工作產品。

檢查單：包括檢查項、檢查結果。

PQA 2.3 溝通質量和不合規問題并確保解決問題。

問題跟蹤表或禪道等工具。

PQA 2.4 記錄并使用質量保證活動的結果。

QA質量保證報告。

第 3 級

PQA 3.1 在質量保證活動中識別并記錄改進機會。（從定性提升到度量與分析）

對于發生頻率比較高的不符合問題要進行反思，分析是否是標準規范定義的不合理，從而識別出標準規范的改進點，也有可能不修改標準規范，而是加強標準規范在組織內的培訓、推廣力度。

質量保證人員與項目組打交道比較多，可以聽到、看到很多好的或壞的現象，從中可以識別出改進的機會。

識別的改進機會要提交到EPG，進行評價、篩選以確定是否納入組織級改進。

3、同行評審PR

Peer（同行）一般是做同樣工作的人，或者是相關領域專家，同行評審也可以叫專家評審。

同行評審是在軟件開發完成之前，通過技術專家發現潛在缺陷的一種有效手段，和在代碼完成之后進行的軟件測試可以相輔相成，提升軟件的質量。而同行評審發現缺陷的成本低、修改缺陷的效率高，在開發中更值得投入。

需求評審

客戶評審、內部專家評審

設計評審

正式的專家評審

代碼評審

核心代碼做代碼走查，代碼走查的核心是提升開發人員的編程習慣和能力。

一般代碼，比如用戶界面那種可以不查或簡單走查。

必須要質量計劃(或項目計劃)里面預先定好評審方式，然后按照計劃去做。同行評審作用大，缺陷去除在頭甲，制訂準則和計劃，合理使用老專家。

4、驗證和確認VV

驗證和確認從不同的角度來解決問題：

驗證針對的是工作產品和解決方案是否能正確地反映指定的需求，即“創建方式是正確的”。

確認針對的是解決方案是否能在目標環境下實現其預期用途，即“創建對象是正確的”。

驗證確認不可缺，哪怕初級也要得，方法標準多助力，分析有益好結果。

注：部分描述引用了互聯網上的文章，如有侵權請及時聯系作者，謝謝。