IT博客-大话人生-随笔分类-软件工程

CMMI 5能创造些什么看富士通的软件过程改善历

大话人生 — Fri, 11 Jul 2008 08:50:00 GMT

眼下，CMM似乎正褪去曾经笼照在它身上的神圣的光环。就连UML之父Ivar Jacobson博士游历中国之时，也不忘提醒他的中国同行：谨防掉入CMM陷阱。从这个角度看，富士通南大软件技术有限公司（FNST）正式通过软件行业内最高级别CMMI 5认证，似乎并不是一件值得关注的事情。但如果我们把历史翻回到二战刚刚结束之时的日本，我们一定会对这样一个事实表示惊异：二战结束初期，日本在工业基础极为低下的条件下，仅仅用了四年时间，就把曾是劣质产品代名词的日本产品，打造成了把美国同类产品打得在地上翻滚挣扎的生力军。造就这个奇迹的只有两个字——品质。

因此，如果我们还原CMMI的本来面目，把它当作是提高品质的有力手段时，FNST的CMMI 5认证之路就有理由值得我们关注了。而如果我们进一步反思日后这场竞争中美国产品重机关报崛起的原因，就不难发现美国绝地反击的法宝——态度。美国人不仅重新认识了造就日本产品奇迹的戴明博士，而且将品质管理上升到了经营管理的最高层次。基于对这种态度所起的作用的认识，我们就更应该下番功夫去研究一下FNST的CMMI 5认证之路了。

品质无泪

提起富士通公司，中国国内几乎到了无人不晓的地步，但提起它的软件业务，却没有几个人能说得清，通过富士通南大软件技术有限公司总经理北冈正治的介绍，我们了解到这源于富士通公司在中国国内的分公司众多。

北冈先生介绍说：“富士通是全球第三大IT及服务公司、全球前五大服务器和PC机生产商、世界第二大企业用硬盘驱动器的制造商和第四大移动硬盘制造商。三十年来，富士通在中国共设立了38家公司；其中，富士通直接投资的与软件开发相关的公司就有四家。FNST是唯一一家面向服务器基础软件的研发机构，主要业务涉及Linux服务器平台、服务器中间件、服务器硬件验证、嵌入式软件和系统应用软件。”从这简单的几句话中我们不难看出南大富士通公司的技术开发难度有多高。无论是围绕服务器平台的整体的软件开发，还是底层的硬件测试与验证，再到存储/网络/CPU的管理与服务器中间件和应用系统，所涉及的技术都非常基础。由此我们也不难想见，在这样一家需要建立高水平的开发团队才能应对的软件企业实施CMMI，确实不是一件容易的事情。

谈起选择CMMI的原因，FNSTCMMI过程改善委员会执行主席蔡志旻先生这样介绍道：“与CMMI类似的模型还有很多，而FNST之所以最终选择了CMM/CMMI模型，是站在提高软件开发品质、成为一流软件企业、提高顾客满意度的角度上综合考虑的。”

事实上，FNST自1999年成立之初就导入了富士通为了提高软件产品的开发能力和产品质量，日本富士通株式会社长期积累而形成的一套行之有效的方法和技术使得FNST是在一个高标准的基础上实施CMM认证的。从2002年下半年开始导入CMM模型进行品质改善和过程改善，一年以后FNST就通过了“软件过程成熟度（CMM3级）论证”，并获得证书。

FNST取得了一个良好的开端，这意味着已经取得了成功的一半。这个良好开端还表现在FNST在CMM认证之初，就采取了一些正确的做法。

CMM/CMMI模型只是给出了为了进行过程改善，"要做什么"，而需要组织把抽象的CMMI概念和目标具体化。在这个过程中，FNST没有让过于偏向理论论述的国内咨询公司参与进来，而是自己选择了“What to Do（CMMI书籍）＝》Why to Do（软件工程典籍）＝》How to Do（建立公司规范）＝》Do it！”这样一条改进之路。真正做到让开发人员理解蕴涵再CMMI相关PA（Practice Area）规定之后的软件工业界三十年来的经验之精髓然后再在实际工作中运用这些经验方法。

要达到品质无泪的境界，全员参与是必不可少的一个环节。值得一提的是，富士通是一家有着追求优异品质传统的公司。富士通品质保证本部长木村弘正这样介绍说：“出于让各分公司都要按照同样优秀的标准提供高品质产品的需求，富士通公司很早就成立了品质保证部。富士通公司内部有一个共识，这就是一个细节上的小失误，也会带来很大的问题。富士通公司的产品线很长，涵盖了软、硬件的各个方面，在软件开发过程中，确实不存在能完美解决所有问题的银弹，但从上而下的帮助可以让各个公共司都按照正确的流程来办事，而细节则由他们自己把握。”就细节问题，FNST技术管理课SQA（品质保证）主任王毅峰介绍说：“FNST实施过程改善，是应开发人员之需，而并非是管理层单方面的意志决定一切的。这避免了常见的过程改善误区：规范的制订者并不是规范的实际执行者；开发者无法从过程改善中受益。”

