中国的企业特别讲责任。对于软件产品的质量责任，在IT企业里一直是一个“剪不断，理还乱”的话题。我常常看到、感受到在一个软件产品或系统的工作链上，所有的上下游角色都急急忙忙地工作着，可是有一天，有个BUG，我们且叫它“坏孩子”吧，被发现了，大家于是就开始了关于这个“孩子”的来源之争：这是代码问题！”----“不，这是设计问题！”-----“不不，这是需求的问题！”。另外，你也许还听说过其他一些关于软件质量责任的看法，比如：“质量是测试出来的。”“质量是设计出来的。”等等八仙观点。

工业时代的全面质量管理，在美国和日本的推动下，为我们消费者带来了无数的精良产品和美的享受。同时，也创建了责任分明的企业质量文化。进入信息时代后，TQM等质量管理理论和方法也被引入，但似乎对信息技术产品无能为力，无法落实。我们手里的质量大棒找不到了对手。显而易见的原因是，软件产品的不可见性和动态性导致了它的“相对不可观测性”。同时，软件质量管理活动和工程活动的结合不足也是非常重要的原因。当然，我们看到了这20年来软件质量管理的新理论、新变化。我们在软件测试领域，不断地推进，从黑盒测试到白盒测试，从手工测试到自动化测试。等等。这些进步，改善了我们代码植入错误的状况。然而，设计依然不能被全面测试，需求依然不能被全面验证。问题没有被根本解决。我们依然达不到象对待工业品那样清晰地管理软件产品质量！

当没有哪个环节能被完整度量的时候，质量就是每个环节的责任！当没有人能对质量独立负责的时候，质量就是大家的责任！所以我说，BUG这个坏孩子，是大家的孩子！

这样的认识基础，必然决定了软件质量全员责任。全员责任又带来了一系列棘手的问题：责任划分的困惑和责任推脱。最后，产生了模糊的企业质量文化。就比如第一段里的那些八仙观点。另外，软件公司里的质量管理部和测试部“伟大的职责和尴尬的地位”也说明了这一点。（这里我要强调的一点是：质量管理问题没有被很好地解决，并不妨碍一些好的产品的问世。）

这里，我试着提出一种软件项目质量管理模型。这个模型帮助我们有效分解责任链，说明软件工程活动的责任分配，并描述软件质量的责任衰减梯度。同时，这个模型也有助于提高我们的工程能力。该模型如下图：

模型的解释如下：

（1）4个象限分别代表4个质量责任区间或质量责任环节，分别是：需求开发人员的质量区间，架构师的质量区间，详细设计人员的质量区间，编程开发人员的质量区间。

（2）沿顺时针方向（图中灰度降低方向），质量责任逐步衰减（降低）。因此，需求开发人员的质量责任最大，编程开发人员的质量责任最小。这个观点可能会被许多同仁反对。但是，我依然这样认为的原因有两点：一是上游的工作对下游工作影响性大，所以上游的工作责任也就应该大，就像河水治理一样，要重点关注源头和上游的水质污染。二是从事上游工作的人才成本高，所以责任也应该大。比如说现在的许多业务专家的待遇特别高。

（3）本模型意架构驱动的开发模型为基础模型，所以，强调架构质量对软件系统的全局性影响。

（4）“测试”没有被作为一个工程过程对待。因为，新的开发观点，如CMMI等，认为，测试是一个质量控制和保证手段，属于产品和需求的验证工作；同时，测试越来越被早期执行，它甚至贯穿整个项目生命周期。

（5）软件质量目标由需求决定。在设计和开发阶段，质量目标被分解和实现。同时，缺陷从一开始变被“人为地”引入。因此，缺陷管理是质量管理的一个中心工作，只要缺陷的打开和不断地关闭，才能促进软件质量的完善。

（6）项目过程质量其实代表的是软件开发的“工艺”，这是工程能力的一个主要方面。过程质量控制和保证可以使用传统的质量管理技术和方法。现在中国掌握了很多西方高新技术理论，但是我们并不能消化这些理论制造出好的产品，其原因就是我们没有好的工艺，工艺代表了实践的经验，不可逾越。听说，全国热火朝天在建的高铁的车轮就是这样的情况。所以，我们需要过程改进，需要EPG，来长期地构建软件企业的质量文化。从这个意义上讲，项目过程质量是关联项目质量和组织质量体系的连接点。过程质量的另外一个价值就是，消弱公司对工程师的严重依赖，降低组织能力和员工能力的耦合度。

（7）产品质量有了明晰的度量方法，度量时间提前。早期如何度量软件的质量看上去似乎是一个伪命题，因为早期软件并没有产生。但是在早期，软件的质量缺陷却已经开始被埋入了。我们就通过埋入缺陷的程度来度量软件质量吧。同时，可以采取技术评审和测试等手段控制质量。

总结一下，该模型说明了质量问题的变化趋势和质量责任接力棒的传递过程。