一种典型的质量体系结构[ZT]

迎风

出处：CSDN
作者：不详



在一次软件行业过程改进大会上，我们了解到国内某大型软件企业的质量体系架构。和很多发展中的软件企业一样，该企业建立开始，研发质量一直是靠传统的测试部门来保障。后来由于对国外领先公司研发的不断了解，该企业才开始逐渐成立专门的质量保证部门，负责公司的质量体系建设。

    下图是典型的质量体系架构，明显的金字塔形。

【见下面附件图1】

各部分的作用是这样的：

    质量方针：是质量活动的总纲，类似于 ISO9000 中明确要求的质量方针。

    质量手册：明确研发关键的开发步骤和质量保证活动，是对质量方针的细化。

    组织手册：明确研发的组织结构，特别是质量保证方面的组织结构。

    规程：对研发各开发活动的具体规章制度

    表格、模板、检查单、指导书、标准：每个规程都有对应的一系列此类文档，是对规程的补充。比如说有项目管理规程，对应就有项目计划的模板、项目管理的指导书等一系列文档。

    这种质量体系，据说最初来源于印度一些公司流行的 QMS 质量管理系统。它的特点是全面、系统，几乎全面覆盖了 CMM 的 2-5 级的所有 KPA 内容，比较符合 CMM 模型的要求，而且有各类比较衫的模板、表格和检查单等形式，具备较强的实际操作性。这套体系是印度成熟的软件产业的成果，已经被证明的高效成熟的模式。

    当然这种体系在实际使用中也存在着一定的局限性。其中之一就是体系庞大，比较适合几十人一个项目组的团队开发，比较适合产业化的开发，要求写作的各种文档、模板较多，对印度那种以外包为主、采用瀑布开发模型、各个开发阶段分工明确的项目组特别适合；如果像国内的几个人的小规模开发方式，使用这种体系的管理成本就相当大了。

    此外，由于这整套体系是基于 CMM 模型的，而 CMM 模型在实际操作中的一个重要欠缺就是对项目开发中人的因素缺乏考虑，因此这套质量体系也存在这样的弱势。从实践来看，项目开发过程中最重要的就是人的管理，在这套体系是较少涉及的。

    同时，如此庞大复杂的一套体系，在执行方面也是需要较大投入的。首先，在人员方面，在公司的各个业务部门都设有较多的 QA ，负责流程的推广和引导；开发人员上岗前，都要经过为期一周左右的专门针对流程使用的 MINIProject 培训；其次，在产品开发评价上，一直是把项目的流程执行情况做为重要的一个指标进行考评的。该公司花费了相当大的人力和时间来保证此套流程的有效执行的。经过几年的流程推广，逐渐使自己的研发队伍完成了向“正规军”的转变。

    我们再看一下质量部门的组织结构。

【见下面附件图2】

其中：

    PQA ，负责产品级的重大质量保证活动和重要评审，与此对应的开发责任人是开发经理，报告对象为 QA 经理；

    SQA ，负责项目级的流程引导和质量保证活动，对应的开发责任人是软件项目经理，报告对象为 QA 经理；

    HQA ，负责硬件项目的流程引导和质量保证活动，对应的开发责任人是硬件项目经理，报告对象为 QA 经理；

    这三种角色共同对产品的不同类型的质量活动服务，共同保证产品质量。 QA 对项目组的作用，对于不熟悉流程的项目组，他们就像教练，告诉项目开发怎样做、流程怎样执行；对于已经熟悉开发流程的项目组，他们就像项目医生和过程警察，帮助项目组寻找质量问题，以及监督项目组的开发活动能按流程进行。

    一般说来，对产品的管理者来说， QA 是助手，通过他们可以看到产品开发的比较客观的情况；对项目经理和项目组成员来说， QA 是教师，帮助项目组更好地做好项目。

    IAG 组，专门负责研发组织内的质量审计活动，一般按月度进行，发现研发普遍存在的问题；

    EPG 工程过程组，负责流程的制定、新的开发工具方法的引进等，类似于 CMM5 级要求的 KPA 的内容。