尽管有了一个好的开端，但FNST的高层领导并不敢松懈，2003年的顾客满意度调查数据表明，2003年8月的顾客满意度得分在满分100分的条件下，FNST的得分只有43.02。蔡志旻先生对这个成绩做了注解：“这表明用户用不用你的产品要依他们的心情而定，还远没有达到离不开你的境界。”

合于术数

中国人爱把成功的步骤归纳为修身、齐家、治国、平天下，而修身的要旨则可归纳为“法于阴阳，合于术数”，这种思想恰好也和CMMI 4级认证的定量管理不谋而合。在从已定义的三级向已管理的四级的转化过程中，对软件开发实施定量管理，对于整个世界软件业界而言都是个具有挑战性的课题，原因就在于软件开发的不可重复性。但对FNST，这却又是一个必须要迈过去的坎。

对这个问题，蔡志旻先生道出了其中的秘密：“与传统制造业相比，软件开发的定量数据的精确性要低很多。其次，数据的收集是件极其耗费时间的工作，而且容易出错。最后，软件开发的数据不能用于评判开发人员的工作。针对这三个难题，我们开发了SPIF（Software Process Integrated Framework）可视化项目管理辅助平台，实现数据的一次录入和处处使用，抓住品质，规模和生产率，日程三个对象实施定量管理，明确定量管理的意义，明确数据判断和分析的方法，特别是如何根据数据来把握开发状况，运用数据来调整下一步的开发活动。”

2004年12月，FNST通过了CMM4级认证，成为南京地区首家通过此认证的软件企业。难能可贵的是，FNST此时并没有把自己的经验作为独门武功珍藏起来，而是利用SPIF工具去帮助其他软件企业。包括江苏金智软件、苏州方舟公司等国内公司，都曾受益于SPIF工具及FNST积累的经验，并与移软公司，金鹰公司，趋势公司等进行了广泛的交流。而此时FNST的客户满意度得分也已提高到了60.60。然而，此时的FNST的业务百分之百地来自于富士通集团本部，面对来自印度等地区关联公司的竞争，FNST并没有让提高品质的工作就此止步。

问题背后的问题

富士通公司在给一家欧洲大型航空公司的订票呼叫中心实施IT整体解决方案时，富士通支持人员发现新业务流程实施之后，呼叫中心接到了很多的电话投诉。富士通支持人员并没有通过“简单地培训服务中心接待人员技能、增加接待人员数量”等表面措施来缓解这个现象，而是通过将电话投诉的内容进行详细的分类和分析，发现大多数投诉的内容集中在“电子机票无法打印”的问题上。再深入分析下去，了解到问题的根源在于印刷票据的打印机出现故障。于是在富士通支持人员的建议下更换了打印设备，大幅度地提高了机票打印的可靠性和效率。在很短的时间内，就使服务中心同期内接到的电话投诉量下降了80%。

对此案例，CMMI过程改善委员会成员王晶先生介绍，当某件事情的执行过程中出现问题的时候，如果只是简单的“头痛医头、脚痛医脚”，采取治标不治本的措施来消除问题的表象，那么会出现类似问题的隐患仍然可能在将来爆发。在问题发生时，为了采取改善措施来消除问题产生的根源以避免今后同样发生，我们必须连问几个“为什么”，以找到导致问题出现的根本原因并消除它，即解决“问题背后的问题”。这种方法称之为“根本原因分析法。”

在FNST，根本原因分析法甚至从2002年就开始在各个项目组得到应用。在面向CMM 4尤其是面向CMMI 5的改善活动，FNST重点在解决“处理交货后产生的质量缺陷”以及“分析客户满意度调查反馈的客户最不满点”的问题上，充分地使用了“根本原因分析法”，在找到问题的根本原因所在后，将改善方法应用到在后续开发环节中，尽可能提前监测到类似缺陷来避免问题的再次发生。较大程度地改善了产品的品质，提高了顾客满意度评价

2006年4月13日，FNST正式通过了CMMI Level 5的审查，成为江苏省内注册的首家通过该级别认证的的外资企业。而此时的顾客满意度得分，也预计将在2005年4月的72.67分的基础上提高于80分。另一个指标更明显地反映出了CMMI给FNST带来的变化：以PGRelief产品为例，在与FNST成立不久的2000年，产品交付后每千行程序的缺陷率相比，2003年通过CMM3时下降为92%，2004年通过CMM4后下降为35%，到实施CMMI5的2005年底则下降为2000年缺陷率的9％。软件产品不能按照交付的现象也已得到了根本杜绝。

