能力成熟度模型

用手机看条目

出自 MBA智库百科(https://wiki.mbalib.com/)

能力成熟度模型(Capability Maturity Model for Software,英文縮寫為SW-CMM,簡稱CMM)

目錄

什麼是能力成熟度模型

  CMM是指“能力成熟度模型”,是對於軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述。CMM的核心是把軟體開發視為一個過程,並根據這一原則對軟體開發和維護進行過程監控和研究,以使其更加科學化、標準化、使企業能夠更好地實現商業目標。

  CMM是一種用於評價軟體承包能力並幫助其改善軟體質量的方法,側重於軟體開發過程的管理及工程能力的提高與評估。CMM分為五個等級:一級為初始級,二級為可重覆級,三級為已定義級,四級為已管理級,五級為優化級。

  其所依據的想法是:只要集中精力持續努力去建立有效的軟體工程過程的基礎結構,不斷進行管理的實踐和過程的改進,就可以剋服軟體生產中的困難。CMM它是目前國際上最流行、最實用的一種軟體生產過程標準,已經得到了眾多國家以及國際軟體產業界的認可,成為當今企業從事規模軟體生產不可缺少的一項內容。

  CMM為軟體企業的過程能力提供了一個階梯式的改進框架,它基於過去所有軟體工程過程改進的成果,吸取了以往軟體工程的經驗教訓,提供了一個基於過程改進的框架;它指明瞭一個軟體組織在軟體開發方面需要管理哪些主要工作、這些工作之間的關係、以及以怎樣的先後次序,一步一步的做好這些工作而使軟體組織走向成熟。

  軟體工程學會SEI的CMM模型的五個梯級如下:

Image:CMM.jpg

能力成熟度模型的歷史和發展

  信息時代,軟體質量的重要性越來越為人們所認識。軟體是產品、是裝備、是工具,其質量使得顧客滿意,是產品市場開拓、事業得以發展的關鍵。而軟體工程領域在1992年至1997年取得了前所未有的進展,其成果超過軟體工程領域過去15年來的成就總和。

  軟體管理工程引起廣泛註意源於20世紀70年代中期。當時美國國防部曾立題專門研究軟體項目做不好的原因,發現70%的項目是因為管理不善而引起,而並不是因為技術實力不夠,進而得出一個結論,即管理是影響軟體研發項目全局的因素,而技術隻影響局部。到了20世紀90年代中期,軟體管理工程不善的問題仍然存在,大約只有10%的項目能夠在預定的費用和進度下交付。軟體項目失敗的主要原因有:需求定義不明確;缺乏一個好的軟體開發過程;沒有一個統一領導的產品研發小組;子合同管理不嚴格;沒有經常註意改善軟體過程;對軟體構架很不重視;軟體界面定義不善且缺乏合適的控制;軟體升級暴露了硬體的缺點;關心創新而不關心費用和風險;軍用標準太少且不夠完善等等。在關係到軟體項目成功與否的眾多因素中,軟體度量、工作量估計、項目規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。由此可見,軟體管理工程的意義至關重要。

  1987年,美國卡內基. 梅隆大學軟體研究所(SEI)受美國國防部的委托,率先在軟體行業從軟體過程能力的角度提出了軟體過程成熟度模型(CMM),隨後在全世界推廣實施的一種軟體評估標準,用於評價軟體承包能力並幫助其改善軟體質量的方法。它主要用於軟體開發過程和軟體開發能力的評價和改進。它側重於軟體開發過程的管理及工程能力的提高與評估。CM自1987年開始實施認證,現已成為軟體業最權威的評估認證體系。CMM包括5個等級,共計18個過程域,52個目標,300多個關鍵實踐。

CMM的基本思想

  CMM的基本思想是,因為問題是由我們管理軟體過程的方法引起的,所以新軟體技術的運用不會自動提高生產率和利潤率。CMM有助於組織建立一個有規律的、成熟的軟體過程。改進的過程將會生產出質量更好的軟體,使更多的軟體項目免受時間和費用的超支之苦。

  軟體過程包括各種活動、技術和用來生產軟體的工具。因此,它實際上包括了軟體生產的技術方面和管理方面。CMM策略力圖改進軟體過程的管理,而在技術上的改進是其必然的結果。

  必須牢記,軟體過程的改善不可能在一夜之間完成,CMM是以增量方式逐步引入變化的。CMM明確地定義了5個不同的“成熟度”等級,一個組織可按一系列小的改良性步驟向更高的成熟度等級前進。其分級、特征與要求見表-1。

Image:CMM模型.gif

  成熟度等級1:初始級(Initial)。處於這個最低級的組織,基本上沒有健全的軟體工程管理制度。每件事情都以特殊的方法來做。如果一個特定的工程碰巧由一個有能力的管理員和一個優秀的軟體開發組來做,則這個工程可能是成功的。然而通常的情況是,由於缺乏健全的總體管理和詳細計劃,時間和費用經常超支。結果,大多數的行動只是應付危機,而非事先計劃好的任務。處於成熟度等級1的組織,由於軟體過程完全取決於當前的人員配備,所以具有不可預測性,人員變化了,過程也跟著變化。結果,要精確地預測產品的開發時間和費用之類重要的項目,是不可能的。

  成熟度等級2:可重覆級(Repeatable)。在這一級,有些基本的軟體項目的管理行為、設計和管理技術是基於相似產品中的經驗,故稱為“可重覆”。在這一級採取了一定措施,這些措施是實現一個完備過程所必不可缺少的第一步。典型的措施包括仔細地跟蹤費用和進度。不像在第一級那樣,在危機狀態下方行動,管理人員在問題出現時便可發現,並立即採取修正行動,以防它們變成危機。關鍵的一點是,如沒有這些措施,要在問題變得無法收拾前發現它們是不可能的。在一個項目中採取的措施也可用來為未來的項目擬定實現的期限和費用計劃。

  成熟度等級3:已定義級(Defined)。在第3級,已為軟體生產的過程編製了完整的文檔。軟體過程的管理方面和技術方面都明確地做了定義,並按需要不斷地改進過程,而且採用評審的辦法來保證軟體的質量。在這一級,可引用CASE環境來進一步提高質量和產生率。而在第—級過程中,“高技術”只會使這一危機驅動的過程更混亂。

  成熟度等級4:已管理級(Managed)。一個處於第4級的公司對每個項目都設定質量和生產目標。這兩個量將被不斷地測量,當偏離目標太多時,就採取行動來修正。利用統計質量控制,管理部門能區分出隨機偏離和有深刻含義的質量或生產目標的偏離(統計質量控制措施的一個簡單例子是每千行代碼的錯誤率。相應的目標就是隨時間推移減少這個量)。

  成熟度等級5:優化級(Optimizing)。—個第5級組織的目標是連續地改進軟體過程。這樣的組織使用統計質量和過程式控制制技術作為指導。從各個方面中獲得的知識將被運用在以後的項目中,從而使軟體過程融入了正反饋迴圈,使生產率和質量得到穩步的改進。

  整個企業將會把重點放在對過程進行不斷的優化,採取主動的措施去找出過程的弱點與長處,以達到預防缺陷的目標。同時,分析各有關過程的有效性資料,作出對新技術的成本與效益的分析,並提出對過程進行修改的建議。達到該級的公司可自發的不斷改進,防止同類缺陷二次出現。

  在表中可以看出,CMM為軟體的過程能力提供了一個階梯式的改進框架,它基於以往軟體工程的經驗教訓,提供了一個基於過程改進的框架圖,它指出一個軟體組織在軟體開發方面需要那些主要工作,這些工作之間的關係,以及開展工作的先後順序,一步一步的做好這些工作而使軟體組織走向成熟。CMM的思想來源於已有多年曆史的項目管理質量管理,自產生以來幾經修訂,成為軟體業具有廣泛影響的模型,並對以後項目管理成熟度模型的建立產生了重要的影響。儘管已有個人或團體提出了各種各樣的成熟度模型,但還沒有一個象CMM那樣在業界確立了權威標準的地位。但PMI於2003年發佈的OPM3以其立體的模型及涵蓋範圍的廣泛有望成為項目管理界的標準。

實施CMM的必要性

  軟體開發的風險之所以大,是由於軟體過程能力低,其中最關鍵的問題在於軟體開發組織不能很好地管理其軟體過程,從而使一些好的開發方法和技術起不到預期的作用。而且項目的成功也是通過工作組的傑出努力,所以僅僅建立在可得到特定人員上的成功不能為全組織的生產和質量的長期提高打下基礎,必須在建立有效的軟體如管理工程實踐和管理實踐的基礎設施方面,堅持不懈地努力,才能不斷改進,才能持續地成功。

  軟體質量是一模糊的、捉摸不定的概念。我們常常聽說:某某軟體好用, 某某軟體不好用;某某某軟體功能全、結構合理, 某某某軟體功能單一、操作困難……這些模模糊糊的語言不能算作是軟體質量評價,更不能算作是軟體質量科學的定量的評價。軟體質量,乃至於任何產品質量,都是一個很複雜的事物性質和行為。產品質量,包括軟體質量,是人們實踐產物的屬性和行為,是可以認識,可以科學地描述的。可以通過一些方法和人類活動,來改進質量。

  實施CMM是改進軟體質量的有效方法:控制軟體生產過程、提高軟體生產者組織性和軟體生產者個人能力的有效合理的方法軟體工程和很多研究領域及實際問題有關,主要相關領域和因素有:需求工程(REQUIREMENTS ENGINEERING)。理論上,需求工程是應用已被證明的原理、技術和工具,幫助系統分析人員理解問題或描述產品的外在行為。軟體復用(SOFTWARE REUSE),定義為利用工程知識或方法,由一已存在的系統,來建造一新系統。這種技術,可改進軟體產品質量和生產率。還有軟體檢查、軟體計量、軟體可靠性、軟體可維修性、軟體工具評估和選擇等。

本條目對我有幫助72
MBA智库APP

扫一扫,下载MBA智库APP

分享到:
  如果您認為本條目還有待完善,需要補充新內容或修改錯誤內容,請編輯條目

本条目由以下用户参与贡献

Zfj3000,Angle Roh,Wwdz,Vulture,Cabbage,Sabre,Yixi,KAER,方小莉,Lin,Mis铭.

評論(共7條)

提示:評論內容為網友針對條目"能力成熟度模型"展開的討論,與本站觀點立場無關。
121.9.32.* 在 2009年10月16日 17:47 發表

非常感謝

回複評論
210.75.15.* 在 2010年3月31日 12:58 發表

thanks a lot

回複評論
222.76.175.* 在 2010年7月22日 22:30 發表

謝謝了,呵呵,

回複評論
121.9.217.* 在 2010年10月27日 11:12 發表

非常感謝

回複評論
61.172.240.* 在 2014年6月12日 10:09 發表

CMM2:可重覆階段   需求管理:requrement management   軟體項目計劃:software project planning   軟體項目跟蹤和監督:software project tracking oversight   軟體子合同管理:software subcontract management   軟體質量保證:software quanlity assurance   軟體配置管理:software configuratione management   CMM3:已定義階段   組織過程焦點:organization process focus   組織過程定義:organization process definition   培訓大綱:training program   集成軟體管理:intergrated software management   軟體產品工程:software product engineering   組間協調:intergroup coordination   同行評審:peer review   CMM4:已管理階段   定量管理過程:quantitative process management   軟體質量管理:software quality management   CMM5:優化階段   缺陷預防:defect prevention   技術改革管理:technology change management   過程更改管理:process change management

回複評論
1.202.198.* 在 2014年9月9日 10:09 發表

good summary!

回複評論
61.149.182.* 在 2016年6月1日 16:17 發表

cmm去哪個網站查

回複評論

發表評論請文明上網,理性發言並遵守有關規定。

打开APP

以上内容根据网友推荐自动排序生成