cmmi五個成熟度級別

1、CMMI 等級的含義 五個成熟度級別之間的比較如下: 1,初始級 特征: (1)軟件過程的特點是雜亂無章,有時甚至混亂.幾乎沒有定義過程的規(guī)則或步 驟. (2)過分的盡諾.常做出良好的承諾:如"按照軟件工程方式,有序的工程過程來 工作"或達到高目標的許諾.但實際上卻出現(xiàn)一系列危機. (3)遇到危機就放棄原計劃過程,反復(fù)編碼和測試. (4)成功完全依賴個人努力和杰出的專業(yè)人才,取決于超常的管理人員和杰出有效 的軟件開發(fā)人員.具體的表現(xiàn)和成果都源于或者說是決定于個人的能力和他們先前的 經(jīng)驗,知識以及他們的進取心和積極程度. (5)能力只是個人的特性,而不是開發(fā)組織的持性.依靠著

2、個人的品質(zhì)或承受著巨 大壓力,或找竅門取得成果.但此類人一旦離去,對組織的穩(wěn)定作用也消失. (6)軟件過程是不可確定的和不可預(yù)見的.軟件成熟性程度處于第一級的軟件組織 的軟件過程在實際的工作過程中被經(jīng)常的改變(過程是隨意的).這類組織也在開發(fā)產(chǎn) 品,但其成果是不穩(wěn)定的,不可預(yù)見的,不可重復(fù)的.也就是說,軟件的計劃,預(yù) 算,功能 和產(chǎn)品的質(zhì)量都是不可確定和不可預(yù)見的. 過程: (1)極少存在或使用穩(wěn)定的過程.(2)所謂"過程",往往是"就這么干"而言. (3)各種條例,規(guī)章制度互不協(xié)調(diào),甚至互相矛盾 人員: (1)依賴個人努力和杰出人物.一旦優(yōu)秀人物離去,

3、項目就無法繼續(xù) (2)人們的工作方式如同"救火".就是在開發(fā)過程中不斷地出現(xiàn)危機,以及不斷 的"救火". 技術(shù): 引進新技術(shù)是極大風(fēng)險 度量: 不收集數(shù)據(jù)或分析數(shù)據(jù) 改進方向: (1)建立項日管理過程.實施規(guī)范化管理.保障項目的承諾. (2)首要任務(wù)是進行需求管理,建立客戶與軟件項目之間的共同理解,使項目真正 反映客戶的要求. (3)建立各種軟件項目計劃.如軟件開發(fā)計劃,軟件質(zhì)量保證計劃,軟件配置管 理計劃,軟件測試計劃,風(fēng)險管理計劃及過程改進計劃. (4)開展軟件質(zhì)量保證活動(SQA). 2,可重復(fù)級 特征 (1)進行較為現(xiàn)實的求諾,可按以前在同類項目

4、上的成功經(jīng)驗建立的必要過程準則 來確保再一次的成功. (2)主要是逐個項目地建立基本過程管理條例來加強過程能力. (3)建立了基本的項目管理過程來跟蹤成本,進度和功能. (4)管理工作主要跟蹤軟件經(jīng)費支出,進度及功能.識別在承諾方面出現(xiàn)的問題. (5)采用基線(BASELINE)來標志進展,控制完整性. (6)定義了軟件項目的標準,并相信它,遵循它. (7)通過于合同建立有效的供求關(guān)系. 過程 (1)軟件開發(fā)和維護的過程是相對穩(wěn)定的,但過程建立在項目一級. (2)有規(guī)則的軟件過程是在一個有效的工程管理系統(tǒng)的控制之下,先前的成功經(jīng)驗 可以被重復(fù). (3)問題出現(xiàn)時.有能力識別及糾正.其承諾是可實