快乐工作，共享成长

按照挖掘“问题背后的问题”这一思路去分析，问题也就不可能不出现。蔡志旻先生显然认同这一观点，他说：“通过了CMMI 5并不是公司提高品质的终点，FNST的新目标是在原先“人人参与，日日改善”的基础上，提出了“快乐工作，共享成长”的新口号，在2009年公司成立十周年之际，成为世界一流的软件开发公司。以产品交付后缺陷率这一指标来说，我们要达到富士通本部的世界先进水平。”

在采访过程中，北冈先生经常需要闭目休息一会儿，由此可见喜欢在业余时间练二胡的他为提高品质的活动付出了多大的心力，再看到蔡志旻、王晶、王毅峰等人匆忙的背影，我们不难想见FNST把品质摆在了一个什么样的地位上。然而，现在非常多的CEO在品质和利润发生冲突时，会毫不迟疑地选择后者。关于这二者的差异，被誉为是“美国最著名的质量管理家”的克劳士比曾做过这样的注解：未来10年，将有更多的产品及公司会因缺乏质量管理而不是因财源短缺而彻底失败。那些醒得早的人，即可掌握市场；那些迟疑过久的人，只能为人作嫁家。克劳士比的话同样道出了CMMI5的真正价值所在，也许我们这个时候更想看到CMMI5在接下来的时间里，为富士通南大软件技术有限公司创造的价值究竟会达到一个什么样的数字。

大话人生 2008-07-11 16:50 发表评论

CMM实施的案例分析

大话人生 — Sun, 16 Mar 2008 16:05:00 GMT

案例1:

　　V公司和竞争对手相比，在技术上并不占有优势，于是V公司采用了“快速响应”的策略。无论是面对瞬息的市场，还是多变的用户需求。V公司总能够抢先于竞争对手推出产品，为此受到了市场的肯定。但是V公司在实施CMM的时候，却错误地选择了“瀑布式”的开发模型，加上相对复杂的实施流程，如果研发体系严格按照要求去做，那么对市场的响应速度必然大大降低，企业的核心竞争力受到威胁。但是如果H公司坚定“快速响应”的策略，现有CMM的实施就无法有效进行。V 企业走入两难的境地。

　　V企业实施CMM并没有错，错的是他们在实施CMM的时候并没有考虑到企业的核心竞争力和总体战略，采用了错误的生命周期模型和相对复杂的实施流程，最后导致了这样的结果。

　　对公司的战略影响是一个方面，另外一个方面是，CMM的实施涉及到机构的重组，如果我们不能在组织架构，薪酬待遇，绩效考核等方面辅助以适当的政策的话，CMM的实施不可能顺利进行。

　　案例2:

　　W公司为了推行CMM，组建了独立的QA部门。尽管在W公司的内部宣传材料上对QA的作用进行了大肆的宣传，认为其对于CMM的推行和项目管理都具有重要作用，但是实际上QA人员的资历都相对较浅，对开发过程，技术和工具都缺乏必要的了解。只能够照搬一些条文来要求开发人员，开发人员对此并不认账，认为 QA人员是没事找事。另外，QA这个岗位在薪酬和升迁方面毫不吸引人。

　　为了避免QA部门成为新手和项目组淘汰人员的集中地，QA部门经理设法推行项目经理锻炼制度，让项目经理到QA部门锻炼一段时间，然后继续担任项目经理或者升迁。但是因为此项制度没有得到有效的支持，项目经理在QA部门工作一段时间以后竟然没有开发部门愿意接收，就更谈不上升迁了。QA部门在W公司的威望江河日下。

　　QA人员对于质量保证和CMM的实施至关重要，如果我们认可QA人员对于公司的价值，那就必须在人才和待遇上向QA部门倾斜。

　　案例3:

　　S公司在推行CMM 2级的时候遇到了极大的阻力，项目经理对估计和计划过程根本不感兴趣。其原因在于S公司有“倒排计划”的习惯做法。

　　项目经理对项目的进度安排没有决定权，当项目经理接受任务的时候，项目的发布日期早已确定，而且项目经理做出的人力资源请求一般也不会得到满足，项目经理被迫在一个资源短缺的环境下开展工作。既然Deadline已经确定，增加人手又不可能，项目经理怎么会对估计和计划有兴趣呢?

　　与此相对应，S公司的内部宣传材料在不断地表彰在资源短缺的困难情形下做出成绩的经理和开发人员，对“无原则服从命令”行为的赞许，已经成为了公司文化根深蒂固的一部分，并且得到管理层的默许和鼓励。

　　S公司的文化和CMM的要求是抵触的。CMM要求项目经理对任务的合理性进行分析，要求在理性的基础上做出判断，而不是盲目地服从。如果S公司不能够改变他们的文化，CMM就不能够得到有效实施。

案例4:

