cmmi认证问题，企业信用认证问题问题

中服质量认证 2022-07-08 10:34

【摘要】小编为您整理关于CMMI认证问题、CMMI中组织级QA问题、项目管理的问题（MBA、PMP、IPMP、CMMI）、实施CMM/CMMI时必须解决的认识问题、ISO9000认证问题相关iso认证公司知识，详情可查看下方正文！

关于CMMI认证问题？

CMMI分5个级别 CMMI Level 1，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。 CMMI Level 2，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。 CMMI Level 3，定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成;而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。 CMMI Level 4，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。 CMMI Level 5，优化级。在优化级水平上，企业的项目管理达到了较高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。

一般是做的。无论软件iso三体系认证还是软件项目，只要涉及软件研发的一般都会做。 cmmi全称是能力成熟度模型的集成，最初是美国国防部投资于卡耐基-梅隆大学的sei，并在一大批专家的努力下逐步形成的。最初cmm也只是运用在美国的军工软件行业。后来，聪明的美国人将这一企业公司成功的商业化了，于是cmmi进入了民营软件生产范畴。早在2000之前，cmmi就已经进入我国了。由于我们国内的软件起步太晚，急需一个指挥棒来告诉我们怎样做才是正确的。于是cmmi进入了单位科技推广部门的视野，并在全国众多
一、二级城市大力扶持cmmi认证咨询、现金补贴等优惠政策。经过了大约10年时间，国内的数千家软件企业通过了cmmi认证咨询。但多数企业实施的含金量不好。原因如下：（1）由于单位的补贴，导致小企业通过cmmi认证咨询向单位‘赚钱’（10万--100万因地区而异）。（2）毕竟cmmi是西方的思想，与我们的文化相隔有较大的差距。（3）cmmi的各个级别是要求非常高的，而我们的企业、iso三体系认证很多时候（本质上）不需要那么高的控制要求，而且即使生搬硬套cmmi的条款也只是为了应对评估而已。一旦评估通过之后，便完全跑到脑后。（4）最初cmmi的企业一般都有外部咨询师、顾问，来指导企业实施。但这些顾问的水平很糟糕。我认为，这些年咨询顾问经历了大约4代人：第一代是纯粹的英文翻译，几乎连什么是c语言都搞不清楚；第二代是混日子成长起来的‘大白兔’，他们的工作经历中几乎没有接触过软件编程。第三代是苦命的孩子，是从it民工或代码工成长起来的苦力；或者是软件企业内专门从事质量工作的打杂的‘小白兔’。他们这些人要么只知道‘编程’但不清楚理论，是实干出身，要么就是只懂理论，但却几乎没做过正经软件。第四代是应运而生的，也是社会需要的真正的专家、顾问。但我觉得以后的第五代、第六代会做的更好。就这样cmmi在强大的单位扶持下，几乎成了与iso起名的、走形式的证书了。但尽管如此，我的印象是通过cmmi认证咨询的公司肯定要强于未实施过cmmi的。一般是企业为了招、投标或其他商务、宣传方面才需要cmmi证书，这个看企业的iso三体系认证、客户类型，以及最关键的：客户需要乙方提供类似cmmi这样的证书--用来证明企业具有较高程度的软件生产能力。也有些软件企业是为了提升内部流程、管理、质量而引进cmmi模型的。而这种趋势正在变得逐渐的明显，与此同时各个地区单位的cmmi认证咨询补贴也在逐步缩水。也就是说cmmi正在发挥它应有的价值和意义。同时10多年过去了，大环境下成长起来的新一代人才--it民工及it企业，也在摸索‘咱中国自己的cmmi’。而这些工作最初在我国的军工系统软件生产组织开展，比如gjb5000/a等如果你需要了解更多，可以继续交流。

CMMI分5个级别 CMMI Level1，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。 CMMI Level2，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。 CMMI Level3，定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成;而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。 CMMI Level4，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。 CMMI Level5，优化级。在优化级水平上，企业的项目管理达到了较高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。

CMMI中组织级QA问题？

