軟件能力成熟度模型

軟件能力成熟度模型
1 過程成熟度框架
關于通過運用新的軟件方法和技術提高生產率和質量的期待經過了20 年仍未實現
工業和政府組織終于意識到他們的基本問題在于對管理其軟件過程無能為力[DOD87] 在無紀律的混亂的項目狀態下即使有較好的方法和工具也難以從中獲益在許多組織中
項目往往一延再延而經費預算則一增再增[Sisgel90] 在這類情況下組織常常是拿不出
幫助項目避免這些問題所需要的基礎設施和支持辦法
不過即使在無紀律的組織中個別軟件項目仍能生產出優秀產品這些項目的成功一
般是通過專設的工作組的杰出努力而不是通過重復使用這個組織的具有成熟軟件過程的經
驗的方法在缺乏全組織范圍的軟件過程的情況下能否取得重復結果完全取決于能否是同
樣人員去做下一個項目單純建立在可得到特定人員上的成功不能為整個組織生產率和質量
的長期提高打下基礎只有通過在不斷為有效軟件工程和管理慣例建立過程基礎設施中所作
的堅持不懈的努力才能不斷改進
1.1 不成熟和成熟軟件組織的比較
在確定合理的過程改進目標時需要了解不成熟軟件組織和成熟軟件族之間的區別
在不成熟軟件組織中軟件過程一般由實踐者及其管理者在項目進程中臨時拼湊即使已規
定了某軟件過程它業的不到嚴格遵守和貫徹不成熟的軟件組織是反應式的通常經理們
致力于解決眼前危機稱為消防由于進度和預算不是基于切實可行的估計因而拖進度
和超預算已成慣例當硬性規定時限時為滿足進度要求常在產品功能和質量上作出讓步
在不成熟組織中不存在判斷產品質量或者解決產品或過程問題的客觀基礎因此產
品質量難以預測當項目進度滯延時常壓縮或取消諸如審查和測試之類旨在提高質量的活
動
一個成熟如軟件組織具有全組織范圍的管理軟件開發和維護過程的能力軟件過程備準
確地傳達到現有職員和新雇員工作活動均按照安排的過程進行強制性的過程是適用的
[Humphrey 91b] 而且和實際工作的方式相一致必要時對這些已定義的過程進行更新并
且通過可控的先導性試驗和或費效分析進行改進在已定義的過程中整個項目和組織
的所有的崗位及其責任都是清楚的
成熟組織中經理監控軟件產品的質量和顧客的滿意程度在判斷產品質量和分析產品
及過程問題方面有可觀的定量的基礎進度和預算是基于以前的表現因而是切實可行的
通常能達到產品的成本進度功能和質量的預期結果一般之所以一個規范的過程得到
一致遵循是因為所有的參加者都了解這樣做的價值而且有著支持該過程的必要基礎設施
要想利用這些有關不成熟和成熟軟件組織的觀察結果需要構造一種軟件過程成熟度框
架該框架描述一條從無序的混亂的過程到成熟的規范的軟件過程的演進途徑若無此
框架改進大綱可能顯得無效因為尚未建立起支持連續改進的必要基礎軟件過程軟件
過程性能和軟件過程成熟度等概念集成一體就形成了軟件過程成熟度框架在下面幾段定
義中所有這些概念
1. 2 構成過程成熟度基礎的基本概念
根據Webster 韋柏字典過程process 是指生產某物時的操作體系能達到終點
或得到結果的一系列的活動變更或功能IEEE 把過程定義為針對給定目標所執行
的一連串步驟[IEEE-STD-610] 所以軟件過程可以定義為人們用已開發和維護軟件及
其相關產品例如項目計劃設計文件代碼測試用例用戶手冊等等的一組活動
方法慣例和變換隨著一組織走向成熟其軟件過程得到更好的定義并在整個組織內得
到更一致的實施
軟件過程能力描述通過遵循軟件過程能夠實現預期結果的程度一個組織的軟件過程能力提供一種預測該組織承擔下一個軟件項目時最終可能的預期結果的方法
軟件過程性能表示遵循軟件過程所達到的實際結果所以軟件過程性能側重于達到的
結果而軟件過程能力則側重于預期結果由于特定項目的屬性和執行該項目的背景所限
該項目的實際性能不可能充分反映組織的整個過程能力即項目的能力受限于它的環境例
如在應用領域所采用的技術上的重大改變可能造成該項目成員因知識所限使得他們的項目
能力和性能達不到該組織的整個過程能力
軟件過程成熟度是特定過程得以明確地定義管理測量控制和生效的程度成熟度
意味著能力上的增長潛力并且表明組織的軟件過程的豐富程度和它在整個組織的項目中運
用時的一致性在成熟組織中通常通過形成文件和進行培訓是全組織有關人員對軟件過程
都能很好了解并且使該過程得到其使用者不斷監控和改進成熟軟件過程的能力是已知的
軟件過程成熟度意味著由于運用組織的軟件過程使過程規范性協調地增強從而是組織的
軟件過程所導致的生產率和質量能隨時間的推移得到改進
隨著軟件組織的軟件過程成熟度的提高組織通過方針標準和組織機構將其軟件過程
制度化制度化需要建立一種支持業務活動的方法慣例和規程的基礎設施及社團文化使
得在最初規定方法慣例和規程的人員離去后這些方法慣例和規程仍能繼續下去
1. 3 能力成熟度模型概述
盡管軟件工程適和經理通常都非常清楚存在的問題但他們對哪項改進最為重要可能
意見不一致如果對改進工作沒有一項有組織的改進策略,要在管理者和專業人員間就首先
需進行哪些改進活動形成一致意見是很困難的為了使過程改進工作能不斷取得成效必須
設計一條發展路徑使組織的軟件過程成熟度按階段逐步提高軟件過程成熟度框架
[Humphrey 87a]將這些階段排序使每個階段上的改進能為下一階段的改進打下基礎于是
根據軟件過程成熟度框架描繪出的改進策略給過程不斷改進的歷程提供了一份導引圖它
指導組織前進并標示出其缺陷它的目的不在于對有麻煩的項目提供快速解決措施
軟件能力成熟度模型為軟件組織提供指導指導軟件組織如何加強對期開發和維護軟件
的過程的控制以及如何逐漸形成一種軟件工程和軟件管理的優秀文化CMM 的設計是為了指
導軟件組織通過確定當前的過程成熟度以及識別軟件質量和過程改進方面的少數幾個關鍵
問題來選定過程改進戰略通過致力于一些有限的活動和進取性工作去實現改進戰略一個
組織就可以穩步地改進其組織范圍的軟件過程從而使其軟件過程能力不斷持續提高
CMM 的分階段結構的基礎是已經存在了60 年的產品質量的原理1930 年Walter
Shewart 提出了統計質量學說他的學說得到W.Edards Deming[Deming86]和Joseph
Juran[Juran88,Juran89]進一步發展和成功驗證SEI把這些原理運用于成熟度框架這種
框架為軟件過程的定量控制奠定了項目管理和工程化基礎這也正是過程持續改進的基礎
運用了這些質量原理的成熟度框架首先見諸于Philip Crosby的著作Quality is Free
質量是免費的[Crosby79] Crosby 的質量管理成熟度粗框架采用質量慣例描述了5 個
漸進的階段在IBM的Watts Humphrey 指導下Ron Radice和他的同事把這種成熟度框架
運用到軟件中[Radice85] 1986年Humphrey 把這種成熟度框架帶到軟件工程研究所補充
了成熟度等級的概念為成熟度框架目前在整個軟件業界的使用奠定了基礎
在SEI的技術報告[Humphrey87a Hamphrey87b] 論文[Humphrey88]和Humphry 的著作
Managing the software Process 管理軟件過程中描述了Humphry的成熟度框架的早
期版本最早的成熟度問卷于1987 年發表作為一種工具向軟件組織提供表征其軟件過
程成熟度的特性的方法1987 年提出了兩種方法即軟件過程評估和軟件能力評價用
于評定軟件過程成熟度1990 年以來SEI 在政府和工業界眾多人員的幫助下根據在軟件過程改進中應用此模型的多年經驗進一步擴充和細化了它
2 軟件過程成熟度的五個等級
過程的不斷改進基于許多小的漸進的步驟而不是革命性的創新[Imail86] CMM 提
供了一個框架將這些漸進步驟組織成五個成熟度等級作為過程不斷改進的遞進基礎這
五個成熟度等級定義了一個順序尺度用以度量組織軟件過程成熟度和評價其軟件過程能
力這些等級還能幫助對其改進工作排出優先次序
成熟度等級是妥善定義的通向成熟軟件過程的漸進平臺每一個成熟度等級為過程繼續
改進提供一個臺基每一等級包含一組過程目標當目標得到滿足時軟件過程的一個重要
構件也就穩定下來每達到成熟度框架的一個等級就建立起軟件過程的不同的構件導致
組織過程能力的增長
將CMM組織成如圖2.1 所示的五個等級對旨在增加軟件過程成熟度的改進行動排出了
先后次序圖2.1 中帶有標注的箭頭指出在成熟度框架的每一步驟上組織將加以制度化的
過程能力的類型
下列的五個成熟等級的特性突出說明在每個等級上的主要過程變化
1 初始級 軟件過程的特點是特設的偶爾甚至是混亂的幾乎沒有什么過程是經過
定義的項目的成功依賴于個人的努力
2 可重復級 建立了基本的項目管理過程以便跟蹤成本進度和功能讀必要的過
程紀律已經就位使具有類似應用的項目能重復以前的成功經驗
3 妥善定義級 管理活動和工程活動兩方面的軟件過程均已形成文件加以標準化并
集成到組織的標準軟件過程中全部項目均采用供開發和維護軟件用的組織的標準軟件過程
的經批準的剪裁版本
4 定量管理級 有關軟件過程和產品質量的詳細度量資料得到采集無論軟件過程還
是產品均得到定量了解和控制
5 持續優化級 能利用來自過程的以及來自先導性創新思想和新技術的定量反饋信息
持續改進過程
2. 1 成熟度等級的行為特征
等級2 到等級5 成熟讀的特征可以通過以下幾方面表述組織為建立活改進軟件過程
而進行的活動圍繞每個項目所進行的活動和所形成的跨各項目的過程能力這里之所以列
出等級1 的行為特性是為了給較高成熟度等級提供過程改進比較的基礎
2.1.2 等級1 初始級
在初始級上組織一般不提供開發和維護軟件的穩定環境一個組織在缺乏健全的管理慣
例時會由于無效的策劃和反應一驅動式承若體系而降低由良好的軟件工程慣例帶來的效
益
情況緊急時項目一般會拋棄預定的規程并且轉到編碼和測試上去項目的成功完全依
賴于有一個杰出的經理及一支有經驗且能力強的軟件隊伍偶爾有能力和權威的軟件經理
能經受住他們在軟件過程中走捷徑的壓力但是當他們離開項目后他們能是過程穩定的影
響也隨之消失甚至一個強的工程過程也不能克服由于缺乏健全的管理慣例所造成的不穩
定等級1組織的軟件過程能力是不可預測的因為軟件過程隨著工作推進經常被改變或修
訂即過程是特設的進度預算功能度和產品質量一般是不可預測的過程性能依賴
于個人的能力且隨個人內在的技能知識和動機的不同而變化等級1 組織幾乎沒有明顯
的穩定的軟件過程只能通過個人的能力而不是組織的能力去預測性能
2.1. 2 等級2 可重復級
在可重復級上建立起了管理軟件項目的方針和實施這些方針的規程對新項目的策
劃和管理是以類似項目上的經驗為基礎在通向等級2 的過程中一個目標是使軟件項目的
有效管理過程制度化這使得組織能重復在以前項目上所開發的成功慣例文件化的已實
施的經過訓練的度量過的和能改進的
在第2級組織中項目設置了基本的軟件管理控制切實可行的項目承若是基于對以前
項目的觀察結果和當前項目的需求項目的軟件經理跟蹤軟件成本進度和功能度假如在
滿足承諾方面有問題一旦出現就可識別軟件需求和為實現需求而開發的工作產品形成了
基線并且其完整性受控軟件項目標準均已確定并且組織確保準切地執行這些標準如
果有分保商軟件項目與他們共同努力建立一種強有力的顧客供方關系
等級2組織的軟件過程能力可概括為有紀律的因為軟件項目的策劃和跟蹤是穩定的并
且能重復以前的成功經驗由于遵循了以前項目的表現為基礎的切實可行的計劃項目過程
處在項目管理體系的有效控制之下
2.1.3 等級3 妥善定義級
在妥善定義級上全組織的開發和維護軟件的標準過程包括軟件工程過程和軟件管理
過程已形成文件而且這些過程被集成為一協調的整體在整個CMM中均稱此標準過程為
組織的標準軟件過程等級3 上所建立的過程被用來適當時經更改幫助軟件經理和技
術人員更有效地工作組織通過使其軟件過程標準化可以有效利用軟件工程慣例在等級3
的組織里有一個負責本組織的軟件過程活動的組例如軟件工程過程組SEPG [Fowler90]
實施全組織的培訓大綱以保證職員和經理具有履行其職責所必須的知識和技能
項目通過剪裁組織的標準軟件過程建立他們自己的已定義的軟件過程以說明項目獨有
的特征在CMM 中這種剪裁后的過程稱作項目定義軟件過程一個已定義的軟件過程包含
一組協調的集成的妥善定義的軟件工程過程和管理過程妥善定義的過程可表征為具有
已準備就緒的用以開展工作的判據輸入標準和規程驗證機制例如同行審查輸出
以及完成判據因為軟件過程已妥善定義管理者就能洞察所有項目的技術進展
第3 級組織的軟件過程能力可概括為標準和一致的因為無論軟件工程活動還是管理活
動過程都是穩定的和可重復的在所建立的產品線內成本進度和功能度均受控制并且
軟件質量受到跟蹤這種過程能力建立在整個組織范圍內對規定的軟件過程中的活動崗位
和責任的共同理解之上
2.1.4 等級4 定量管理級
在定量管理級組織對軟件產品和過程都設置定量的質量目標作為組織度量大綱的一
部分針對跨所有項目的軟件過程活動測量生產率和質量利用一個全組織的軟件過程數據
庫收集和分析從項目定義軟件過程得到的數據在等級4上軟件過程配備有妥善定義的和
一致的度量這些度量為定量地評價項目的軟件過程和產品打下基礎,項目通過降旗過程性能的變化限制在定量的可接受的范圍之內實現對其產品和過程的
控制可以將過程性能方面有意義的變化與隨機變化噪聲區別開來特別是在所建立的
產品線內為提升到新應用領域的知識層次而帶來的風險是已知的并得到精心的管理
第4 級組織的軟件過程能力可概括為可預測的因為過程得到測量并在可度量的范圍內
運行該等級的過程能力使得組織能在度量的限制范圍內預測過程和產品質量的趨勢當超
過限制范圍時采取措施予以糾正軟件產品具有可預測的高質量
2.1.5 等級5 持續優化級
在持續優化級整個組織致力于不斷的過程改進為了預防缺陷出現組織有辦法是別
出弱點并預先加強過程利用軟件過程有效性方面的數據對新技術和組織軟件過程的更改建
議進行費效分析識別出采用最佳軟件工程慣例的技術創新并在整個組織推廣
在第5級組織中軟件項目組將分析缺陷以確定其發生的原因為了防止已知類型的缺
陷再次出現他們會評價軟件過程并且把經驗教訓告知其它項目
等級5組織的軟件過程能力可表征為不斷改進因為這些組織為該近期過程能力而不斷
進取從而不斷改善期項目的過程性能為了實現改進即通過現有過程的第金也通過那
些采取新技術和新方法的革新
2.2 理解成熟度等級
CMM 是一種敘述性模型在此意義下它描述那些預期用于表征某具體成熟度等級組織
的本質或關鍵屬性CMM 使一個規范模型在此意義下它的詳細慣例描述組織在政府
合同環境中從事大規模項目時預期具有的行為規范模型的特征這樣一來CMM就處在足夠
的抽象層次上使它不會不適當地限制一個組織如何是使軟件過程CMM僅描述那些通常預
期的軟件過程的本質屬性
在任何運用CMM的環境中均應該注意對于慣例的合理解釋當組織的業務環境明顯地
不同于大型合同組織的業務環境時必須運用所掌握的專業判斷力合理地解釋CMM
CMM 不是處方它并不告訴組織如何進行改進CMM 描述在每個成熟度等級上的組織特
征而沒有給出達到那個成熟度等級的具體方法從等級1 到等級2 可能需用幾年的時間
而在其它等級見得升遷通?；ㄙM約2 年時間
軟件過程改進發生在以下背景中組織的戰略計劃和經營目標它的組織機構所使用
的技術它的社會文化和它的管理體系CMM側重于全面質量管理工作的過程方面成功的
過程改進意味著涉及軟件過程之外的其它方面例如與改變組織文化有關的人員問題改
變組織文化使過程改進得以實現并且制度化
2.2. 1 理解初始級
盡管等級1 組織的特征常常表現為其過程是特定的,甚至是混亂的但他們也常常開發
出能工作的產品只不過它們可能會超過預算和拖延進度等級1組織的成功依賴于組織中
人員的能力和奮斗當然對所有成熟度等級的組織來說選擇雇用培養和或留住
有能力的人都是重要議題但它們已大大超出了CMM 的考慮范圍
2.2. 2.2.2 理解可重復級和明確定義級
隨著項目規模和復雜性的增長注意力從技術問題轉向組織問題和管理問題過程
成熟度的焦點問題[Siegel 90 DOD87 GAO-92-48] 通過將最優秀的員工的經驗教訓納入
文件化的過程通過培育為有效執行這些過程所需的技能通常以培訓的方式以及通過
不斷向從事該作業的人們學習而進行的持續改進過程能使人們工作得更為有效
為達到等級2 管理者必須致力于他們自己的過程使之成為有紀律的軟件過程等級2
是等級3 的基礎因為在處理等級3上的技術和組織問題之前側重點放在忙于改進其過程
的管理者上在實現等級2 的過程中通過將項目管理過程編制成問兼并遵照執行管理者
建立起領導地位
在等級2 組織中不同項目的過程可能不同為了達到等級2 對組織方面的要求是拿
出方針在建立合適的管理過程中指導項目文件化的規程是協調的過程的基礎在培訓和
軟件質量保證工作的幫助下能在全組織范圍內使這些過程制度化
通過對完整的軟件過程加以定義集成和文件化使等級3建立在這種項目管理基礎之
上在此情況下集成意味著一個作業的輸出順利地成為下一個作業的輸入當作業存在不
匹配現象時在軟件過程的策劃階段它們就得到識別和處理而不是等到實施過程中遇到它
們時等級3 的一個挑戰是如何做到構造的過程使軟件人員能在一定的自由度下工作
[Humphrey 91b]
2.2.3 理解定量管理級和持續優化級
成熟度等級4 和等級5 對軟件業來說還是一個相對未知的領域僅有少數幾個等級4
和等級5 的軟件項目和組織[Humphrey 91a Kitson902] 由于現有的實例太少還不能得出
等級4和等級5組織特征的普遍性結論通過與其它行業類比和利用軟件業界中顯示出這些
等級過程能力的少數例子給這些等級的特征作了規定
等級4和等級5的許多特征建立在圖2.2說明的統計過程控制概念的基礎上朱蘭三部
曲圖[Juran 88]顯示過程管理的主要目標
Juran將質量管理分成三個基本管理過程[Juran 88] 質量策劃的目的是向操作隊伍
即軟件生產者提供生產出能滿足顧客需求的產品的方法操作隊伍生產產品但由于質量
缺陷不得不做某些返工這種浪費是經常性的因為過程就是那樣安排的執行質量控制
只是為了防止事情惡化過程中的偶發尖峰如圖2.2所示代表消防活動經常性的浪費
提供了改進的機會抓住這個機會進行工作就叫質量改進
質量改進的首要責任也是等級4 的關注焦點是過程控制管理軟件過程使之在質量
控制帶內穩定運行雖然必定還有一些經常性的浪費測量結果中可能還有偶發性尖峰需要
控制但是系統在整體上是穩定的在這種場合控制特殊變因的概念發揮作用因為過程
即穩定又可測所以當出現某些例外情況時能夠識別并處理特殊變因
質量改進的第二個責任也是等級5的關注焦點是過程的不斷改進變更軟件過程已
提高質量質量控制區隨之移動建立新的減少經常性浪費的性能基線在改進這個過程中
所得到的經驗教訓被運用到策劃未來的過程中去在這種場合處理共性編印的概念有了用
武之地僅僅由于隨機變化在任何體系中均存在返工形式的經常性的浪費浪費是不能容
忍的有組織的消除浪費的工作導致更改體系也就是通過克服造成低效的共性原因來
改善過程以防止出現浪費
我們期望達到CMM最高成熟度等級的組織具有能在可預計的成本和進度的限度內生
產出級可靠的軟件的過程隨著對較高成熟度等級理解的加深將對已有的關鍵過程方面加
以提煉也可能給模型添加些內容CMM是從制造業中產生的過程思想演變而來的但是軟
件過程不像制造業過程那樣以復現問題占主導地位軟件過程以設計問題占主導地位而且是知識密集型的活動[Crutis 88]
2.3 軟件過程的可視性
軟件工程師們對項目狀態有詳細而深入的了解因為他們掌握有關項目狀態和表現的第
一手材料可是對于大項目他們的洞察力通常僅來源于在其中職責范圍內的個人經驗
項目以外的不掌握第一手材料的人例如高級經理對項目過程缺乏可視性為得到他們監
視項目進程所需要的信息只得依靠定期的審查圖2.3示出在過程成熟度的每個等級上顯示
給管理者的項目狀態和表現的可視性程度隨成熟度等遞增軟件過程可視性亦提高
等級1的軟件過程是一種混濁體一個黑盒項目過程的可視性受到限制由于活動
階段的劃分做的差經理們極難確定項目進程和活動狀態
需求以不受控的方式進入軟件過程然后出產品軟件開發常被看作為不可知的魔術
特別對不熟悉軟件的經理而言更是如此
等級2上顧客需求和工作產品受到控制已經建立其基本的項目管理慣例這些管理
控制使得項目在規定點可視構造軟件的過程可看作一連串黑盒子隨著活動在盒子間流動
在各過渡點項目里程碑上具有管理可視性盡管管理者可能不知道盒子內發生事情的細
節但是過程的產品和用以證實過程正在運行的檢驗點都是確定和已知的當問題出現時
管理者能對它們作出反應
等級3上盒子的內部結構即項目規定的軟件過程中的作業是可視的該內部結構
反應處在具體項目上運用組織的標準軟件過程的方式經理們和工程師們都了解他們在過程
中的崗位和責任知道他們的活動如何在相當的細節層次上相互影響管理者對可能發生的
風險預先有準備由于已定義的過程提供對項目活動很好的可視性所以項目外的人能準確
而及時地得到狀態更新信息
等級4上已定義的軟件過程具備定量特性并受到定量控制經理們能夠度量進度和問
題他們作決策時有一個客觀的定量的基礎隨著過程的變異性越來越小他們預測結果
的能力穩定增長變得越來越準確
等級5上為了提高生產率和質量以受控的方式不斷嘗試新的和改進的構造軟件的方
法隨著無效的或者以出錯的活動得到標識和替代或修改有紀律的更改成為一種生活方式
洞察立延展到現行過程以外并且能深入了解潛在變更的作用經理們能定量的估計更改的
影響和有效性然后跟蹤它們
2.4 過程能力和性能預測
一個組織的軟件過程成熟度有助于預測項目達到其目標的能力在等級1 組織中各個
項目在達到成本進度功能度和質量目標方面差別很大如圖2.4 中的例子所示隨著組
織的軟件過程愈趨成熟可看出在滿足預定目標方面有三個改進之處
首先隨著成熟度增長所有項目的預定結果與實際結果間的差異減小例如如果有
十個相同規模的項目預定在5月1 日交付那么隨著組織的成熟它們交付的平均日期會越
來越靠近5月1日等級1 組織常常會大大拖延其最初安排的交付日期而等級5的組織應
該能相當準確地滿足預定日期要求這是因為等級5 組織采用仔細構造在已知參數內運行
的軟件過程而且確定目標日期是基于它們擁有的有關其過程的大量數據以及它們在運用其
過程時的表現此段含義在圖2.4 中用目標日期線右邊曲線下的面積大小表示
其次隨著成熟度增長實際結果相對預定結果的偏差減小例如等級1組織中規
模類似的項目的交付日期不可預測其變化很大而等級5組織中的類似項目的交付日期的變化范圍小得多之所以在最高成熟度等級上變化范圍很小原因在于所有的項目實際上
均是針對成本進度功能度和度量等在那些引導本組織過程能力的受控參數內運行此
層含意在圖2.4 中以曲線下方集中于目標線附近的面積大小表示
第三隨著組織成熟度的增長預定結果得到改善這就是說隨著軟件組織的成熟
成本降低開發時間縮短生產率和質量提高在等級1 上的組織其開發時間可能十分長
因為必須大量糾錯返工相反等級5 組織采用持續的改進過程和缺陷預防技術增加過程有
效性和消除費錢的返工使開發時間縮短這層含意在圖2.4 中反映在目標線距原點的水
平距離上
圖2.4中表示的在預測項目結果方面的改進基于以下假定即隨著噪聲通常以返工
形式出現從軟件過程中消除軟件項目結果也就更可預測無先例的系統會使情況變得復
雜因為新的技術和應用將增加可變性從而降低過程能力不過即使在無先例系統的情
況下與比較不成熟的組織相比較成熟組織的管理和工程慣例的特性有助于在卡發周期的
較早階段識別和處理問題較早查出缺陷能消除后面階段的返工從而提高項目的穩定性
和性能在成熟的過程中風險管理是項目管理的必不可少的部分在某些情況下一個成
熟的過程意味著在軟件生存周期的早期識別處失敗項目使得在無望的事情上的投資最
小
2.5 跳越成熟度等級
CMM 中的成熟度等級描述處于某個成熟度等級的組織的特征前面的等級為后續等級奠
定基礎為有效地實施過程提供支持不過如果有益組織也可以使用比它們所在等級高
的那些成熟度等級中所描述的過程例如雖然CMM中在等級3以前不論工程過程諸如
需求分析設計編碼和測試但是甚至等級1 組織都必須進行這些活動在有利時等級
1 或等級2組織可以進行同行審查等級3 的巴羅特Pareto 分析等級4 的或者
引入新技術等級5 的在說明一個組織為了從等級1 提高到等級2 應采取哪些步驟時
一個常有的建議是建立軟件工程過程小組二者是等級3 組織的屬性雖然度量是等級4
的關注焦點但它也是較低成熟度等級的必備部分
這些過程只有在適當基礎上才能發揮其潛力例如同行審查只有在統一實施的情況下
才能充分發揮作用即使燃眉之急的項目也是如此成熟度等級之描述某個等級上占主導地
位的問題等級1 組織的占主導地位的問題等級1 組織的占主導地位的問題是管理因為
難以策劃和管理軟件項目而掩蓋了其它問題
因為每個等級時到達一級的必要的基礎因此跳越等級將適得其反CMM確定的幾個
等級一個組織必須逐步經歷才能建立優秀的軟件工程文化沒有合適基礎的過程會迫于壓
力而在最需要它們的時刻失去作用它們也不給未來改進提供基礎
等級1組織若在建立可重復過程等級2 之前試圖去實施已定義的過程通常不會
成功因為項目經理會被進度和成本的壓力壓垮這是在關注工程過程之前應首先集中注意
力于管理過程的基本原因乍看起來定義和實踐工程過程似乎要比定義和實施管理過程容易
特別在技術人員眼中但是如果沒有管理紀律工程過程會成為進度和成本等壓力的犧
牲品[Humphrey 88]
一個尚無已定義過程作為基礎就試圖實施定量管理過程等級4 的組織通常是不成功
的因為沒有已定義的過程就沒有解釋度量的共同基礎雖然可以采集各個項目的數據但
幾乎沒有什么度量對其它項目有重大意義也不能顯著地增加組織對軟件過程的理解缺少
已定義過程時由于接受度量的過程自身的變化要件別處有意義的度量時困難的
一個尚無定量管理過程等級4 作為基礎就試圖實施持續優化過程等級5 的組織
由于缺乏對過程更改所產生的后果的了解多半會失敗若不能把過程控制在統計意義上狹
窄的范圍內即過程度量變化的情況下數據中噪聲太多以致不能客觀地確定某具體的過
程改進是否有效因為幾乎沒有定量基礎用于作出理性的有根據的決策決策可能退化為
聽天由命
過程改進工作應該關注本組織在其業務環境的背景中的需要那種實施較高成熟度等級
的過程的能力并不意味著可以跳越成熟度等級
3 CMM 的操作定義
CMM 是一個框架對那些希望提高其軟件過程能力的組織來說它展示一條推薦的改
進路徑為了支持使用CMM 的多種方法設計了CMM的操作細節至少有四中CMM 的用法受
到支持
評估組運用CMM 去識別組織中的強項和弱項
評價組運用CMM 確定在各個承包商中選擇授予業務時的風險和監控合同
經理和技術人員運用CMM去理解那些對于策劃和實施其組織的軟件過程改進大綱來說必
不可少的活動
過程改進組例如SEPG 軟件工程過程小組運用CMM 作為指南幫助他們定義和改
進其組織的軟件過程
因為CMM 有多種用法所以必須將它分解得足夠細以便能從成熟度等級的結構推
導出對實際過程的建議這種分解也指出那些能反映軟件過程能力的特征的過程及其結構
3.1 成熟度等級的內部結構
每個成熟度等級能分解為若干構件除第一級外每個成熟度等級均從等級的抽象概
要向下分解至它們得以關鍵慣例形式出現的可操作定義如圖3.1所示每個成熟度等級有
幾個關鍵過程方面組成每個關鍵過程方面又按五個稱為公共特性的部分加以組織公共特
性規定關鍵慣例當這些關鍵慣例均得到實施時就能實現關鍵過程方面的目標
3.2 成熟度等級
成熟度等級時妥善定義的通往成熟軟件過程的前進平臺正如圖2.1 所示每個成
熟度等級指示過程能力的一個等級例如在等級2 上通過建立健全的項目管理控制組
織的過程能力已經從無序狀態提高到有紀律的狀態
3.3 關鍵過程方面
除等級1 外每個成熟度等級被分解成幾個關鍵過程方面指明為了改進其軟件過程
組織應關注的方面關鍵過程方面標識出為了達到某個成熟度等級所必須著手解決的問題
每個關鍵過程方面標識出一串相關的活動當這些活動全部完成時能達到一組對增強
過程能力來說相當重要的目標如圖3.2所示這些關鍵過程方面已被規定駐留在各個成熟
度等級上 達到關鍵過程方面目標的途徑可能因項目而異這是因為在應用領域或環境上
有差異不過為了使得組織實現某個關鍵過程方面必須達到該關鍵過程方面的全部目標
當持續跨項目實現了某個關鍵過程方面的目標時可以說該組織便已經使以此關鍵過程方
面為特征的過程能力制度化了形容詞關鍵意味著存在對于實現某個成熟度等級來說非關鍵的過程方面和若干過
程CMM 并不細述所有與開發和維護軟件有關的過程方面已經確定出某些過程方面為過
程能力的關鍵CMM 中描述的正是這些過程方面
盡管其它問題也影響過程性能但我們只確定關鍵過程方面這是因為它們對改進組織
軟件過程能力很有效可以認為它們時達到某成熟度等級的必要條件圖3.2 顯示每個成熟
度等級的關鍵過程方面為了實現一個關鍵過程方面必須達到該關鍵方面的每一個目標
目標概括一個關鍵過程方面的關鍵慣例并且可用來確定一個組織或一個項目是否以有效的
實現該關鍵過程方面目標表明每個關鍵過程方面的范圍邊界和意圖
隨著組織達到過程成熟度的更高等級每個關鍵過程方面上將執行的具體慣例將有所發
展例如等級2 上軟件項目策劃關鍵過程方面所描述的項目估計能力中由許多項必須
發展才能處理在等級3 4 5 上附加的項目數據可用性當采用已定義軟件過程來管理項
目時等級2 的軟件項目策劃及軟件項目跟蹤和監督進化為等級3上的集成軟件
管理
CMM 的關鍵過程方面反應一種描述組織如何成熟的方法這些關鍵過程方面是在軟件工
程和軟件管理方面多年的經驗和五年多軟件過程評估和軟件能力評價方面的經驗的基礎上
確定下來的
等級2 上的關鍵過程方面集中關注軟件項目所關心的與建立基本項目管理控制有關的
事情下面是等級2 上每個關鍵過程方面的描述
!" 需求管理的目的是在顧客和軟件項目之間建立對將由該軟件項目處理的顧客需求
的共同理解與顧客的協定是策劃如軟件項目策劃中所描述的和管理如軟件項目跟蹤
和監督中所描述的軟件項目的基礎對與顧客關系的控制依靠遵循有效的更改控制過程如
配置管理中所描述的
!"軟件項目策劃的目的是制定出按之進行軟件工程和管理軟件項目的切實可行的計劃這
些計劃是管理軟件項目的必要基礎如軟件項目跟蹤和監督中所描述的沒有切合實
際的計劃不可能實施有效的項目管理
!"軟件項目跟蹤和監督的目的是建立適當的對實際進展的可視性使管理者在軟件項目性
能顯著偏離軟件計劃時能采取有效的措施
!"軟件子合同管理的目的是選擇合格的軟件分包商并有效地管理它們它把用于基本管
理控制的需求管理軟件項目策劃以及軟件項目跟蹤和監督的關鍵過程方面所關注的事
情與軟件質量保證和軟件配置管理等過程方面中的必不可少的協調結合在一起并且當
合適時對分包商運用這種基本管理控制
!"軟件質量保證的目的時給管理者提供對于軟件項目正在采用的過程和正在構造的產品
的適當的可視性軟件質量保證是絕大多數軟件工程過程和管理過程的不可缺少的部
分
!"軟件配置管理的目的是在項目整個軟件生存周期中建立和維護軟件產品的完整性軟件
配置管理是絕大多數軟件工程過程和管理過程的不可缺少的部分
等級3 的關鍵過程方面既涉及項目問題又涉及組織的問題這是因為組織建立起使
跨項目的有效的軟件工程和管理過程制度化的基礎設施下面是等級3 上每個關鍵過程方面
的描述
!"組織過程聚焦的目的是針對哪些旨在改進本組織整體軟件過程能力的各項軟件過程活
動確定組織責任組織過程焦點活動的主要結果使一組軟件過程財富它們的組織過程
定義中描述這些財富按集成軟件管理中所述供軟件項目使用
!"組織過程定義的目的是開發和保持一組便于使用的軟件過程財富用以改進跨項目的過
程性能并且為組織的長期累積性得益奠定基礎這些財富提供一組穩定的基本原則通過諸如培訓等機制能使其制度化培訓在培訓大綱中加以描述
!"培訓大綱的目的是培育個人的技能和知識使得他們能有效地和高效率地履行其職責
盡管培訓是組織的責任但是軟件項目應該是別出它們所需要的技能并且當項目有獨
特需要時該項目應提供必要的培訓
!"集成軟件管理的目的是將軟件工程活動和管理活動集成為一個協調的已定義的軟件過
程該過程通過剪裁組織的標準軟件過程和組織過程定義中所描述的相關的過程財富而
得到剪裁應以項目的業務環境和技術需要為基礎如軟件產品工程中所述集成軟件
管理是從等級2的軟件項目策劃和軟件項目跟蹤和監督進化而來
!"軟件產品工程的目的是一致地執行一個妥善定義的工程過程該工程過程集成全部軟件
工程活動以便能有效地和高效率地生產正確的一致的軟件產品軟件產品工程描述
項目的技術活動例如需求分析設計編碼和測試
!"組間協調的目的是確定軟件工程組織積極參與其它工程組工作的方法以便更有效地和
高效率地滿足顧客的需求組間協調是集成軟件管理在軟件工程之外的跨學科方面的延
伸不僅應該集成軟件過程而且軟件工程組和其它組之間的相互作用也必須加以協調
和控制
!"同行審查的目的是及早和高效地除去軟件工作產品中的缺陷一個重要的必然作用是增
強對軟件工作產品和可預防的缺陷的了解同行審查是軟件產品工程中使用的一種重要
而又有效的工程方法可運用法根式檢查Fagan-style檢查[Fagan 86] 結構式走
查或者一些其它的學院式的審查方法[Freedman 90]實施
等級4 上的關鍵過程方面的關注焦點是建立起對軟件過程和正在構造的軟件工作產品
的定量了解該等級上的兩個關鍵過程方面定量過程管理和軟件質量管理是相互緊
密依賴的說明如下
!"定量過程管理的目的是定量地控制軟件項目的過程性能軟件過程性能表示遵循某個軟
件過程所得到的實際結果焦點是在可測的穩定的過程范圍內找出變化的具體原因并
且是當時改正那些促成發生瞬時變化的環境定量過程管理給組織過程定義集成軟件
國力組間協調和同行審查的各項慣例附加一個綜合測量計劃
!"軟件質量管理的目的是建立對項目的軟件產品質量的定量了解和實現特定的質量目標
軟件質量管理對軟件產品工程中所描述的軟件工作產品實施綜合測量計劃
等級5 上的關鍵過程方面覆蓋的問題包括那些為了實現持續的和可度量的軟件過程改
進而必須由組織和項目處理的問題下面是等級5 的每個關鍵過程方面的描述
!"缺陷預防的目的是識別缺陷的原因并防治它們再次出現如集成軟件管理中所述軟件
項目分析缺陷識別其原因并更改項目定義軟件過程如過程變更管理中所述應將具
有普遍價值的過程更改傳播到其它軟件項目
!"技術變革管理的目的是識別出能獲益的新技術即工具方法和過程并以有序的方式
將它引進到組織中如過程變更管理中所述技術變更管理的關注焦點是在不斷變化的
環境里高效率地革新
!"過程變更管理的目的是持續地改進組織中所采用的軟件過程以便改進軟件質量提高
生產率和縮短產品開發周期過程變更管理即采用缺陷預防的增量式改進又采用技術變
更管理的創新式改進并使得整個組織可以享用這些改進
3.4 公共特性
為方便起見各個關鍵過程方面按公共特性加以組織公共特性使那些表明某個關鍵
過程方面的實施和制度化是否有效可重復且持久的屬性五個公共特性如下
執行承諾 執行承諾描述組織為確保過程得以建立和持續起作用所必須采取的措施
執行承諾一般包含確定組織的方針和高級管理者的支持
執行能力 執行能力描述為了能完滿實施軟件過程項目或組織必須具備的先決條件
執行的活動一般包括資源組織結構和培訓
執行的活動 執行的活動描述的是為實現某個關鍵過程方面所必需的崗位和程序
執行的活動一般包括制定計劃和規程進行工作跟蹤它并在需要時采取糾正措施
測量和分析 測量和分析描述對過程進行測量和對測量結果進行分析的需要測量和
分析一般包括一些了確定執行的活動的狀態和有效性所能在用的測量的例子
驗證實現 驗證實現描述那些用以確保各項活動遵照已建立的過程進行的步驟驗證
一般包括管理者和軟件質量保證部門所作的評價和審核
在執行的活動這一公共特性中的各項慣例描述為了建立過程能力必須作些什么其它的
各項慣例作為一個整體形成一個使組織能將執行的活動中所描述的各項慣例制度化的基礎
3.5 關鍵慣例
每個關鍵過程方面用一些可對實現其目標作出貢獻的關鍵慣例加以描述關鍵管理描
述對關鍵過程方面的有效實施和制度化貢獻最大的基礎設施和活動
每個關鍵慣例由一句話組成往往再加上較為詳細的描述可能還包括例子和詳細細節
這些關鍵慣例又稱為頂層關鍵慣例說明關鍵過程方面的基本方針規程和活動進行詳
細描述的部分常稱作子慣例圖3.3 給出軟件項目策劃關鍵過程方面中一個關鍵慣例的內部
結構的例子
如圖3.3 所示為了確保一致地實現使那些用于策劃和跟蹤項目的計劃文件化這一目
標組織必須建立一個文件化的規程用以指導對軟件規模的估計由于看不出在估計規模使
各種假設之間的差別如果不根據文件化的規程導出這些估計那么估計值可能會在很大范
圍內變化這類規程應該包括使用以前的規模數據要求各種假設形成文件和對估計進行審
查這些準則對于在判斷是否遵循合理的規模估計規程時提供指導
關鍵慣例描述要做什么而不應解釋為強制性的應該如何實現目標換用別的
慣例也可能實現該關鍵過程方面的目標應該合理地解釋關鍵慣例以便判斷關鍵過程方面的
目標是否已被有效地實現盡管實現目標的方式可能不同能力成熟度模型的關鍵慣例
1.1 版[Paulk 93b]中包含各項關鍵慣例極其解釋指南
4 運用CMM
CMM 建立一組公眾可用的描述成熟軟件組織特征的準則組織能運用這些準則去該近
期開發和維護軟件的過程政府或商業組織能用他們去評價與某具體公司簽訂軟件項目合同
時的風險
本章集中于SEI研制的用以評價一個組織執行的軟件過程的成熟度的兩種方法軟件過
程評估和軟件能力評價
!"軟件過程評估 用于確定一個組織的現行軟件過程的狀態確定組織所面臨的具有搞
優先級的與軟件過程有關的問題和獲得組織對軟件過程改進的支持
!"軟件能力評價 用于識別有資格完成軟件工作的承包商或者監控現有軟件工作中所運
用的軟件過程的狀態
此概述本身不足以指導讀者進行評估或評價任何希望通過這兩各方法去運用CMM
的人應該請求得到有關評估和評價培訓的進一步的信息
CMM 是軟件過程評估和軟件能力評價的共同基礎可是這兩種方法的目的十分不同因
此具體用法存在重大差異但是兩者又都基于CMM 模型及從它導出的產品CMM加上基于CMM
的產品能使這些方法得到可靠且一致的運用
4.1 軟件過程評估和軟件能力評價方法
軟件過程評估致力于找出組織自己的軟件過程的優先改進之處評估組用CMM 指導
他們找出值得改進之出并進行優先級排序這些調查發現與CMM中的關鍵慣例所提供的指導
一起被例如軟件工程過程小組用來策劃組織的改進策略
軟件能力評價致力于識別與某項要求在規定的進度和預算內構造出高質量軟件的特定
項目或合同相聯系的風險在采辦過程中可以對投標者進行軟件能力評價評價的發現如
CMM 所設計的那樣可以用于確定在挑選特定承包商時的風險也可對現行的合同進行評價
以便監控它們的過程性能其目的是在承包商的軟件過程中識別出潛在的可改進之處
CMM 為進行軟件過程評估各軟件能力評價建立一個共同的參考框架雖然這兩種方法的
目的不同但均采用CMM作為評定軟件過程成熟度的根據圖4.1概要描述評估和平加重的
共同步驟
第一步是選擇工作組對該組進行CMM 基本要領和評估或評價方法細節的培訓改組的
成員應具有豐富的軟件工程和管理方面知識
第二步是讓待評估或待評價單位的代表填寫成熟度問卷和按其它診斷工具的要求做一
旦完成此項活動評估或評價組就對回復的情況進行分析第三步即對問卷響應計分
并確定必須作進一步探究的方面待探究的方面與CMM 的關鍵過程方面相對應
現在該組已準備好訪問被評估或評價單位的現場第四步從響應分析的結果著手
該組進行采訪和審查文件以便了解該現場所遵循的軟件過程CMM 中的關鍵過程方面和關鍵
慣例指導改組成員進行提問傾聽并且審查和綜合得自采訪和文件中的信息在確定現場的
關鍵過程方面的實施是否滿足相關的關鍵過程方面的目標時該組需要運用專業性的判斷
當CMM的關鍵慣例與現場的慣例間存在明顯差異時該組必須把它用于判斷此關鍵過程方面
的理論依據形成文件
在現場工作階段結束時該組寫出調查發現清單第五步標識出該組織軟件過程的
強項和弱項在軟件過程評價中這些調查發現成為提出過程改進建議的基礎在軟件能力
評價中調查發現成為采辦單位所作的風險分析的一部分
最后該組給出一份關鍵過程方面概貌第六步顯示出該組織已滿足和尚未滿足關
鍵過程方面目標的那些地方某個關鍵過程方面可能已得到滿足但仍有一些相關的調查發
現前提是這些調查發現并未反應儲存在有障礙于實現該關鍵過程方面的任何一個目標的重
大問題
歸納起來軟件過程評估和軟件能力評價方法兩者均
!" 采用成熟度問卷作為現場訪問的出發點
!" 采用CMM 作為指導現場調查研究的路線圖
!" 按CMM 中的關鍵過程方面書寫那些標識軟件過程強項和弱項的調查發現
!" 在對關鍵過程方面目標滿足情況進行分析的基礎上進一步得出該關鍵過程方面
的概貌
!" 用調查發現和關鍵過程方面概貌向相應的被審核對象提出結論意見
4.2 軟件過程評估和軟件能力評價之間的差異
盡管由這些相似之處但軟件過程評估或軟件能力評價的結果可能不同甚至在相繼運用相同的方法的情況下也是如此一個原因是評估或評價的范圍可能變化首先必須確
定受調查的組織對大公司而言可能對組織有幾種不同的定義組織的范圍可能基于
有共同的高級管理者共同的地位位置指定的盈虧中心共同的應用領域或者其它考慮
其它甚至在似乎是相同的組織中所選項目的樣本也可能影響范圍評估可能對公司中的
一個部門進行評估組是在全部門的范圍的出其調查發現后來可能對該部門中的一條產
品線進行評價評價組的調查發現得自一個窄得多的范圍不了解背景而對結果作比較是成
問題的
軟件過程評估和軟件能力評價在動機目的輸出和結果的所有權上均不同這些因素
導致在采訪的動因詢問的范圍所采集的信息和結果的表示方式上有本質的不同驗看所
采用的詳細規程可發現評估和評價的方法大小不相同經過評估培訓的小組做不了評價
反之亦然
軟件過程評估是在開放合作的環境中進行的評估的成功靠的是管理者和專業人員兩
方面關于要改進本組織的承諾評價目的在于暴露問題和幫助經理和工程師改進他們的組
織盡管問卷有助于使評估組關注成熟度等級問題但是終點仍應放在預先安排的和隨意的
采訪上把它作為了解組織軟件過程的工具除了識別組織所面臨的軟件過程問題外評估
的最有價值的結果是為改進贏得支持全組織范圍關注過程以及在執行改進行動計劃上的
動力和熱情
另一方面軟件能力評價在更為面向審核的環境中進行評價目的與金錢密切相關因
為評價組的推薦將幫助挑選承包商或設置獎金重點放在形成文件的審核記錄上它們揭示
組織實行執行的軟件過程
4.3 CMM 在過程改進方面的其它用法
對軟件工程過程組SEPG 或試圖改進其軟件過程的其它組來說CMM 在改進措施
的策劃上行動計劃實施上和過程定義上有著特殊的價值在策劃改進措施期間具有有關
其軟件過程問題和業務環境得知使得軟件工程過程組的成員可將CMM 中關鍵過程方面的目
標與其現行的慣例相比較對于各個關鍵慣例應該結合公司目標管理優先級該慣例的性
能水平實施每個慣例對組織的價值以及該組織在其文化背景下實施某慣例的能力等加以審
視
接下來軟件工程過程組必須確定需要做那些過程改進如何實現更改以及如何獲得必要
的支持CMM通過給有關過程改進的討論提供起始點和幫助揭示關于普遍接受的軟件工程慣
例的那些面目全非的假定從而對這項活動提供幫助在實施行動計劃時該過程組可用
CMM 和關鍵慣例來擬制部分可操作的行動計劃和定義軟件過程
5 CMM 的未來發展方向
向軟件過程成熟度的更高等級攀登是漸進的過程要求對不斷改進過程又長期的支持
軟件組織可能用十年或更長的時間為持續的過程改進奠定基礎和建立前瞻性文化雖然對絕
大多數美國公司來說長達十年的過程改進計劃是陌生的但是為了成為成熟軟件組織這
種層次的努力是必要的這個時間框架與其它行業例如美國的汽車制造業的經驗相一致
它們在過程成熟度上已取得重大的進展[Gabor 90]
5.1 CMM 不覆蓋什么
CMM 不是無所不包的[Brooks 87] 它并不涉及對成功項目來說是重要的所有問題例
如CMM目前并未涉及特定應用領域內的專門知識也未提倡具體的軟件技術或者就如何選
擇雇用激勵和留住有能力的人提出建議雖然這些問題對項目的成功至關重要其中一
些已在其它背景中進行了分析[Curtis 90] 可是尚未將這些問題綜合到CMM 中CMM是為
了提供一個條理分明有條不紊的框架以便在此框架內闡述軟件管理過程和工程過程的問
題而專門研制的
5.2 近期活動
在遍及美國的主要會議和研討會上經常舉辦CMM 短訓班及講座以確保軟件業界對
CMM 及其相關聯的產品有足夠的了解正在開發和或修改基于CMM的工具例如成熟
度問卷軟件過程評估培訓和軟件能力評價培訓以便納入到CMM 中去
CMM 開發活動的近期關注焦點是那些經剪裁的CMM版本例如適用于小項目和或小
規模組織的CMM CMM1.1版是用那些與政府簽訂大型合同的組織的標準慣例表達的這些慣
例必須加以剪裁才適合不同于這個樣板的組織的需要
5.3 長期活動
在以后的幾年內通過在軟件過程評估和軟件能力評價中不斷使用CMM CMM 將繼
續經受廣泛的檢驗適當時將研制和修定基于CMM 的產品和培訓資料CMM是一份將得到
改進的文件但是與其至少直到1996 年CMM1.1 版將仍然是基線這樣救災對穩定性和不斷
改進的需要之間提供合適的和切合實際的平衡
對于CMM 的下一個版本版本2.0SEI將其注意力轉向改進整個模型雖然模型的所有
等級都可能被修改但重點放在等級4 和等級5 上目前已非常完備地規定了等級2 和等級
3 的關鍵過程方面由于沒有幾個組織經評估是處在等級4 或等級5 上的[Humphrey 91a
Kitson 92] 所以對這類組織的特征知之甚少SEI 正與力求了解和達到等級4 和等級5 的
組織密切合作將對這兩個等級的慣例進行推敲CMM也可能成為多維的以便處理技術和
人力資源的問題
5.4 結論
正如持續改進之于軟件過程那樣持續改進也適用于成熟度模型和慣例必須考慮到
CMM 的更改對軟件界的潛在影響但是CMM 成熟度問卷和軟件過程評估及軟件能力評價方
法等將隨著有關軟件過程改進方面經驗的不斷積累而不斷地進化SEI 打算在推進此項進化
上繼續與工業界政府和學術界緊密合作
CMM提供了一種以有條不紊的和一致的方式改進軟件產品的管理和開發的概念性結構
但是它并不能保證軟件產品將成功地構造出來或者保證恰當地解決全部軟件工程中的問
題雖然CMM確定了成熟軟件過程的管理和提供某些當前慣例水平并且在某種情況下是
當前技術水平的例子但是這并不意味著它是詳盡無漏的或是可以強制執行的CMM只標
識出有效軟件過程的特征但是成熟組織必須致力于對成功項目來說是必不可少的全部問
題包括人技術和過程

原文轉自：http://www.kjueaiud.com