試論CMM/CMMI不適合在當(dāng)前軟件開發(fā)當(dāng)中應(yīng)用的原因

作為最著名的軟件過程管理參考模型之一，能力成熟度模型CMM以及后續(xù)的集成模型CMMI，該模型在實踐當(dāng)中經(jīng)常被誤用。Brooks在《沒有銀彈》一章中提到的——“軟件開發(fā)的四個內(nèi)在特性是: 復(fù)雜性 不一致性 不可見性 可變性”，由于軟件開發(fā)的這些內(nèi)在特性，使得描述軟件開發(fā)過程的軟件開發(fā)與組織方法也天然帶著一定的抽象性，由此帶來了很多概念上的誤導(dǎo)和實踐中的爭論。

因此在我們探討CMM/CMMI不適合應(yīng)用在當(dāng)前軟件開發(fā)中之前，需要先探討什么是軟件過程，什么是軟件過程管理，然后討論CMM/CMMI的概念，最后再探討為什么CMM/CMMI不適用于軟件開發(fā)。

軟件過程的由來

軟件自誕生開始，其規(guī)模以及在一個完整計算機系統(tǒng)中所占的比重一直呈上升趨勢，類似硬件產(chǎn)品的“摩爾定律”，軟件產(chǎn)業(yè)也有一個類似的“摩爾定律”，即: 類似功能的軟件產(chǎn)品的規(guī)模每隔18個月，其規(guī)模(比如代碼行)會翻倍，而用戶獲取該軟件或者服務(wù)的代價將下降?！澳柖伞睂τ谲浖到y(tǒng)的開發(fā)和維護帶來很多負(fù)面影響，為了解決這些問題，對軟件開發(fā)進行有效地組織和管理非常重要，由此誕生并且演化了一系列的所謂軟件過程與方法。

伴隨著不斷演化的軟件過程與方法，軟件開發(fā)的組織與管理當(dāng)中出現(xiàn)了大量方法上的爭議和由此帶來的各種誤解以及混亂，其根源在于對軟件項目管理和軟件過程管理概念區(qū)分不清晰。所以接下來我們需要先對這兩個概念進行解析。

軟件項目管理

軟件項目管理被稱為規(guī)劃和帶領(lǐng)項目團隊的藝術(shù)和科學(xué)。其管理的對象是各類軟件項目，具體而言是應(yīng)用方法、工具、技術(shù)以及人員能力來完成軟件項目，實現(xiàn)項目目標(biāo)的過程?？梢栽偌?xì)分為兩種管理視角——軟件過程與生命周期模型

  • 軟件過程是為了實現(xiàn)一個或者多個事先定義的目標(biāo)而建立起來的一組實踐的集合。這組實踐之間往往有一定的先后順序，作為一個整體來實現(xiàn)事先目標(biāo)。
  • 生命周期模型是對一個軟件開發(fā)過程的人為劃分，是軟件開發(fā)過程的主框架，是對軟件開發(fā)過程的一種粗粒度劃分，往往不包括技術(shù)實踐。

軟件過程管理

軟件過程管理的管理對象是軟件過程，這種管理的直接目的是為了讓軟件過程在開發(fā)效率、質(zhì)量等方面有著更好性能績效。如果將軟件項目管理視為傳統(tǒng)行業(yè)的產(chǎn)品生產(chǎn)管理的話，軟件過程管理則應(yīng)該是對生產(chǎn)該產(chǎn)品的流水線的設(shè)計、建設(shè)、維護、優(yōu)化以及升級改造。軟件過程管理一般包括了軟件過程的建立、執(zhí)行、監(jiān)控、評估以及改進等活動。

