統一服務熱線:
023-63424072

重慶ISO認證
重慶裕恆,服務項目  
服務項目 Solutions
相關信息 / Solutions More
企業當家人的困惑 他(她)們是有夢想的人,有著敏銳的洞察力和超強的創新力,激情洋溢,思維敏捷,高瞻遠矚,運籌帷幄。 曾幾何時,他(她)們有了焦慮感,脾氣大了,愛發火了 如何实现业绩倍增? 如何快速突破瓶颈? 如何优化组织结构提升运营效率? 如何明确战略定位? 如何提升市场竞争力? 如何打造高绩效团队? 如何建立高绩效组织? ...
一、什麼是中國有機食品認證 指在動植物生產過程中不使用化學合成的農藥、化肥、生長調節劑、飼料添加劑等物質,以及基因工程技術及其產物,而是遵循自然規律和生態學原理,採取一系列可持續發展的農業技術,協調種植業和養殖業的平衡,維持農業生態系統持續穩定的一種農業生產方式。 有機食品這一名詞是從英文0rganicFood直譯過來的,相近的說法還有生態或生物食品。有機食品是指原料來自於有機生產...
Solutions 服務項目

CMMI認證諮詢

日期: 2019-11-29 00:00:00
  • 来源:
  • 日期: 2019-11-29 00:00:00
  • 作者:

  

  一、CMMI-简介

   CMMI的全稱爲:CapabilityMaturityModelIntegration,即能力成熟度模型集成。
   CMMI家族包括CMMIforDevelopment,CMMIforService和CMMIforAcquisition三個套裝產品。
   早期的CMMI(CMMI-SE/SW/IPPD)1.02版本是應用於軟體業項目的管理方法,SEI在部分國家和地區開始推廣和試用。隨著應用的推廣與模型本身的發展,演繹成爲一種被廣泛應用的綜合性模型。
   自從1994年SEI正式發布軟體CMM以來,相繼又開發出了系統工程、軟體採購、人力資源管理以及集成產品和過程開發方面的多個能力成熟度模型。雖然這些模型在許多組織都得到了良好的應用,但對於一些大型軟體企業來說,可能會出現需要同時採用多種模型來改進自己多方面過程能力的情況。這時他們就會發現存在一些問題,其中主要問題體現在:
   n不能集中其不同過程改進的能力以取得更大成績;
   n要進行一些重複的培訓、評估和改進活動,因而增加了許多成本;
   n遇到不同模型中有一些對相同事物說法不一致,或活動不協調,甚至相牴觸。
   於是,希望整合不同CMM模型的需求產生了。1997年,美國聯邦航空管理局(FAA)開發了FAA-iCMMSM(聯邦航空管理局的集成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(Capabilitymaturitymodelintegration)是爲了合併三個模型到一個框架中
   CapabilityMaturityModelforSoftware(SW-CMM)v2.0draftC,
   ElectronicIndustriesAllianceInterimStandard(EIA/IS)731
   IntegratedProductDevelopmentCapabilityMaturityModel(IPD-CMM)v0.98
   正如其他CMM模型,CMMI提供了流程改進的指導,而不是流程或流程的描述。組織使用的實際流程取決於很多因素,包括應用領域·組織框架和規模。CMMI將許多經過驗證的方法加入架構中,來幫組組織評價成熟度·某個軟體流程的能力度,並且建立改進的優先順序和實施改進。
   從CMMI框架可以產生不同的CMMI模型,因此必須首先確定那種模型適合企業流程改進的需要。
    阶段式描述or连续式描述
    系统工程or软件工程or两者皆有
   使用連續式描述可以根據企業需要選擇流程改進順序,降低企業風險,這給通過ISO做流程改進提供了一個方便的比較。使用能力度(Capability)來衡量。
   階段式描述提供了已經過驗證的流程改進順序,方便從CMM移植過來。使用成熟度(Maturity)來衡量流程改進。
   系統工程包括整個系統的開發,可能包括軟體也可能不包括。
   軟體工程用於軟體系統的開發,主要集中在使用系統的·科學的·量化的方法來開發·運行·維護軟體。
    CMM是项目管理
   由美國卡內基梅隆大學的軟體工程研究所(SEI)創立的CMM(CapabilityMaturityModel軟體能力成熟度模型)認證評估,在過去的十幾年中,對全球的軟體產業產生了非常深遠的影響。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(SoftwareCMM)軟體CMM
   (2)SE-CMM(SystemEngineeringCMM)系統工程CMM
   (3)SA-CMM(SoftwareAcquisitionCMM)軟體採購CMM
   (4)IPT-CMM(IntegratedProductTeamCMM)集成產品羣組CMM
   (5)P-CMM(PeopleCMM)人力資源能力成熟度模型
   爲了以示區別,國內外很多資料把CMM叫做SW-CMM。按照SEI原來的計劃,CMM的改進版本2.0應該在1997年11月完成,然後在取得版本2.0得實踐反饋意見之後,在1999年完成准CMM2.0版本。
   但是,美國辦公室要求SEI推遲發布CMM2.0版本,而要先完成一個更爲緊迫的項目CMMI,原因是在同一個組織中多個過程改進模型的存在可能會引起衝突和混淆,CMMI就是爲了解決怎麼保持這些模式之間的協調。
   CMMI(CapabilityMaturityModelIntegration)即能力成熟度集成模型,這是美國部的一個設想,他們想把現在所有的以及將被發展出來的各種能力成熟度模型,集成到一個框架中去。這個框架有兩個功能,一,軟體採購方法的改革;第二,建立一種從集成產品與過程發展的角度出發、包含健全的系統開發原則的過程改進。就軟體而言,CMMI是SW-CMM的修訂本。
   它兼收了SW-CMM2.0版C稿草案和SPA中更合理、更科學和更周密的優點。SEI在發表CMMI-SE/SW1.0版時,宣布大約用兩年的時間完成從CMM到CMMI的過渡。
   CMMI項目更爲工業界和政府部門提供了一個集成的產品集,其主要目的是消除不同模型之間的不一致和重複,降低基於模型改善的成本。CMMI將以更加系統和一致的框架來指導組織改善軟體過程,提高產品和服務的開發、獲取和維護能力。
   由業界、美國政府和卡內基?梅隆大學軟體工程研究所率先倡導的能力成熟度模型集成(CMMI)項目致力於幫助企業緩解這種困境。CMMI爲改進一個組織的各種過程提供了一個單一的集成化框架,新的集成模型框架消除了各個模型的不一致性,減少了模型間的重複,增加透明度和理解,建立了一個自動的、可擴展的框架。因而能夠重總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。
   與原有的能力成熟度模型類似,CMMI也包括了在不同領域建立有效過程的必要元素,反映了業界普遍認可的"較佳"實踐;專業領域覆蓋軟體工程、系統工程、集成產品開發和系統採購。在此前提下,CMMI爲企業的過程構建和改進提供了指導和框架作用;同時爲企業評審自己的過程提供了可參照的行業基準。
    七、源模型
   軟體能力成熟度模型2.0版,C稿;電子行業協會臨時標準(EIA/IS)731;集成產品開發能力成熟度模型(IPD-CMM)v0.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過程能夠產生相同的結論。統一的CMMI(U-CMMI)是指產生一個只有公用方法和支持他們的KPA組成的模型。當按一種概念性的可伸展的方式編寫,並產生了用於定義組織的特定目標過程模版,定義的模版構件將定義一個模型以適用於任何工程或其他方面。
    十二、与CMM差别
   CMMI模型的前身是SW-CMM和SE-CMM,前者就是我們指的CMM。CMMI與SW-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級里單獨提出了一個獨立的關鍵過程域叫做風險管理。
    十三、标准名词术语
   1ATAssessmentTeam評審小組
   2ATMAssessmentTeamMember評審小組成員
   3BABaselineAssessment基線評審
   4CARCausalAnalysisandResolution原因分析與決策
   5CBACMM-BasedAppraisal基於CMM的評價
    6CBA-IPI
   CMM-BasedAppraisalforInternalProcess
    Improvement
   爲內部過程改進而進行的基於CMM的評價(通常
    称为CMM评审)
   7CCConfigurationController配置管理員
   8CFCommonFeature公共特性
   9CFPSCertifiedFunctionPointSpecialist註冊功能點專家
   10CIConfigurationItem配置項
   11CMConfigurationManagement配置管理
   12CMMCapabilityMaturityModel能力成熟度模型
   13CMMICapabilityMaturityModelIntegration能力成熟度集成模型
   14COTSCommerceofftheshelf商業現貨供應
   15DARDecisionAnalysisandResolution決策分析與制定
   16DBDDatabaseDesign資料庫設計
   17DDDetailedDesign詳細設計
   18DPDataProvider數據提供者
   19DRDerivedRequirement派生需求
   20EPGEngineeringProcessGroup工程過程小組
   21FPFunctionPoint功能點
   22FPAFunctionPointAnalysis功能點分析
   23FRFunctionalRequirement功能性需求
    24GAGapAnalysis差距分析
   25IDInterfaceDesign接口設計
   26IFPUGInternationalFunctionPointUsersGroup國際功能點用戶組織
   27IPMIntegratedProjectManagement集成項目管理
   28IRInterfaceRequirement接口需求
   29KPAKeyProcessArea關鍵過程域
   30KRKeyRequirements關鍵需求
   31LALeadAssessor主任評審員
   32MAMeasurementandAnalysis測量與分析
   33MATMetricsAdvisoryTeam度量諮詢組
   34MCAMetricsCoordinatorandAnalyst度量專員
   35MLmatriarchylibrary度量資料庫
   36NFRNon-functionalRequirement非功能性需求
   37OCOperationalConcept操作概念
   38OIDOrganizationalInnovationandDeployment組織革新與部署
   39OPDOrganizationalProcessdefinition組織過程定義
   40OPFOrganizationalProcessfocus組織過程焦點
   41OPLOrganizationalProcessAssets組織過程財富
   42OPPOrganizationalProcessPerformance組織過程性能
   43OSSPOrganization’sSetofStandardProcess
    组织标准过程集合
   44OTOrganizationalTraining組織級培訓
    45PAProcessAreas过程域
   46PATProcessActionTeam過程行動小組
   47PBProcessAssetsLibrary過程財富庫
   48PDPreliminaryDesign概要設計
   49PDSPProjectDefinedStandardProcesses項目定義標準過程
   50PIProduceIntegration產品集成
   51PLCProductLifeCycle產品生命周期
   52PMCProjectMonitoringandControl項目監控
   53PPProjectPlanning項目策劃
   54PPQAProcessandProductQualityAssurance過程與產品質量保證
   55PPRPricePerformanceRatio性能價格比
   56QASoftwareQualityAssurance軟體質量保證
   57QAQualityAssurance質量保證
   58QAPSoftwareQualityAssurancePlan質量保證計劃
   59QPMQuantitativeProjectManagement量化項目管理
   60RDRequirementsDevelopment需求開發
   61RM/ReqMRequirementsManagement需求管理
   62RSKMRiskManagement風險管理
   63RTMRequirementTraceabilityMatrix需求跟蹤矩陣
   64SAMSupplierAgreementManagement.供應協議管理
   65SCSteeringCommittee指導委員會
    66SCAMPI
   StandardCMMIAssessmentMethodfor
   ProcessImprovement過程改進CMMI標準評審方法
   67SCCBSoftwareConfigurationControlBoard軟體配置管理控制委員會
   68SCMSoftwareConfigurationManagement軟體配置管理
   69SDPSoftwareDevelopmentPlan軟體開發計劃
   70SEISoftwareEngineeringInstitute(美國)軟體工程學院
   71SEPGSoftwareEngineeringProcessGroup軟體工程過程組
   72SPISoftwareProcessImprovement軟體過程改進
   73SPPSoftwareProjectPlanning軟體項目策劃
   74SPTOSoftwareProjectTrackingandOversight軟體項目跟蹤與監控
   75SRSystemRequirements系統需求
   76SRSSoftwareRequirementSpecification軟體需求規格
   77SSMSoftwareSubcontractManagement軟體分包管理
   78SSRSoftwareSystemRequirement軟體系統需求
   79TSTechnicalSolution技術解決方案
    80UCUseCase用例
   81UIDUserInterfaceDesign用戶界面設計
    82VALValidation确认
    83VERVerification验证
   84WBSWorkBreakdownStructure工作分解結構
   85WPWorkProducts工作產品
    86Pre-assessment预评审
    87Baseline基线
   88QualityAttribute質量屬性
    89Scenario场景
    十四、实施
   現在很多企業因某種原因想做CMMI了,大體做法
    1、决定实施CMMI
    2、EPG接受培训,理解CMMI
   3、EPG根據自己理解的CMMI和實際情況開發一大堆漂漂亮亮的過程文檔、流程圖、表格、模板、檢查單、作業指南。
   4、大家邊聽著EPG的解釋(包括培訓、答疑),邊執行這些過程標準,然後審計(內、外)
   將目前的實踐記錄下來、寫下來、文檔化下來。
   很多新的EPG在做了一段時間後無奈的發現自己居然淪落成了一個過程標準解說員、甚至文檔管理員。自己工作大部分時間是面對文檔,或者督促別人寫文檔
   EPG主要的工作應該深入到研發一線,幫助研發人員解決研發過程中面臨的嚴重的實際問題(當然是解決方案要上升到過程高度,而不應是單個問題或個人),甚至哪怕是一些不嚴重但以你的項目經驗知道該如何解決的問題上。總體說來就是掌握項目進展中的任何細微的技術難點要點,並主動記錄下來。
   爲什麼這麼說呢?CMMI實施的主要宗旨就是以每個項目爲採集數據的源頭,達到企業整體效益提升和資源重用。真正有價值的東西,是需要一線人員在實際工作中遇到問題,解決問題,並總結問題,不是一個一線工作的流水帳。就象一份研發人員的日報。寫了上午做什麼,下午做什麼。這對企業的積累有什麼用處呢?他工作過程中,遇到什麼問題,他是怎麼解決的,走過什麼彎路,實驗過幾種方法,失敗了,失敗的原因是什麼,然後選擇了什麼方法,可能不是較好的,但完成了任務,達到了效率和資源分配的平衡。這些東西才可能是未來類似項目中,遇到類似問題時,可能有參考價值的。通常也是EPG個人職業生涯的技術積累。只有公司里每個員工,把自己認爲有價值的積累貢獻出來。才可能達到公司有價值的積累。而決不是形式上寫的上午下午每個小時的流水帳。
    十五、人员素质
   1、明白什麼是有價值的積累,先是對你個人,然後才是順便幫公司做了積累。
   2、深入一線,發現她們並忠實地記錄她們。CMMI里的SP、GP,只是幫助你,提醒你在哪個環節,哪些東西可能是有價值了。你去收集一下,別視而不見了。因爲還有一個企業和你個人的角度不同,立場不同的問題。例如,REQM里收集需求,對個人技術方面的積累雖然不多,但對企業是至關重要的,一次需求變更,沒詳細寫清楚,忘記了到客戶那裡去簽字落實,可能就會給企業造成很大的損失。做爲一個合格的EPG,是需要有這份責任和義務把每個環節都做到較好,這是職業道德所在。同時也是對自我延伸的一個好機會,學會一些和人的溝通,傾聽,把專業的東西以平易的方式表達。這些也都算是EPG額外的收穫。
   通常情況下,爲了按時按量完成項目,一線的骨幹,對寫日報、周報、文檔都很不屑。EPG也很遷就,事後再補,這也不失爲一個提高效率的好辦法。但過去一個月半年了,我們正常人的記憶都能想像,很難記住細節。無非就是敷衍。這也在情理之中。你總不能讓一個明天就要交東西的小組,今天晚上在通宵努力解決BUG的同時,還寫什麼報告,這也不盡人情。但作爲EPG不能只把眼光集中在這婦人之心上。要想的更遠。爲什麼會把項目推到這麼晚,BUG還沒解決完?難道要永遠這樣下去嗎?項目中是有很多不可預測的因素,甚至是開發人員常說的"手氣問題","人品問題"。但這些是需要控制的,也是通過經驗可以控制的,所謂藝高人膽大。藝的高低,就是經驗的積累決定的。
   那怎麼解決這種兩難的問題呢?逼著技術骨幹寫心水,人家沒時間也的確壓力很大。不寫,公司又得不到有效積累,積累的都是垃圾流水。有個公司的辦法和經驗到可以借鑑一下:
   公司內部搞了個BBS,把不同類型的工作分成不同的組,有純技術的,JAVA組,C++組等,也有PPT組,甚至動畫組,界面組。大家把自己平時的工作積累FTP上去,甚至製作方法,遇到問題和解決方法的文檔都丟上去,開始怎麼想,用了多少套方案,然後選擇了什麼。自我感覺如何。把這些心路歷程都寫成文檔。丟到陽光下,大家評論。用點擊率和"頂"的人數來說明誰寫的是心水,誰在寫垃圾。大家都是一個公司的,很容易實名。直接納入考核機制中。做爲一線人員,大家也有動力來寫,自己的聰明才智有了展現的平台,虛榮心和荷包都得到了相應的滿足。何樂而不爲呢?
   EPG適時的評估大家的成果,並把他們分到項目里。幫助項目總結,甚至在平時遇到問題時,直接幫助技術人員做必要記錄。項目進度松時,再督促項目人員完善內容。以達到對個人和公司積累的較大化。
   EPG應該明白學習和積累是個終身的過程,對公司如此,對個人也是如此。CMMI是個輔助,輔助我們對公司做積累,也幫助我們個人做必要的積累。公司需要逐步走向更高的管理水平,發展平台。
    十六、实施流程
    阶段1:CMMI项目启动会
   明確企業實施CMMI的商業目標,建立CMMI項目實施的溝通機制。
   階段2:CMMI基礎培訓和過程改進小組(EPG)組建
   進行CMMI基礎概念講解,指導企業建立核心的過程改進小組。
    阶段3:诊断
   充分了解企業研發過程現狀,識別企業現有軟體過程與企業現階段理應達到的的CMMI成熟度級別的差距,提交診斷報告,進行過程改進的策劃。
    阶段4:过程域培训和文件定义
   結合企業過程現狀進行CMMI過程域培訓,通過舉例、案例分析等方式,讓企業的EPG掌握過程文件定義技巧,結合企業實際情況有針對性的定義組織的研發過程,並確定過程產出物(如:需求報告)
    阶段5:项目试点
   選擇代表公司核心業務的項目或者典型項目進行試點,通過試點來完善過程文件,從而爲企業全面推廣過程文件打下基礎。
    阶段6:组织推广
    全员参与全面导入与执行CMMI。
    阶段7:预评估
   驗證組織推廣的結果,識別企業尚存缺陷並制定再次改善方案,準備充分,以便企業能夠更好進行正式SCAMPI評估。
    阶段8:SCAMPI正式评估

   由SEI授權的主任評估師領導,採用SCAMPI(StandardCMMIAppraisalMethodforProcessImprovement)評估方法,對企業的能力成熟度進行正式的評估,頒發證書,通過SEI網站向全球發布企業信息。


Copyright ©2013 - 2017 重庆裕恒企业管理咨询有限公司 
重慶網站建設


分享到:
服務熱線
統一服務熱線:
全國統一服務熱線:
023-63424072

客服QQ:
微信二維碼
親,掃一掃
瀏覽微信雲網站
X
3

SKYPE 設置

4

阿里旺旺設置

2

MSN設置

5

電話號碼管理

  • 13330214281
6

二維碼管理

8

郵箱管理

展開
進入手機網站