质量控制

总体来讲，软件的质量控制是一件令人头痛的事情，尤其是把质量控
制细化了以后，具体到每个人的质量控制，更是令人挠头，
领导觉得程序员的设计质量不好，但是程序员却觉得这是
自己苦心思考的独到之处，到底谁对呢？
处理的不好，程序员还认为是领导故意为难自己。

从这几个月的工作经历看，这里的质量控制主要有这么两个方面。

硬性控制：
    1. 有需要严格遵守的软件开发过程
    2. 在设计中以方面引入更为优良的设计工具，例如UML，顺序图等等，
    3. 在编码阶段，有编码标准，有代码复杂度计算工具，单元测试工具等等。
    4. 庞大的测试队伍。
       
   
软性控制：
 
    讨论/评论
 
    从最开始的需求阶段，就有大量的讨论/评论会议。
    会议要求相关的人员参加，并且有相应的讨论/评论会议记录。
 
    此后的任何一个工作成果的发布，都有相应的讨论/评论会议。
 
 
从表面上看，硬性控制是最有效的控制分方法，但是，由于软件产品是一个高度智力化的产品。
因此，很难用硬性控制标准去衡量所有的工作成果。这时就需要软性控制。

但是，如果这个环节仅仅由很少的人员进行讨论/评论，难免出现偏颇，同时容易造成员工内部关系的紧张。

毕竟，质量控制环节是挑出产品的缺陷过程，作者对于自己的劳动成果是满怀感情的，因此难免心情不愉快。

但是如果在这个环节上，是很多的人在讨论/评论，假如很多人对于某一点都提出了意见，那么这个作者自然会想，自己在这一点上是不是的确有问题。
 
这样，控制的质量更为客观一些。
 
同时，很多人都在为这个产品出谋献策，最终的质量自然会比一个闷头做，要好得多。

这种软性的质量控制，化有形于无形之间。

最后，还要给这种软性质量控制来一个硬性控制，以防其走过场，评审代码的时候，每小时不能超过多少行，必须找出多少个bug，评审文档，每小时不能超过多少页。每次评审会议不得超过2个小时，以保证与会者的精力。