軟體測試中CMI是什麼

2021-03-07 05:53:13 字數 4879 閱讀 5608

1樓:叫獸

別說那麼複雜嘛,不復制哈,全稱縮寫是cmmi(先糾正,呵呵)是一個質量評估體系,你可以看做是評估一個公司的規範性達到多高的標準,評定級別越高,市場認可度就越大,當然,這也不是唯一體現一個公司真實水品的標準,呵呵

通常口述某級別都是:達到cm3或cm4這樣,呵呵

2樓:星辰

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

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

cmm是由美國卡內基梅隆大學軟體工程研究所2023年研製成功的,是目前國際上最流行最實用的軟體生產過程標準和軟體企業成熟度等級認證標準。目前,我國已有軟體企業通過了cmm標準認證 。

sw-cmm(capability maturity model for software 軟體生產能力成熟度模型,以下簡稱"cmm"),是87年由美國卡內基梅隆大學軟體工程研究所(cmu sei)研究出的一種一種用於評價軟體承包商能力並幫助改善軟體質量的方法,其目的是幫助軟體企業對軟體工程過程進行管理和改進,增強開發與改進能力,從而能按時地、不超預算地開發出高質量的軟體。

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

cmm目前通用流行的版本是1.1(version1.1)。《按照軟體工程研究所(sei)的原來計劃,cmm的改進版版本2.0(v2.0)是要在2023年的11月完成的。但是,美國國防部辦公室要求軟體工程研究所(sei)延遲發放公佈cmm版本2.0,直至他們完成另一個更為緊迫的專案-cmmi。

cmmi(capability maturity model integration能力成熟度模型整合),是美國國防部的一個設想。他們希望把所有現存的與將被發展出來的各種能力成熟度模型,整合到一個框架中去。這個框架用於解決兩個問題:

第一,軟體獲取辦法的改革;第二,從整合產品與過程發展的角度出發,建立一種包含健全的系統開發原則的過程改進。

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

一、cmm的誕生

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

軟體管理工程引起廣泛注意源於20世紀70年代中期。當時美國國防部曾立題專門研究軟體專案做不好的原因,發現70%的專案是因為管理不善而引起,而並不是因為技術實力不夠,進而得出一個結論,即管理是影響軟體研發專案全域性的因素,而技術隻影響區域性。到了20世紀90年代中期,軟體管理工程不善的問題仍然存在,大約只有10%的專案能夠在預定的費用和進度下交付。

軟體專案失敗的主要原因有:需求定義不明確;缺乏一個好的軟體開發過程;沒有一個統一領導的產品研發小組;子合同管理不嚴格;沒有經常注意改善軟體過程;對軟體構架很不重視;軟體介面定義不善且缺乏合適的控制;軟體升級暴露了硬體的缺點;關心創新而不關心費用和風險;軍用標準太少且不夠完善等等。在關係到軟體專案成功與否的眾多因素中,軟體度量、工作量估計、專案規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。

由此可見,軟體管理工程的意義至關重要。

軟體管理工程和其它工程管理相比有其特殊性。首先,軟體是知識產品,進度和質量都難以度量,生產效率也難以保證。其次,軟體系統複雜程度也是超乎想象的。

因為軟體複雜和難以度量,軟體管理工程的發展還很不成熟。

軟體管理工程的發展,在經歷了從70年代開始以結構化分析與設計、結構化評審、結構化程式設計以及結構化測試為特徵的結構化生產時代,到90年代中期,以cmm模型的成熟模型和日益為市場接受為標誌,已經進入以過程成熟模型cmm、個體軟體過程psp和群組軟體過程tsp為標誌的以過程為中心的時代,而軟體發展第三個時代,及軟體工業化生產時代,從90年代中期軟體過程技術的成熟和麵向物件技術、構件技術的發展為基礎,已經漸露端倪,估計到2023年,可以實現真正的軟體工業化生產,這個趨勢應該引起軟體企業界和有關部門的高度重視,及早採取措施,跟上世界軟體發展的腳步。軟體生產轉向以改善軟體過程為中心,是世界各國軟體產業或遲或早都要走的道路。

軟體過程改善是當前軟體管理工程的核心問題。50多年來計算事業的發展使人們認識到要高效率、高質量和低成本地開發軟體,必須改善軟體生產過程。軟體管理工程走過了一條從70年代開始以結構化分析與設計、結構化評審、結構化程式設計以及結構化測試到90年代中期以過程成熟模型cmm、個體軟體過程psp和群組軟體過程tsp為標誌的以過程為中心向著軟體過程技術的成熟和麵向物件技術、構件技術的發展為基礎的真正軟體工業化生產的道路。

軟體生產轉向以改善軟體過程為中心,是世界各國軟體產業或遲或早都要走的道路。軟體工業已經或正在經歷著"軟體過程的成熟化",並向"軟體的工業化"漸進過渡。規範的軟體過程是軟體工業化的必要條件。

軟體過程研究的是如何將人員、技術和工具等組織起來,通過有效的管理手段,提高軟體生產的效率,保證軟體產品的質量。由此誕生了軟體過程的三個流派:cmu-sei的cmm/psp/tsp;iso 9000質量標準體系;iso/iec 15504(spice)。

cmm/psp/tsp即軟體能力成熟度模型/ 個體軟體過程/群組軟體過程,是2023年美國 carnegie mellon 大學軟體工程研究所(cmu/sei)以w.s.humphrey為首的研究組發表的研究成果"承製方軟體工程能力的評估方法";so 9000質量標準體系是在70年代由歐洲首先採用的,其後在美國和世界其他地區也迅速地發展起來。

