CMMI课堂笔记整理

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

课堂笔记整理(15.4.25-4.26)
字体颜色说明:
红色:标题
紫色:是我觉得的重点强调的地方
黑色:一般叙述
课程名称:
CMMI(Capability Maturity Model Integration,能力成熟度模型集成)
任课教师:
荣国平老师
新浪微博、博客:“@只言片语说软件”
推荐书目:《人月神话》,《人件》(老师上课的时候经常引用其中的话)
上课风格(个人观点):经常会有一些比较开放的思考性问题,个人觉得其实也没有绝对的正确答案,主要是体验一种思考的过程并获取一些启发,有些观点也不是很赞同。

还会穿插一些其它学科的知识,让我感到自身知识是多么的匮乏…
相关背景:
上世纪80年代初,美国国防部等政府机构在将一些项目外包时,发现选择承包的公司是一件很复杂的事情,所以就希望弄一个评价标准。

于是就委托位于匹兹堡的卡内基梅隆大学(CMU,学校的相关专业很厉害),其成立了软件工程学院(SEI)来进行研究。

领头的是Watt Humphrey(从IBM辞职而来,具有很丰富的专业经验),其聚集了不少专家进行研究探讨。

总结了大概一百多条标准,开始的时候是做了一个调查问卷,后来逐渐转变为CMM(能力成熟度模型)。

而CMMI算是对于CMM的继承。

需要注意的是,CMMI的构建Humphrey 并没有在其中,据老师说因为他意识到即便有这么个玩意儿也不能从根本上解决遇到的问题,所以其将研究精力转向了其它方面。

具体相关的如果大家感兴趣的可以去搜索些深入阅读材料。

课堂构架:
老师上课的思路感觉还是蛮清晰的,我大概说下一个大框架。

1.一个模型
2.两种表现形式
3.三种应用领域
4.四种类型
5.五个级别
一个模型:就是指能力成熟度模型,老师说他觉得这是软件工程领域很少见的做的相当完美的一项研究。

(还记得背景中提到的Humphrey 拉了一帮人一起探讨列条目么?这列出来的一百多条内容里,在日后的这么些年里被实践证明仅有十几条是他们并未想到的。

)其本质是刻画一个软件公司从不成熟到成熟的路线图。

(而不是一般人所认为的CMMI就是一堆材料)
在这里老师提出了几个问题来帮助认知
我就直接写结论了…
1 CMMI是一个不需要裁减的模型,其本身是完整的。

2敏捷开发和CMMI并非是对立面关系。

敏捷指的是一种开发方法,而CMMI是一种模型。

两种表现形式:即连续式和阶段式
连续式是反应一个软件公司的能力水平,阶段式则是反应其成熟度水平。

这里老师也做了一些具体的说明,所谓连续式可以理解为做的好与不好,而阶段式则可以理解为做了还是没做。

其中阶段式所反应的成熟度水平拥有5个级别的划分,而可以把连续式看作是第六个级别。

这里老师表达了自己的观点,他觉得这些东西
不能太过于绝对化,比如Google公司,它是没有CMMI级别的,但谁都知道这是一家好公司。

而一个只做2级的公司有时候要好于3级的,可以理解为是它的性价比比较低,说明是脚踏实地做事的。

