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