说到软件产品可靠性，往往离不开一个软件行业人士经常碰到的名词--bug。想必这个领域中奋斗的兄弟姐妹们，都在思索着如何才能更有效的预防bug的产生、控制bug的影响。从而更好的控制软件产品的可靠性。

一：bug的预防：

  首先应该重点关注的是项目分析阶段的Tech Spec。这个是需要SQC、需求分析人员、开发一起探讨的。需求分解越详细，对SQC和开发的指导工作越有利。从而也能够更好控制后续的工作流程。这恐怕是最有效、最直接的控制产品可靠性的方法；

  其次是系统评审，开发工作的效率和效果因具体owner不同而表现出巨大的差异，好的开发人员往往能够很快的完成一个模块的功能，而一般开发人员除了时间上要求更长，质量或者模块稳定性上也难以保障。这对项目来说是一种风险，对产品可靠性控制来说也是一种莫大的难度。因此有必要对具体模块的开发进行代码review，而负责这部分工作的人员便是评审人员。这样评审人员的能力将直接影响产品可靠性，因此如何提高评审人员的能力，并维护其稳定性对一个公司来说将至关重要。

  再此是提高开发水平，这是比较直接的提高产品可靠性的办法，但是由于涉及的人员比较多且复杂，这部分工作任务不是一个项目就能够承担的，这需要公司层面的支持，培训体系、导师指导体系、日常工作流程等都起着潜移默化的影响；

以上均是在预防角度控制可靠性，预防永远比检查重要。

二：Bug影响的控制：

  任何软件产品都会或多或少的存在bug，因此控制bug影响的第一步就是加强测试。测试是从使用者的角度来进行衡量产品可靠性的过程。从不同于研发的角度思考问题将有助于更全面了解bug的数量以及影响。测试的重要性在整个软件开发中是不可替代的；第二步是SQC用合适的方法方法Release测试结果，采取邮件公布的方式比较有效，这样可以防止SQC和开发之间爆发不可调和的矛盾。第三步处理bug，处理bug的方式也是因人、因公司环境而异。但比较有效的便是首先对bug归类，需要着重分析bug属于哪些模块？以及产生这些bug的原因。如果有必要，则需要重新review那部分代码。这种方式比较常见于前期测试，待到项目后期后，模块已经基本稳定，这个时候另一个重点是预防degrade的bug，因此会根据项目需要引入回归测试来控制产品可靠性。控制bug的影响需要多方面综合性的努力，由于每个人都是独特的，bug的处理将异常复杂。

  鉴于软件项目的特殊性，例如影响可靠性的个人因素过多、量化指标难以明确等多方面原因，软件项目的产品可靠性目前还处于探讨研究阶段。以上也只是个人针对软件开发项目的一些愚见。不当之处，请多多指教！