holidayinn斯图加特
  
ISO14001 環境管理體系
ISO 27001 信息安全管理體系
QC080000 有害物質流程管理體系
ISO9001 質量管理體系
OHSAS18001 職業健康安全管理體系
ISO13485 醫療器械質量管理體系
TS16949 汽車行業管理體系認證
ISO22000食品安全管理體系
SA8000 社會責任國際標準
TL9000 電訊行業質量管理體系
GMP 良好作業規范
FSC森林認證
CMMI
TAPA 物流安全標準認證
AS9100 航空基礎質量體系標準
HSE
ISO50001能源管理體系
ISO 20000 IT服務管理體系
CMMI能力成熟度模型集成
CMMI

一、CMMI-簡介             
        CMMI 的全稱為:Capability Maturity Model Integration,即能力成熟度模型集成

CMMI家族包括CMMI for Development, CMMI for ServiceCMMI for Acquisition三個套裝產品。

早期的CMMICMMI-SE/SW/IPPD1.02版本是應用于軟件業項目的管理方法,SEI在部分國家和地區開始推廣和試用。隨著應用的推廣與模型本身的發展,演繹成為一種被廣泛應用的綜合性模型。

自從1994 SEI 正式發布軟件CMM 以來,相繼又開發出了系統工程、軟件采購、人力資源管理以及集成產品和過程開發方面的多個能力成熟度模型。雖然這些模型在許多組織都得到了良好的應用,但對于一些大型軟件企業來說,可能會出現需要同時采用多種模型來改進自己多方面過程能力的情況。這時他們就會發現存在一些問題,其中主要問題體現在:

  n 不能集中其不同過程改進的能力以取得更大成績;

  n 要進行一些重復的培訓、評估和改進活動,因而增加了許多成本;

  n 遇到不同模型中有一些對相同事物說法不一致,或活動不協調,甚至相抵觸。

于是,希望整合不同CMM 模型的需求產生了。1997 年,美國聯邦航空管理局(FAA)開發了FAA-i CMMSM (聯邦航空管理局的集成CMM),該模型集成了適用于系統工程的SE-CMM、軟件獲取的SA-CMM 和軟件的SW-CMM 三個模型中的所有原則、概念和實踐。該模型被認為是第一個集成化的模型。

二、評估預備工作

  評估實踐證明:在進行CMMI評估之前,制定一個正確的評估計劃并將其文檔化,確保有一個富有經驗的、受過培訓且具有適當資格的小組能被用來評估,為執行評估過程做準備,是十分必要的。

  我們所說的文檔化CMMI評估計劃的結果,包括:要求,協定,估價,風險,剪裁方法,以及與評估相關的實際考慮(例如:日程安排,后勤,組織的背景信息)。此外,還應當獲取并記錄發起方對于CMMI評估計劃的正式批準。在制定評估計劃之前,應對CMMI評估輸入中反映出來的協議文檔化,該協議將有助于CMMI評估目標和關鍵評估計劃參數的共同理解。在對驅動計劃過程的關鍵參數達成共同理解的基礎上,CMMI評估發起方和SCAMPI主任評估師應就評估計劃達成一致;發起者和評估小組領導應就已計劃的評估中技術和非技術細節達成一致。這個計劃在執行其他的計劃和準備階段活動中需要進一步細化。

  而通過CMMI評估小組的準備工作,將產生一支富有經驗的、受過培訓的且定位準確的小組準備執行CMMI評估任務。該小組的成員都應當獲得了完成他們各自的任務所必備的知識,或者他們之前所擁有的知識被證實足以完成相關任務。評估小組領導者已經給每一個人提供了為完成他們各自的任務所需的對技能進行實踐的機會,或者證實這些技能在過去已經得到了示范。小組成員相互了解,同時開始計劃他們如何協調一致的工作。還應該做到:準備好的小組是為評估目標而服務的,小組的成員已提供培訓且培訓結果被記錄,在必要的時候,對他們所做的因知識或技能不足的補救工作已經完成。我們認為,無論CMMI評估小組領導者是從頭培訓一支全新的評估小組,還是通過從富有經驗的小組成員中選擇來組建一個小組,確保他們與CMMI評估小組領導者能組成一個成功的集體是其責任。此外,在對CMMI評估進行的預備工作的過程中,我們還應當對模型剪裁的原則有所了解:

  1.在某些應用中,計劃模板和例行的程序能夠根據評估的需要進行調整,這和當地的過程所有權一樣,有助于交流;

  2.一個結構化的計劃工藝組有利于只有有限的評估經驗的組織,這樣一個工藝就像緩和策略樣,對于發現風險是一個很有價值的機會;

  3.案例研究材料提供了各種各樣的選擇來擴充小組培訓內容以增強那些更需要培訓的重點;

  4.富有經驗的評估小組領導者在沒有案例分析的情況下,同樣可以管理和模擬評估行為;

  5.在小組所有已獲得培訓成員的集合中,對小組的建立工作進行管理以確保其團隊凝聚力是十分重要的,因此,很多的小組建立練習是可以利用的,小組的規模、技能、組成部分都是本方法的裁剪內容;

  6.所采用工具可以包括評估計劃模板,樣例,和計劃模板中嵌入式的程序上的幫助,此外,為了估計評估約束的影響,估算工作表和方法也是很有用處的。

  總之,CMMI評估是一個十分復雜的過程,更由于其具有的不確定性,在評估的實踐中,一定要做到有備無患。真理來自于實踐,我們相信,隨著越來越多的軟件組織著手CMMI評估,越來越多的成功經驗將為我們所利用和借鑒。

