Re: [請益]CMMI重要嗎?
※ 引述《teman ()》之銘言：
: Number of CMMI Appraisal by Country
: September 2006 March 2006
: Taiwan – 31 Taiwan – 26
: China – 158 China – 117
: Japan – 155 Japan – 131
: India – 177 India – 140
: USA – 598 USA – 500
: United Kingdom – 42 United Kingdom – 35
: Korea - 56 Korea - 50
: 資料是幹成大大學某教授的投影片
: 資料也許有點舊
: 這就是政府和學界一直想推的原因
我大概知道那位教授是誰...論CMMI，那位教授大概是台灣
學界的領導人。
不過，其實CMMI在台灣推行有很大的問題，最大的問題之一
台灣政府方面對CMMI的認識不成熟。
第一點是政府方承辦人對於CMMI的認識不深，對政府而言，
CMMI只是在RFP上承包條件的部分多一個項次而已，其他什麼
都沒有了，甲方也不會依照CMMI上的精神去監督乙方的作業
狀況，更不肯用心去看乙方所提供的專案相關文件，做做樣
子大家都會，這讓乙方也想反正我只要把專案完成交出去就
好了，符不符合CMMI的原則那管他去死咧，惡性循環之下，
當拿到認證之後，沒人去理CMMI那也是人之常情。
第二點是台灣方面教育也對CMMI的教育不足，所以該教授才
會在學界推所謂的Light-weight CMMI，只挑了CMMI Level
2-3中幾個重點來實施，從學校教育開始訓練學生對於CMMI
的認識。但這其實是杯水車薪，而且就我所知，許多學生反
到因此更不認同CMMI，因為這東西讓他們花了許多的時間在
Paper work上，而影響到他們原來專案的運作。
在台灣軟體業流動率如此之高的情況下，要好好的實施CMMI
那更是難上加難，CMMI他不是一個技術問題，而是一個教育
問題，常常當認證結束之後，一大堆公司的人也被CMMI給逼
走了，更何況，CMMI的導入期通常長達1年半的時間，這麼
長的時間，人又來來去去，真的說要落實，那無疑是天方夜
譚。
CMMI他不是一個技術層次的規範，他是一個「專案」層次的
規範，就跟PMP一樣，但PMP並沒有限定特定的Industry，而
CMMI則是針對Software領域。而且並不只是作那種OEM或是
承包的軟體，只要是用軟體寫程式的單位，MIS部門、ERP部
門，甚至是嵌入式系統、Driver撰寫的單位都適用CMMI。
他也不是一個新的規範，CMMI只是把我們平常在開發軟體時
就應該做到的東西整理歸納並做成規範而已，很多東西其實
是老生常談。
就舉Level 2的Configuration Management（建構管理）來
說好了，建構管理的目的在於管理你的Code和Document的品
質，看他的SG來說明好了：
SG1 建立基準(Baseline)
這裡所謂的Baseline就是指專案完成過程中，所要建構項目
的基本項目有哪些、要如何管理這些建構項目。而所謂的建
構項目指得就是程式碼、文件或其他等等需要交付給客戶的
東西，都必需納入建構項目當中。
SP1.1 界定建構項目
這個SP會產生的工作產品就是「已界定的建構項目」，什麼
叫做已界定的建構項目？如先前所說，公司內部有公司內部
要求的建構項目，如「原始程式碼」、「系統需求分析書」
、「系統設計報告書」、「測試報告書」、「合約」、「專
案規劃書」等等你公司規定的項目。
可能還會包含客戶在合約上要求的項目，這不在公司規定裡
面的比如，「系統操作手冊」、「教育訓練規劃書」、「產
品保證書」等等許許多多只要合約上有規定的項目，就必需
要納入成為建構項目。
SP1.2 建立建構管理系統
在找出你專案中所有的建構項目之後，下一步就是要建立如
合管理這些建構項目的機制，他包含三個部分：
建構管理系統
建構管理程序
變革管理資料庫
建構管理系統用白話一點的話來說，就是「版本管理系統」
，就程式碼而言，你要告訴評審委員，你用什麼東西去管理
你的「原始程式碼」？他可以只用File System管理，你也
不能說他錯，但你要告訴評審委員，你用檔案總管來管理，
你要怎麼記錄程式碼的版本？你要怎樣保障程式碼的安全？
所以，為了方便，建構管理系統可以採用一些現成的工具，
比如Open Source的CVS、SVN或是MS的SourceSafe，都有紀錄
版本與管理原始程式碼的功能。
那文件呢？其實文件版本管理也有很多Solution，你可以把
文件也跟程式碼擺在同一個建構管理系統上，或者，很多KM
平台、文管平台（例如ISO所提供的那些），都提供版本控管
，安全性控管的功能，這些都是你的建構管理系統。
建構管理程序則是你在建立建構、變更建構、刪除建構有沒有
依循一定的規範？哪些建構項目只有哪些角色可以存取，哪些
建構項目要變更的時候要經過哪些人同意？你要有規範，要有
章法，比如合約內容可能就只有讓PM知道的必要，不必開放給
工程師知道，或者當要變更原始程式碼，需要經由SD的同意才
能夠開放簽入簽出，類似這樣的規定必需要建立起來，建構項
目才能安全地被管控。
變革管理資料庫記錄你在專案發展過程中對建構項目一切變革
的紀錄，比如你的簽入、簽出，修改新增，都必需有log記得
明明白白並且可追蹤。
SP1.3 建立或發行基準
所謂的基準，就是一種規範（基礎的水準），當建構項目沒有
到達這個基礎的水準時，是不能夠交付給客戶的。根據SP1.3
的精神，你必需對你的建構項目建立發行的基準。
如你的程式碼，必需要求在「完成單元測試」的前提條件下才
可以簽入，不然別人簽出你的程式時根本連編譯都無法進行。
或者，你的建構出來的「系統需求分析書」裡面必需要包含：
需求追溯矩陣、需求清單、UML定義的Concept Class Diagram
.....等等的項目，才可以交付給客戶。
換句話說，在建構管理裡面，你必需要先建立兩套準則，第一
個準則就是建構變更的準則，第二個準則就是建構建立與發行
的準則。
以上僅僅舉SG1來說明，SG2則請自行參閱。從SG1看出其實這
些都是很基本的東西，比如「程式碼版本」一定要管控，「交
付文件版本」一定要管控，這些都是老生常談的事情，你程式
碼沒有統一的管理機制，交接一定出包，整合一定出包，這是
顯而易見的事情，然而CMMI將這些顯而易見的東西加以整理、
規範。
其實CMMI他不是一個什麼不容易瞭解的牛鬼蛇神。我們如果肯
用心思去看裡面在說些什麼的話，一定多少會有一點收穫，也
必等到公司，就從自己就可以做到CMMI的管理。
--
界(http://derekhsu.idv.st)
我的世界、世界的界線；我與這個世界的界線
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 211.74.254.164
討論串 (同標題文章)