“质量是企业的生命”、“质量是企业的尊严”等等已成为现代企业界的共识，质量对于从事软件的IT企业更是价值与尊严的起点，因为质量是软件产品的生命。

　　上世纪的工业时代，来自日本的全面质量管理（TQM）和美国的六西格玛（6σ）为用户带来了精良产品和美的享受。而今在中国的软件企业里面质量管理是一个“剪不断，理还乱”的话题，常常看到在一个软件产品或系统的工作链条上，所有的上下游角色都在忙于救火，平安无事后，又重复着同样的故事。看看现在中国软件企业中一旦出现BUG，则就会一些八仙观点：“为质量生，为性能死，为找bug奋斗一辈子，吃工具的亏，上自动化的当，最后倒在需求上”，“不，这是设计的问题”，“不，这是代码的问题”，“质量是测试出来的”。这些观点也成全了软件企业中测试部门或质量部门的“伟大的职责和尴尬的地位”！

　　纵然软件产品有它的不可见性和动态性导致它的“相对不可观测性”，但软件质量管理活动和项目工程活动未紧密结合才是最重要的因素。而软件质量管理活动的驱使是企业质量体系制度和企业质量文化，在没有驱使动力下目前很多软件企业的质量管理现状如下：

　　1、责任链不清：中国是一个讲究责任的国度，但因软件开发的特点往往出现“剪不断，理还乱”的怪像。

　　2、软件质量保证（审查、复审和测试）没有贯穿到整个软件开发全过程中去。

　　3、在于这些软件产品对其质量内涵的把握，仅仅停留在减少软件运行错误、加强软件测试，避免软件缺陷的一般性层面，而对整个软件开发生命周期的全过程质量管理。

　　软件质量管理责任链模型

　　即使在软件项目管理中质量管理定义了很多，但需求依然不能完全被验证，设计依然不能全面被测试。需求的缺陷、设计的缺陷、代码的缺陷、测试执行的覆盖度不全等等，这些缺陷一旦在系统上线后被放大，那么修复的成本会有多高？看看一般软件项目的质量管理的责任链模型：

图表 1 软件项目质量管理责任链模型

　　质量缺陷从一开始就人为的“被引入”了，并且随着“需求”、“设计”、“编码”的灰度降低则缺陷责任将被降低，缺陷的修复成本则反之。而现状是大部分项目在追赶进度，需求在未被完全验证或确认的情况下，已开展设计，再设计未被全面评审或测试的情况下，开发已跑步前进。设计的时候发现需求逻辑存在问题，开发的时候发现设计不够严谨…..当然并不是需求和设计，设计与开发必须串行，而是在一定粒度和耦合度下必须串行。

　　根据业界统计，软件产品在上线后发现的质量缺陷修复成本是在设计阶段修复成本的100多倍。而如何有效避免或降低后期产品缺陷呢？最有效的手段就是评审。

　　评审

　　评审是静态测试技术的重要组成部分，是对软件工作产品（包括代码）进行测试的一种方式，它应该在动态测试之前进行。评审通常是通过深入阅读、理解和检查文档来完成的。

　　评审包括管理评审、审查、技术评审、走查和非正式评审等不同的评审技术，评审的通用过程由以下六个阶段组成。

　　计划阶段：选择评审员，分配角色；为更加正式的评审类型（例如：审查）规定评审的入口准则和出口准则；选择需要进行评审的文档或文档章节等。