CMM/CMMI 的區別
1.CMM/CMMI 的發展
為了保證軟體產品的質量,80年代中期,美國聯邦政府提出對軟體承包商的軟體開發能力進行評估的要求。因此,美國卡內基-梅隆大學軟體工程研究所 (CMU/SEI) 於1987年研究釋出了軟體過程成熟度框架,並提供了軟體過程評估和軟體能力評價兩種評估方法和軟體成熟度提問單。4年之後,SEI將軟體過程成熟度框架進化為軟體能力成熟度模型(Capability Maturity Model For Software,簡稱SW-CMM),併發布了最早的SW-CMM 1.0版。經過兩年的試用,1993年SEI正式釋出了SW-CMM1.1版,這是目前使用最為廣泛的版本。
自1991年SW-CMM首次釋出後,SEI又開發了其他成熟度模型,包括:系統工程、採購、人力資源管理和整合產品開發等。雖然各個模型針對的專業領域不同,但彼此之間也有一定的重疊,畢竟它們同出一轍;另外,這些模型在表現形式上又有不統一之處:系統工程模型是連續式的,而其他模型採用了分級式。當SEI開始開發新一代成熟度模型的時候,其發起人提出了新的要求:整合不同模型中的最佳實踐,建立統一模型,覆蓋不同領域,供企業進行整個組織的全面過程改進。所以,SEI於2001年12月正式釋出了能力成熟度整合模型(CMMI)1.1版本,這次釋出標誌著CMMI的正式使用。SEI也正式宣佈,將不再維護SW-CMM的CBA-IPI評估方法:在CMMI1.1釋出後的兩年內,SEI還提供有關SW-CMM和CBA-IPI主任評估員的培訓,並接收評估資料,但這一切已於2003年12月底正式停止。
這裡需要注意的是,SEI並沒有廢除CMM模型,而是以CMMI的SCAMPI評估方法取代CMM的CBA-IPI評估方法。當然很多業內人士認為,隨著軟體行業的發展,CMMI模型將最終取代CMM模型。
CMMI起源於三個模型(源模型),分別是:
(1) 軟體能力成熟度模型( SW-CMM)2.0版,C稿
(2) 電子行業協會臨時標準(EIA/IS731)
(3) 整合產品開發能力成熟度模型(IPD-CMM)v0.98
模型中同時整合了供應管理的內容。另外,在CMMI中除了沿用成熟度等級的方式(即CMMI的分階段表示形式)外,還吸取TR 15504的特點,增加了與15504類似的CMMI的連續表示形式,以滿足ISO15504國際標準對過程改進評估的要求。CMMI模型的組成和適用範圍如表1所示。
表1 CMMI模型的組成和適用範圍
CMMI模型元件 適用範圍
SE/SW 軟體工程、系統工程
SE/SW /IPPD 軟體工程、系統工程、整合產品和過程開發
SE/SW /IPPD/SS 軟體工程、系統工程、整合產品和過程開發、供應採購
培訓課程 評估師、過程改進人員等培訓
SCMPI 評估方法
在CMMI 模型元件中,SE/SW是核心,SE/SW /IPPD、SE/SW /IPPD/SS是在此基礎上擴充套件而來的。
CMM模型基於眾多軟體專家的實踐經驗,是組織進行軟體過程改善和軟體過程評估的一個有效的指導框架。CMMI專案更為工業界和政府部門提供了一個整合的產品集,其主要目的是消除不同模型之間的不一致和重複,降低基於模型改善的成本。CMMI將以更加系統和一致的框架來指導組織改善軟體過程,提高產品和服務的開發、獲取和維護能力。CMM或CMMI不僅是一個模型,一個工具,它更代表了一種管理哲學在軟體工業中的應用。
CMM/CMMI的思想來源於已有多年曆史的產品質量管理和全面質量管理。Watts Humphrey和Ron Radice在IBM公司將全面質量管理的思想應用於軟體工程過程,收到了很大的成效。SEI的軟體能力成熟度框架就是在以Humphrey為主的軟體專家實踐經驗的基礎上發展而來的。軟體能力成熟度模型中融合了全面質量管理的思想,以不斷進化的層次反映了軟體過程定量控制中專案管理和專案工程的基本原則。CMM/CMMI所依據的想法是隻要不斷地對企業的軟體工程過程的基礎結構和實踐進行管理和改進,就可以克服軟體生產中的困難,增強開發製造能力,從而能按時地、不超預算地製造出高質量的軟體。
2.CMM/CMMI的作用
最近的SEI評估報告顯示,從1996年到2003年,全球有2千多個組織進行了CMM/CMMI評估,其中大部分為商業組織,有將近一半的組織規模是在100人以下。這些資料表明,CMM/CMMI評估已經引起軟體及IT企業的高度關注,並且這種評估同樣適合中小企業。
CMM/CMMI主要應用在兩大方面:能力評估和過程改進。
1)能力評估
CMM/CMMI是基於政府評估軟體承包商的軟體能力發展而來的,有兩種通用的評估方法用以評估組織軟體過程的成熟度:軟體過程評估和軟體能力評價。
軟體過程評估:用於確定一個組織當前的軟體工程過程狀態及組織所面臨的軟體過程的優先改善問題,為組織領導層提供報告以獲得組織對軟體過程改善的支援。軟體過程評估集中關注組織自身的軟體過程,在一種合作的、開放的環境中進行。評估的成功取決於管理者和專業人員對組織軟體過程改善的支援。
軟體能力評價:用於識別合格的軟體承包商或者監控軟體承包商開發軟體的過程狀態。軟體能力評價集中關注識別在預算和進度要求範圍內完成製造出高質量的軟體產品的軟體合同及相關風險。評價在一種稽核的環境中進行,重點在於揭示組織實際執行軟體過程的文件化的稽核記錄。
2)過程改進
軟體過程改進是一個持續的、全員參與的過程。CMM/CMMI建立了一組有效地描述成熟軟體組織特徵的準則。該準則清晰地描述了軟體過程的關鍵元素,幷包括軟體工程和管理方面的優秀實踐。企業可以有選擇地引用這些關鍵實踐指導軟體過程的開發和維護,以不斷地改善組織軟體過程,實現成本、進度、功能和產品質量等目標。
3.CMM/CMMI的主要內容
CMMI中成熟度等級的概念與SW-CMM模型相同,只是某些等級的名稱有些變化。1級、3級和5級的名稱沒有變化,名稱還是初始級、已定義和優化中,但是2級和4級分別變為已管理級和定量管理級,這個變化更突出了2級定性管理和4級定量管理的特點。
另外,CMMI能力等級的確定,建立了CMMI和ISO15504之間的有機聯絡,CMMI連續式模型的3、4級名稱雖然與ISO15504有區別,但其含義是基本一樣的。
表2列出了CMMI、CMM、ISO15504模型的等級名稱的對應關係。
表2 各模型的等級對應
Level CMM CMMI(分級式) CMMI(連續式) ISO15504
5 優化中 優化中 優化中 優化中
4 已管理 定量管理 定量管理 可預測
3 已定義 已定義 已定義 已建立
2 可重複 已管理 已管理 已管理
1 初始級 初始級 已執行 已執行
0 未完成 未完成
CMM/CMMI把軟體開發組織的能力成熟度分為5~6個可能的等級。除了第1級外,其他每一級由幾個過程方面組成。每一個過程方面都由公共特性予以表徵。CMM/CMMI給每個過程規定了一些具體目標。按每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例,這個關鍵過程的各專案標就能達到,這就表明該關鍵過程實現了。這種分級的思路在於把一個組織執行軟體過程的成熟程度分成循序漸進的幾個階段,這與軟體組織提高自身能力的實際推進過程相吻合。這種成熟度分級的優點在於級別明確而清楚地反映了過程改進活動的輕重緩急和先後順序。這一點很重要,因為大多數軟體組織只能在某一段時間裡集中開展少數幾項過程改進活動。
CMMI共有分屬於4個類別的25個過程域,覆蓋了4個不同的領域(相對應,SW-CMM共有18個過程域)。雖然CMMI中的很多過程域與SW-CMM中的基本相同,但有幾個過程域的範圍和內容發生了重要的變化,另外也有幾個新增加的過程域。兩個模型的過程域關係比較見表3。
表3 CMMI和CMM過程域關係比較
等級 CMM CMMI 類別
過程域 縮寫 過程域 縮寫
5 技術更新管理 TCM 組織革新與部署 OID 過程管理
過程更改管理 PCM CAR
缺陷預防 DP 原因分析與決策 支援
4 軟體質量管理 SQM 組織過程效能 OPP 過程管理
定量過程管理 QPM 定量專案管理 QPM 專案管理
3 軟體產品工程
同行評審 SPE
PR 需求制定 RD 工程
技術方案 TS 工程
產品整合 PI 工程
驗證 VER 工程
確認 VAL 工程
組織過程聚焦 OPF 組織過程聚焦 OPF 過程管理
組織過程定義 OPD 組織過程定義 OPD 過程管理
培訓大綱 TP 組織培訓 OT 過程管理
整合軟體管理 ISM 整合專案管理 IPM 專案管理
組間協調
風險管理 RSKM 專案管理
決策分析與決定 DAR 支援
整合供應商管理 ISM 專案管理
組織整合環境 OEI 支援
IC 整合組隊 IT 專案管理
2 需求管理 RM 需求管理 RM
軟體專案策劃 SPP 專案策劃 PP 專案管理
軟體專案監督與控制 SPTO 專案監督與控制 PMC 專案管理
軟體分包管理 SAM 供應協議管理 SAM 專案管理
軟體質量保證 SQA 過程與產品質量保證 PPQA 支援
軟體配置管理 SCM 配置管理 CM 支援
度量與分析 MA 支援
1
4.CMM/CMMI的評估
原來的CMM評估須遵循SEI的CAF (CMM Assessment Frame-work) 規範,由CMU/SEI授權的主任評估師(Lead Assessor)領導一個評審小組進行,評估方法採用IPI-CBA,評估過程包括員工培訓(企業的高層領導也要參加)、問卷調查和統計、文件審查、資料分析、與企業的高層領導討論和撰寫評估報告等,評估結束時由主任評估師簽字生效。
隨著CMM過渡到CMMI,其CAF評估框架變成評估需求(ARC:Appraisal Requirements for CMMI);IPI-CBA評估方法被SCAMPI(Standard CNNI Appraisal Method for Process Improvement)方法代替。根據CMMI評估需求(ARC)規定三種評估型別,表4列出了SCAMPI評估方法的適用情況。
表4 可用的評估型別 評估型別 ISO15504相容 SCAMPI 使用 主任評估師需求 評估組規模
Class A × 可能 × 5-17
Class B - 部分 - 2-7
Class C - 部分 - 2-3
SCAMPI評估組由幾方人員共同組成,由主任評估師領導。其中評估小組是由經驗豐富的軟體專業人員組成,還要經過CMMI和SCAMPI評估方法的培訓,使他們瞭解組織的同時,也懂得如何將CMM/CMMI模型及關鍵實踐與組織的要求建立關聯。參與評估的人員包括:公司的管理人員、專案經理,開發人員,培訓人員,採購人員等。
評估過程主要分成三個階段:準備階段、評估階段和報告階段。準備階段包括小組人員培訓、計劃以及其它必要的評估準備工作。在評估的最初幾十天,小組成員的主要任務是採集資料,回答SEI的CMM/CMMI提問單,文件審閱以及進行交談,對整個組織中的應用有一個全面的瞭解。
然後進行資料分析。評估員要對記錄進行整理,並檢驗所觀察到的一切資訊,然後把這些資料與CMM/CMMI模型進行比較,最後給出一個評估報告。在每個評估報告中,必須針對CMM/CMMI 的每個過程方面,指出這個軟體過程在什麼地方已經有效地執行了,什麼地方還沒有有效地執行。只有所有評估人員一致通過的情況下,這個評估報告才有效。
在評估報告的基礎上,評估小組產生一個評估結果。評估和評級的結果應與有關的關鍵過程方面和目標相對應。評估報告和結果將送交所有有關的人員並上報CMU/SEI。
5.我國軟體能力評估標準的制定與實施
軟體已經作為一個新興高技術產業在我國崛起。但與已開發國家相比,無論在開發能力還是管理水平上都還存在一定差距,尤其是落後的軟體工程管理制約了開發能力的發揮。某些國家的軟體開發能力並不比我國強,但在國際軟體市場上的份額卻遠大於我國,其主要原因之一是我們在軟體開發管理方面明顯落後。國務院以國發[2000]18號文頒佈了《鼓勵軟體產業和積體電路產業發展的若干政策》,其中要求通過標準化工作對軟體產業發展提供必要的支撐與保障。為了落實國務院18號文的精神,加快我國軟體能力模型標準的制定,推動軟體產業的發展,資訊產業部2000年9月28日主持成立了軟體體系評估標準特別工作組,同時提出了 “依據我國軟體政策,利用國際先進經驗,結合我國國情,制定出有助於指導和促進我國軟體企業發展的評估模型標準”的原則,並確定了標準制定的兩個主要目標:支援軟體企業和企業內的軟體組織對自身的軟體過程能力實施持續性的內部改進;支援對軟體企業的綜合軟體能力進行第二方和第三方評估。
工作組深入研究了CMM、CMMI、ISO/IEC TR15504、ISO9000以及其他有關的資料和檔案以及國外企業實施CMM的實際情況,結合國情,確定了以CMMI作為主要參考檔案來制定標準。最終形成了SJ/T 11234-2001《軟體過程能力評估模型》和SJ/T 11235-2001《軟體能力成熟度模型》行業正式標準,並於2001年5月1日正式實施。這就是中國的“軟體過程及能力成熟度評估”,即SPCA評估。
隨著我國經濟市場的日益成熟,與資訊產業部建立的計算機資訊系統整合資質認證體制一樣,SPCA評估及其評估結果在市場化運作中將會起到越來越重要的作用。廣大使用者和企業也越來越接受和認可SJ/T11234和SJ/T11235標準,並將作為企業招投標,選擇合作伙伴的一項指標,也是進行第二方評估或評價的依據。這對我國軟體企業和產業的提高、發展和壯大也將產生積極的影響。
SPCA依據的評估標準是SJ/T 11234和SJ/T 11235,這兩個標準是在深入研究了CMM、CMMI、ISO/IEC TR15504、ISO9000、TL 9000以及其他有關的資料和檔案以及國外企業實施CMM的實際情況後,結合國內企業的實際情況,以CMMI作為主要參考檔案最終形成的,這兩個行業標準由資訊產業部於2001年5月1日釋出實施。
SJ/T 11234《軟體過程能力評估模型》針對軟體企業對自身軟體過程能力進行內部改進的需要,與CMMI連續表示形式基本相同。該模型有22個過程,分為4大類,即:過程管理類、專案管理類、工程化類和支援類,每個過程能力從0到5劃分為6個評估等級,每個等級包含了通用目標、通用慣例、特定目標和特定慣例,它們組成一套衡量準則。按此準則對實際執行的過程進行評估,可以確定當前軟體過程的能力狀態。對每個過程評估後,可以得到企業軟體過程能力的一條“譜線”。企業還可以針對軟體開發專案,根據專案的目標和要求,有針對性地“弄清楚”有關過程的能力狀態,實施必要的過程改進,以支援專案的完成。
SJ/T 111235《軟體能力成熟度模型》針對軟體企業綜合能力第二方或第三方評估的需求,與CMMI分階段表示形式基本相同。該模型用成熟度1~5個等級來描述綜合軟體能力。與SJ/T 11234相同,也有22個過程方面。除了成熟度等級1外,每個等級包含若干個過程方面,每個過程方面的實施情況由相應目標和慣例的實施情況體現。採用這種衡量準則可以評估軟體企業的綜合能力——軟體能力成熟程度。
SPCA評估遵循《軟體過程及能力成熟度評估指南》,該指南是國家認監委和資訊產業部2002年8月共同釋出的利用SJ/T11234或SJ/T11235實施評估的操作指南。評估過程由經過培訓的專業隊伍以評估參考模型作為確定過程的強項和弱項的基礎而對一個或多個過程進行檢查。從不同用途考慮,評估分為內部過程改進評估和顧客選擇評價兩種。
為了保證軟體產品的質量,80年代中期,美國聯邦政府提出對軟體承包商的軟體開發能力進行評估的要求。因此,美國卡內基-梅隆大學軟體工程研究所 (CMU/SEI) 於1987年研究釋出了軟體過程成熟度框架,並提供了軟體過程評估和軟體能力評價兩種評估方法和軟體成熟度提問單。4年之後,SEI將軟體過程成熟度框架進化為軟體能力成熟度模型(Capability Maturity Model For Software,簡稱SW-CMM),併發布了最早的SW-CMM 1.0版。經過兩年的試用,1993年SEI正式釋出了SW-CMM1.1版,這是目前使用最為廣泛的版本。
自1991年SW-CMM首次釋出後,SEI又開發了其他成熟度模型,包括:系統工程、採購、人力資源管理和整合產品開發等。雖然各個模型針對的專業領域不同,但彼此之間也有一定的重疊,畢竟它們同出一轍;另外,這些模型在表現形式上又有不統一之處:系統工程模型是連續式的,而其他模型採用了分級式。當SEI開始開發新一代成熟度模型的時候,其發起人提出了新的要求:整合不同模型中的最佳實踐,建立統一模型,覆蓋不同領域,供企業進行整個組織的全面過程改進。所以,SEI於2001年12月正式釋出了能力成熟度整合模型(CMMI)1.1版本,這次釋出標誌著CMMI的正式使用。SEI也正式宣佈,將不再維護SW-CMM的CBA-IPI評估方法:在CMMI1.1釋出後的兩年內,SEI還提供有關SW-CMM和CBA-IPI主任評估員的培訓,並接收評估資料,但這一切已於2003年12月底正式停止。
這裡需要注意的是,SEI並沒有廢除CMM模型,而是以CMMI的SCAMPI評估方法取代CMM的CBA-IPI評估方法。當然很多業內人士認為,隨著軟體行業的發展,CMMI模型將最終取代CMM模型。
CMMI起源於三個模型(源模型),分別是:
(1) 軟體能力成熟度模型( SW-CMM)2.0版,C稿
(2) 電子行業協會臨時標準(EIA/IS731)
(3) 整合產品開發能力成熟度模型(IPD-CMM)v0.98
模型中同時整合了供應管理的內容。另外,在CMMI中除了沿用成熟度等級的方式(即CMMI的分階段表示形式)外,還吸取TR 15504的特點,增加了與15504類似的CMMI的連續表示形式,以滿足ISO15504國際標準對過程改進評估的要求。CMMI模型的組成和適用範圍如表1所示。
表1 CMMI模型的組成和適用範圍
CMMI模型元件 適用範圍
SE/SW 軟體工程、系統工程
SE/SW /IPPD 軟體工程、系統工程、整合產品和過程開發
SE/SW /IPPD/SS 軟體工程、系統工程、整合產品和過程開發、供應採購
培訓課程 評估師、過程改進人員等培訓
SCMPI 評估方法
在CMMI 模型元件中,SE/SW是核心,SE/SW /IPPD、SE/SW /IPPD/SS是在此基礎上擴充套件而來的。
CMM模型基於眾多軟體專家的實踐經驗,是組織進行軟體過程改善和軟體過程評估的一個有效的指導框架。CMMI專案更為工業界和政府部門提供了一個整合的產品集,其主要目的是消除不同模型之間的不一致和重複,降低基於模型改善的成本。CMMI將以更加系統和一致的框架來指導組織改善軟體過程,提高產品和服務的開發、獲取和維護能力。CMM或CMMI不僅是一個模型,一個工具,它更代表了一種管理哲學在軟體工業中的應用。
CMM/CMMI的思想來源於已有多年曆史的產品質量管理和全面質量管理。Watts Humphrey和Ron Radice在IBM公司將全面質量管理的思想應用於軟體工程過程,收到了很大的成效。SEI的軟體能力成熟度框架就是在以Humphrey為主的軟體專家實踐經驗的基礎上發展而來的。軟體能力成熟度模型中融合了全面質量管理的思想,以不斷進化的層次反映了軟體過程定量控制中專案管理和專案工程的基本原則。CMM/CMMI所依據的想法是隻要不斷地對企業的軟體工程過程的基礎結構和實踐進行管理和改進,就可以克服軟體生產中的困難,增強開發製造能力,從而能按時地、不超預算地製造出高質量的軟體。
2.CMM/CMMI的作用
最近的SEI評估報告顯示,從1996年到2003年,全球有2千多個組織進行了CMM/CMMI評估,其中大部分為商業組織,有將近一半的組織規模是在100人以下。這些資料表明,CMM/CMMI評估已經引起軟體及IT企業的高度關注,並且這種評估同樣適合中小企業。
CMM/CMMI主要應用在兩大方面:能力評估和過程改進。
1)能力評估
CMM/CMMI是基於政府評估軟體承包商的軟體能力發展而來的,有兩種通用的評估方法用以評估組織軟體過程的成熟度:軟體過程評估和軟體能力評價。
軟體過程評估:用於確定一個組織當前的軟體工程過程狀態及組織所面臨的軟體過程的優先改善問題,為組織領導層提供報告以獲得組織對軟體過程改善的支援。軟體過程評估集中關注組織自身的軟體過程,在一種合作的、開放的環境中進行。評估的成功取決於管理者和專業人員對組織軟體過程改善的支援。
軟體能力評價:用於識別合格的軟體承包商或者監控軟體承包商開發軟體的過程狀態。軟體能力評價集中關注識別在預算和進度要求範圍內完成製造出高質量的軟體產品的軟體合同及相關風險。評價在一種稽核的環境中進行,重點在於揭示組織實際執行軟體過程的文件化的稽核記錄。
2)過程改進
軟體過程改進是一個持續的、全員參與的過程。CMM/CMMI建立了一組有效地描述成熟軟體組織特徵的準則。該準則清晰地描述了軟體過程的關鍵元素,幷包括軟體工程和管理方面的優秀實踐。企業可以有選擇地引用這些關鍵實踐指導軟體過程的開發和維護,以不斷地改善組織軟體過程,實現成本、進度、功能和產品質量等目標。
3.CMM/CMMI的主要內容
CMMI中成熟度等級的概念與SW-CMM模型相同,只是某些等級的名稱有些變化。1級、3級和5級的名稱沒有變化,名稱還是初始級、已定義和優化中,但是2級和4級分別變為已管理級和定量管理級,這個變化更突出了2級定性管理和4級定量管理的特點。
另外,CMMI能力等級的確定,建立了CMMI和ISO15504之間的有機聯絡,CMMI連續式模型的3、4級名稱雖然與ISO15504有區別,但其含義是基本一樣的。
表2列出了CMMI、CMM、ISO15504模型的等級名稱的對應關係。
表2 各模型的等級對應
Level CMM CMMI(分級式) CMMI(連續式) ISO15504
5 優化中 優化中 優化中 優化中
4 已管理 定量管理 定量管理 可預測
3 已定義 已定義 已定義 已建立
2 可重複 已管理 已管理 已管理
1 初始級 初始級 已執行 已執行
0 未完成 未完成
CMM/CMMI把軟體開發組織的能力成熟度分為5~6個可能的等級。除了第1級外,其他每一級由幾個過程方面組成。每一個過程方面都由公共特性予以表徵。CMM/CMMI給每個過程規定了一些具體目標。按每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例,這個關鍵過程的各專案標就能達到,這就表明該關鍵過程實現了。這種分級的思路在於把一個組織執行軟體過程的成熟程度分成循序漸進的幾個階段,這與軟體組織提高自身能力的實際推進過程相吻合。這種成熟度分級的優點在於級別明確而清楚地反映了過程改進活動的輕重緩急和先後順序。這一點很重要,因為大多數軟體組織只能在某一段時間裡集中開展少數幾項過程改進活動。
CMMI共有分屬於4個類別的25個過程域,覆蓋了4個不同的領域(相對應,SW-CMM共有18個過程域)。雖然CMMI中的很多過程域與SW-CMM中的基本相同,但有幾個過程域的範圍和內容發生了重要的變化,另外也有幾個新增加的過程域。兩個模型的過程域關係比較見表3。
表3 CMMI和CMM過程域關係比較
等級 CMM CMMI 類別
過程域 縮寫 過程域 縮寫
5 技術更新管理 TCM 組織革新與部署 OID 過程管理
過程更改管理 PCM CAR
缺陷預防 DP 原因分析與決策 支援
4 軟體質量管理 SQM 組織過程效能 OPP 過程管理
定量過程管理 QPM 定量專案管理 QPM 專案管理
3 軟體產品工程
同行評審 SPE
PR 需求制定 RD 工程
技術方案 TS 工程
產品整合 PI 工程
驗證 VER 工程
確認 VAL 工程
組織過程聚焦 OPF 組織過程聚焦 OPF 過程管理
組織過程定義 OPD 組織過程定義 OPD 過程管理
培訓大綱 TP 組織培訓 OT 過程管理
整合軟體管理 ISM 整合專案管理 IPM 專案管理
組間協調
風險管理 RSKM 專案管理
決策分析與決定 DAR 支援
整合供應商管理 ISM 專案管理
組織整合環境 OEI 支援
IC 整合組隊 IT 專案管理
2 需求管理 RM 需求管理 RM
軟體專案策劃 SPP 專案策劃 PP 專案管理
軟體專案監督與控制 SPTO 專案監督與控制 PMC 專案管理
軟體分包管理 SAM 供應協議管理 SAM 專案管理
軟體質量保證 SQA 過程與產品質量保證 PPQA 支援
軟體配置管理 SCM 配置管理 CM 支援
度量與分析 MA 支援
1
4.CMM/CMMI的評估
原來的CMM評估須遵循SEI的CAF (CMM Assessment Frame-work) 規範,由CMU/SEI授權的主任評估師(Lead Assessor)領導一個評審小組進行,評估方法採用IPI-CBA,評估過程包括員工培訓(企業的高層領導也要參加)、問卷調查和統計、文件審查、資料分析、與企業的高層領導討論和撰寫評估報告等,評估結束時由主任評估師簽字生效。
隨著CMM過渡到CMMI,其CAF評估框架變成評估需求(ARC:Appraisal Requirements for CMMI);IPI-CBA評估方法被SCAMPI(Standard CNNI Appraisal Method for Process Improvement)方法代替。根據CMMI評估需求(ARC)規定三種評估型別,表4列出了SCAMPI評估方法的適用情況。
表4 可用的評估型別 評估型別 ISO15504相容 SCAMPI 使用 主任評估師需求 評估組規模
Class A × 可能 × 5-17
Class B - 部分 - 2-7
Class C - 部分 - 2-3
SCAMPI評估組由幾方人員共同組成,由主任評估師領導。其中評估小組是由經驗豐富的軟體專業人員組成,還要經過CMMI和SCAMPI評估方法的培訓,使他們瞭解組織的同時,也懂得如何將CMM/CMMI模型及關鍵實踐與組織的要求建立關聯。參與評估的人員包括:公司的管理人員、專案經理,開發人員,培訓人員,採購人員等。
評估過程主要分成三個階段:準備階段、評估階段和報告階段。準備階段包括小組人員培訓、計劃以及其它必要的評估準備工作。在評估的最初幾十天,小組成員的主要任務是採集資料,回答SEI的CMM/CMMI提問單,文件審閱以及進行交談,對整個組織中的應用有一個全面的瞭解。
然後進行資料分析。評估員要對記錄進行整理,並檢驗所觀察到的一切資訊,然後把這些資料與CMM/CMMI模型進行比較,最後給出一個評估報告。在每個評估報告中,必須針對CMM/CMMI 的每個過程方面,指出這個軟體過程在什麼地方已經有效地執行了,什麼地方還沒有有效地執行。只有所有評估人員一致通過的情況下,這個評估報告才有效。
在評估報告的基礎上,評估小組產生一個評估結果。評估和評級的結果應與有關的關鍵過程方面和目標相對應。評估報告和結果將送交所有有關的人員並上報CMU/SEI。
5.我國軟體能力評估標準的制定與實施
軟體已經作為一個新興高技術產業在我國崛起。但與已開發國家相比,無論在開發能力還是管理水平上都還存在一定差距,尤其是落後的軟體工程管理制約了開發能力的發揮。某些國家的軟體開發能力並不比我國強,但在國際軟體市場上的份額卻遠大於我國,其主要原因之一是我們在軟體開發管理方面明顯落後。國務院以國發[2000]18號文頒佈了《鼓勵軟體產業和積體電路產業發展的若干政策》,其中要求通過標準化工作對軟體產業發展提供必要的支撐與保障。為了落實國務院18號文的精神,加快我國軟體能力模型標準的制定,推動軟體產業的發展,資訊產業部2000年9月28日主持成立了軟體體系評估標準特別工作組,同時提出了 “依據我國軟體政策,利用國際先進經驗,結合我國國情,制定出有助於指導和促進我國軟體企業發展的評估模型標準”的原則,並確定了標準制定的兩個主要目標:支援軟體企業和企業內的軟體組織對自身的軟體過程能力實施持續性的內部改進;支援對軟體企業的綜合軟體能力進行第二方和第三方評估。
工作組深入研究了CMM、CMMI、ISO/IEC TR15504、ISO9000以及其他有關的資料和檔案以及國外企業實施CMM的實際情況,結合國情,確定了以CMMI作為主要參考檔案來制定標準。最終形成了SJ/T 11234-2001《軟體過程能力評估模型》和SJ/T 11235-2001《軟體能力成熟度模型》行業正式標準,並於2001年5月1日正式實施。這就是中國的“軟體過程及能力成熟度評估”,即SPCA評估。
隨著我國經濟市場的日益成熟,與資訊產業部建立的計算機資訊系統整合資質認證體制一樣,SPCA評估及其評估結果在市場化運作中將會起到越來越重要的作用。廣大使用者和企業也越來越接受和認可SJ/T11234和SJ/T11235標準,並將作為企業招投標,選擇合作伙伴的一項指標,也是進行第二方評估或評價的依據。這對我國軟體企業和產業的提高、發展和壯大也將產生積極的影響。
SPCA依據的評估標準是SJ/T 11234和SJ/T 11235,這兩個標準是在深入研究了CMM、CMMI、ISO/IEC TR15504、ISO9000、TL 9000以及其他有關的資料和檔案以及國外企業實施CMM的實際情況後,結合國內企業的實際情況,以CMMI作為主要參考檔案最終形成的,這兩個行業標準由資訊產業部於2001年5月1日釋出實施。
SJ/T 11234《軟體過程能力評估模型》針對軟體企業對自身軟體過程能力進行內部改進的需要,與CMMI連續表示形式基本相同。該模型有22個過程,分為4大類,即:過程管理類、專案管理類、工程化類和支援類,每個過程能力從0到5劃分為6個評估等級,每個等級包含了通用目標、通用慣例、特定目標和特定慣例,它們組成一套衡量準則。按此準則對實際執行的過程進行評估,可以確定當前軟體過程的能力狀態。對每個過程評估後,可以得到企業軟體過程能力的一條“譜線”。企業還可以針對軟體開發專案,根據專案的目標和要求,有針對性地“弄清楚”有關過程的能力狀態,實施必要的過程改進,以支援專案的完成。
SJ/T 111235《軟體能力成熟度模型》針對軟體企業綜合能力第二方或第三方評估的需求,與CMMI分階段表示形式基本相同。該模型用成熟度1~5個等級來描述綜合軟體能力。與SJ/T 11234相同,也有22個過程方面。除了成熟度等級1外,每個等級包含若干個過程方面,每個過程方面的實施情況由相應目標和慣例的實施情況體現。採用這種衡量準則可以評估軟體企業的綜合能力——軟體能力成熟程度。
SPCA評估遵循《軟體過程及能力成熟度評估指南》,該指南是國家認監委和資訊產業部2002年8月共同釋出的利用SJ/T11234或SJ/T11235實施評估的操作指南。評估過程由經過培訓的專業隊伍以評估參考模型作為確定過程的強項和弱項的基礎而對一個或多個過程進行檢查。從不同用途考慮,評估分為內部過程改進評估和顧客選擇評價兩種。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/3433/viewspace-420446/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- W君的“PMBOK與CMMI有何區別?”討論
- 敏捷與CMM的恩怨敏捷
- CMM2認證工作成果
- CMMI V2.0丨如何通過CMMI真正在企業中的實施規模化敏捷開發敏捷
- LinkedList和ArrayList的區別、Vector和ArrayList的區別
- http和https的區別/get和post的區別HTTP
- ||和??的區別
- /*和/**的區別
- ??與?:的區別
- 蜂蜜的區別
- CMMI術語中英文對照
- UIModalPresentationStyle 各種型別的區別UI型別
- 值型別與引用型別的區別型別
- scala中:: , +:, :+, :::, +++的區別
- jquery $(this) 和this的區別jQuery
- JQuery this和$(this)的區別jQuery
- T和?的區別
- makefile =和:=的區別
- ++a和a++的區別
- @synthesize @dynamic 的區別
- ../和./和/的區別
- ./ 和sh 的區別
- JavaScript中的“=、==、===”區別JavaScript
- python 中 is, is not ,==, != 的區別Python
- == euqals hascode的區別
- Golang的值型別和引用型別的範圍、儲存區域、區別Golang型別
- 自增長列和序列的區別(identity與sequence的區別)IDE
- JS 的型別(null 和 undefined 的區別)JS型別NullUndefined
- oracle知識整理(1) union和union all的區別,left join和right join的區別(各種join的區別)Oracle
- XML和HTML的主要區別、 jQuery 能做什麼?JavaScript中的“=、==、===”區別?XMLHTMLjQueryJavaScript
- 10.05.25主題--CMMI認證實施案例分析
- 帶你全面認識CMMI V2.0(二)
- PHP 中的 -> 和 :: 的區別PHP
- springmvc和springboot的區別SpringMVCSpring Boot
- animation、transition、transform的區別ORM
- SDK和API的區別?API
- const與static的區別
- HTTP 與 HTTPS 的區別HTTP