结论一：交付后软件缺陷的发现及修复成本往往是需求、设计阶段发现及修复缺陷成本的百倍。
这个结论要求我们强化前期需求、架构设计工作，为原型法及迭代开发模式提供价值基础。
结论二：40%到50%软件项目的工作量花在了可以避免的返工上面。
注意哦，有些返工是不可避免的，特别是有不确定因素的软件项目。但通过改进软件过程，完善软件架构，有效风险管理，可以大大减少这些不必要的返工的。
结论三：前述可避免返工的80%来自于20%的缺陷。
有效的缺陷分析，可以帮助我们识别出这20%缺陷类型，从而找到减少返工的办法。
结论四：80%的缺陷来自20%的模块，大约50%模块不包含任何缺陷。
这也是为什么我们需要找出容易出问题模块的特征的原因。
结论五：10%的缺陷导致了90%的软件系统停机。
说明基于风险场景的测试是高性价比的测试。
结论六：同行评审可以发现60%的缺陷。
数据显示同行评审发现缺陷的范围是31%到93%，中值为60%。我高度怀疑这个数据来源是否包含中国软件项目，因为大部分国内CMMI三级，甚至一些高成熟度的组织，同行评审只能发现低于30%的缺陷。 CMMI 2.0将同行评审又提升为实践域，我们需要动动脑筋解决同行评审在中国水土不服的问题。
结论七：基于多场景透视图阅读（Perspective-based）的评审比一般随机而做的评审多发现35%的缺陷。
说明同行评审是个技术活啊，正确的方法至关重要。
结论八：自律的个人实践可以少植入多达75%的缺陷。
结论九：开发可靠性高的软件产品的成本往往比开发可靠性底的软件产品的成本高出50%。但考虑到后期的运维成本，对某些软件系统来讲，这个投入是非常值得的。
盲目赶进度、走捷径的朋友请务必记住这一点。
结论十：大约40%到50%的程序都有严重缺陷。
质量是所有人的责任，更是管理者的责任。Ron Radice认为管理者至少应承担75%的质量问题的责任。
源自公众号 老丛讲桌