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