WEB開發 de 點滴

■ 常用特殊字符

　　只要你認識了 HTML 標記，你便會知道特殊字符的用處。

CMMI(Capability Maturity Model Integration，能力成熟度模式整合)

CMMI（ Capability Maturity Model Integration）的本質是軟件管理工程的一個部分。軟件過程改善是當前軟件管理工程的核心問題， 50多年來計算的發展使人們認識到要高效率、高質量和低成本地開發軟件，必須改善軟件生產過程。基於模型的過程改進是指用採用能力模型來指導組織的過程改進，使之過程能力穩定的進行改善，該組織也能變得更加成熟。

然而，軟件組織形成一套完整而成熟的軟件過程不是一蹴而就的事情，需要經歷一系列的成熟度。軟件組織首先要進行差異分析，評定自己比較接近哪一個成熟度，然後再根據自身的情況來決定要採取哪些改進活動，來更有效地改進自己的軟件過程。這就對軟件過程的評定提出了一個客觀的標準。美國卡內基梅隆大學軟件工程學院於1987年研究成功的SW-CMM（Capability Maturity Model for Software）就是這樣的一個理論模型，其目的在於幫助軟件組織改善軟件生產流程，以探索一個保證軟件產品質量、縮短開發週期、提高工作效率的軟件工程模式與標準規範。

CMMI是一個可以改進系統工程和軟件工程的整合模式。1997年10月SEI停止對CMM的研究，改而致力於CMMI，以解決使用多個過程改進模型的問題。SEI同時宣佈CMMI將取代CMM，與2000年8月11日頒布了CMMI-SE/SW 1.0版本，2001年12月頒布了1.1版本，這次發佈標誌著CMMI正式啟用,並準備今年內完成CMM到CMMI的過渡。

CMM是由美國軟件工程學會（Software engineering inStitute）制定的一套專門針對軟件產品的質量管理和質量保證標準。該標準最初是為美國軍方選擇軟件產品提供商時評價軟件企業的軟件開發質量保證能力而制定，所以稱為軟件企業能力成熟度模型（Capability Maturity Model，簡稱CMM）。該標準將軟件企業的能力成熟度劃分為5個等級，級別越高表明該企業在提供合格軟件產品方面的能力越強。

CMMCapability Maturity Model　 是能力，成熟度模型的縮寫。CMM的工作最早開始于 1986年11月，當時為了滿足美國聯邦政府評估軟件供應商能力的要求，美國卡內基·梅隆大學的軟件工程研究院Sei　牽頭，在Mitre公司的協助下，于1987年9月發布了一份能力成熟度框架Capability Maturity fraMework　以及一套成熟度問卷 Maturity QueStionnaire　．很多人認為這套問卷就代表了CMM模型，其實它只是用于探索軟件過程成熟度的一個工具，真正的模型出現在四年以后。Sei總結了自1987年以來對成熟度框架和初版成熟度問卷的實戰經驗，并以此為基礎，推出了CMM1．0 版。這個推出于 1991年的 CMM1．0 集中了四年來對軟件公司評估的經驗以及廣泛的用戶反饋，在成熟度框架的基礎上建立了一個可用的模型，這個模型可以更加有效地幫助軟件企業建立和實施過程改進計劃。

CMM1．0 版使用兩年之后，于1992年四月進行了一個研討會，參加研討會的有約兩百名富有經驗的軟件專業人員。在廣泛聽取了他們的反饋意見之后，Sei于 1993 年推出了CMM1．1 版。近幾年來，CMM又推出了2．0 版本，同時進入了iSo 體系，稱為 iSo／ieC15504 或 SpiCe． SpiCe從1995年起進入實地測試階段，可能于2001年發布 。

CMM 致力于軟件開發過程的管理及工程能力的提高與評估。該模型在美國和北美地區已得到廣泛應用同時正在被越來越多的歐洲和亞洲等國家的大型信息技術企業所采納，實際上已成為軟件開發過程改進與評估的事實上的工業標準。

印度是軟件大國，十分重視軟件開發過程的管理及與其相關的理論與標準的發展。據統計，在印度的2000多家軟件公司中有75家軟件公司通過了iSo9000認證，60多家軟件公司通過了CMM認證，其中達到CMM5級一家，4級三家，3級4家。

CMM與iSo9000的區別主要有以下幾點：CMM是專門針對軟件產品開發及服務的，而iSo9000則有寬得多的范圍；CMM強調軟件開發過程的成熟度，即過程的不斷改進和提高，而iSo9000則僅描述可接收的質量體系的最低標準；CMM3級的覆蓋范圍要大于iSo9000的覆蓋范圍。