5、現(xiàn)的. 人員 (1)項目的成功依賴于個人的能力以及管理層的支持. (2)理解管理的必要性及對管理的承諾. (3)注意人員的培訓(xùn)問題, 技術(shù) 建立技術(shù)支持活動,并有穩(wěn)定的計劃. 度量 每個項目建立資源計劃.主要是關(guān)心成本,產(chǎn)品和進度.有相應(yīng)的管理數(shù)據(jù). 改進方向 (1)不再按項目制定軟件過程,而是總結(jié)各種項目的成功經(jīng)驗,使之規(guī)則化,把具 體經(jīng)驗歸納為全組織的標準軟件過程.把改進組織的整體軟件過程能力的軟件過程活 動,作為軟件開發(fā)組織的責任. (2)確定全組織的標準軟件過程,把軟件工程及管理活動集成到一個穩(wěn)固確定的軟 件過程中.從而可以跨項目改進軟件過程效果,也可作為軟件過程剪裁的基礎(chǔ). (3)建

6、立軟件工程過程小組(SEPG)長期承擔評估與調(diào)控軟件過程的任務(wù),以適應(yīng)未 來軟件項目的要求. (4)積累數(shù)據(jù):建立組織的軟件過程庫及軟件過程相關(guān)的文檔庫 (5)加強培訓(xùn). 3,確定級 特征 ：(1)無論管理方面或工程方面的軟件過程都已文件化,標準化,并綜合成軟件開發(fā) 組織的標準軟件過程. (2)軟件過程標準被應(yīng)用到所有的工程中,用于編制和維護軟件.有的項目也可根 據(jù)實際情況,對軟件開發(fā)組織的標準軟件過程進行剪裁. (3)在從事一項工程時,產(chǎn)品的生產(chǎn)過程,花費,計劃以及功能都是可以完全控制 的,從而軟件質(zhì)量也可以控制. (4)軟件工程過程組(SEPG)負責軟件過程活動. (5)在全組織范圍內(nèi)安排

7、培訓(xùn)計劃. 過程： (1)整個組織全面采用綜合性的管理及工程過程來管理.軟件工程和管理活動是穩(wěn) 定的和可重復(fù)的,具有連續(xù)性的. (2)軟件過程起了預(yù)見及防范問題的作用,能使風(fēng)險的影響最小化 人員： (1)以項目組的方式進行工作.如同綜合產(chǎn)品團隊. (2)在整個組織內(nèi)部的所有人對于所定義的軟件過程的活動,任務(wù)有深入理解.大 大加強了過程能力. (3)有計劃地按人員的角色進行培訓(xùn) 技術(shù) 在定性基礎(chǔ)上建立新的評估技術(shù).度量： (1)在全過程中收集使用數(shù)據(jù). (2)在全項目中系統(tǒng)性地共享數(shù)據(jù) 改進方向 (1)開始著手軟件過程的定量分析,以達到定量地控制軟件項目過程的效果. (2)通過軟件的質(zhì)量管理達到

8、軟件的質(zhì)量目標. 4,管理級 特征 ：(1)制定了軟件過程和產(chǎn)品質(zhì)量的詳細而具體的度量標準.軟件過程和產(chǎn)品的質(zhì)量 都可以被理解和控制. (2)軟件組織的能力是可預(yù)見的.原因是軟件過程是被明確的度量標準所度量和操 作.不言而喻.軟件產(chǎn)品的質(zhì)量就可以預(yù)見和得以控制. (3)組織的度量工程保證所有項目對生產(chǎn)率和質(zhì)量進行度量,并作為重要的軟件過 程活功. (4)具有良好定義及一致的度量標服來指導(dǎo)軟件過程,并作為評價軟件過程及產(chǎn)品 的定量基礎(chǔ). (5)在開發(fā)組織內(nèi)已建立軟件過程數(shù)據(jù)庫,保存收集到的數(shù)據(jù),可用于各項目的軟 件過程. 過程： (1)開始定量地認識軟件過程. (2)軟件過程的變化小.一般在可接

