軟體能力成熟度模型(指能力成熟度模型)

CMM(指能力成熟度模型)一般指本詞條

本詞條是多義詞,共2個義項
更多義項 ▼ 收起列表 ▲

軟體能力成熟度模型是一種對軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述形成的標準。

基本介紹

  • 中文名:軟體能力成熟度模型
  • 簡稱:CMM
概述,分級,歷史來源,CMM的誕生,CMM的發展,

概述

CMM:其英文全稱為Capability Maturity Model for Software,英文縮寫為SW-CMM,簡稱CMM。它是對於軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述。CMM的核心是把軟體開發視為一個過程,並根據這一原則對軟體開發和維護進行過程監控和研究,以使其更加科學化、標準化、使企業能夠更好地實現商業目標。

分級

CMM是一種用於評價軟體承包能力並幫助其改善軟體質量的方法,側重於軟體開發過程的管理及工程能力的提高與評估。CMM分為五個等級:一級為初始級,二級為可重複級,三級為已定義級,四級為已管理級,五級為最佳化級。
CMM/CMMI將軟體過程的成熟度分為5個等級,以下是5個等級的基本特徵:
(1)初始級(initial)。工作無序,項目進行過程中常放棄當初的計畫。管理無章法,缺乏健全的管理制度。開發項目成效不穩定,項目成功主要依靠項目負責人的經驗和能力,他一但離去,工作秩序面目全非。
(2)可重複級(Repeatable)。管理制度化,建立了基本的管理制度和規程,管理工作有章可循。 初步實現標準化,開發工作比較好地按標準實施。 變更依法進行,做到基線化,穩定可跟蹤,新項目的計畫和管理基於過去的實踐經驗,具有重複以前成功項目的環境和條件。
(3)已定義級(Defined)。開發過程,包括技術工作和管理工作,均已實現標準化、文檔化。建立了完善的培訓制度和專家評審制度,全部技術活動和管理活動均可控制,對項目進行中的過程、崗位和職責均有共同的理解 。
(4)已管理級(Managed)。產品和過程已建立了定量的質量目標。開發活動中的生產率和質量是可量度的。已建立過程資料庫。已實現項目產品和過程的控制。可預測過程和產品質量趨勢,如預測偏差,實現及時糾正。
(5)最佳化級(Optimizing)。可集中精力改進過程,採用新技術、新方法。擁有防止出現缺陷、識別薄弱環節以及加以改進的手段。可取得過程有效性的統計數據,並可據進行分析,從而得出最佳方法。

歷史來源

CMM是由美國卡內基梅隆大學軟體工程研究所1987年研製成功的,是目前國際上最流行最實用的軟體生產過程標準和軟體企業成熟度等級認證標準。目前,我國已有軟體企業通過了CMM標準認證 。
SW-CMM(Capability Maturity Model For Software 軟體生產能力成熟度模型,以下簡稱"CMM"),是87年由美國卡內基梅隆大學軟體工程研究所(CMU SEI)研究出的一種一種用於評價軟體承包商能力並幫助改善軟體質量的方法,其目的是幫助軟體企業對軟體工程過程進行管理和改進,增強開發與改進能力,從而能按時地、不超預算地開發出高質量的軟體。
其所依據的想法是:只要集中精力持續努力去建立有效的軟體工程過程的基礎結構,不斷進行管理的實踐和過程的改進,就可以克服軟體生產中的困難。CMM它是目前國際上最流行、最實用的一種軟體生產過程標準,已經得到了眾多國家以及國際軟體產業界的認可,成為當今企業從事規模軟體生產不可缺少的一項內容。
CMM目前通用流行的版本是1.1(Version1.1)。《按照軟體工程研究所(SEI)的原來計畫,CMM的改進版版本2.0(V2.0)是要在1997年的11月完成的。但是,美國國防部辦公室要求軟體工程研究所(SEI)延遲發放公布CMM版本2.0,直至他們完成另一個更為緊迫的項目-CMMI。
CMMI(Capability Maturity Model Integration能力成熟度模型集成),是美國國防部的一個構想。他們希望把所有現存的與將被發展出來的各種能力成熟度模型,集成到一個框架中去。這個框架用於解決兩個問題:第一,軟體獲取辦法的改革;第二,從集成產品與過程發展的角度出發,建立一種包含健全的系統開發原則的過程改進。
CMM為軟體企業的過程能力提供了一個階梯式的改進框架,它基於過去所有軟體工程過程改進的成果,吸取了以往軟體工程的經驗教訓,提供了一個基於過程改進的框架;它指明了一個軟體組織在軟體開發方面需要管理哪些主要工作、這些工作之間的關係、以及以怎樣的先後次序,一步一步的做好這些工作而使軟體組織走向成熟。