引進CMM的意義有兩個方面

1．對軟件企業：

提高軟件開發的管理能力：CMM提供了軟件企業自我評估的方法和自我提高的手段；提高軟件生產率；加強軟件生產的國際競爭力。

2．對軟件項目發包單位和軟件用戶：

提供了對軟件開發商開發管理水平的評估手段，有助于軟件開發項目的風險識別。

CMM與CMMI對比
來源：Worthy Tech
CMMI：

CMMI 全稱是Capability Maturity Model Integration, 即軟件能力成熟度模型集成模型，是由美國國防部與卡內基-梅隆大學和美國國防工業協會共同開發和研制的。CMMI是一套融合多學科的、可擴充的產品集合，其研制的初步動機是為了利用兩個或多個單一學科的模型實現一個組織的集成化過程改進。CMMI可以解決現有不同CMM模型的重復性、復雜性，并減少由此引起的成本、縮短改進過程，它將軟件CMM2.0版草案（SW-CWW）、EIA過渡標準731（系統工程CMM）及IPD-CMM集成為一體，同時還與 ISO15504相兼容。 CMMI是有效過程元素的集合，目前有如下模型：?
CMMI是有效過程元素的集合，目前有如下模型：
CMMI-SE/SW/IPPD/SS,V1.1
CMMI-SE/SW/IPPD V1.1
CMMI-SE/SW V1.1
CMMI-SW V1.1?

CMMI自推出以來，在世界各地得到了廣泛的推廣與接受。在日本、歐洲、臺灣、印度等地都有很多企業在推廣與應用CMMI模型。尤其在印度CMMI的應用甚至超過了美國。

CMMI階段式的基本結構從CMM演變而來，但是CMMI的結構更加的形式化和精致，也更加的復雜，尤其為了保證連續式和階段式的同一性，更加增加了結構的理解難度。

CMMI強調了對需求的管理，有兩個過程域說明對需求的控制：需求管理REQM、需求開發RD。而在CMM中只有一個關鍵過程域需求管理RM以及軟件產品工程SPE中的一個實踐來說明對需求的管理和控制。

CMMI加強了對工程過程的重視，提供了更加細致的要求和指導，而CMM中卻只有一個SPE關鍵過程來進行要求和指導CMMI強調了度量，并且從項目的早期就已經進行了度量，在階段式中CMMI二級由一個過程域度量和分析；而在CMM中沒有專門的要求和指導。

CMMI對比CMM更加強調了對風險的管理，在CMM中風險只“是項目策劃”SPP中的一個活動，而在CMMI中風險管理作為一個單獨的過程域。　

CMM：
CMM作為較早推出的軟件過程改進標準，目前已在世界范圍被廣泛地推廣和應用。不可否認，CMM在建立有效的開發系統、控制軟件產品開發過程式、降低軟件企業內外部故障成本、提高企業的經濟效益和社會效益等方面，取得了巨大成功。

但CMM也存在著一些不足，如CMM中的一個關鍵過程域“組間協調”IC在CMMI中地位下降，只是作為“集成化項目管理”IPM中的一個目標。

CMM中的關鍵過程域“同行評審”PR，在CMMI中得到了更高的抽象；對應CMMI的“驗證”VER，說明了對產品進行相應的QC活動。（同行評審本身就是一種QC活動）。

CMMI的公共特性中，沒有了測量（ME），這些度量內容被組織起來形成了一個支持過程“度量和分析”。具體理由如下：
度量和分析本身應用的復雜性和它執行的高成本在原來的CMM中每個KPA均有單獨的測量要求，容易造成“過度測量”，也沒有形成對組織級的、統一的度量體系的指導和要求，造成實施中的困難。例如在CMM中如果一個組織達到了CMM三級，由于各個KPA均要求了測量（ME），實際上已經建立了全組織過程的測量，這和CMM的等級劃分思想是有著沖突的。

總結：
CMMI改進了這個方面，要求組織從組織級的統一要求出發建立度量體系。這樣的想法也符合過程改進理論的思想；這樣組織在實施過程中可以選擇必要的過程進行測量，而不是全部過程的測量，從這個意義上，CMMI對比CMM降低了對度量的要求和實施難度，但是更加具有全局性和可實施性。

CMM是作為評估標準出現的，所以是“必要”的才能保證評估的標準。

CMMI是作為改進模型出現的，羅列了較多的最佳實踐，利于過程的改進。