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