9、受的范圍內(nèi). (3)可以預(yù)見軟件過程中和產(chǎn)品質(zhì)量方面的一些趨勢.一旦質(zhì)量經(jīng)度量后超出這些 標準或是有所違反.可以采用一些方法去改正,以達到良好的日標. 人員 ：每個項目中存在強烈的群體工作意識,因為每人都了解個人的作用與組織的關(guān) 系,因此能夠產(chǎn)生這種群體意識. 技術(shù) 不斷的在定量基礎(chǔ)上評估新技術(shù). 度量： (1)在全組織內(nèi)進行數(shù)據(jù)收集與確定. (2)度量標準化. (3)數(shù)據(jù)用于定量地理解軟件過程及穩(wěn)定軟件過程. 改進方向 ：(1)缺陷防范.不僅僅在發(fā)現(xiàn)了問題時能及時改進,而且應(yīng)采取特定行動防止將來 出現(xiàn)這類缺陷. (2)主動進行技術(shù)變動管理,標識,選擇和評價新技術(shù).使有效的新技術(shù)能在開發(fā) 組織

10、中施行, (3)進行過程變動管理.定義過程改進的目的,經(jīng)常不斷地進行過程改進. 5,優(yōu)化級 特征 ：(1)整個組織特別關(guān)注軟件過程改進的持續(xù)性,頂見及增強自身.防止缺陷及問題 的發(fā)生.不斷地提高他們的過程能力. (2)加強定量分析,通過來自過程的質(zhì)量反饋和吸收新觀念,新科技,使軟件過程 能不斷地得到改進, (3)根據(jù)軟件過程的效果,進行成本/利潤分析,從成功的軟件過程實踐中吸取經(jīng) 驗,加以總結(jié).把最好的創(chuàng)新成績迅速向全組織轉(zhuǎn)移.對失敗的案例,由軟件過程小 組近行分析以找出原因. (4)組織能找出過程的不足并預(yù)先改進.把失敗的教訓(xùn)告知全體組織以防止重復(fù)以 前的錯誤. (5)對軟件過程的評價相對標

11、準軟件過程的改進,都在全組織內(nèi)推廣. 過程 ：(1)不斷地系統(tǒng)地改進軟件過程 (2)理解并消除產(chǎn)生問題的公共根源.在任何一個系統(tǒng)中都可找到:由于隨機變化 造成重復(fù)工作,進而導(dǎo)致時間浪費.為了防止浪費人力可能導(dǎo)致的系統(tǒng)變化.要消除 "公共"的無效根源,防止浪費發(fā)生.盡管所有級別都存在這些問題,但這是第五級 的焦點. 人員 ：(1)整個組織都存在自覺的強烈的團隊意識. (2)每個人都致力于過程改進.人們不再以達到里程碑的成就而滿足,而要力求減 少錯誤率. 技術(shù) 基于定量的控制和管理,事先主動考慮新技術(shù),追求新技術(shù),利用新技術(shù).可以 實現(xiàn)軟件開發(fā)中的方法和新技術(shù)的革新,以防止出現(xiàn)

12、錯誤,不斷提高產(chǎn)品的質(zhì)量和生 產(chǎn)率. 度量： 利用數(shù)據(jù)來評估,選擇過程改進. 改進方向 保持持續(xù)不斷的軟件過程改進. 二,敏捷開發(fā)和高級別 CMMI 關(guān)鍵字:高級別 CMMI 敏捷開發(fā) 我經(jīng)常和別人一起討論敏捷開發(fā)過程的知識,并且我們也會經(jīng)常爭論結(jié)合使用敏 捷開發(fā)過程和 CMMI 高級別的話題.他們兩個是否能夠結(jié)合使用?或者他們兩個只是 向相反的方向發(fā)展?帶著這個疑問,下面我們一起來探討. "這個問題可以說是老生常談,但是我對第 5 級別中的那個基本差異有一個疑 問,這個疑問會使人產(chǎn)生不安的情緒.CMMI1.2 強調(diào)了想在組織中控制結(jié)果的變更, 進而將其重心轉(zhuǎn)移到了個人的身上.敏捷開