CMM/CMMI是什么

  • CMMI概念
    CMMI(Capability Maturity Model Integration)即能力成熟度模型集成，是一套包括多個學(xué)科、可擴充的模型系列，其前身包括4個成熟度模型(即CMMI的源模型)，他們分別為面向開發(fā)的SW-CMM、面向系統(tǒng)工程的SE-CMM、面向產(chǎn)品集成的IPPD-CMM、以及設(shè)計外購協(xié)作的SS-CMM。所謂CMMI模型，是指CMMI刻畫了軟件團隊/組織從不成熟到成熟的每個階段的特征——即所謂的路線圖roadmap。與實際的開發(fā)模型沒關(guān)系。這個路線圖其實也是CMMI模型最為精華的部分，甚至都可以在很多其他的領(lǐng)域借鑒。

  • CMMI好處

  1. 改進進度和預(yù)算的可預(yù)測性
  2. 改進開發(fā)周期
  3. 提高生產(chǎn)率
  4. 改進質(zhì)量(質(zhì)量缺陷)
  5. 增加客戶的滿意度
  6. 提高員工的士氣
  7. 增加投資回報和低質(zhì)量成本

有兩種通用的評估方法用以評估組織軟件過程的成熟度: 軟件過程評估和軟件能力評價。

  • 軟件過程評估: 用于確定一個組織當(dāng)前的軟件工程過程狀態(tài)及組織所面臨的軟件過程的優(yōu)先改善問題，為組織領(lǐng)導(dǎo)層提供報告以獲得組織對軟件過程改善的支持。軟件過程評估集中關(guān)注組織自身的軟件過程，在一種合作的、開放的環(huán)境中進行。評估的成功取決于管理者和專業(yè)人員對組織軟件過程改善的支持。
  • 軟件能力評價: 用于識別合格的軟件承包商或者監(jiān)控軟件承包商開發(fā)軟件的過程狀態(tài)。軟件能力評價集中關(guān)注識別在預(yù)算和進度要求范圍內(nèi)完成制造出高質(zhì)量的軟件產(chǎn)品的軟件合同及相關(guān)風(fēng)險。評價在一種審核的環(huán)境中進行，重點在于揭示組織實際執(zhí)行軟件過程的文檔化的審核記錄。

CMM/CMMI不適用于軟件開發(fā)的原因

  • CMM/CMMI并不是一種具體的軟件過程或者軟件開發(fā)方法
    軟件過程改進是一個持續(xù)的、全員參與的過程。CMM/CMMI建立了一組有效地描述成熟軟件組織特征的準(zhǔn)則，該準(zhǔn)則清晰地描述了軟件過程的關(guān)鍵元素，并包括軟件工程和管理方面的優(yōu)秀實踐。企業(yè)可以有選擇地引用這些關(guān)鍵實踐指導(dǎo)軟件過程的開發(fā)和維護，以不斷地改善組織軟件過程，實現(xiàn)成本、進度、功能和產(chǎn)品質(zhì)量等目標(biāo)。CMMI應(yīng)該是過程改進模型而非軟件過程或者軟件過程模型。
    然而在不少文獻中，CMM/CMMI都被視作一種官僚化和教條主義的重型軟件過程，并且與當(dāng)前軟件開發(fā)大環(huán)境格格不入。事實上，按照CMM/CMMI模型的要求，一個軟件組織應(yīng)當(dāng)定義使用本軟件組織特點的軟件過程，并且不斷優(yōu)化該過程，來更好地實現(xiàn)軟件組織的商業(yè)目標(biāo)。再實踐中，軟件組織為了迎合基于CMM/CMMI模型的“Verification”評估方法，刻意準(zhǔn)備大量文檔化證據(jù)，導(dǎo)致CMM/CMMI被視作在軟件項目管理中必須滿足的某種標(biāo)準(zhǔn)，這顯然是對CMM/CMMI模型意圖和使用方法的曲解。

  • CMM/CMMI并不能作為檢驗軟件過程優(yōu)劣的標(biāo)準(zhǔn)
    實踐中，很多人會將達到一定成熟度水平視作某個軟件組織的研發(fā)能力，并且試圖進行橫向比較，認(rèn)為成熟度較高的企業(yè)，其研發(fā)能力應(yīng)該強于成熟度較低的企業(yè)。而事實上，由于企業(yè)所處的環(huán)境以及要實現(xiàn)的目標(biāo)等方面的差異，過程改進對于不同企業(yè)的含義是不一樣的。因此，成熟度等級不適宜脫離企業(yè)環(huán)境直接橫向比較；同處于相同的成熟度等級，也并不能說明這些企業(yè)的研發(fā)能力也是相同的。CMMI不是過程優(yōu)劣的標(biāo)準(zhǔn)，也不適用作公司之間的能力比較。

  • CMM/CMMI與其他軟件過程或者軟件開發(fā)方法的比較是沒有任何意義的
    很多人習(xí)慣于將CMM/CMMI作為敏捷方法的對立面，試圖來解釋和說明敏捷方法的優(yōu)勢。事實上，這種語境之下所謂的CMM/CMMI方法其實已經(jīng)不是一個過程管理的參考模型了，而是某個特定軟件組織為了迎合或者滿足CMM/CMMI評估的需要所定義出來的某個具體軟件過程。顯然，將這個為了特定目的而定義出來的軟件過程的缺點視作CMM/CMMI模型的缺點是不合適的。所以諸如“CMMI vs Agile”的比較都是不恰當(dāng)?shù)?，前者本質(zhì)不是一種軟件過程模型，而是一種過程改進。

