Re: [請益]CMMI重要嗎?

看板Soft_Job作者Franckie ( )時間17年前 (2007/07/19 09:53)推噓8(8推 0噓 7→)

留言15則, 5人參與討論串6/13 (看更多)

※ 引述《derekhsu (斷頭不過碗大疤)》之銘言： : ※ 引述《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 : : 資料是幹成大大學某教授的投影片 : : 資料也許有點舊 : : 這就是政府和學界一直想推的原因 d大講的看起來似乎對，但卻仍然沒有了解到CMMI的精隨 CMMI的終極目標不是專案，而是整體組織持續進步 CMMI和OOA，OOD，OOP沒關係，不是非要UML、Class Diagram...etc CMMI的重點不是人，走了案子的任何一個成員也不會影響到案子的進行 CM是很基本很基本的東西，重要但是還沒有碰到CMMI的精隨 CMMI運用到極致是不鳥CMMI : 我大概知道那位教授是誰...論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的管理。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.113.23.107

推

choufeng

07/19 10:11, , 1^F

07/19 10:11, 1^F

推

choufeng

07/19 10:12, , 2^F

07/19 10:12, 2^F

推

leicheong

07/19 10:51, , 3^F

07/19 10:51, 3^F