評估方法

1991年起,CMM出現了很多模型,覆蓋了各種各樣的專業領域。其中著名的模型有系統工程·軟件工程·軟件采購·集成產品和流程開發等。然而當企業想要在組織內不同專業領域的流程改進,這些針對不同專業領域的模型在架構·內容和方法上的不同限制了組織成功實施改進的能力。此外,將這樣模型在組織內部集成也提高了培訓·認證和改進的費用。一套包括多個專業領域的模型加上整合的培訓和認證支持將解決這些問題。

  CMMI(Capability maturity model integration)是為了合并三個模型到一個框架中

  Capability Maturity Model for Software (SW-CMM) v2.0 draft C,

  Electronic Industries Alliance Interim Standard (EIA/IS) 731

  Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98

  正如其他CMM模型,CMMI提供了流程改進的指導,而不是流程或流程的描述。組織使用的實際流程取決于很多因素,包括應用領域·組織框架和規模。CMMI將許多經過驗證的方法加入架構中,來幫組組織評價成熟度·某個軟件流程的能力度,并且建立改進的優先順序和實施改進。

  從CMMI框架可以產生不同的CMMI模型,因此必須首先確定那種模型最適合企業流程改進的需要。

  階段式描述 or 連續式描述

  系統工程 or 軟件工程 or 兩者皆有

  使用連續式描述可以根據企業需要選擇流程改進順序,降低企業風險,這給通過ISO做流程改進提供了一個方便的比較。使用能力度(Capability)來衡量。

  階段式描述提供了已經過驗證的流程改進順序,方便從CMM移植過來。使用成熟度(Maturity)來衡量流程改進。

  系統工程包括整個系統的開發,可能包括軟件也可能不包括。

  軟件工程用于軟件系統的開發,主要集中在使用系統的·科學的·量化的方法來開發·運行·維護軟件。

CMM是項目管理

  由美國卡內基梅隆大學的軟件工程研究所(SEI)創立的CMM(Capability Maturity Model 軟件能力成熟度模型)認證評估,在過去的十幾年中,對全球的軟件產業產生了非常深遠的影響。CMM共有五個等級,分別標志著軟件企業能力成熟度的五個層次。從低到高,軟件開發生產計劃精度逐級升高,單位工程生產周期逐級縮短,單位工程成本逐級降低。據SEI統計,通過評估的軟件公司對項目的估計與控制能力約提升40%50%;生產率提高10%20%,軟件產品出錯率下降超過1/3

  對一個軟件企業來說,達到CMM2就基本上進入了規模開發,基本具備了一個現代化軟件企業的基本架構和方法,具備了承接外包項目的能力。CMM3評估則需要對大軟件集成的把握,包括整體架構的整合。一般來說,通過CMM認證的級別越高,其越容易獲得用戶的信任,在國內、國際市場上的競爭力也就越強。因此,是否能夠通過CMM認證也成為國際上衡量軟件企業工程開發能力的一個重要標志。

CMM是目前世界公認的軟件產品進入國際市場的通行證,它不僅僅是對產品質量的認證,更是一種軟件過程改善的途徑。參與CMM評估的博科負責人表示,通過CMM的評估認證不是目標,它只是推動軟件企業在產品的研發、生產、服務和管理上不斷成熟和進步的手段,是一種持續提升和完善企業自身能力的過程。如果一家公司最終通過CMMI的評估認證,標志著該公司在質量管理的能力已經上升到一個新的高度。

 三、等級                                                        

   1 初始級