(这里没有必要太过钻牛角尖,主要是想传达一个思想,CMMI说到底也只是一个相对的评判标准,不可以说的太绝对。

就好像评价一个人,不是用好和坏这么简单就可以定义的。


还有一点老师想阐述的是这种评估是过程改进的起点,而不是终点。

不是说公司评到了5级就好像任务完成,什么都不去追求了。

这种评估只是一种辅助手段,最终目的不在于此。

三种应用领域:
开发(CMMI for Development,CMMI-DEV)
服务(CMMI for Service,CMMI-SVC)
采购(CMMI for Acquisition,CMMI-ACQ)
这三个领域共享16个核心过程域,同时每个领域自己特有的一些过程域。

在这里老师还谈了谈所谓管理,如何才算管理呢?首先就必须要有一个目标,如果没有目标,就不会出现偏差。

因为没有和实际的一个参照物。

而管理就是对这个目标的跟进和对目标的补救。

对于过程域,或者说很多的联系,是一种相关性的,而不是因果关系。

就是说这些的联系不是上下级或者太过于紧密的关系。

四种类型:
对于这些过程域要进行分类
分为项目管理、过程管理、工程类、支持类
单个过程域属于唯一的一个类型,比如不会出现一个过程域既是项目管理的又是过程管理的。

这里有个题外内容:老师推荐看一看Google编码规范和代码评审的相关博文。

这个和考试的关系肯定是没什么的,老师也强调了一点,就是希望通过上课学到一些东西,哪怕是听说几个新鲜的名词,反正是应该有所收获的,而不是以对付考试为目的。

五个级别:
这个好像就是CMMI评审的那5个级别了,即阶段式所反应的成熟度水平。

需要注意的是老师说这里的5个级别和CMM中的是有所区别的,在以后自己阅读一些相关材料的时候要注意这一点,以免晕掉…
第一个级别:原始级(所有的公司都默认是这个级别)Initial
特点:个人英雄主义,一般团队里有个Superstar,他会左右项目的进展甚至是成功还是失败。

开发过程通常随意且混乱。

第二个级别:已管理Managed
特点:这时候项目已经拥有了跟踪,确保整个过程按照方针得到计划与执行。

第三个级别:已定义Defined
特点:核心是共享,过程得到了清晰的说明与理解,并以标准、规程工具与方法的形式进行描述。

第四个级别:已量化的管理Quantitatively Managed
特点:就是量化…老师在这里谈的挺多,主要是因为现实和理想之间存在差距,导致矛盾的存在。

说白一些,就是这个量化到底是不是好呢?很难说也很难做到一种完美的量化方法。

第五个级别:优化中Optimizing
特点:从英文表述可以看出,上面几个都是ed形式,而这个是ing,即为无止境的。

这里老师说了一个观点,就是所有的4级、5级的公司基本都是做的数据,再直白点就是造假。

因为真实的数据无法体现一种变化关系,但要评级必须…咳咳,就是这样,大家应该都懂的…但是这并非是一味的好或者坏,要辩证看待。

比如量化这个东西,它不能完全没有也不能太死板,就是没有一个完美的标准,看个人意识了。

基本老师就这么个意思,所以还需要继续研究和探索,大家也不能妄自菲薄,
认为前途很黑暗。

这里老师还阐述了一下软件工程与传统行业的差异表现在哪里,最核心的就是传统行业生产每件东西都是一样的,是重复性的。

而软件不一样,每一件都是新的。

所以说软件开发是个很困难很复杂的事情,所以我们都很不容易~~
这就是一个大概的体系架构,希望大家可以比较清晰些,不会太晕菜,具体的东西再看看那些PDF。

老师说有几个比较重要的东西,一个是过程域的结构,具体就是CMMI Slides这个PDF文档中的Process Area Components这张图,大家仔细看看。

另一个是老师在黑板上画的一张表格。

接下来老师就是具体讲述表格中的每个过程域了,目前讲了的有PP、PMC、SAM(这个没有讲,老师说如果有时间再讲)、CM、MA、PPQA、RD、TS、PI
我个人觉得没有必要太过于扣那些细节,除非要去实践的时候,不然开始就这么干的话没有一些毅力基本会晕菜…老师在介绍这些具体过程域的时候也是以一种探讨的方式,而不是单纯的讲述概念。

比如PP这个过程域,就是项目计划,这里谈到了估算问题,老
师其实没有过多说什么具体的估算方法,毕竟时间也不允许。

但老师表达了一个想法,估算的具体方法不是最重要的,而是在于让所有的团队里的人相信这个具体的方案是可行的。

又比如PMC这个过程域,就是项目监控。

项目监控是必须的,也是有价值的,但出现偏差时,不能鲁莽地去补救,因为导致偏差的原因有很多,要具体去分析。

课上老师还介绍很多,但都比较琐碎。

比如老师说了一个词语:技术负债,他希望我们能够自己去搜索一下这个概念并且有所收获。

比如谈到配置管理的时候,老师说一般有3部分,工作库(基本的东西都可以包含其中)、配置库(稳定版本)这里的东西是不允许随意变更的,但不是不可以变更,需要有一套流程。

还有就是产品库。

说实话,这里我不是很懂…如果有人能阐述清楚的话,就适当修改一下哈~老师还说代码进入配置库的的节点时在单元测试结束。

比如老师还谈到了语言的问题,bug和defect翻译成中文都是缺陷,但其实在英文中这两个是有区别的,bug是可预知结果的,而defect则是不可预知的错误。

比如老师还说软件工程往往是一种权衡,而不是一种科学。

比如老师还谈论了测试这个职位,他的观点是测试是编码规范的执行者,但产品质量的保障其实并不等于测试的职责。

测试在整个循
环改进中是个重要角色,但他不是万能的。

比如老师还说客户需求和产品需求是两个不同的概念,客户需求是用户所需要的使用价值,是用户面临的问题。

而产品需求则是根据客户需求所产生的解决方案,乍一看有点晕,仔细想想区别还是蛮明显的哈。

老师还说和用户最好只讨论具体问题而不涉及系统,因为当你给用户建立了系统的概念以后,也许需求就需要全部改,也就是大侠重新来过……
比如老师还说有时候太多名词并不是一件好事情,因为软件开发本身已足够复杂,再弄一堆复杂的东西会让人疯掉的…
比如老师还说一个缺陷在开发过程中存在的时间越长,解决的代价越大,且增长不是线性的,有可能是指数级的。

还有很多很多,就不赘述了。

而我个人的感受是老师在课堂上阐述的最多的是一种辩证的观念,就以CMMI为例,它本身就个完美的模型,而每一个过程域所阐述的则是最佳方案(理想方案),但实际操作起来确实是很难达到的。

比如老师说评审消除缺陷的平均代价是最低的,大家也知道,但是却很少有人能严格地执行评审制度。

我们更多的是寻找一种平衡,一种自己和团队认可的东西。

最后总结一下:软件开发很复杂,大家活的很不容易,多看些书接受点新思想多一点思考不一定立马有用但一定是有益的,矛盾是没法消除的,而考试却是不会很难的,就这样。

PS:我是坐在后排的,而且限于各方面条件和自身水平,这只能提供一个参考,要有什么地方有问题,欢迎大家提出来一起交流,也可以直接在这个上面完善和修改~~
李博洋。

相关文档
最新文档