CMM的誕生

資訊時代,軟體質量的重要性越來越為人們所認識。軟體是產品、是裝備、是工具,其質量使得顧客滿意,是產品市場開拓、事業得以發展的關鍵。而軟體工程領域在1992年至1997年取得了前所未有的進展,其成果超過軟體工程領域過去15年來的成就總和。
軟體管理工程引起廣泛注意源於20世紀70年代中期。當時美國國防部曾立題專門研究軟體項目做不好的原因,發現70%的項目是因為管理不善而引起,而並不是因為技術實力不夠,進而得出一個結論,即管理是影響軟體研發項目全局的因素,而技術只影響局部。到了20世紀90年代中期,軟體管理工程不善的問題仍然存在,大約只有10%的項目能夠在預定的費用和進度下交付。軟體項目失敗的主要原因有:需求定義不明確;缺乏一個好的軟體開發過程;沒有一個統一領導的產品研發小組;子契約管理不嚴格;沒有經常注意改善軟體過程;對軟體構架很不重視;軟體界面定義不善且缺乏合適的控制;軟體升級暴露了硬體的缺點;關心創新而不關心費用和風險;軍用標準太少且不夠完善等等。在關係到軟體項目成功與否的眾多因素中,軟體度量、工作量估計、項目規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。由此可見,軟體管理工程的意義至關重要。
軟體管理工程和其它工程管理相比有其特殊性。首先,軟體是知識產品,進度和質量都難以度量,生產效率也難以保證。其次,軟體系統複雜程度也是超乎想像的。因為軟體複雜和難以度量,軟體管理工程的發展還很不成熟。
軟體管理工程的發展,在經歷了從70年代開始以結構化分析與設計、結構化評審、結構化程式設計以及結構化測試為特徵的結構化生產時代,到90年代中期,以CMM模型的成熟模型和日益為市場接受為標誌,已經進入以過程成熟模型CMM、個體軟體過程PSP和群組軟體過程TSP為標誌的以過程為中心的時代,而軟體發展第三個時代,及軟體工業化生產時代,從90年代中期軟體過程技術的成熟和面向對象技術、構件技術的發展為基礎,已經漸露端倪,估計到2005年,可以實現真正的軟體工業化生產,這個趨勢應該引起軟體企業界和有關部門的高度重視,及早採取措施,跟上世界軟體發展的腳步。軟體生產轉向以改善軟體過程為中心,是世界各國軟體產業或遲或早都要走的道路。
軟體過程改善是當前軟體管理工程的核心問題。50多年來計算事業的發展使人們認識到要高效率、高質量和低成本地開發軟體,必須改善軟體生產過程。軟體管理工程走過了一條從70年代開始以結構化分析與設計、結構化評審、結構化程式設計以及結構化測試到90年代中期以過程成熟模型CMM、個體軟體過程PSP和群組軟體過程TSP為標誌的以過程為中心向著軟體過程技術的成熟和面向對象技術、構件技術的發展為基礎的真正軟體工業化生產的道路。軟體生產轉向以改善軟體過程為中心,是世界各國軟體產業或遲或早都要走的道路。軟體工業已經或正在經歷著"軟體過程的成熟化",並向"軟體的工業化"漸進過渡。規範的軟體過程是軟體工業化的必要條件。
軟體過程研究的是如何將人員、技術和工具等組織起來,通過有效的管理手段,提高軟體生產的效率,保證軟體產品的質量。由此誕生了軟體過程的三個流派:CMU-SEI的CMM/PSP/TSP;ISO 9000質量標準體系;ISO/IEC 15504(SPICE)。
CMM/PSP/TSP即軟體能力成熟度模型/ 個體軟體過程/群組軟體過程,是1987年美國 Carnegie Mellon 大學軟體工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表的研究成果"承制方軟體工程能力的評估方法";SO 9000質量標準體系是在70年代由歐洲首先採用的,其後在美國和世界其他地區也迅速地發展起來。目前,歐洲聯合會積極促進軟體質量的制度化,提出了如下ISO9000軟體標準系列:ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002;ISO/IEC 15504(SPICE)是1991年國際標準化組織採納了一項動議,開展調查研究,按照CMU-SEI的基本思路,產生的技術報告ISO/IEC 15504--信息技術軟體過程評估。
目前,學術界和工業界公認美國 Carnegie Mellon 大學軟體工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發的軟體能力成熟度模型CMM是當前最好的軟體過程,已成為業界事實上的軟體過程的工業標準。