13、發(fā)在意義上說不單單是為了讓每個項目能 在應(yīng)對各種各樣的環(huán)境中都擁有靈活的能力,并且可以讓他們在這個環(huán)境中盡其所能 表現(xiàn)的最好.我們并沒有特別關(guān)注在所有項目中要規(guī)范行為以便可以預(yù)知結(jié)果是"可 靠的". 但是,我并不清楚我現(xiàn)在盡力想說明的這種區(qū)別,是否確實是敏捷開發(fā)和 CMMI 的基本概念中的一個基礎(chǔ)的區(qū)別,還是只是組織如何解釋和執(zhí)行 CMMI 第 5 級別的一 個結(jié)果.當然,敏捷開發(fā)團隊在過程模型和過程實踐資產(chǎn)中擁有的信任似乎要比 CMMI 團隊中的要少雖然在敏捷中沒有方法可以規(guī)范這些事情即便他們是低成本的,但 是沒有假設(shè)說明這就是組織要走的路.事實上,敏捷開發(fā)支持者偏向于這

14、樣的想法, 在任何形式的可遇見的過程模型中快速地建立起逐漸減少的成果.是否這就是等同說 敏捷開發(fā)支持者相信特殊原因會影響執(zhí)行效果是如此的普遍,以至在組織中試圖建立 預(yù)見性的模型是無用的?" CMMI 第 4 級別: QPM(量化項目管理):主要關(guān)注懂得過程行為變更的個別項目,他們認為這些 變更影響著他們的成功和如何處理事情或者至少影響著完成產(chǎn)品發(fā)展或者達成目 標.組織單位(EPG)必須要監(jiān)控成果. OPP(組織過程實踐):主要關(guān)注集成模型,項目可以使用模型來規(guī)范他們想要 達到成功的方面,比如說質(zhì)量,進度表,預(yù)算,維護以及其他任何事情.訣竅就是項 目在過程執(zhí)行中以這些模型為基礎(chǔ),控制

15、QPM 中的行為.比較典型的是,這些模型可 能是基于相似的項目中的重復(fù)的結(jié)果不斷建立起來的,雖然可能并沒有這樣的需求. 在個別項目級別中模型應(yīng)該先被改進以便使用,所以在 CMMI 模型中使用基于一個項 目的歷史數(shù)據(jù)(比如說,增量)或者 20 個項目的歷史數(shù)據(jù)是沒有區(qū)別的,雖然這可能 對使用者來說是有區(qū)別的. CMMI 第 5 級別: CAR(原因分析與解決方法):主要關(guān)注引起問題的主要原因,過失,管理問題 或者其他一切需要解決的問題.項目,EPG 或者其他任何人是否可以應(yīng)用,是作為解 決問題的方法.EPG 在 OPP 中監(jiān)控結(jié)果,或者得到別的經(jīng)驗.(敏捷開發(fā)是否在增量 開始點或者結(jié)束點不建議進

16、行類似的行為?我不清楚我所知道的術(shù)語是否正確) OID(組織創(chuàng)新與推展):完全非項目特點.關(guān)注基于個體,CAR,模型使用,外 界因素等的組織改進.你是否會收集并且使用所有這些學(xué)到的經(jīng)驗?你進入企業(yè)后是 否會尋求新的或者更好的做生意的方法(其中敏捷開發(fā)可能只是一個例子)?在組織 中又該如何處理證明,分析(職業(yè)),和使用(結(jié)構(gòu)請參照第 4 級別中的模型和過程 控制)這些改進. 我個人認為 CMMI 高級別和敏捷開發(fā)應(yīng)該結(jié)合起來工作.敏捷可以幫助 CMMI 高級 別更容易實現(xiàn)短期的轉(zhuǎn)變,并且它在處理事情的發(fā)展上起了很重要的作用.我的經(jīng)驗 基本是從第 5 級別得來的,有部分來自第 4 級別.許多組織懷

17、著"每個人都必須如此 做"的想法而通過了第 3 級別,但是他們卻反對在第 4,5 級別中有著同樣的想法.就 像我曾經(jīng)提到的,敏捷開發(fā)是使用 CMMI 第 4,5 級別來改進如何發(fā)展產(chǎn)品的完美例 子. CMMI 是 Capability Maturity Model Integration(能力成熟度模型集成)的縮寫, 是在 CMM(Capability Maturity Model 能力成熟度模型)的基礎(chǔ)上發(fā)展而來 三,CMMI 實施 現(xiàn)在很多企業(yè)因某種原因想做 CMMI 了,大體做法 1,決定實施 CMMI 2,EPG 接受培訓(xùn),理解 CMMI 3,EPG 根據(jù)自己理解的

