在长期的项目管理实施过程中，人们发现被人们奉为软件质量管理圣经的CMM和ISO9000似乎并不奏效，现实和理想之间的差距太大。人们渐渐的发现了商业目标决定质量目标这一道理。

提高软件质量的最终目的是为了赢利，而不是创造完美无缺的产品。因此对于普通商业软件而言，并不是“质量越高越好”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内；因此质量人员在全面软件质量管理中发挥重要作用。重视软件质量是应该的，但是“质量越高越好”并不是普适的真理。只有极少数软件应该追求“零缺陷”，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌驾于商业目标之上。

怎样理解软件质量呢？软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量。软件的质量属性很多，如正确性、精确性，健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员下功夫去改善。何为质量要素呢？质量要素包括两方面的内容（1）从技术角度讲，对软件整体质量影响最大的那些质量属性才是质量要素；（2）从商业角度讲，客户最关心的、能成为卖点的质量属性才是质量要素。

质量保证（Quality Assurance, QA）是CMM和ISO9001最为推崇的改善软件质量的方法。但是在实际的项目实施过程中我们深有体会，质量保证并不能保证质量；它只是个美丽的谎言而已。

CMM对软件质量保证是这样描述的：软件质量保证的目的是为管理者提供有关软件过程和产品的适当的可视性。它包括评审和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范。如此简单的活动为什么被冠以“质量保证”这等份量的术语呢？

我们可以做这样一个假设：过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。假设企业已经制定了软件过程规范，如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存在缺陷。反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是合格的。

但是符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷。例如，即使程序员们都按照统一的编程规范来编写程序，但是编程新手的代码可能错误百出，而高手的代码则无可挑剔，可是质量保证这种方法根本无法识别新手和高手的差距。质量保证的技术含量太低了，只能检查出肤浅的缺陷，不能对付有技术难度的缺陷。所以单独的“质量保证”其实并不能“保证质量”。

所以说“质量保证并不能保证质量”，质量保证对于保证质量而言只是必要的手段，而不是充分的手段。

提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。

可在现实之中，大多数软件企业都是在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄。

根据现阶段的实际情况，我们可以借鉴成功的质量管理经验，将其管理过程用于我们实际的管理过程中。

以下是一比较成功的质量管理模型我们不妨根据我们的实际情况借鉴此模型让我们的质量管理在现在的阶段上更进一步。

段上更进一步。

在此模型中质量人员的职责在于：（1）负责制定质量计划 （2）负责过程检查 （3）参与技术评审 （4）参与软件测试 （5）参与软件过程改进

技术评审与软件测试关注的是产品质量而不是过程质量，两者的技术强度比过程检查要高得多，更加容易发现缺陷。技术评审和软件测试能弥补过程检查的不足。质量人员除了过程检查之外，还要参加（并监督）重要的技术评审和测试工作，这样做才富有成效。并且质量计划、技术评审、软件测试、过程检查、缺陷跟踪是全面软件质量管理方案中不可缺少的环节。

软件过程改进专家曾一针见血的说过“世界上还没有万能的软件质量管理圣经，我们不要迷信CMM和ISO9000。”我们只有认识到“商业目标决定质量目标”这个道理，才能够研制出适合于本企业的质量管理方案。