　　A公司是一个小型公司，但却采用了一个步骤繁琐的CMM实施方案，而且没有采用任何自动化的过程工具，大部分由纸面文件传递来进行。比如在测试中如果发现了一个问题，必须由测试人员找到文件模版，填写好缺陷的种类和描述，打印出来，交给相关人员签字，开发人员的修改结果就只好填写在纸面上，最后还要找项目经理签字。相关人员浪费在文件传递上的时间可能比进行开发和测试的时间还要长。

　　以CMM为模型制订管理框架，其本质是为了规范管理，减少错误的发生。而执行这些管理规程，就其本身而言，并不是我们的目的，而仅仅是一种手段。对这些规程的执行也不创造任何价值。在条件许可的情况下，我们要尽可能地简化手续，提高效率。并适当地引入自动化工具。像A公司的情况，用一个缺陷追踪工具就可以大幅度地提高效率。

　　案例5:

　　H公司和Z公司都在研发相同类型的C产品。H公司在推广CMM，采用了相对严格的过程规范，并且把相对重要的部分外包给了印度的CMM5级公司。这些手段Z公司都没有采用，但是Z公司却抢在了前面。

　　Z公司的“秘密武器”是一种形式化语言—SDL，Z公司采用SDL作为设计工具，这样C产品的相当一部分代码可以由SDL工具自动生成，而且在设计阶段就可以进行仿真运行，这样就大大地提高了效率并减少了缺陷。H公司虽然采用了相对严格的过程规范，但是因为全部代码为手工编制，所以，无论是效率还是质量， H公司都落后了。

　　H公司显然忽视了先进技术可能为生产率带来的进步，通过了CMM高级别的评估，只能说明被评估的组织机构在过程控制上做得更加细致，但是并不能够保证你的开发过程是高效的。某些沉迷于CMM的组织机构忘记了先进的软件工程技术的重要性。

　　案例6:

　　H公司的B项目是一个庞大的项目组，技术相当复杂。名词术语很多，而且对于同一件事物的表达方式也不尽相同。项目组非常有必要制定一个规范的术语表，既统一了说法，也方便项目组的新人查阅。但是事情的发展是很有戏剧性的。

　　项目组在起初并没有重视术语表的编制，因为人少，产生的文档也不多，所以这件事情无人重视。但是到了项目进展了1/3左右，术语的混乱已经相当严重的时候。B项目组的一个工程师X自发地开发了一个小程序，用于查阅术语的名称和缩写。项目经理对X工程师的做法提出了表扬，并委任X开发和维护这个标准术语表。

　　项目经理和相关部门的始终没有意识到：(1)开发和维护这样的标准术语表是项目经理和配置管理人员的职责，不是某一个软件工程师的任务。(2)类似的问题在别的项目组一定出现过，以后的项目组一定也会遇到，必须在开发规范上堵住这个漏洞，让别的项目不会重蹈覆辙。

　　所谓的“管理无大事”，过程管理的真谛就在于这些看似细节的小事。基本的过程管理原则和规范只是“骨架”，而“血肉”是要靠这些看似细枝末节的小事来丰满的。积沙成塔，集腋成裘，点滴持续地改进，其效果最终是巨大的。

大话人生 2008-03-17 00:05 发表评论

软件发布的流程

大话人生 — Sun, 16 Mar 2008 05:54:00 GMT

严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制，保证软件产品质量的关键过程之一。

参与软件产品发布的人员主要是测试负责人和BM（Build Master）。

公司软件产品发布的规程如下：

1、发布准备。发布之前，所有程序freezed由测试人员进行确认测试；检查qcs系统内登记的所有bug都已经被fixed，或者遗留的bug不影响系统的使用，如果有严重bug未解决（级别为must fixed）不能发布；程序打包前做冒烟测试。

2、测试负责人编写release产品质量报告进行质量分析和总结。

3、源码、文档入库。源码包括数据库创建脚本（含静态数据）、编译构建脚本和所有源代码；文档包括需求、设计、测试文档，安装手册、使用手册、二次开发手册、产品介绍（ppt）、使用demo等。

4、 BM进行程序打包；标记源码、文档版本tag。

5、 BM填写发布基线通知并通知相关人员；BM经理对发布基线进行审计。

6、在qcs系统上新建产品发布计划，填写配置项，执行发布计划（发布产品）。

7、上传程序包、使用文档至download站点。

9、正式发布通知。通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍。

10、后续工作。产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打patch或者按照流程重新发布。

11、临时发布。软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；BM需要为源码、文档打tag标记。

大话人生 2008-03-16 13:54 发表评论

IT博客-大话人生-随笔分类-软件工程

CMMI 5能创造些什么 看富士通的软件过程改善历

CMM实施的案例分析

软件发布的流程

CMMI 5能创造些什么看富士通的软件过程改善历