18、 CMMI 和實際情況開發(fā)一大堆漂漂亮亮的過程文檔,流程 圖,表格,模板,檢查單,作業(yè)指南. 4,大家邊聽著 EPG 的解釋(包括培訓(xùn),答疑),邊執(zhí)行這些過程標準,然后審計 (內(nèi),外) 將目前的最佳實踐記錄下來,寫下來,文檔化下來. 很多新的 EPG 在做了一段時間后無奈的發(fā)現(xiàn)自己居然淪落成了一個過程標準解說 員,甚至文檔管理員.自己工作大部分時間是面對文檔,或者督促別人寫文檔 我到覺得 EPG 最主要的工作應(yīng)該深入到研發(fā)第一線,幫助研發(fā)人員解決研發(fā)過程 中面臨的最嚴重的實際問題(當然是解決方案要上升到過程高度,而不應(yīng)是單個問題或 個人),甚至哪怕是一些不嚴重但以你的項目經(jīng)驗知道該如何解決的問

19、題上.總體說來 就是掌握項目進展中的任何細微的技術(shù)難點要點,并主動記錄下來. 為什么這么說呢?CMMI 實施的主要宗旨就是以每個項目為采集數(shù)據(jù)的源頭,達到 企業(yè)整體效益提升和資源重用.真正有價值的東西,是需要一線人員在實際工作中遇 到問題,解決問題,并總結(jié)問題,不是一個一線工作的流水帳.就象一份研發(fā)人員的 日報.寫了上午做什么,下午做什么.這對企業(yè)的積累有什么用處呢?他工作過程中, 遇到什么問題,他是怎么解決的,走過什么彎路,實驗過幾種方法,失敗了,失敗的 原因是什么,最后選擇了什么方法,可能不是最好的,但完成了任務(wù),達到了效率和 資源分配的平衡.這些東西才可能是未來類似項目中,遇到類似問題時

20、,可能有參考 價值的.通常也是 EPG 個人職業(yè)生涯的技術(shù)積累.只有公司里每個員工,把自己認為 最有價值的積累貢獻出來.才可能達到公司有價值的積累.而決不是形式上寫的上午 下午每個小時的流水帳. 明白了上面的說的 CMMI 的目的,做為一個合格的 EPG,就應(yīng)該具備以下的素 質(zhì): 1,明白什么是有價值的積累,先是對你個人,然后才是順便幫公司做了積累. 2,深入一線,發(fā)現(xiàn)她們并忠實地記錄她們.CMMI 里的 SP,GP,只是幫助你,提 醒你在哪個環(huán)節(jié),哪些東西可能是有價值了.你去收集一下,別視而不見了.因為還 有一個企業(yè)和你個人的角度不同,立場不同的問題.例如,REQM 里收集需求,對個人 技術(shù)

21、方面的積累雖然不多,但對企業(yè)是至關(guān)重要的,一次需求變更,沒詳細寫清楚, 忘記了到客戶那里去簽字落實,可能就會給企業(yè)造成很大的損失.做為一個合格的 EPG,是需要有這份責任和義務(wù)把每個環(huán)節(jié)都做到最好,這是職業(yè)道德所在.同時也 是對自我延伸的一個好機會,學(xué)會一些和人的溝通,傾聽,把專業(yè)的東西以平易的方 式表達.這些也都算是 EPG 額外的收獲. 通常情況下,為了按時按量完成項目,一線的骨干,對寫日報,周報,文檔都很 不屑.EPG 也很遷就,事后再補,這也不失為一個提高效率的好辦法.但過去一個月 半年了,我們正常人的記憶都能想象,很難記住細節(jié).無非就是敷衍.這也在情理之 中.你總不能讓一個明天就要交

