關於「CMMI」幾個問題的自我提問

  • 1986年由美國卡內基美隆大學的「軟體工程學院(SEI)」受到國防部委託而發展的。可以幫助軟體開發者改善軟體流程。
  • CMM軟體能力成熟度模式(Capability Maturity Model for Software,簡稱CMM或SW-CMM)
  • CMMI整合能力成熟度模式(Capability Maturity Model Integrated,簡稱CMMIsm)

因為前天看到國內某篇資訊雜誌訪談現任Borland的CPO(Chief Process Officer) Bill Curtis ,他對國內政府帶動軟體資訊產業走向 CMMI,深表期許與贊同。

Curtis 認為:CMMI導入,管理議題 重於技術開發。
又,記者問了一個問題:在CMMI的流程架構下,是不是很難凸顯個人的能力? Curtis 的回答是:不會,反而可以塑造出優秀的人才,寫程式不只是要凸顯個人的能力,而是在流程和專案管理方面的發揮。

整篇文章看起來,CMMI 是非常重視製程的品質與流程的管理。

因為政府輔導因素,還有,最重要的是,未來政府資訊系統的標案,會要求軟體廠商需具有 CMMI 認證的資格。所以,國內許多資訊廠商,趕忙著 “宣布” 他們已經通過了 CMMI Level-2 or 3,甚至朝向 Level 5 的終極目標邁進。

原來有些納悶,軟體開發工具大廠 Borland 會如此的支持 CMMI 的推動?
思考了一陣子,站在 Borland 的角度來思考與其的商業利益,就蠻清楚了。Borland 約兩年前陸續購併了許多輔助專案管理工具的廠商,包括當紅的 UML 塑模工具 Together,將這些工具整合成為軟體專案開發的 Total Solution,稱為 ALM( Application Lifecycle Management)。而為了推動 CMMI 的軟體廠商,的確是需要專案管理與開發工具的利器,這就正符合 Borland 的商業目的,會是成為最具 “潛力市場” 的目標客戶群了。

所以,對於 Borland 推動 CMMI 軟體工程實驗室,我就不會覺得意外了。
不過,有幾個對 CMMI 的一些問題,仍存於我的心中:

  1. 既然是稱為 “軟體能力成熟度”,那麼,除了可以協助管理與製程的成熟之外,專案開發團隊的 “成熟度” 是如何去學習與成長,以提升其成熟度?
  2. 政府的標案(以前輔導過幾家軟體廠商,就近多少知道一些),很奇怪的是,永遠時間都很趕。一個上億的案子,要求在幾個月內就完成含系統分析、設計與實做及建構部署。
    若永遠就是有哪一個先決幾近無法改變的事實:時間就是不夠,那麼,如何能在如此短的時間內開發出 “成熟” 的系統呢?