利用 RUP達到 CMM2和3級
（rational公司）
摘要
軟件工程協會 (SEI) 的能力成熟度模型 (CMM) 提供了一種著名的軟件流程成熟度基準。CMM 已經成為了許多領域內的流行工具，用于評估一個組織的軟件流程的成熟程度。本白皮書說明了 Rational Unified Process 如何支持正在努力達到 CMM 級別 2 （可重復的）和級別 3（已定義的）的組織。
簡介
軟件工程協會 (SEI) 的能力成熟度模型 (CMM) 是一個描述有效軟件流程元素的框架 [REF1]。CMM 描述了一條從臨時的、未成熟的流程向成熟的、規范化的流程演進的途徑。
CMM 覆蓋軟件開發和維護的規劃、工程以及管理經驗。這些關鍵的經驗提高了組織實現成本、進度、功能性和產品質量等目標的能力。
CMM 有五個成熟級別：從級別 1 到級別 5。如下圖所示。每個成熟級別由關鍵流程領域（Key Process Areas，KPA）組成，每個KPA確定一組相關活動。當這些相關活動一起開展時，它們完成一系列被認為對在該成熟級別建立流程能力有重要影響的目標。
rup.gif" width="460" height="298">
級別 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) 進行復審，確保變更符合現實的，并且可以被項目的整體日程接受。
分包管理的目的在于選擇合格的軟件分包商并對他們進行有效的管理。它綜合考慮了需求管理、軟件項目規劃、軟件項目跟蹤與勘察等的基本管理控制，以及軟件質量保證和軟件配置管理之間的必要協調，并在適當時候對分包商施以控制。
目標 1：由主承包商選擇合格的軟件分包商。
目標 2：主承包商和軟件分包商同意彼此承擔的義務。
目標 3：主承包商和軟件分包商保持連續不斷的交流。
目標 4：主承包商針對其承諾追蹤軟件分包商的實際結果和執行情況。
這些目標超出了 Rational Unified Process 當前的范圍，并且依賴于組織的具體情況。
盡管 Rational Unified Process 并未對項目分包作明確說明，但它的工具、技術和機制都是以向下流動到分包商為前提的，因此流程仍屬同類。
所有的分包決策都應該記錄在商業理由中。與主承包商執行同一開發計劃的分包商還參與技術交換、主要里程碑和狀態評估等活動。
軟件質量保證的目的是為管理人員提供軟件項目所用流程和正在構建的產品的可見度。軟件質量保證是大多數軟件工程和管理流程的一個構成部分。
Rational Unified Process 認為“質量”是所有項目員工共同的責任，它并非由組織本身體現出來。
目標 1：計劃軟件質量保證活動。
軟件質量保證的規劃是組織的一個責任。然而，Rational Unified Process 有許多屬性用來塑造一個有效的項目質量保證計劃。
每個 Rational Unified Process 里程碑都有特定的完成標準，這些標準可作為審計的基礎。Rational Unified Process 中的每個活動都有一個單獨的復審活動。每次復審都有一組檢查點與之相關，它們代表了在進入下一個活動之前必須“通過”的“關口”。
Rational Unified Process 提供有關誰應該復審給定工件的指南。例如，設計員執行的“對象分析”的結果需要由一個獨立的構架設計師、設計員、用例設計員和設計復審員來進行復審。如果有已定義的 Rational Unified Process 和工件復審標準，產品質量密切相關的目標實體應該能夠輕松地評估是否遵守流程以及是否符合開發標準及指南。
目標 2：客觀地驗證軟件產品及活動是否遵守適用的標準、過程和需求。
該目標可以通過挑選組織的質量保證人員來實現。.然而，Rational Unified Process 提供了必要的復審清單和文檔模板，它們可作為項目標準。
目標 3：將軟件質量保證活動和結果通知受影響的小組和個人。
如軟件項目規劃所述，Rational Unified Process 的目標之一是確保各方的期望同步并且保持一致。除根據質量審計結果提供的輸入之外，Rational Unified Process 還需要關于資源（員工配備和財政）、首要十大風險、用指標進行衡量的技術進展以及主要里程碑結果等的報告。Rational Unified Process 指標計劃提供了關于以下指標集合的指南：
- 進度（代碼行、類、每次迭代的功能點）
- 穩定性（返工類型、易變性）
- 適應性（返工成本）
- 模塊度（返工影響范圍）
- 質量（缺陷發現頻率、密度、繼承深度）
- 成熟程度（每次故障的測試時間）
- 資源耗費配置文件（計劃的與實際的）
目標4：在軟件項目內無法解決的非兼容性問題由高級管理層負責處理。
這超出了 Rational Unified Process 的范圍，屬于組織的職責范疇。然而，Rational Unified Process 里描述的變更控制流程可以驅動某個機制，藉此記錄非兼容性的問題并可以記錄下來并向上提交以便解決。
軟件配置管理的目的是在項目的整個軟件生命周期內建立并維護軟件項目產品的完整性。軟件配置管理是大多數軟件工程和管理流程的一個構成部分。
目標 1：計劃軟件配置管理活動。
如 Rational Unified Process 所述，可靠的配置管理是受控的迭代式開發方法中一個必不可少的元素。既然軟件是分階段演進的，因此以前開發的軟件版本可以用于后續開發是非常重要的。在每一階段規劃如何開發指導性軟件是 Rational Unified Process 的核心。
Rational Unified Process 有兩個主要手段，用于規定如何維護項目的軟件開發資產以及如何集成這些資產：
- 配置管理計劃，以及
- 集成構建計劃。
在先啟階段啟動的配置管理計劃描述以下內容：
- 管理軟件的版本化和處理；
- 保存指定的 Rational Unified Process 模型，將它們分成多個配置項；
- 使用變更控制方法管理變更和發布。
集成構建計劃提供了關于待構建的配置項的詳細信息以及它們在某個特定的迭代中的集成順序。
目標 2：確定、控制所選的軟件工作產品，并使之可用。
Rational Unified Process 配置管理計劃需要一個對配置控制和管理流程的說明，確保確實確定和控制工作產品，并使之可用。
目標 3：對已確定軟件工作產品的變更進行控制。
Rational Unified Process 主張，項目應有一個變更控制委員會 (CCB) 和一個變更管理系統，以便有效地管理、跟蹤和實施變更請求，并計算其變更成本。
目標 4：將軟件基線的狀態和內容通知受影響的小組與個人。
Rational Unified Process 提倡使用電子方式維護需求、設計和實施基線以及它們之間的可追蹤性�；�的所有變更分別由不同級別的項目控制團隊來裁定。例如，變更控制委員會 (CCB) 負責考慮需求級別的變更所帶來的影響。規模較小的設計和實施變更，由相應級別的技術權威進行復審。批準、控制級別以及它們傳達的方式分別在配置管理計劃和軟件開發計劃中說明。
級別 3，已定義的
組織流程重點的目的是建立軟件流程活動的組織職責，這些活動提高了組織的整體軟件流程能力。組織流程重點活動產生的主要結果是一組軟件流程資產，這些資產在組織流程定義中有描述。如集成軟件管理所述，軟件項目使用這些資產。
目標 1：在組織范圍內協調軟件流程開發和改進活動。
Rational Unified Process 是一個迭代式流程，它依賴于在多次迭代中重新制定“同一”已定義的流程。流程制定的重復性質、狀態指標的評估、以及每一階段和迭代獲得的經驗教訓都提供了在連續的各次迭代中調整流程的機會。
目標 2：軟件流程的優缺點根據相對于流程標準進行鑒別。
Rational Unified Process 代表了一個整體軟件開發流程，可對其進行定制，以便在某一類型的項目中更有效地使用它。環境工作流程提供關于如何定制 Rational Unified Process 的指南。除了技術和管理復雜性外，在項目中可用于確定流程“形狀”的一些流程判別標準有：
- 業務環境（投機或者內部的合同）
- 軟件開發工作量的大小
- 創新程度
- 應用類型
目標 3：計劃組織級別的流程開發和改進活動。
該級別 3 目標完全依賴于采用該級別的組織。
組織流程定義的目的在于開發和維護一套適用的軟件流程資產，提高項目的流程性能，為組織提供不斷積累的長期利益的基礎。這些資產提供了一個通過培訓等機制實現制度化的穩定基礎，這在培訓計劃中進行說明。
目標 1：為組織開發并維護一個標準的軟件流程。
Rational Unified Process 在這方面居于領先地位，用作組織的基線軟件開發流程，可對其進行發展、定制和維護。
目標 2：收集、復審與軟件項目使用組織的標準軟件流程有關的信息，并使之可用。
這一目標需要得到采用 Rational Unified Process 的組織的支持。
培訓計劃的目的在于發展個人的技能和知識，以便他們能高效地履行其職責。培訓是組織的職責，但軟件項目應該先確定所需要的技能，并在項目需求獨特時提供必要的培訓。
目標 1：計劃培訓活動。
這個目標只有采用 Rational Unified Process 的組織才能實現。然而，Rational Unified Process 是一個“行業最佳方案”知識庫，它提供了關于如何開展各種軟件開發活動的指南、概念和詳細的分步說明。因此，Rational Unified Process 本身就是一個優秀的培訓材料來源。
然而，Rational Unified Process 還需要相關的支持課程，包括：
- Rational Unified Process 概述，包括需求、分析設計、實施、測試、構架、流程配置、管理、工具等幾個模塊，以及對面向對象的介紹。
- 通過用例來實現需求管理 (RMUC)
- 面向對象的項目管理 (OOPM)
- 面向對象的設計分析 (OOAD)
- 軟件質量自動化
- 配置管理
- 軟件構架和迭代式流程
目標 2： 為培養履行軟件管理和技術職責所需的技能和知識而提供培訓。
目標 3：軟件工程組和其他軟件相關小組的個人接受必要的培訓，以便履行其職責。
采用 Rational Unified Process 的組織需實現這些培訓計劃目標。然而，Rational Unified Process 提供了一系列的課程，如上節所述。
集成軟件管理的目的在于將軟件工程和管理活動集成到一個一致、確定的軟件流程中，該流程是根據組織的標準軟件流程和相關流程資產定制的，這在組織流程定義中有描述。如軟件產品工程所述，該定制是根據業務環境和項目的技術需要進行的。集成軟件管理是從級別 2 的軟件項目規劃和的軟件項目跟蹤與勘察演進得到的。
目標 1：項目的已定義軟件流程是組織標準軟件流程的一個定制版本。
與 Rational Unified Process 環境工作流程一致，Rational Unified Process 的標準交付版本是可配置并且可以根據各種類型的項目調整使用規模。
目標 2：根據項目的已定義軟件流程計劃并管理項目。
這一目標需由采用 Rational Unified Process 的組織來說明。
軟件產品工程的目的是為了統一執行一個明確定義的軟件工程流程，將所有的軟件工程活動進行集成，以便高效地生產出正確、一致的軟件產品。軟件產品工程描述項目的技術活動，如需求分析、設計、代碼和測試等。
目標 1：定義、集成并統一執行軟件工程任務，以便生產軟件。
Rational Unified Process 活動以及對每個角色需要什么的定義，在項目必備計劃工件的背景下，確保確定、分配和完成任務。Rational Unified Process 內在的迭代式開發流程可以迅速證明軟件開發團隊的效力，并提供對最終產品的評估。
目標 2：軟件產品互相保持一致。
工程模型（用例模型、設計模型、源代碼和可執行構件）之間的可追蹤性通過環境進行維護。
組間協作的目的是為軟件工程小組積極參與其他工程小組的工作提供一種方法，以便項目能更好地高效滿足客戶的需要。組間協作是集成軟件管理的跨學科的方面，它超越了軟件工程的范圍。不但軟件流程應該集成，軟件工程小組與其他組的交互也必須協調和控制。
目標 1：客戶的需求得到所有項目涉及的團隊的同意。
使用用例而不是其他“正式”需求規約方法作為需求獲取和說明的依據的一個重大好處在于，用例容易被涉眾理解。同樣，Rational Unified Process 用例需求獲取方法代表所有涉眾可以對需要執行的任務達成一致意見。這在流程中得到進一步的貫徹執行，并反映在作為軟件開發基礎的模型和復審中。
目標 2：工程組之間的承諾得到項目涉及的團隊的認可。
這個目標需由采用 Rational Unified Process 的組織來說明。然而，Rational Unified Process 可視模型有助于人們理解產品開發各個階段（從需求獲取到部署）有什么要求。Rational Unified Process 變更和配置管理流程確保提議的變更得到適當評估，并將評估結果向所有涉眾傳達。
工程組確定、追蹤并解決組間問題。Rational Unified Process 迭代式開發流程有助于通過連續集成所有已開發軟件來及早發現軟件問題。為提出和解決團隊間的問題，對多個團隊開發的軟件進行集成時產生的問題可作為一個“公共空間”。Rational Unified Process 檢測和變更請求流程支持這種觀點，該流程提供了一種正式機制，用于捕獲、追蹤并解決項目開發問題。
平級復審的目的是為了及早有效地排除軟件工作產品的缺陷。一個重要的結果就是加深了對軟件工作產品以及可以防止的缺陷的理解。平級復審是軟件產品工程提出的一個重要而有效的工程方法。
目標-1：計劃平級復審活動。
如在級別 2 的質量保證目標中所述，Rational Unified Process 內的每個活動都有一個獨立的復審活動。
由于早期問題檢測能降低整體成本，因此 Rational Unified Process 提倡“及早并經�！彼泄ぜ�，尤其是關鍵工件進行平級復審。Rational Unified Process 提供了每一階段、每一模型內要復審的重要特性清單。
目標 2：識別和排除軟件工作產品中的缺陷。
Rational Unified Process 工件復審員需要確定用于下一個開發階段的工件是否準備就緒。如果工件未達到復審“合格”標準，根據 Rational Unified Process 指標計劃，需要獲取以下方面的詳細資料：
- 穩定性（返工類型、易變性）
- 適應性（返工成本）
- 模塊度（返工影響范圍）
- 質量（缺陷發現頻率、密度、繼承深度）
- 成熟程度（每次故障的測試時間）
- 資源耗費配置文件（計劃的與實際的）
參考資料：
[REF1] Mark C. Paulk et al, "Key Practices of the Capability Maturity Model - Version 1.1", Software Engineering Institute - Carnegie Mellon University.
文章來源于領測軟件測試網 http://www.kjueaiud.com/