CMM與CMMI的比較 | ||||||||
| 本文總結(jié)了從傳統(tǒng)軟件管理技術(shù)過渡到現(xiàn)代軟件管理技術(shù)的一些思想。我特別要認可軟件工程學院SEI在其新方法CMMI（能力成熟度模型集成）中的改進，并促進開發(fā)公司正確地應(yīng)用這個方法。雖然我一直支持原來的能力成熟度模型（CMM）的精神，但實際它經(jīng)常被錯誤地理解和應(yīng)用。從我25年來和許多進行過程改進的世界領(lǐng)先的軟件開發(fā)組織的合作經(jīng)驗看，我相信大多數(shù)應(yīng)用CMM的組織還局限于默認的瀑布模式思想上。我不認為錯在模式本身，因為我知道CMM語境里的一些過程改進是基于一種現(xiàn)代的、疊代的開發(fā)方法。不過，我這種啟示性的理解并非規(guī)范。 本文總結(jié)了從傳統(tǒng)軟件管理技術(shù)過渡到現(xiàn)代軟件管理技術(shù)的一些思想。我特別要認可軟件工程學院SEI在其新方法CMMI（能力成熟度模型集成）中的改進，并促進開發(fā)公司正確地應(yīng)用這個方法。雖然我一直支持原來的能力成熟度模型（CMM）的精神，但實際它經(jīng)常被錯誤地理解和應(yīng)用。從我25年來和許多進行過程改進的世界領(lǐng)先的軟件開發(fā)組織的合作經(jīng)驗看，我相信大多數(shù)應(yīng)用CMM的組織還局限于默認的瀑布模式思想上。我不認為錯在模式本身，因為我知道CMM語境里的一些過程改進是基于一種現(xiàn)代的、疊代的開發(fā)方法。不過，我這種啟示性的理解并非規(guī)范。 CMM綜述 基于組織對關(guān)鍵過程域的支持，CMM定義了軟件過程成熟度的五個級別。級別1（初始級）描述了不成熟，或者說是未定義的過程的組織。級別2（可重復(fù)級），級別3（已定義級），級別4（已管理級）和級別5（優(yōu)化級）分別描述了軟件過程成熟度級別遞增的組織。和這些級別相關(guān)的KPA是： 級別2：需求管理，軟件項目計劃，軟件項目跟蹤和監(jiān)控，軟件子合同管理，軟件質(zhì)量保證，軟件配置管理。 級別3：組織級過程焦點，組織級過程定義，培訓大綱，集成軟件管理，軟件產(chǎn)品工程，組間協(xié)調(diào)，同行評審。 級別4：定量過程管理，軟件質(zhì)量管理 CMMI被看做是把各種CMM集成為一個系列的模型中。CMMI的基礎(chǔ)源模型包括：軟件CMM 2.0版（草稿C）, EIA-731系統(tǒng)工程，以及IPD CMM (IPD) 0.98a版。CMMI也描述了5個不同的成熟度級別。 強調(diào)級別2的關(guān)鍵過程域的前后一致的、項目級的紀律，以建立組織級的活動和實踐。附加的組織級過程域包括： 4. 級別4（定量管理級）代表了以改進組織性能為特征的過程成熟度。3級項目的歷史結(jié)果可用來交替使用，在業(yè)務(wù)表現(xiàn)的競爭尺度（成本、質(zhì)量、時間）方面的結(jié)果是可預(yù)測的。級別4附加的過程域包括： 組織級過程執(zhí)行：為過程執(zhí)行設(shè)定規(guī)范和基準。 5. 級別5（優(yōu)化級）代表了以可快速進行重新配置的組織性能，和定量的、持續(xù)的過程改進為特征的過程成熟度。附加的級別5過程域包括： 因果分析和解決方案：主動避免錯誤和強化最佳實踐。 組織級改革和實施：建立一個能夠有機地適應(yīng)和改進的學習組織。 CMM過時了嗎？ 一些CMM實踐的問題也是傳統(tǒng)瀑布方法和過度基于過程的管理的癥狀。CMM的基于活動的度量方法和瀑布過程的有次序的、基于活動的管理規(guī)范有非常密切的聯(lián)系（即：先是需求活動，然后是設(shè)計活動，編碼活動，單位測試活動，集成活動，以及系統(tǒng)接收測試）。這大概可以解釋為什么許多組織對CMM的認識停留在瀑布思想上。 另外，疊代開發(fā)技術(shù)、軟件產(chǎn)業(yè)最佳實踐、和經(jīng)濟動機推動組織采用基于結(jié)果的方法：開發(fā)業(yè)務(wù)案例、構(gòu)想和原型方案；細化后納入基線結(jié)構(gòu)、可用發(fā)布，最后定為現(xiàn)場版本的發(fā)布。雖然 CMMI保留了基于活動的方法，它的確集成了軟件產(chǎn)業(yè)內(nèi)很多現(xiàn)代的最好的實踐，因此它很大程度上淡化了和瀑布思想的聯(lián)系。 分析CMM 和 CMMI分別和瀑布模型以及疊代開發(fā)之間有什么聯(lián)系，方法之一就是看每個模型的KPA是否為這兩種不同的開發(fā)方法激發(fā)了合理的軟件管理原理。首先，讓我們來定義那些軟件管理原理。過去10年間，我編譯了兩套原理：一套用于傳統(tǒng)的瀑布方法，另一套用于現(xiàn)代的疊代方法。得承認的是，這"十大原理"沒有科學基礎(chǔ)，并且只提供了符合它們各自的管理方法的成功模版的粗略的描述。但是它們的確為我的觀點提供了一個合適的框架：CMM和瀑布思想相聯(lián)系，而CMMI和疊代思想聯(lián)系得更緊密。 1. 設(shè)計之前凍結(jié)需求。這是需求第一過程的本質(zhì)：項目組努力提供一個準確的需求定義，然后嚴格按照需求實施。需求變更會嚴重破壞編碼和測試階段，因此，項目組在其他設(shè)計和開發(fā)活動中投入主要力量之前，必需完整地、明確地指定需求。 2. 詳細設(shè)計評審前避免編碼。編碼變更會嚴重破壞編碼和測試階段，在開始編碼前，如果還有很多變更阻力，項目組必需保證整個設(shè)計是成熟和完整的。 3. 是使用更高指令編程語言。更高指令編程語言避免了一系列主要的錯誤根源（通過先進的數(shù)據(jù)錄入、接口分離以及打包和編程結(jié)構(gòu)），并允許軟件方案可以使用更少的人工合成碼進行編程。 4. 集成前要結(jié)束單元測試。雖然設(shè)計是自上向下的，測試過程是自下向上的：在交付進行集成測試之前，最小的單元先進行全面測試。這樣的次序限制是為了在集成前多發(fā)現(xiàn)一些單元級別上的缺陷，否則它們將造成更多的問題和返工。 5. 維護所有產(chǎn)品可跟蹤性。為了保證在每個階段維護項目的完整性和一致性，要跟蹤需求產(chǎn)品以及設(shè)計和測試產(chǎn)品。當提出變更或開發(fā)一線人員識別變更時，這提供了變更對評審的實際影響和潛在影響的完整視圖。 6. 文檔化并維護設(shè)計。沒有文檔化的設(shè)計就不是設(shè)計了。在以后的階段，由于代碼成為主要的工程產(chǎn)品，必須更新設(shè)計產(chǎn)品以保證一致性，并為變更決策提供基礎(chǔ)。 7. 由一個獨立小組評估質(zhì)量。項目組應(yīng)指定一個獨立小組負責保證產(chǎn)品和過程的全面質(zhì)量一致性，以維護一個有別于分析人員、設(shè)計人員和檢測人員的獨立的報告渠道。 8. 全面檢查。通過檢查詳細設(shè)計和代碼來發(fā)現(xiàn)錯誤，比通過測試發(fā)現(xiàn)錯誤要好得多。要確保檢查覆蓋所有需求、設(shè)計、代碼和測試產(chǎn)品。 9. 在項目早期進行全面的精確的計劃。對于識別關(guān)鍵路徑、管理風險以及評估程序變更來說，一個完整的、精確的、細化的計劃是必要的，它應(yīng)該安排整個進度的詳細活動和產(chǎn)品。 10. 嚴格控制源代碼基線。一旦產(chǎn)品進入編碼階段，就必須用嚴格的配置管理維護測試過程的正式發(fā)布的基線控制，并把產(chǎn)品轉(zhuǎn)換成適合發(fā)布的零缺陷狀態(tài)。 現(xiàn)代（疊代）軟件管理的十大原理 1. 首先注重結(jié)構(gòu)過程。這要求在組織承諾全面開發(fā)的充足資源之前，平衡操作需求、對結(jié)構(gòu)而言很重要的設(shè)計決策、以及生命周期計劃。 2. 用疊代生命周期在早期防御風險。需要一個疊代過程來更好地理解問題，形成有效的方案和有效的計劃，以保證平衡對待所有利益相關(guān)者目標。應(yīng)在早期提出主要的風險以提高可預(yù)測性，避免為隨后的問題和返工付出大的代價。 3. 強調(diào)基于構(gòu)件的開發(fā)。為了減少人工合成源代碼和習慣開發(fā)的數(shù)量，項目組必須在現(xiàn)存的結(jié)構(gòu)框架內(nèi)從代碼行思想轉(zhuǎn)移到基于構(gòu)件的思想。構(gòu)件是已經(jīng)存在的代碼行的附著部分，有已定義的接口和行為，存在于源代碼中或可執(zhí)行格式中。 4. 建立變更管理環(huán)境。疊代開發(fā)的動力學包括并發(fā)的工作流，因為不同的工作組都為共享產(chǎn)品工作。這需要客觀控制的基線供所有項目成員參閱。 5. 用循環(huán)工程工具使變更更自由。循環(huán)工程提供了各種不同格式（如：需求說明書、設(shè)計模型、源代碼和可執(zhí)行代碼）的自動工程和同步工程信息所必需的環(huán)境支持。如果不使用實質(zhì)的自動操作，把疊代周期簡化為可管理的，允許并鼓勵變更的時間框架是很困難的。疊代過程中產(chǎn)品變更自由是必需的，因為它清除了工程組摩擦的一個主要來源。 6. 使用嚴格的、基于模型的設(shè)計符號?；谀Ｐ偷姆椒ǎɡ纾篣ML）支持語意豐富的圖形和文本的設(shè)計符號。相對于傳統(tǒng)的人工評審和紙張文檔的特定設(shè)計表現(xiàn)的檢查，帶嚴格符號和正式的、機器處理語言的可視模型允許更客觀的評估。 7. 提供過程的客觀質(zhì)量控制的手段。過程和所有中間產(chǎn)品的生命周期評估必須緊密集成到產(chǎn)品中去，把從展開的工程產(chǎn)品中直接獲得的、定義好的度量集成到所有活動和小組中去。 8. 使用中間產(chǎn)品的基于演示的評估。把目前的產(chǎn)品狀態(tài)的產(chǎn)品（不論是早期原型，基線結(jié)構(gòu)，還是β能力）轉(zhuǎn)換成相關(guān)的使用案例的可執(zhí)行演示，以促進集成轉(zhuǎn)換更早發(fā)生，對設(shè)計權(quán)衡的更切實的理解，以及更早消除產(chǎn)品缺陷。 9. 發(fā)布細化的、展開的計劃。在系統(tǒng)的操作語境中，軟件管理過程的早期的持續(xù)的演示是至關(guān)重要的，也就是它的使用案例。每個項目的增加和演示都應(yīng)該反應(yīng)目前需求和結(jié)構(gòu)的詳細水平。使用案例是組織需求、定義疊代內(nèi)容、評估實施和組織接收測試的重要機制。 10. 建立一個可升級的、可配置的過程。沒有哪個過程是適合所有軟件開發(fā)項目的?，F(xiàn)實的說，一個過程框架必須是可配置的，適合大范圍的應(yīng)用軟件。為保證經(jīng)濟級別和投資回報，組織必須灌輸一個通用過程"精神"，這樣所有項目都能集成一系列通用的最好實踐，尤其是項目管理、獨立于語境的工作流、檢查點、度量和產(chǎn)品的最好實踐。還應(yīng)允許各個項目進行剪裁和指定，以便針對項目特定的語境優(yōu)化過程實施。 CMM和兩套管理原則的關(guān)系 表1識別出每套原則中各有哪些是直接由 CMM的KPA激發(fā)的。這些都是我的判斷，結(jié)合了Rational公司許多同事的觀點，但并沒有科學依據(jù)。另外，請記住這些原則不僅基于CMM，還基于對默認實踐的觀察和組織級的慣性。 表1：CMM如何激發(fā)軟件管理原則
如表1所示，CMM的關(guān)鍵過程域直接激發(fā)了大多數(shù)傳統(tǒng)原理，但對現(xiàn)代原理幾乎沒什么影響。在我看來，有些現(xiàn)代原理實際上是和CMM關(guān)鍵過程域相沖突的。我想這張表格會在過程改進的狂熱支持者中引發(fā)激烈的爭論，但我相信最終軟件開發(fā)項目一線的多數(shù)工程師和項目經(jīng)理都會贊同我的結(jié)論的。 CMMI和現(xiàn)代管理原則的聯(lián)系 表2：CMMI如何激發(fā)疊代軟件管理原則
請注意我的分析依然是基于產(chǎn)業(yè)的默認實踐的觀察，而非CMMI的目的。我們這種和傳統(tǒng)方法和組織文化的聯(lián)系會成為達到CMMI真正目的的障礙，因此我對我的觀點持保守態(tài)度。顯然，我的觀點就是：CMMI代表了主要的改進。 | ||||||||