軟件過程是無序的,有時甚至是混亂的,對過程幾乎沒有定義,成功取決于個人努力。管理是反應式的。

   2.可重復級

  建立了基本的項目管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律,能重復早先類似應用項目取得的成功經驗。

   3 已定義級

  已將軟件管理和工程兩方面的過程文檔化、標準化,并綜合成該組織的標準軟件過程。所有項目均使用經批準、剪裁的標準軟件過程來開發和維護軟件,軟件產品的生產在整個軟件過程是可見的。

   4 量化管理級

  分析對軟件過程和產品質量的詳細度量數據,對軟件過程和產品都有定量的理解與控制。管理有一個作出結論的客觀依據,管理能夠在定量的范圍內預測性能。

   5 優化管理級

  過程的量化反饋和先進的新思想、新技術促使過程持續不斷改進。

  每個等級都被分解為過程域,特殊目標和特殊實踐,通用目標、通用實踐和共同特性:

  每個等級都有幾個過程區域組成,這幾個過程域共同形成一種軟件過程能力。每個過程域,都有一些特殊目標和通用目標,通過相應的特殊實踐和通用實踐來實現這些目標。當一個過程域的所有特殊實踐和通用實踐都按要求得到實施,就能實現該過程域的目標。

  能力度等級:屬于連續式表述,共有六個能力度等級(0~5),每個能力度等級對應到一個一般目標,以及一組一般執行方法和特定方法。

  0 不完整級

  1 執行級

  2 管理級

  3 定義級

  4 量化管理級

  5 最佳化級

四、評估方式                                                     

  自我評估:用于本企業領導層評價公司自身的軟件能力。

  主任評估:使本企業領導層評價公司自身的軟件能力,向外宣布自己企業的軟件能力

  CMMI的評估類型:

  軟件組織的關于具體的軟件過程能力的評估。

  軟件組織整體軟件能力的評估(軟件能力成熟度等級評估)。

五、CMMI的基本思想                                                

  1、解決軟件項目過程改進難度增大問題

  2、實現軟件工程的并行與多學科組合

  3、實現過程改進的最佳效益

