關於「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. 政府的標案(以前輔導過幾家軟體廠商,就近多少知道一些),很奇怪的是,永遠時間都很趕。一個上億的案子,要求在幾個月內就完成含系統分析、設計與實做及建構部署。
    若永遠就是有哪一個先決幾近無法改變的事實:時間就是不夠,那麼,如何能在如此短的時間內開發出 “成熟” 的系統呢?

文章導覽

   

共有 10 則迴響

  1. 對於IT 人員,很難去思索CMMI之重要性,但是無論是CMMI 或是專案管理之PMBOK,都再再強調”經驗學習”之重要性(Lesson Learn),而這種學習,不是從書本上,就可以取得,重要的公司經營管理之資訊,來獲取,在台灣之IT產業中,因應惡性競爭,而忽略了本質,不斷改善之精神,只剩下一昧的追求,要導入CMMI,而軟體之持續改善,真正做了沒,就不得而知了~

  2. Hello, 各位大大:
    看到各位大大發表的熱烈,就加入發表一些小小心得,Kenming兄的考量的確是沒錯,即使如RUP/CMMI/ISO等若淪為形式,當然會失去其本質,曾和國內的CMMI顧問以及導入的公司作過訪談,更發覺其中玩味的地方,導入這些東西的確帶來確實上的改善,這點由導入前後的 Gap analysis 就知道了。 但多數人也反應,導入後讓原來 Resources 不足的情況,人員身上的擔是更吃緊。我想…利弊是一體兩面的, 至於印度方面能跑出成果來, 或許在 Resource 方面較充足,或是說配置的較好…這個若有機會訪談他們的話, 就可以明白。^__^ 至於要作到個人面,至專案團隊,至 organization, 其實在 CMMI Scope 中,是有 PSP & TSP 在探討基層 capability & maturity. 小小意見與大家分享. ^_^

  3. Hello 抓跟:

    看起來國內有好許多專家在專研 CMMI 🙂

    我一直在思考一些事,我看過許多軟體公司,導入 RUP,結果幾乎是在做 “假” 的 RUP,亦即,只是在作一些漂亮的 “文件”,卻實際與應用程式產出是兩回事。那麼,類似的事,是否,也會出現在導入 CMMI 的這些 ISV 呢?

    再則,國內專注於導入 CMMI,著重於製程的控管,而對於軟體開發,最根本性的本質性設計思考能力,是否又忘卻及不重視了呢?

    還有一個現實的問題,導入 CMMI,到底是否是與 印度、大陸等軟體工廠直接硬碰硬的競爭,還是能達成和諧的互補呢?

    在個人的心中,一直存在許多與 CMMI 相關的問題,我是蠻想,有機會,很希望能請教各位專研 CMMI 的前輩、專家們的看法與見解。

  4. 見到Kenming兄也開始Touch CMMI,我也拉雜扯ㄧ下:

    1.CMMI Level 2(staged),我認為是在紮project management的馬步,是要告訴project leader在project management上該做些什麼最基本的事。而Level 2的7個PA(Process Area),個人認為REQM及SAM是比較可以看出成效(當然還是有前提….),而MA最難,難在要量測什麼最有用(both for business objectives and project members)

    2.Level 2 focus on project scope,Level 3 on orgnization scope(not enterprise scope)

    3.Level 3是重頭戲(跟programmer比較切身的development life cycle裡面的活動),而且要based on practices and measures implemented in Level 2,所以應該是要”按部就班”的落實CMMI(IBM Taiwan直攻Level 5所使出的特異神功則不在此列)。要講Integration,Level 3應該是最棒的試煉舞台。

    4.EPG(or SEPG) plays a key role in implementing CMMI。EPG members should be: 腦要清,肩要硬,心要軟,手要實。

    5.搞CMMI,跟搞OOADㄧ樣挑戰、ㄧ樣有趣 🙂

  5. Hello 誰說殺生不慈悲~

    您所提的問題是否正是一些軟體廠商導向 CMMI 所應該需注意及瞭解的?
    而若,導向 CMMI 已是必然的的趨勢(政府的推動),那麼,在這個框架內是否可以思考如何讓這個框運轉得更順暢呢?

  6. Hi Kenming
    針對您看法,小弟有另一種看法,專案在執行時,本是許多獨立的個體(STAKEHOLDER)有者大致相同的目的的互動,若專案本身就是不可行,再好的框能改善問題嗎?所以,小弟再想有框其實就是無框,系統的互動(人及軟體)是需要用心體會的

    謝謝

  7. Hello TC:

    很高興能認識您,並提供如此多的寶貴意見,讓我對 CMMI 也有些基本的認識 🙂

    最近所思考的是,如何將軟體設計(尤其是隱含於系統內部的結構設計,非僅從外部的需求面) “內化” 與 CMMI 的 “框” 能成為很好的互補。
    最近會開始著重於這方面的研究。也希望若可以,能與您請教討論。

    P.S. 若有機會,未來我們軟體設計開新班時,請直接聯絡我~

  8. Hi Kenming,

    1.沒錯,顧問的角色是針對該組織的特性來提供及建議一套可行的Workflow及Process,換句話說,在導入的過程中,都是在溝通及回饋,設法找出符合CMMI精神的一套流程。

    2.這是個很好的問題,也是我非常concern的問題,但遺憾的是,CMMI並沒有針對SA/SD來驗證其成熟度,也許我這麼說有很多人並不同意,因為CMMI Level 3開始有V&V(Verification & Validation)的工作區域,透過V&V的活動,可以驗證生命週期每個階段的產出,那他們就認為品質可以得到保障,但我瞭解你提出這個質疑的背景,因為我也認為這樣做仍不足以驗證其品質。

    3.”Tailor”是CMMI或ISO制度一項非常重要的機制,tailor後的流程仍必須符合CMMI或ISO的規範,只是有些文件或是中間產物可以省略不做,以提高工作效率。

    對於你在軟體設計方面的觀念,深表贊同,也希望有機會可以去上你開的課。

  9. Hello TC:

    非常感謝您對於個人幾個疑問點上的提示。

    1. CMMI 只告訴我們 “What to do”, “not how to do”,這與我心裡所想的差不多,我是認為 CMMI 是一個 “框”,是一種制度、一個規範。不過,到沒想到您所提的需要顧問公司來輔導。只是,這個顧問公司,所輔導的內容是否比較是針對流程與建構管理面上呢?

    2. “成熟度”要靠良好的需求分析、制定可測試的需求及建構管理來達成,這點是我比較質疑的,因為,系統最核心的部分:結構的分析與設計,是如何被驗證其 “成熟度” 呢?

    3. “tailor” 這個字彙蠻有意思的。 但要能說服客戶(尤其是政府機構的老大心態)對專案規模作裁適,本身就是一件超高難度的工作。

  10. 首先對於CMMI所闡述模型、流程及活動都只是告訴我們 What to do! not How to do, 所以需要顧問公司根據公司實際狀況來輔導。
    專案開發團隊的”成熟度”要靠良好的需求分析、制定可測試的需求及建構管理來達成(你看這就是我說的What to do, not How to do)
    政府的標案、時間就是不夠用,完全同意,因為你所面對的是一個只會要求時程的客戶(其他完全不知道),所以依我的認知,如果要符合CMMI並符合時程上的要求,需要依據實際專案的大小來裁適(tailor)一番,才有可能達成。
    以上是個人淺見,歡迎challenge…

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *