质量保证活动基本上就是检查软件项目的“工作过程和工作成果”是否符合既定的规范，但符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷，质量保证对于保证质量而言只是必要的手段，而不是充分的手段。

上面提到的第一个例子就能说明这个问题。现在公司建立了障害系统，公司严格要求使用障害系统，并在每个月月末，做分析统计，然后开会讲解，总结经验，尽量让每个人参加这个会议，会议内容就是将Bug分门别类做出统计，根据二八现象法则，重点关注Bug较高的类型，并挑出就有代表性的Bug实例总结，我们不是不可以犯错误，只是不可以犯同样的错误，这样做非常好，一直坚持下去，认真总结，一定会有非常好的结果。其实这方面对日做的比较好，我们国内部做的相对对差些。其实我们的bug率很高的，《××××应收账款系统》这个项目其实除了一些关于页面显示的，校验几个方面的Bug,其实还有很多业务性的Bug没有登录，因为这些Bug,要想描述起来非常麻烦，因为业务是应收账款，跟钱打交道的，很多是金额对不上问题，描述起来有一定难度。居各国例子，这个项目业务是基于工作流的应收账款管理，其中有一个bug是经过多个工作环节流程走下来，大概几十次会出现一次错误，想演示出错误都难，但错误却的确存在，这个Bug要想登录障害系统，的确有难度。我们项目的考核，除了纳期管理，投入产出比，还有一个指标就是千行Bug率。这个好像还跟项目奖金挂钩。对日项目，用这个考虑还比较合理，因为对日项目毕竟是Coding为主。而国内项目用这个考核，个人始终感觉不大合适。这一年办当中，我接手的，无一例外，全是系统改造，开发工具各不相同，所以不同项目，哪怕是人月数一样，代码量相差非常大，而且改造项目，这代码量简直没法统计。比如改造，一个人月的工作，很可能我改了几十条或几百条语句，但很可能出现了好几个bug,按照这个Bug率计算结果，高得超乎你的想象， 所以为了数字更好看些，更接近公司的标准，在项目总结的时候，全是瞎填的，如果做到这个份上，是没有任何意义的，还浪费大量时间。个人建议，国内项目Bug率=Bug数/(人月数×标准人月代码行)，标准人月代码行取行业或公司平均值由公司提供。

目前公司过了CMMI3，执行CMMI有不少好处，比如文档全面完整了，项目管理的可视性提高了。但是对于我们国内部，它并没有在根本上提高国内部我们公司的国内部软件能力。仍然停留在为了补充文档而文档，对开发而言，恐怕目前仅仅是进度管理表，项目工时分配表，起到了他应该起的作用，目前感觉国内在CMMI管理中，最薄弱的环节就是评审！评审，对项目的成败起着至关重要的作用，可是目前为止我好像只参加过一次。评审的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。通过消除工作成果的缺陷而提高产品的质量，技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本，如果开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。对日项目的评审是如何进行的，以及评审小组成员都是什么类型的我不清楚，我从没参加过，这里不做评论。我这里只说国内项目评审，本人认为评审小组成员，一定应该是项目经验丰富的，最好也是生活阅历丰富的，项目经验丰富一般技术比较全面，参与项目较多，曾经遇到问题较多，而生活阅历经验丰富的，容易抓出事物的本质，更容易从客户的角度考虑问题。而且我觉得这个评审小组成员应该是对日项目人员，国内项目人员混合在一起的小组，这样大家才可以相互借鉴经验，共同提高！目前公司评审的活动好像很少，而且小组的人员配置也需要加强(目前好像也没有专门的评审小组)。 符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。所以CMMI这方面，肯定要坚定的走下去，最后我们还要过CMMI5。