希望这些资料能对你有所帮助，我们已经过了C3认证咨询，马来西亚的主任评估师，其实主要的职责业务为：监督公司的研发流程，培训活动，过程改进活动按照已定义的流程来执行。QA的访谈一般为，也可以你作为业务的参考：QA访谈问题：
1、你是如何开展PPQA工作的？--参与项目启动会议。在项目开始时参与项目规划活动，制定QA计划-在PA结束后检查执行情况，对PMC、RSKM、CHM、CM、PPQA等过程域定期检查；对DAR、TR这些过程域是当做完决策评审及技术评审后进行检查。-审核里程碑报告-协助收集、审核项目度量数据，分析质量趋势-参加重要技术评审会议-提供QA周报，跟踪解决项目质量问题-项目结束时提供《质量总结报告》！！仔细看OSSP中的PPQA过程iso三体系认证
2、公司有没有质量管理部门？主要职责是什么？有几个专职QA人员？
3、是谁派你到项目中做QA的？QA的工作，周报/月报向谁报告？
4、 QA与EPG在项目中角色有何不同？
5、有无QA计划？QA计划的主要内容是什么？
6、 QA周报的主要内容是什么？
7、如何检查过程、iso三体系认证的符合性？-依据OSSP中PA检查单进行检查，如有NC则通报并跟踪问题的解决。
8、过程检查和iso三体系认证检查的区别在哪里？以项目规划阶段和技术评审阶段为例说明？
9、 QA是否评审项目PDP裁剪结果？评审PDP时主要检查哪些内容？
10、QA参加了哪些项目活动？1
1、项目的缺陷率是如何定义的？有没有统计缺陷率的分布情况？项目的实际质量成本是多少？1
2、NC报告是如何管理的？举例说明你处理的具体NC案例。1
3、如何检查支持组类（SAM、OT、EPG）的工作？具体说明对OT是如何审核的？1
4、你如何做CM的审计？-CM计划的检查-根据基线计划检查建立情况-检查CM是否按规程执行1
5、基线检查的重点是什么？-是否完整-正确性-版本1
6、对CM的审计与其他PA检查有哪些不同？1
7、PPQA的方针有哪些？1
8、参加过哪些PPQA方面的培训？1
9、QA工作中产生哪些工作iso三体系认证？放在哪里？20、QA检查单有无定期审核、修改？2
1、谁检查QA的工作符合性？2
2、高层如何了解QA的工作情况？有没有NC与项目组不能达成一致的情况需要高层处理协调？2
3、怎样保证度量项偏差的真实、准确？2
4、质量总结报告的主要内容是什么？2
5、怎样识别出公司CMMI方面强项和弱项？2
6、如何向EPG提交过程改进建议？-收集项目组的建议-根据QA的工作经验提出改进建议2
7、QA活动做哪些度量？2
8、关于项目度量与组织级度量工作方面QA主要做哪些工作？给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分给分

这个没有标准的，严重等级和优先级的定义都是根据你公司的实际情况定义的。具体可以问问咨询师或者参照其他公司的定义方法。

这个需要根据公司的实际情况来定的，可以先从哪些方面对公司影响比较大，比如哪个部门如果出现问题会对公司造成的影响较大，然后排定优先级。

项目管理的问题（MBA、PMP、IPMP、CMMI）？

关键看这个人牛不牛，光有一大堆MBA,PMP没P用得！

MBA 是学历，PMP是资格认证咨询这个不能比的

实施CMM/CMMI时必须解决的认识问题？