根據(jù)Humphrey再《Managing the Software Process》一書中對軟件過程管理這一術(shù)語的解釋來看，所謂軟件過程管理應(yīng)該同時包含按照既定過程的執(zhí)行和不斷提升過程能力兩個方面的內(nèi)容，所以，軟件過程改進應(yīng)被視為軟件過程管理的一部分。其常用的參考模型就是PDCA和IDEAL，這兩個過程改進的元模型。軟件過程管理和軟件過程改進兩者不能割裂，既不能脫離改進談管理，也不能脫離管理談改進。因此CMM/CMMI模型可以被稱為軟件過程管理參考模型，也可以被稱為軟件過程改進參考模型，但并不是軟件過程模型或軟件過程管理模型。

對CMM/CMMI模型的誤解

  • CMMI模型需要適當(dāng)裁剪以適應(yīng)公司的實際情況
    CMMI模型不需要裁剪，模型本身僅僅刻畫成熟度路線圖上不同階段的特征。大部分公司都不具備能力來裁剪這個模型，真要裁剪，也是應(yīng)該由CMMI的模型的提出方和維護方SEI干。真正需要裁剪的是公司內(nèi)部定義的組織級開發(fā)流程和開發(fā)規(guī)范，這個需要裁剪以適應(yīng)具體的項目場景，與CMMI模型的裁剪是完全不同的概念。
  • CMMI模型太重了，不適合互聯(lián)網(wǎng)時代的輕量級開發(fā)
    這個說法的錯誤之處在于，不一定是CMMI重或者輕，而是，CMMI根本就不是開發(fā)模型。
  • CMMI模型只適合大公司、大項目，不適合小項目
    首先沒人檢驗過；其次，項目的大小衡量本身也缺乏值得信賴的參考依據(jù)；最后，接受這種說法的人還是把CMMI當(dāng)成是一種特殊的開發(fā)模型。
  • CMMI模型只適合需求不變或者很少變化的場合，不適合需求不確定，變化很多的場合
    CMMI不是開發(fā)模型，與需求變化與否無關(guān)，談不上適應(yīng)或者不適應(yīng)。
  • CMMI與敏捷開發(fā)的對比
    這種說法是錯的。最根本的原因是CMMI不是開發(fā)過程，而大部分敏捷則是具體的開發(fā)過程。兩者根本就是風(fēng)馬牛不相及的事物，不具備沖突的基礎(chǔ)。所以不存在兩者之間的權(quán)衡和借鑒。此外，也不存在CMMI的抽象是其不足。所有的模型都是抽象的，抽象恰恰是模型的本質(zhì)特征之一。模型通過抽象來強化特征與目標(biāo)之間的關(guān)系，這才能幫助我們理解其內(nèi)在機理，指導(dǎo)具體實踐。

引用

  1. 本文大部分觀點是基于《軟件過程與管理方法綜述》 榮國平，張賀，邵棟，王青
  2. 只言片語說軟件的新浪博客系列
  1. 南京大學(xué)軟件學(xué)院《軟件工程與管理》課程ppt

最后，再次感謝榮國平老師以簡明扼要的文字，闡明了軟件開發(fā)領(lǐng)域容易混淆的部分，發(fā)人深思，值得我繼續(xù)潛心鉆研。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容