※ 引述《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