軟件工程協會 (SEI) 的能力成熟度模型 (CMM) 提供了一種著名的軟件流程成熟度基準。CMM 已經成為了許多領域內的流行工具，用于評估一個組織的軟件流程的成熟程度。本白皮書說明了 Rational Unified Process 如何支持正在努力達到 CMM 級別 2 （可重復的）和級別 3（已定義的）的組織。
簡介
軟件工程協會 (SEI) 的能力成熟度模型 (CMM) 是一個描述有效軟件流程元素的框架 [REF1]。CMM 描述了一條從臨時的、未成熟的流程向成熟的、規范化的流程演進的途徑。
CMM 覆蓋軟件開發和維護的規劃、工程以及管理經驗。這些關鍵的經驗提高了組織實現成本、進度、功能性和產品質量等目標的能力。
CMM 有五個成熟級別：從級別 1 到級別 5。如下圖所示。每個成熟級別由關鍵流程領域（Key Process Areas，KPA）組成，每個KPA確定一組相關活動。當這些相關活動一起開展時，它們完成一系列被認為對在該成熟級別建立流程能力有重要影響的目標。
級別 2，“可重復的級別”定義如下：
在可重復級別，應建立管理軟件項目的策略以及實施這些策略的過程步驟。新項目的規劃和管理是以類似項目的經驗為基礎的。達到級別 2 的目標就是為了使軟件項目的有效管理流程制度化，從而讓組織重復在過去的項目中獲得的成功經驗，即使項目實施的具體流程可能存在差異。有效流程的特征可以歸納為熟練的、文檔化的、加強的、培訓的、評測的和可以改進。
級別 2 的組織的項目已經安裝了基本的軟件管理控制。符合現實的項目承諾是根據對以前項目的觀察結果和當前項目的需求做出的。項目的軟件經理跟蹤軟件成本、進度和功能，并確定在履行承諾期間出現的問題。創建軟件需求和為滿足這些需求開發的工作產品的基線，并控制它們的完整性。定義軟件項目標準后，組織確保這些標準得到不折不扣的執行。如果有分包商，則軟件項目可以和分包商合作，建立牢靠的顧客供應商關系。
級別 2 組織的軟件流程能力可以用規范化來概括，因為軟件項目的規劃和跟蹤是穩定的，以前的成功經驗可重復使用。項目的流程受項目管理系統的有效控制，遵守根據以前項目的性能制定的符合現實的計劃。
級別 2 KPA 是：
需求管理
軟件項目規劃
軟件項目跟蹤與勘察
軟件分包管理
軟件質量保證
軟件配置管理
級別 3，“已定義的級別”定義如下：
在已定義的級別上，組織開發維護軟件的標準流程已做記錄（包括軟件工程和管理流程），而且這些流程都集成到一個連貫的整體中。標準流程在整個 CMM 中始終是指組織的標準軟件流程。在級別 3 建立的流程用于（必要的時候可修改）幫助軟件經理和技術人員更有效地執行任務。組織在建立標準化的軟件流程的時候，利用了有效的軟件工程的經驗和方法。有一個小組負責組織的軟件流程活動，如軟件工程或SEPG。為了確保員工和經理具有完成分配給他們的任務必須掌握的知識和技能，需要在整個組織范圍內實施培訓計劃。
項目對組織的標準軟件流程進行定制，開發它們自己定義的軟件流程，使項目具有獨一無二的特點。這個定制流程在 CMM 中是指項目的已定義軟件流程。已定義的軟件流程包含了定義明確的軟件工程和管理流程的一個一致、完整的集合。明確定義的流程其特征可以歸納為包含準備就緒的準則、輸入、執行工作的標準和過程、驗證機制（如平級復審）、輸出和完成標準等。由于明確定義了軟件流程，管理層對所有項目的技術進展都有深刻的了解。
級別 3 組織的軟件流程能力可以用標準一致來概括，因為軟件工程和管理活動不僅穩定而且可重復。在已建立的產品線內，成本、進度和功能都受到控制，并且軟件質量獲得跟蹤。這一流程能力建立在整個組織對已定義的軟件流程的活動、角色和責任形成共同理解的基礎上。
級別 3 KPA 是：
組織流程重點
組織流程定義
培訓計劃
綜合軟件管理
軟件產品工程
組間協作
平級復審
本文各節描述 Rational Unified Process 特性、方法、程序和工件如何實現 KPA 目標。
本文是為關心達到 CMM 框架內的組織成熟級別 2 和級別 3 的組織人員而編寫的。
級別 2，可重復的
需求管理
需求管理的目的是為了在客戶和處理客戶需求的軟件項目之間建立共識。與客戶達成的統一認識是軟件項目規劃（如軟件項目規劃 KPA 所述）和管理（如軟件項目跟蹤與勘察 KPA 所述）的基礎。對客戶關系的控制依賴于執行有效的變更控制流程（如軟件配置管理 KPA 所述）。
Rational Unified Process 的關鍵特性之一在于它是用例驅動的。用例代表了獲取、組織和傳達用戶需求的一種系統化方案。它們提供了記錄功能性需求的方式，而功能性需求是項目開發、測試和迭代規劃的基礎。在 Rational Unified Process 中，用例在用例模型中進行維護，并在項目的整個生命周期里統一引用，從分析到測試一直到維護。
在工程環境中獲取需求的 Rational Unified Process 工件是：
由用例和用例包構成的用例模型
非功能性的“補充規約”
用例模型調查
用例報告
詞匯表
在管理環境中使用的、說明待開發用例及場景（需求）的 Rational Unified Process 工件包括：
迭代計劃
集成構建計劃
項目計劃
軟件開發計劃
所有這些工件都建立了基線，并受某個變更管理規定的制約。
目標 1 ：對分配給軟件的系統需求進行控制，以便創建軟件工程和管理的基線。
Rational Unified Process 主張對所有演進的工件進行連續的配置控制，然而，“正式的”基線與以下里程碑對應。
生命周期目標里程碑（先啟階段），
生命周期構架里程碑（精化階段），
初始操作能力里程碑（構建階段），以及
產品發布里程碑（產品化階段）。
同樣，Rational Unified Process 在需求、需求管理、跟蹤及創建基線上與 CMM 一致。
目標 2：軟件計劃、產品和活動與分配給軟件的系統需求保持一致。
該 CMM 目標重點在于確保交付的系統滿足用戶需求。Rational Unified Process 通過兩種方式幫助組織實現這一目標：
用例方案確保用戶需求得到理解并被獲取。獲取需求后，需求向下流動到各個“可視的” Rational Unified Process 模型（用例、設計、實施和測試），以保證一致性和連貫性。
控制的迭代式開發方案是一種風險降低策略，藉此項目風險能夠及早得到理解和研究，然后經常重新檢查。每一次累進迭代，通過不斷集成新增的功能，及早揭示風險。若使用傳統的瀑布式方法，則這些風險直到開發生命周期的后期才能夠被發現。及早識別風險對項目管理有直接好處，可重新定義需求規模，或者提出其他戰術改變。
Rational Unified Process 管理文檔包括：
商業理由
軟件開發計劃
評測計劃
風險列表
項目計劃
迭代計劃
迭代評估和狀態評估。
有效的變更控制和管理是 Rational Unified Process 的另一特性，它確保了軟件根據分配的、受到跟蹤的指定需求來開發。
Rational Unified Process 主張每個項目都應設立一個變更控制委員會 (CCB)，對提議的變更或者開發過程中發現的缺陷在規模及影響方面（預算、技術或時間安排）作出公斷。為了協助 CCB 的運作，Rational Unified Process 建議使用強大的配置管理和版本控制工具/環境。
軟件項目規劃
軟件項目規劃的目的在于建立合理的計劃，執行軟件工程和管理軟件項目。這些計劃是軟件項目管理（如軟件項目跟蹤與勘察 KPA 所述）所必不可少的。沒有符合現實的計劃，就不可能實施有效的項目管理。
目標1：對軟件估算進行記錄，以便用于規劃和跟蹤軟件項目。
Rational Unified Process 的目標之一是確保各方面的期望都同步進行并且保持一致。它通過在項目生命周期內進行定期評估來確保完成，并記錄在狀態評估報告中。報告需要對資源（人員配備和財政）、首要的十大風險、技術進步的追蹤數據，通過指標和主要的里程碑結果來進行測量。
Rational Unified Process 利用了以下類別的指標：
進度（代碼行、類的個數、每次迭代的功能點、返工）
穩定性（返工類型、需求或實施變更率）
適應性（返工成本）
模塊度（返工影響范圍）
質量（缺陷發現頻率、密度、繼承深度、返工指示符）
成熟程度（每次故障的測試時間）
資源耗費配置文件（計劃的與實際的）
目標 2：計劃并記錄軟件項目活動和承諾。
獲取項目計劃和承諾的 Rational Unified Process 文檔包括：
商業理由
軟件開發計劃
評測計劃
風險列表
項目計劃
迭代計劃
迭代評估，以及
狀態評估。
軟件項目跟蹤與勘察
軟件項目跟蹤與勘察的目的在于建立實際進度的適當可見度，以便管理人員在軟件項目的執行極大偏離軟件計劃時采取有效的措施。
目標 1：對比軟件計劃追蹤實際結果和性能。
如軟件項目規劃一節所述，Rational Unified Process 有幾個級別的項目計劃和一個狀態評估報告。狀態評估報告對比計劃與實際的結果，從而進行評估。為特定里程碑生成狀態評估報告是項目經理的職責。
主要的 Rational Unified Process 里程碑對應著一個階段（先啟、精化、構建或產品化）的結束，有明確指定的完成標準。一個階段的每次迭代結束時，在次要的里程碑處都存在復審的機會，這也是決策點，是未來發展方向的經驗教訓。
例如，精化階段的目標是分析問題領域，建立一個堅固的構架基礎，制定項目計劃，消除項目中的風險最高的元素。必須對整個系統有了理解之后，才能做出構架決策。這就暗示著在描述大部分用例時會考慮一些約束：補充需求。為驗證構架，實施一個系統，來證明所選構架是正確的，并執行意義重大的用例。
在精化階段結束時，檢查詳細的系統目標和規模，以及選擇的構架和確定的主要風險。當實際結果和性能極大地偏離軟件計劃時，采取糾正措施，并管理至項目結束。
風險列表是一個 Rational Unified Process 工件，它概括了項目中所有已知風險，并作為規劃和項目評估的輸入。每個風險都根據它的影響和應急計劃來進行描述，應急計劃是為降低風險而制定的。風險列表與業務案例一起制定，它們形成了“執行”或“不執行”項目的決策基礎。風險列表在項目的整個生命周期都要進行維護。
目標 2：軟件承諾的變更得到受影響的小組和個人的同意。
如 Rational Unified Process 所述，受控的迭代式開發流程確保涉眾能經�？吹巾椖窟M展情況以及為了保持項目不偏離軌道所作的任何必要的變更。提議的變更由變更控制委員會 (CCB) 進行復審，確保變更符合現實的，并且可以被項目的整體日程接受。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