在软件工程发展的历史进程中，人们为了解决软件危机，尝试了采用诸如形式化描述语言、结构化开发方法、CASE工具、构件化开发方法等等各种解决方案，但是含金量并不那么显著，CMU SEI提出了软件过程能力成熟度模型（CMM/CMMI）基于过程的角度来解决软件危机。那么是否实施了CMM/CMMI，软件企业的开发能力就一定能提高，一定能带来经济效益呢？答案是否定的。如果企业里要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，才能保证带来经济效益，因为人员、技术和过程是支撑软件开发平台的三条腿，少了那一条都不行。大家也都知道木桶原理，一个木桶可存槠水的最大容量是由最短的那根木头决定的。在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。在开始实施CMM/CMMI时，最容易犯的一个错误就是"唯管理论"或孤立地只抓过程改善，忽略了开发技术与人员的提高，过分强调管理的作用，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改善就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，虽然也采用RUP过程、也采用ROSE等开发工具，但是仅仅是形似，没有做到真正的OO方法，没有得到OO方法的精髓，这种问题仅仅依靠过程改善是无法解决的。还有的企业开发人员的积极性很差，工作热情很低，企业的激励机制没有起到很好的作用，这种问题也是依靠CMM/CMMI无法解决的。管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心在实施CMM/CMMI时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内含金量显著，上面我们谈到了，含金量显著与否不是由一个方面的要素决定的，需要多个因素共同改善。而管理的最大作用是预防，防患于未然。任何的管理的改善都是符合J曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到含金量。所以在改善的初期大家要有这个思想准备，要有耐心。坚持活学活用，以我为主机械照搬CMM/CMMI的条文是在实施CMM/CMMI时常犯的错误。在国内的软件企业中，都是从作坊式的软件组织逐步发展过来的，也没有经过软件工程化阶段，甚至也没有什么标准、规范。真正超过10年软件工程经验的人员更是比较少的，加上大家不愿从事管理，因而有的企业所组建SEPG的人员中可能在工程经验方面是有欠缺的，又没有真正的有实践经验的专家进行指导，所以对CMM/CMMI的理解就不可能一下就很深刻，不敢裁剪CMM/CMMI，容易机械照搬CMM/CMMI条文，其实这恰恰违背了CMM/CMMI的精神，CMM/CMMI是软件工程经验的集大成，是从实践中总结出来，用以指导实践的，CMM/CMMI本身也在更新版本，不断完善。每个企业都有自己的特点，就象微软的MSF，那是微软自己内部的管理过程标准，是微软的iso三体系认证开发经验总结，有些内容是CMM/CMMI中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地来尝试。在推行CMM/CMMI时，所以遇到的阻力，很大程度上是由于照搬CMM/CMMI的条文，不切合项目组的实际，没有具体情况具体分析。实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁有发言权。所以在制定CMM/CMMI规程标准时，尤其是在制定大家要执行的操作规程、模板和记录表样时，一定要得到执行者的认同，否则就容易造成执行和沟通的障碍，你硬要推，表面上看来似乎大伙也照规程做了，其实是表面iso质量体系证书，对改善没有实际帮助，以导致SPI工作受阻。要改良式不要革命式以革命的方式来实施CMM/CMMI，期望通过一场运动来解决过程能力的问题，一种可能是不懂CMM/CMMI，不晓得管理的改进是循序渐进的，一种可能是明知故犯，期望在短期内通过CMM/CMMI评估，单纯追求市场上的轰动效应。有的企业在短时间内虽通过了CMM/CMMI几级评估，我想恐怕由于没有实效而得不到大家的认同而难以将这种"水平"持续下去。一个企业引入CMM/CMMI之后会从本质上影响企业的文化，改变大家的思想与做事方法。有人曾形象得将过程改进比喻为减肥，你是可以依靠减肥药在短时间内减轻体重，但如果不从根本上改善饮食、生活、运动的习惯，那么体重将会在短时间内恢复到原来，我认为这个比喻是十分形象的。革命的方式与改良的方式我都曾经尝试过，含金量差异很大。所以我总结一条就是让大家在"小步快跑"中接受变革，这样风险最小，含金量最好。CMM/CMMI与企业的创新文化是不矛盾的软件企业的有些管理人员，也包括一些开发人员往往抱怨或认为严格的管理会束缚他们的创新，他们认为在CMM/CMMI中提倡的一种按部就班，什么活动都要做计划、按规程标准来做，对企业的创新文化会起负面作用。在我遇到的开发人员中，越是技术钻研越深的人持这种观点的越多。我想形成这种观点主要有二个原因：一是企业在推行CMM/CMMI时，过分机械，没有从实际出发，不能与实践紧密结合，挫伤了开发人员的积极性。比如说在分析与iso认证阶段，需要开发人员能够发挥创意的成分更大一些，如果你要求他们一定就要按统一的文档标准来写文档，甚至字号大小、缩进格式一点也不能差，这的确很难做到，可能你需要在项目组配备文档支持人员，有他们来做这些完善工作，降低分析与iso认证人员的这些工作量。二是这类人员缺少真正的软件工程经验，做的大项目太少，经历的失败太少。关于这一点是不要争论的，CMM/CMMI是软件工程经验与教训的集大成，我们无需再去重复那些失败。软件企业必须形成创新的文化，事实CMM/CMMI本身也一种软件工程管理的创新，而技术创新是必须进行管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。要勇于实践，也要允许犯错误CMM/CMMI就是软件工程经验与教训的总结。在实施CMM/CMMI的过程中，肯定会走些弯路，甚至于要犯错误，由此许多人会议论纷纷，一直会反映到高层经理处，这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，现在大家都是"摸着石头过河"，不下水，是没有办法过河的，临渊慕鱼不如退而结网。要少说不，少说难，勇于实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、SEPG等人员有偏见，要提倡这种文化。管理过程改进是组织内所有人的事情，而并非仅仅是SEPG的事情按照CMM/CMMI专家的建议，在一个组织内专职从事软件过程改善的人数应为组织总人数的2-3%，根据这一建议，我们企业内一开始就配备专职的软件工程过程组（SEPG），这些员工专职负责企业的软件过程改善工作，另外我们根据需要组织一些技术任务组（TWG），他们会兼职的参与特定过程规程、标准的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题：SEPG成了最忙的人，TWG的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由SEPG的成员替代TWG做工作；