目前,歐洲聯合會積極促進軟體質量的制度化,提出瞭如下iso9000軟體標準系列:iso9001、iso9000-3、iso9004-2、iso9004-4、iso9002;iso/iec 15504(spice)是2023年國際標準化組織採納了一項動議,開展調查研究,按照cmu-sei的基本思路,產生的技術報告iso/iec 15504--資訊科技軟體過程評估

目前,學術界和工業界公認美國 carnegie mellon 大學軟體工程研究所(cmu/sei) 以w.s.humphrey為首主持研究與開發的軟體能力成熟度模型cmm是當前最好的軟體過程,已成為業界事實上的軟體過程的工業標準。

二、cmm的發展

2023年美國 carnegie mellon 大學軟體工程研究所(cmu/sei)以w.s.humphrey為首的研究組發表了cmm/psp/tsp 技術,為軟體管理工程開闢了一條新的途經。

cmm框架用5個不斷進化的層次來評定軟體生產的歷史與現狀:其中初始層是混沌的過程,可重複層是經過訓練的軟體過程,定義層是標準一致的軟體過程,管理層是可**的軟體過程,優化層是能持續改善的軟體過程。任何單位所實施的軟體過程,都可能在某一方面比較成熟,在另一方面不夠成熟,但總體上必然屬於這5個層次中的某一個層次。

而在某個層次內部,也有成熟程度的區別。在cmm框架的不同層次中,需要解決帶有不同層次特徵的軟體過程問題。因此,一個軟體開發單位首先需要了解自己正處於哪一個層次,然後才能夠對症下藥地針對該層次的特殊要求解決相關問題,這樣才能收到事半功倍的軟體過程改善效果。

任何軟體開發單位在致力於軟體過程改善時,只能由所處的層次向緊鄰的上一層次進化。而且在由某一成熟層次向上一更成熟層次進化時,在原有層次中的那些已經具備的能力還必須得到保持與發揚。

軟體產品質量在很大程度上取決於構築軟體時所使用的軟體開發和維護過程的質量。軟體過程是人員密集和設計密集的作業過程:若缺乏有素訓練,就難以建立起支援實現成功是軟體過程的基礎,改進工作亦將難以取得成效。

cmm描述的這個框架正是勾列出從無定規的混沌過程向訓練有素的成熟過程演進的途徑。

cmm包括兩部分"軟體能力成熟度模型"和"能力成熟度模型的關鍵慣例"。"軟體能力成熟度模型"主要是描述此模型的結構,並且給出該模型的基本構件的定義。"能力成熟度模型的關鍵慣例"詳細描述了每個"關鍵過程方面"涉及的"關鍵慣例"。

這裡"關鍵過程方面"是指一組相關聯的活動;每個軟體能力成熟度等級包含若干個對該成熟度等級至關重要的過程方面,它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域,反之有非關鍵過程域是指對達到相應軟體成熟度等級的目標不起關鍵作用。歸納為:

互相關聯的若干軟體實踐活動和有關基礎設施的一個集合。而"關鍵慣例"是指使關鍵過程方面得以有效實現和制度化的作用最大的基礎設施和活動,對關鍵過程的實踐起關鍵作用的方針、規程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述"做什麼"而不強制規定"如何做"。

各個關鍵慣例按每個關鍵過程方面的5個"公共特性"(對執行該過程的承諾,執行該過程的能力,該過程中要執行的活動,對該過程執**況的度量和分析,及證實所執行的活動符合該過程)歸類,逐一詳細描述。當作到了某個關鍵過程的的全部關鍵慣例就認為實現了該關鍵過程,實現了某成熟度級及其以低階所含的全部關鍵過程就認為達到到了了該級。

上面提到了cmm把軟體開發組織的能力成熟度分為5個的等級。除了第1級外,其他每一級由幾個關鍵過程方面組成。每一個關鍵過程方面都由上述5種公共特性予以表徵。

cmm給每個關鍵過程了一些具體目標。按每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例,這個關鍵過程的各專案標就達到了,也就表明該關鍵過程實現了。

這種成熟度分級的優點在於,這些級別明確而清楚地反映了過程改進活動的輕重緩急和先後順序

軟體測試級別中的SABC是什麼意思

1 小版本 du確認測試 2 高 3 中 4 低zhi 我們將測試用 dao例分成4類 專bvts,高,中和低。現屬在的問題是將測試用例分到不同的優先順序別裡。畢竟,優先順序別將指出哪些測試用例被認為是需要更頻繁的執行的,哪些又不是。軟體測試bug級別說明 b.重大性 處理結果不正確 流程不對 效能...

軟體測試中,軟體測試中 v模型和w模型的區別?

一 指代不同 1 v模型 是軟體開發過程中的一個重要模型,由於其模型構圖形似字母v,所以又稱軟體測試的v模型。2 w模型 由兩個v字型模型組成,分別代表測試與開發過程。二 特點不同 1 v模型 僅僅把測試過程作為在需求分析 系統設計及編碼之後的一個階段,忽視了測試對需求分析,系統設計的驗證,需求的滿...

軟體測試發展如何?自學軟體測試,看些什麼書好呢

你好,我就是做軟體測試的,不知道是什麼專業的?是否有基礎?我是軟體工程專業,但大學都打遊戲去了,如果你想學推薦你看 測試入門 軟體測試 效能測試 效能測試進階指南 loadrunner11實戰 不過我不建議你自學,畢竟技術性的東西,想要了解個大概很簡單,但想要自學後能直接從事這方面工作還是非常困難的...