CMM 2（可重複級）就是建立了基本的項目級管理過程，可對項目的成本、進度進行跟蹤和控制，生產的過程、標準、工作產品以及服務都是被嚴格定義和文檔化的。基於以往管理類似的項目的經驗，計畫和管理新項目，並可依據一定的標準重複利用類似的軟體產品。CMM 2的核心就是重複利用。
基本介紹
- 中文名：cmm2標準
- 核心：重複利用
- 關鍵過程域：6個
- 定義：建立基本的項目級管理過程
CMM2由6個關鍵過程域（KPA）組成：需求管理（RM）、軟體項目計畫（SPP）、軟體項目跟蹤與監控（SPTO）、軟體子契約管理（SSM）（本文略）、軟體質量保證（SQA）、軟體配置管理（SCM）。
需求管理（Requirement Management)
需求管理的目的是為了在客戶和處理客戶需求的軟體項目之間建立共識。這是軟體項目規劃（SPP）和管理（SPTO）的基礎，需求變更依賴於配置管理（SCM）的變更控制流程。在項目實施過程中，最突出的現象就是項目組成員沒有完全理解需求，軟體需求不穩定，客戶經常變更需求，無法有效控制需求變更，需求變更往往造成項目延期和費用超支。
CMM2要求的需求管理的基本流程可如<；圖一>；所示。該流程描述了軟體工程組開始獲取原始需求，匯總為系統需求，分配系統需求，複審軟體需求，軟體需求必須文檔化形成需求文檔，此文檔必須經過相關組和個人的評審，通過評審之後才納入配置管理，為需求文檔建立基線。軟體項目計畫、活動及軟體工作產品，應和軟體需求的變化保持一致。
根據流程，可以結合實際開發情況確定項目的需求管理步驟：
a. 獲取需求和確認需求以Use case（用例）為單位，以Rational Requisite Pro作為需求管理工具，使用Rational Rose進行維護Use case和Use case Model。
獲取需求工件是：用例模型（Use case Model）、非功能性的“補充規約”、用例規約（Use case Specification）、辭彙表（Glossary)
b. 通過訪談，從客戶處獲取原始需求，形成需求文檔。
c. 分析軟體需求形成Use case描述文檔，與客戶共同確認需求，向客戶展示Use case文檔，獲得客戶認可。
d. 建立基線的需求必須通過相關組的審查，包括：系統分析組、設計組、編碼組、測試組、質量保證組、配置管理組、文檔管理中心及個人。通過審查，項目組成員發現需求是否可行、是否完善、是否清晰、是否可進行測試。
e. 通過審查後，將需求文檔納入配置管理，為需求創建基線。
f. 通過工具管理，對需求進行跟蹤，儘快找出需求變更受影響的需求及工件，並了解需求的實現情況。
g. 客戶確認後如需變更，項目小組成員向其說明變更的影響，並有可能增加費用及時間，儘量控制客戶的需求。需求變更的流程按配置管理的變更流程執行。
h. 一旦需求發生變更，項目計畫、活動、工序隨之變更，並重新提交相關組和個人複審。
i. 實際項目需求管理中套用的文檔有：
項目需求管理流程定義、項目需求複審流程定義、項目需求及狀態跟蹤流程定義、需求獲取表格、需求狀態報告、需求複審報告、需求變更報告、需求跟蹤報告
軟體項目計畫（Software Project Plan)
CMM2軟體項目計畫根據納入配置管理後的軟體需求進行項目估算，並依據文檔化的流程，形成項目計畫文檔。項目計畫文檔經複審後納入配置管理，由項目開發人員遵循，並據此跟蹤檢查計畫的執行。項目計畫文檔在複審過程中，如果項目計畫對風險估算不足或存在其它問題，就需要對項目計畫文檔重新修正，以獲得項目組和高層管理者的支持。軟體項目計畫（SPP）也稱為軟體開發計畫（SDP：Software Development Plan），軟體開發計畫一般是指管理軟體項目的全面計畫。
在項目實施過程中，比較常見的情況一種是制定的軟體項目計畫內容簡單，無法具體到每一個疊代或每周，可變性太大；或者制定了詳細的軟體項目計畫，但實際執行根本就不按照計畫實施。
軟體項目計畫的實際套用模式如下：
a) 項目採用 Microsoft Word 擬定計畫文檔，以 Microsoft Project 擬定計畫的進度表。
b) 項目經理根據項目軟體需求進行估算，確定進行項目選擇的生命周期、項目規模、所需的人員、時間、進度、資源、風險等內容。將估算的結果形成估算過程文檔，並擬定軟體開發計畫。
d) 估算過程文檔和軟體項目計畫文檔必須通過相關組的審查，以獲得相關組及個人的支持，包括：系統分析組、設計組、編碼組、測試組、質量保證組、配置管理組、文檔管理中心及個人。通過審查，發現並修正項目估算和項目計畫的偏差。只有獲得了支持，軟體項目組在開發過程中才能儘量避免或消除風險。
e) 在高層管理者複審通過後，項目經理指定人員或參與擬定軟體開發計畫其它部分，並由相關組和個人複審。
f) 配置管理人員將軟體開發計畫文檔納入配置管理。
g) 實際項目中套用的文檔有：
制定項目計畫流程定義、項目估算流程定義、項目評估表、資源評估表、軟體開發計畫模板（包括：軟體項目計畫、疊代計畫、配置管理計畫、質量保證計畫、需求管理計畫、項目評測計畫、風險管理計畫、產品驗收計畫、問題解決計畫、測試計畫）、進度時間表、制訂軟體開發計畫的指南。
軟體項目跟蹤與監控（Software Project Tracking and Oversight)
軟體項目跟蹤和監督的目的是建立對實際進展的適當的可視性，為了及時發現開發過程與項目計畫之間的誤差，使項目經理或高層管理者能夠及時了解軟體開發過程的狀態，能在軟體項目明顯偏離軟體計畫時採取有效措施。
CMM2軟體項目跟蹤與監控的基本流程可如<；圖二>；所示。該流程描述了軟體項目組根據文檔化的估計、承諾、計畫跟蹤和審查軟體成果，並基於實際調整計畫。文檔化的軟體項目計畫被用作跟蹤軟體活動、了解狀態和修正計畫的基礎。項目經理根據項目開發計畫跟蹤項目的執行情況，定期形成項目進度報告，並與項目開發計畫進行對比，發現問題，根據實際情況對軟體開發計畫進行修正。掌握了這個核心，實施軟體項目跟蹤與監控活動就很容易了。
根據流程，在進行實際項目計畫跟蹤與監控時，可以採取如下方式：
a) 項目組使用 Rational 的工具進行管理，將 Microsoft Project 擬定的項目計畫進度表導入 ClearQuest，主要以 ClearCase 和 ClearQuest 作為跟蹤監控工具。
b) 項目經理每周根據項目的實際執行情況，擬定項目的進度報告。然後召集項目小組成員，對進度報告進行確認和修正。
c) 項目經理對照計畫與實際執行情況，發現差距並將其紀錄成問題報告，其中包括：費用、進度、風險、人員、資源狀況等。
d) 由高層管理者複審進度報告及問題報告，並敦促項目經理修正其計畫及解決項目存在的問題和風險。
e) 實際項目中套用的文檔有：
項目跟蹤與監控流程定義、項目進度報告、項目進度指標收集指南。