22、東西的小組,今天晚上在通宵努力解決 BUG 的同時, 還寫什么報告,這也不盡人情.但作為 EPG 不能只把眼光集中在這婦人之心上.要想 的更遠.為什么會把項目推到這么晚,BUG 還沒解決完?難道要永遠這樣下去嗎?項目 中是有很多不可預(yù)測的因素,甚至是開發(fā)人員常說的"手氣問題","人品問題".但這些 是需要控制的,也是通過經(jīng)驗可以控制的,所謂藝高人膽大.藝的高低,就是經(jīng)驗的 積累決定的. 那怎么解決這種兩難的問題呢?逼著技術(shù)骨干寫心水,人家沒時間也的確壓力很 大.不寫,公司又得不到有效積累,積累的都是垃圾流水.有個公司的辦法和經(jīng)驗到 可以借鑒一下: 公司內(nèi)

23、部搞了個 BBS,把不同類型的工作分成不同的組,有純技術(shù)的,JAVA 組, C+組等,也有 PPT 組,甚至動畫組,界面組.大家把自己平時的工作積累 FTP 上 去,甚至制作方法,遇到問題和解決方法的文檔都丟上去,開始怎么想,用了多少套 方案,最后選擇了什么.自我感覺如何.把這些心路歷程都寫成文檔.丟到陽光下, 大家評論.用點擊率和"頂"的人數(shù)來說明誰寫的是心水,誰在寫垃圾.大家都是一個公 司的,很容易實名.直接納入考核機制中.做為一線人員,大家也有動力來寫,自己 的聰明才智有了展現(xiàn)的平臺,虛榮心和荷包都得到了相應(yīng)的滿足.何樂而不為呢? EPG 適時的評估大家的成果,并把他

24、們分到項目里.幫助項目總結(jié),甚至在平時 遇到問題時,直接幫助技術(shù)人員做必要記錄.項目進度松時,再督促項目人員完善內(nèi) 容.以達到對個人和公司積累的最大化. EPG 應(yīng)該明白學(xué)習(xí)和積累是個終身的過程,對公司如此,對個人也是如此.CMMI 是個輔助,輔助我們對公司做積累,也幫助我們個人做必要的積累.公司需要逐步走 向更高的管理水平,發(fā)展平臺. 四,CMMI 實施之核心 關(guān)鍵字:CMMI,SCAMPI,過程改進,能力成熟度,EPG,PA,過程域 在上一章節(jié)中,我們談到了關(guān)于過程改進團隊的組建方法及在組建過程中需要注 意的問題,在本節(jié)中我們將繼續(xù)探討 EPG 過程改進的另一個更為重要的一環(huán)定義 過程文檔

25、. 曾經(jīng)有一位評估師開玩笑說,三級是寫文檔,四級是寫文檔的文檔,五級是寫文 檔的文檔的文檔.由此可見,文檔貫穿于整個 CMMI,在過程改進中起著舉足輕重的作 用.那么如何才能寫出既符合 CMMI 又立足于企業(yè)本身實際情況的文檔呢?這就是本 文將要探討的問題定義過程文檔. 在定義過程文檔時,首先,應(yīng)該進行企業(yè)的習(xí)慣表述與 CMMI 術(shù)語和語言間的映 射.特別是組織結(jié)構(gòu)中的一些術(shù)語,角色,組織內(nèi)部之間關(guān)系以及過程活動的表述方 式都需要映射到其組織的相應(yīng)部分,以防止別人無法理解. 定義過程文檔的一般步驟是: (1)先確定并描述產(chǎn)品的生命周期. 一般來說,產(chǎn)品生命周期可以劃分為 6 個階段,即產(chǎn)品概念階段,產(chǎn)品定義階 段, 產(chǎn)品開發(fā)階段, 產(chǎn)品測試階段,用戶驗收階段,產(chǎn)品維護階段. (2)根據(jù)產(chǎn)品生命周期的各個階段確定需要改進的過程域(PA)活動. "過程域"用于描述 CMMI 標準定義的軟件過程能力評估模型中的一種部件.在 該模型中,"過程域"是最大的的構(gòu)造塊,每個"過程域"由一組目標構(gòu)成,每個