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

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

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

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

    其中：

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

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

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

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

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

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

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