CMM的發展

1987年美國 Carnegie Mellon 大學軟體工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表了CMM/PSP/TSP 技術,為軟體管理工程開闢了一條新的途經。
CMM框架用5個不斷進化的層次來評定軟體生產的歷史與現狀:其中初始層是混沌的過程,可重複層是經過訓練的軟體過程,定義層是標準一致的軟體過程,管理層是可預測的軟體過程,最佳化層是能持續改善的軟體過程。任何單位所實施的軟體過程,都可能在某一方面比較成熟,在另一方面不夠成熟,但總體上必然屬於這5個層次中的某一個層次。而在某個層次內部,也有成熟程度的區別。在CMM框架的不同層次中,需要解決帶有不同層次特徵的軟體過程問題。因此,一個軟體開發單位首先需要了解自己正處於哪一個層次,然後才能夠對症下藥地針對該層次的特殊要求解決相關問題,這樣才能收到事半功倍的軟體過程改善效果。任何軟體開發單位在致力於軟體過程改善時,只能由所處的層次向緊鄰的上一層次進化。而且在由某一成熟層次向上一更成熟層次進化時,在原有層次中的那些已經具備的能力還必須得到保持與發揚。
軟體產品質量在很大程度上取決於構築軟體時所使用的軟體開發和維護過程的質量。軟體過程是人員密集和設計密集的作業過程:若缺乏有素訓練,就難以建立起支持實現成功是軟體過程的基礎,改進工作亦將難以取得成效。CMM描述的這個框架正是勾列出從無定規的混沌過程向訓練有素的成熟過程演進的途徑。
CMM包括兩部分"軟體能力成熟度模型"和"能力成熟度模型的關鍵慣例"。"軟體能力成熟度模型"主要是描述此模型的結構,並且給出該模型的基本構件的定義。"能力成熟度模型的關鍵慣例"詳細描述了每個"關鍵過程方面"涉及的"關鍵慣例"。這裡"關鍵過程方面"是指一組相關聯的活動;每個軟體能力成熟度等級包含若干個對該成熟度等級至關重要的過程方面,它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域,反之有非關鍵過程域是指對達到相應軟體成熟度等級的目標不起關鍵作用。歸納為:互相關聯的若干軟體實踐活動和有關基礎設施的一個集合。而"關鍵慣例"是指使關鍵過程方面得以有效實現和制度化的作用最大的基礎設施和活動,對關鍵過程的實踐起關鍵作用的方針、規程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述"做什麼"而不強制規定"如何做"。各個關鍵慣例按每個關鍵過程方面的5個"公共特性"(對執行該過程的承諾,執行該過程的能力,該過程中要執行的活動,對該過程執行情況的度量和分析,及證實所執行的活動符合該過程)歸類,逐一詳細描述。當作到了某個關鍵過程的的全部關鍵慣例就認為實現了該關鍵過程,實現了某成熟度級及其以低級所含的全部關鍵過程就認為達到到了了該級。
上面提到了CMM把軟體開發組織的能力成熟度分為5個的等級。除了第1級外,其他每一級由幾個關鍵過程方面組成。每一個關鍵過程方面都由上述5種公共特性予以表征。CMM給每個關鍵過程了一些具體目標。每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例,這個關鍵過程的各項目標就達到了,也就表明該關鍵過程實現了。這種成熟度分級的優點在於,這些級別明確而清楚地反映了過程改進活動的輕重緩急和先後順序。

相關詞條

熱門詞條

聯絡我們