六、研發背景                                                 

  CMM的成功促使其他學科也相繼開發類似的過程改進模型,例如系統工程、需求工程、

  人力資源、集成產品開發、軟件采購等等,從CMM衍生出了一些改善模型,比如:

  (1 SW-CMM (Software CMM) 軟件CMM

  (2 SE-CMM (System Engineering CMM) 系統工程CMM

  (3 SA-CMM (Software Acquisition CMM) 軟件采購CMM

  (4 IPT-CMM (Integrated Product Team CMM) 集成產品群組CMM

  (5 P-CMM (People CMM) 人力資源能力成熟度模型

  為了以示區別,國內外很多資料把CMM叫做SW-CMM。按照SEI原來的計劃,CMM的改進版本2.0應該在199711月完成,然后在取得版本2.0得實踐反饋意見之后,在1999年完成準CMM2.0版本。

  但是,美國國防部辦公室要求SEI推遲發布CMM2.0版本,而要先完成一個更為緊迫的項目CMMI,原因是在同一個組織中多個過程改進模型的存在可能會引起沖突和混淆, CMMI就是為了解決怎么保持這些模式之間的協調。

  CMMICapability Maturity Model Integration)即能力成熟度集成模型,這是美國國防部的一個設想,他們想把現在所有的以及將被發展出來的各種能力成熟度模型,集成到一個框架中去。這個框架有兩個功能,第一,軟件采購方法的改革;第二,建立一種從集成產品與過程發展的角度出發、包含健全的系統開發原則的過程改進。就軟件而言,CMMISW-CMM修訂本

  它兼收了SW-CMM 2.0C稿草案和SPA中更合理、更科學和更周密的優點。SEI在發表CMMI-SE/SW 1.0版時,宣布大約用兩年的時間完成從CMMCMMI的過渡。

  CMMI項目更為工業界和政府部門提供了一個集成的產品集,其主要目的是消除不同模型之間的不一致和重復,降低基于模型改善的成本。CMMI將以更加系統和一致的框架來指導組織改善軟件過程,提高產品和服務的開發、獲取和維護能力。

  由業界、美國政府和卡內基?梅隆大學軟件工程研究所率先倡導的能力成熟度模型集成(CMMI)項目致力于幫助企業緩解這種困境。CMMI為改進一個組織的各種過程提供了一個單一的集成化框架,新的集成模型框架消除了各個模型的不一致性,減少了模型間的重復,增加透明度和理解,建立了一個自動的、可擴展的框架。因而能夠重總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。

  與原有的能力成熟度模型類似,CMMI也包括了在不同領域建立有效過程的必要元素,反映了業界普遍認可的"最佳"實踐;專業領域覆蓋軟件工程、系統工程、集成產品開發和系統采購。在此前提下,CMMI為企業的過程構建和改進提供了指導和框架作用;同時為企業評審自己的過程提供了可參照的行業基準。

七、源模型                                                      

  軟件能力成熟度模型2.0版,C稿;電子行業協會臨時標準(EIA/IS731;集成產品開發能力成熟度模型(IPD-CMMv0.98

八、原則                                                         

  (1)強調高層管理者的支持。過程改進往往也是由高層管理者認識和提出的,大力度的、一致的支持是過程改進的關鍵。

  (2)仔細確定改進目標,首先應該對給定時間內的所能完成的改進目標進行正確的估計和定義并制定計劃。選擇能夠達到的目標和能夠看到對組織的效益。

  (3)選擇最佳實踐,應該基于組織現有的軟件活動和過程財富,參考其他標準模型,取其精華去其糟粕,得到新的實踐活動模型。

  (4)過程改進要與組織的商務目標一致,與發展戰略緊密結合。

九、目標                                                          

  (1)為提高組織過程和管理產品開發、發布和維護能力提供保障。

  (2)幫助組織客觀評價自身能力成熟度和過程域能力,為過程改進建立優先級以及執行過程改進。

十、方法                                                           

  (1)決定哪個CMMI模型等級最適合組織過程改進需要。

  (2)選擇模型的表示法是連續式還是階段式。

  (3)決定組織需要用到的模型中的知識領域。

  (4)類似CMM提出的過程改進6步,集成化過程改進分成:開始集成過程改進,建造集成改善平臺,集成傳統過程,啟動新過程,進行改進評估。

十一、內容                                                       

  CMMI內容分為“Required”(必需的)、“Expected”(期望的)、“Informative”(提供信息的)三個級別,來衡量模型包括的質量重要性和作用。最重要的是"要求"級別,是模型和過程改進的基礎。第二級別"期望"在過程改進中起到主要作用,但是某些情況不是必須的可能不會出現在成功的組織模型中。 "提供的信息"構成了模型的主要部分,為過程改進提供了有用的指導,在許多情況下他們對"必需""期望"的構件做了進一步說明。

  "必需"的模型構件是目標,代表了過程改進想要達到的最終狀態,它的實現表示了項目和過程控制已經達到了某種水平。當一個目標對應一個關鍵過程域,就稱為"特定目標";對應整個關鍵過程域就稱為"公用目標"。整個CMMI模型包括了54個特定目標,每個關鍵過程域都對應了一到四個特定目標。每個目標的描述都是非常簡捷的,為了充分理解要求的目標就是擴展"期望"的構件。

  "期望"的構件是方法,代表了達到目標的實踐手段和補充認識。每個方法都能映射到一個目標上,當一個方法對一個目標是唯一就是"特定方法";而能適用于所有目標時就是"公用方法"CMMI模型包括了186個特定方法,每個目標有兩到七個方法對應。

  CMMI包括了10"提供的信息":目的,概括和總結了關鍵過程域的特定目標;介紹說明,介紹關鍵過程域的范圍、性質和實際方法和影響等特征;引用,關鍵過程域之間的指向是通過引用;名字,表示了關鍵過程域的構件;方法和目標關系,關鍵過程域中方法映射到目標的關系表;注釋,注釋關鍵過程域的其他模型構件的信息來源;典型工作產品集,定義關鍵過程域中執行方法時候產生的工作產品;子方法,通過方法活動的分解和詳細描述;學科擴充,CMMI對應學科是獨立的,這里提供了對應特定學科的擴展;公用方法的詳細描述,關鍵過程域中公用方法應用實踐的詳細描述。

  CMMI提供了階段式和連續式兩種表示方法,但是這兩種表示法在邏輯上是等價的。我們熟悉的SW-CMM軟件能力成熟模型就是是階段式的模型,SE-CMM系統工程模型是連續式模型,而IPD-CMM集成產品開發模型結合了階段式和連續式兩者的特點。

  階段式方法將模型表示威一系列"成熟度等級"階段,每個階段都有一組KPA指出一個組織應集中于何處以改善其組織過程,每個KPA用滿足其目標的方法來描述,過程改進通過在一個特定的成熟度等級中滿足所有KPA的目標而實現的。

  連續式模型沒有像階段式那樣的分散階段,模型的KPA中的方法是當KPA的外部形式,并可應用于所有的KPA中,通過實現公用方法來改進過程。它不專門指出目標,而是強調方法。組織可以根據自身情況適當裁剪連續模型并以確定的KPA為改進目標。

  兩種表示法的差異反應了為每個能力和成熟度等級描述過程而使用的方法,他們雖然描述的機制可能不同,但是兩種表示方法通過采用公用的目標和方法作為"必需"的和"期望"的模型元素,而達到了相同的改善目的。

  現在CMMI面臨的一個挑戰就是創建一個單一的模型,可以從連續和階段兩個角度進行觀察,包含相同的過程改進基本信息;處理相同范圍的一個CMMI過程能夠產生相同的結論。統一的CMMIU-CMMI)是指產生一個只有公用方法和支持他們的KPA組成的模型。當按一種概念性的可伸展的方式編寫,并產生了用于定義組織的特定目標過程模版,定義的模版構件將定義一個模型以適用于任何工程或其他方面。

十二、CMM差別                                                 

  CMMI 模型的前身是 SW-CMM SE-CMM,前者就是我們指的CMMCMMISW-CMM的主要區別就是覆蓋了許多領域;到目前為止包括四個下面領域:

  (1)軟件工程(SW-CMM

  軟件工程的對象是軟件系統的開發活動,要求實現軟件開發、運行、維護活動系統化、制度化、量化。

  (2)系統工程(SE-CMM

  系統工程的對象是全套系統的開發活動,可能包括也可能不包括軟件。系統工程的核心是將客戶的需求、期望和約束條件轉化為產品解決方案,并對解決方案的實現提供全程的支持。

  (3)集成的產品和過程開發(IPPD-CMM

  集成的產品和過程開發是指在產品生命周期中,通過所有相關人員的通力合作,采用系統化的進程來更好地滿足客戶的需求、期望和要求。如果項目或企業選擇IPPD進程,則需要選用模型中所有與IPPD相關的實踐。

  (4)采購(SS-CMM

  采購的內容適用于那些供應商的行為對項目的成功與否起到關鍵作用的項目。主要內容包括:識別并評價產品的潛在來源、確定需要采購的產品的目標供應商、監控并分析供應商的實施過程、評價供應商提供的工作產品以及對供應協議很供應關系進行適當的調整。

  在以上模塊中,企業可以選擇軟件工程,或系統工程,也可以都選擇。集成的產品和過程開發和采購主要是配合軟件工程和系統工程的內容使用。例如,純軟件企業可以選擇CMMI中的軟件工程的內容;設備制造企業可以選擇系統工程和采購;集成的企業可以選擇軟件工程、系統工程和集成的產品和過程開發。CMMI中的大部分內容是適用各不同領域的,但是實施中會有顯著的差別,因此模型中提供了"不同領域應用詳解"

  CMM的基于活動的度量方法和瀑布過程的有次序的、基于活動的管理規范有非常密切的聯系,更適合瀑布型的開發過程。而CMMI相對CMM更一步支持迭代開發過程和經濟動機推動組織采用基于結果的方法:開發業務案例、構想和原型方案;細化后納入基線結構、可用發布,最后定為現場版本的發布。雖然CMMI保留了基于活動的方法,它的確集成了軟件產業內很多現代的最好的實踐,因此它很大程度上淡化了和瀑布思想的聯系。

  在 CMMI 模型中在保留了CMM階段式模式的基礎上,出現了連續式模型,這樣可以幫助一個組織以及這個組織的客戶更加客觀和全面的了解它的過程成熟度。同時,連續模型的采用可以給一個組織在進行過程改進的時候帶來更大的自主性,不用再象CMM 一樣,受到等級的嚴格限制。這種改進的好處是靈活性和客觀性強,弱點在于由于缺乏指導,一個組織可能缺乏對關鍵過程域之間依賴關系的正確理解而片面的實施過程,造成一些過程成為空中樓閣,缺少其他過程的支撐。兩種表現方式(連續的和階段的)從他們所涵蓋的過程區域上來說并沒有不同,不同的是過程區域的組織方式以及對成熟度(能力)級別的判斷方式。

  CMMI 模型中比CMM 進一步強化了對需求的重視。在CMM 中,關于需求只有需求管理這一個關鍵過程域,也就是說,強調對有質量的需求進行管理,而如何獲取需求則沒有提出明確的要求。在CMMI的階段模型中,3 級有一個獨立的關鍵過程域叫做需求開發,提出了對如何獲取優秀的需求的要求和方法。CMMI 模型對工程活動進行了一定的強化。在CMM中,只有3級中的軟件產品工程和同行評審兩個關鍵過程域是與工程過程密切相關的,而在CMMI中,則將需求開發,驗證,確認,技術解決方案,產品集成這些工程過程活動都作為單獨的關鍵過程域進行了要求,從而在實踐上提出了對工程的更高要求和更具體的指導。CMMI中還強調了風險管理。不像在CMM 中把風險的管理分散在項目計劃和項目跟蹤與監控中進行要求,CMMI3級里單獨提出了一個獨立的關鍵過程域叫做風險管理。

十三、標準名詞術語                                               

  1 AT Assessment Team 評審小組

  2 ATM Assessment Team Member 評審小組成員

  3 BA Baseline Assessment 基線評審

  4 CAR Causal Analysis and Resolution 原因分析與決策

  5 CBA CMM-Based Appraisal 基于CMM的評價

  6 CBA-IPI

  CMM-Based Appraisal for Internal Process

  Improvement

  為內部過程改進而進行的基于CMM的評價(通常

  稱為CMM評審)

  7 CC Configuration Controller 配置管理員

  8 CF Common Feature 公共特性

  9 CFPS Certified Function Point Specialist 注冊功能點專家

  10 CI Configuration Item 配置項

  11 CM Configuration Management 配置管理

  12 CMM Capability Maturity Model 能力成熟度模型

  13 CMMI Capability Maturity Model Integration 能力成熟度集成模型

  14 COTS Commerce off the shelf 商業現貨供應

  15 DAR Decision Analysis and Resolution 決策分析與制定

  16 DBD Database Design 數據庫設計

  17 DD Detailed Design 詳細設計

  18 DP Data Provider 數據提供者

  19 DR Derived Requirement 派生需求

  20 EPG Engineering Process Group 工程過程小組

  21 FP Function Point 功能點

  22 FPA Function Point Analysis 功能點分析

  23 FR Functional Requirement 功能性需求

  24 GA Gap Analysis 差距分析

  25 ID Interface Design 接口設計

  26 IFPUG International Function Point Users Group 國際功能點用戶組織

  27 IPM Integrated Project Management 集成項目管理

  28 IR Interface Requirement 接口需求

  29 KPA Key Process Area 關鍵過程域

  30 KR Key Requirements 關鍵需求

  31 LA Lead Assessor 主任評審員

  32 MA Measurement and Analysis 測量與分析

  33 MAT Metrics Advisory Team 度量咨詢組

  34 MCA Metrics Coordinator and Analyst 度量專員

  35 ML matriarchy library 度量數據庫

  36 NFR Non-functional Requirement 非功能性需求

  37 OC Operational Concept 操作概念

  38 OID Organizational Innovation and Deployment 組織革新與部署

  39 OPD Organizational Process definition 組織過程定義

  40 OPF Organizational Process focus 組織過程焦點

  41 OPL Organizational Process Assets 組織過程財富

  42 OPP Organizational Process Performance 組織過程性能

  43 OSSP Organization’s Set of Standard Process

  組織標準過程集合

  44 OT Organizational Training 組織級培訓

  45 PA Process Areas 過程域

  46 PAT Process Action Team 過程行動小組

  47 PB Process Assets Library 過程財富庫

  48 PD Preliminary Design 概要設計

  49 PDSP Project Defined Standard Processes 項目定義標準過程

  50 PI Produce Integration 產品集成

  51 PLC Product Life Cycle 產品生命周期

  52 PMC Project Monitoring and Control 項目監控

  53 PP Project Planning 項目策劃

  54 PPQA Process and Product Quality Assurance 過程與產品質量保證

  55 PPR Price Performance Ratio 性能價格比

  56 QA Software Quality Assurance 軟件質量保證

  57 QA Quality Assurance 質量保證

  58 QAP Software Quality Assurance Plan 質量保證計劃

  59 QPM Quantitative Project Management 量化項目管理

  60 RD Requirements Development 需求開發

  61 RM/ReqM Requirements Management 需求管理

  62 RSKM Risk Management 風險管理

  63 RTM Requirement Traceability Matrix 需求跟蹤矩陣

  64 SAM Supplier Agreement Management. 供應協議管理

  65 SC Steering Committee 指導委員會

  66 SCAMPI

  Standard CMMI Assessment Method for

  Process Improvement 過程改進CMMI標準評審方法

  67 SCCB Software Configuration Control Board 軟件配置管理控制委員會

  68 SCM Software Configuration Management 軟件配置管理

  69 SDP Software Development Plan 軟件開發計劃

  70 SEI Software Engineering Institute (美國)軟件工程學院

  71 SEPG Software Engineering Process Group 軟件工程過程

  72 SPI Software Process Improvement 軟件過程改進

  73 SPP Software Project Planning 軟件項目策劃

  74 SPTO Software Project Tracking and Oversight 軟件項目跟蹤與監控

  75 SR System Requirements 系統需求

  76 SRS Software Requirement Specification 軟件需求規格

  77 SSM Software Subcontract Management 軟件分包管理

  78 SSR Software System Requirement 軟件系統需求

  79 TS Technical Solution 技術解決方案

  80 UC Use Case 用例

  81 UID User Interface Design 用戶界面設計

  82 VAL Validation 確認

  83 VER Verification 驗證

  84 WBS Work Breakdown Structure 工作分解結構

  85 WP Work Products 工作產品

  86 Pre-assessment 預評審

  87 Baseline 基線

  88 Quality Attribute 質量屬性

  89 Scenario 場景

十四、實施                                                      

  現在很多企業因某種原因想做CMMI了,大體做法

  1、決定實施CMMI

  2EPG接受培訓,理解CMMI

  3EPG根據自己理解的CMMI和實際情況開發一大堆漂漂亮亮的過程文檔、流程圖、表格、模板、檢查單、作業指南。

  4、大家邊聽著EPG的解釋(包括培訓、答疑),邊執行這些過程標準,然后審計(內、外)

  將目前的最佳實踐記錄下來、寫下來、文檔化下來。

  很多新的EPG在做了一段時間后無奈的發現自己居然淪落成了一個過程標準解說員、甚至文檔管理員。自己工作大部分時間是面對文檔,或者督促別人寫文檔

  EPG最主要的工作應該深入到研發第一線,幫助研發人員解決研發過程中面臨的最嚴重的實際問題(當然是解決方案要上升到過程高度,而不應是單個問題或個人),甚至哪怕是一些不嚴重但以你的項目經驗知道該如何解決的問題上。總體說來就是掌握項目進展中的任何細微的技術難點要點,并主動記錄下來。

  為什么這么說呢?CMMI實施的主要宗旨就是以每個項目為采集數據的源頭,達到企業整體效益提升和資源重用。真正有價值的東西,是需要一線人員在實際工作中遇到問題,解決問題,并總結問題,不是一個一線工作的流水帳。就象一份研發人員的日報。寫了上午做什么,下午做什么。這對企業的積累有什么用處呢?他工作過程中,遇到什么問題,他是怎么解決的,走過什么彎路,實驗過幾種方法,失敗了,失敗的原因是什么,最后選擇了什么方法,可能不是最好的,但完成了任務,達到了效率和資源分配的平衡。這些東西才可能是未來類似項目中,遇到類似問題時,可能有參考價值的。通常也是EPG個人職業生涯的技術積累。只有公司里每個員工,把自己認為最有價值的積累貢獻出來。才可能達到公司有價值的積累。而決不是形式上寫的上午下午每個小時的流水帳。

十五、人員素質                                                   

  1、明白什么是有價值的積累,先是對你個人,然后才是順便幫公司做了積累。

  2、深入一線,發現她們并忠實地記錄她們。CMMI里的SPGP,只是幫助你,提醒你在哪個環節,哪些東西可能是有價值了。你去收集一下,別視而不見了。因為還有一個企業和你個人的角度不同,立場不同的問題。例如,REQM里收集需求,對個人技術方面的積累雖然不多,但對企業是至關重要的,一次需求變更,沒詳細寫清楚,忘記了到客戶那里去簽字落實,可能就會給企業造成很大的損失。做為一個合格的EPG,是需要有這份責任和義務把每個環節都做到最好,這是職業道德所在。同時也是對自我延伸的一個好機會,學會一些和人的溝通,傾聽,把專業的東西以平易的方式表達。這些也都算是EPG額外的收獲。

  通常情況下,為了按時按量完成項目,一線的骨干,對寫日報、周報、文檔都很不屑。EPG也很遷就,事后再補,這也不失為一個提高效率的好辦法。但過去一個月半年了,我們正常人的記憶都能想象,很難記住細節。無非就是敷衍。這也在情理之中。你總不能讓一個明天就要交東西的小組,今天晚上在通宵努力解決BUG的同時,還寫什么報告,這也不盡人情。但作為EPG不能只把眼光集中在這婦人之心上。要想的更遠。為什么會把項目推到這么晚,BUG還沒解決完?難道要永遠這樣下去嗎?項目中是有很多不可預測的因素,甚至是開發人員常說的"手氣問題""人品問題"。但這些是需要控制的,也是通過經驗可以控制的,所謂藝高人膽大。藝的高低,就是經驗的積累決定的。

  那怎么解決這種兩難的問題呢?逼著技術骨干寫心水,人家沒時間也的確壓力很大。不寫,公司又得不到有效積累,積累的都是垃圾流水。有個公司的辦法和經驗到可以借鑒一下:

  公司內部搞了個BBS,把不同類型的工作分成不同的組,有純技術的,JAVA組,C++組等,也有PPT組,甚至動畫組,界面組。大家把自己平時的工作積累FTP上去,甚至制作方法,遇到問題和解決方法的文檔都丟上去,開始怎么想,用了多少套方案,最后選擇了什么。自我感覺如何。把這些心路歷程都寫成文檔。丟到陽光下,大家評論。用點擊率和""的人數來說明誰寫的是心水,誰在寫垃圾。大家都是一個公司的,很容易實名。直接納入考核機制中。做為一線人員,大家也有動力來寫,自己的聰明才智有了展現的平臺,虛榮心和荷包都得到了相應的滿足。何樂而不為呢?

  EPG適時的評估大家的成果,并把他們分到項目里。幫助項目總結,甚至在平時遇到問題時,直接幫助技術人員做必要記錄。項目進度松時,再督促項目人員完善內容。以達到對個人和公司積累的最大化。

  EPG應該明白學習和積累是個終身的過程,對公司如此,對個人也是如此。CMMI是個輔助,輔助我們對公司做積累,也幫助我們個人做必要的積累。公司需要逐步走向更高的管理水平,發展平臺。

十六、實施流程                                        

  階段1CMMI項目啟動會

  明確企業實施CMMI的商業目標,建立CMMI項目實施的溝通機制。

  階段2CMMI基礎培訓和過程改進小組(EPG)組建

  進行CMMI基礎概念講解,指導企業建立核心的過程改進小組。

  階段3:診斷

  充分了解企業研發過程現狀,識別企業現有軟件過程與企業現階段理應達到的的CMMI成熟度級別的差距,提交診斷報告,進行過程改進的策劃。

  階段4:過程域培訓和文件定義

  結合企業過程現狀進行CMMI過程域培訓,通過舉例、案例分析等方式,讓企業的EPG掌握過程文件定義技巧,結合企業實際情況有針對性的定義組織的研發過程,并確定過程產出物(如:需求報告)

  階段5:項目試點

  選擇代表公司核心業務的項目或者典型項目進行試點,通過試點來完善過程文件,從而為企業全面推廣過程文件打下基礎。

  階段6:組織推廣

  全員參與全面導入與執行CMMI

  階段7:預評估

  驗證組織推廣的結果,識別企業尚存缺陷并制定再次改善方案,準備充分,以便企業能夠更好進行正式SCAMPI評估。

  階段8SCAMPI正式評估
SEI授權的主任評估師領導,采用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)評估方法,對企業的能力成熟度進行正式的評估,頒發證書,通過SEI網站向全球發布企業信息。

電話:023-62940569 手機:13883338193 聯系人:張先生 郵箱:[email protected]

2013-2015 標創企業咨詢版權所有. 渝ICP備13003571號
holidayinn斯图加特 天津快乐十分分布图 太原沐足转让 吉林快三豹子最大遗漏 如何靠桌游赚钱 pk10软件计划手机免费软件 2019成都沐足论坛 36棋牌新神兽下载官网 女仆联盟破解版下载 太仓股票配资 福建十一选五开奖号码 山西11选5走势图表分析 股票涨跌幅计算公式 上海时时票开奖结果 韩国美女组合性感热舞 0.1元一炮的捕鱼游戏 AG鬼马小丑