有人参加过CMMI的吗？

rice715

不知道有没有参加过CMMI的？

各位兄台多多指教啊

总是觉得这个东西好抽象

谁能告诉我过这个东西的整个的流程？sdlkfj9

yolanda22

前段时间刚结束了cmmi3级的认证
网上有很多资料的
主要是一些过程域

cjycjy11

CMMI对工作流程的制度化的质量体系，关注知识积累和过程改进。
核心是计划和监控、度量和改进。
在实际工作中去感受吧。

我爱测试

这个东西的过程是:编制过程域,然后进行试点,再进行推广,最后进行评估
在这中间注意反馈的收集,不断优化过程,使之适应公司流程.
同时为公司制订出质量体系,规范等.建立财富库,提取最佳实践.

Jeongspear

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

nan3937

前段时间公司过了ISO，过几个月就要过CMMI5了。我不是做QA的，但是感觉是对CMMI这类质量评定感觉就是文档化。内部Audit的感觉也是查你每一部是不是有记录。

huaibaobao

标签：        cmmi 项目研发 项目管理 亚远景


来源：www.cmmcn.com
基于基线化的迭代开发和风险管理策略
亚远景科技项目研发管理专题系列（1）
作者：杨俊  庞丽
IPMS（Integrated Project Management System），是一个为上海贝尔阿尔卡特某移动事业部门定制化开发的多系统集成项目管理系统，其目标是通过对该部门整个开发管理工具环境的集成来达到对项目的实时跟踪和管理，以及数据的采集和度量。然而，一个客观事实是，国内大量的中小型项目中的绝大多数都存在着需求不明确性的问题，伴随而来的是大量需求变更所带来的开发风险。那么面对这样的客观事实，是否意味着项目经理根本无法应对这样的问题呢？真正优秀的项目经理又会如何挑战需求不明确和需求变更所带来的开发风险呢？
[案例背景]
背景描述1: 随着阿尔卡特与朗讯科技的合并，该移动事业部门也将与原两家公司的多个部门进行合并。合并后的新部门将采用全新的产品线定义，并实施新的项目管理流程。在这样的情况下，以前的IPMS系统已经无法满足该事业部门对项目的流程管理，IPMS系统三期开发势在必行。
背景描述2: IPMS系统作为一个集成化的管理系统与众多功能强大的软件系统集成，其中包括ClearQuest，一个强大的事务状态管理软件。原先IPMS与ClearQuest通过一组ClearQuest软件预先定义的API进行数据通讯。
[提出问题]
由于合并的时间过于仓促，以及部门之间的项目数据定义和管理流程的不同，导致IPMS三期开发的需求极不明确，整合后的新部门内部还在为部门的项目管理的流程定义和系统可能的功能修改争论不休，在这样的情况下，项目进展十分缓慢。
IPMS三期的第一个迭代中有这样一个非功能性需求，即ClearQuest的版本升级，随之而来的一个风险便是，伴随着ClearQuest的版本升级，没有人知道原版本中与IPMS数据通讯的API接口是否可以向下兼容。
[解决方案]
　1．基于现实的问题，即该事业部门确实无法在很短的时间内协调和构思出统一的系统需求，以及部门希望尽快将部分功能使用起来的愿望，项目组采取了基于需求基线化管理的迭代开发。项目组采用了合适的开发步骤，首先基于目前的需求不稳定性项目组决定了以一个月为开发的迭代周期；然后在策划期提取出一组客户的高端需求，通过对需求的简要分析和工作量估算，并依据一组参数（比如重要性，紧急程度和需求的稳定程度）规划出一个月内（一次迭代期）的项目需求；对这些需求建立基线，一旦需求的基线确立，那么在这个迭代周期内的需求应该是稳定的；最后项目组在一个迭代周期内，通过依据CMMI的流程对系统进行三期开发。
通过这样的方式，能够尽可能的降低需求不明确所带来的开发风险，增强需求的可管理性，但是如果在迭代内部发生了需求的变更又该如何处理呢？
2．项目组通过对风险可能的发生时间点和阀值的控制，来管理风险的危机。
项目组首先识别出了ClearQuest升级后的API兼容性风险；同时，通过讨论，项目组确定了这个风险可能转化为问题的时间点，即一旦完成三期对项目注册功能的修改后，必须在测试时确定IPMS中注册的项目数据是否可以正确的被保存入ClearQuest中，我们可称那个时间点为A时间点；当项目的开发活动快到达A时间点之前，项目组安排人力对新版本ClearQuest中的相同API进行了简单的功能原型测试，测试结果表明确实存在兼容性问题；项目组立刻决定修改项目计划，并在原先的风险预留的时间段内增加了对API兼容性问题的处理事务，从而解决了ClearQuest版本升级可能导致的系统无法正常注册项目的重大问题，使得项目得以平稳开发。
[案例评析]
在软件项目开发过程中，对于开发模型的选择，需要在项目定义过程中明确。CMMI V1.2 For dev中，过程域IPM的SP1.1 Establish the Project’s Defined Process有明确要求。在上述案例中，提到的迭代式开发模型为众多开发模型中的一种，而在项目中具体要使用哪种模型可从组织项目定义过程中进行选择。软件开发模型通常有以下几种：瀑布型，迭代型，原型等，具体选择何种，需要视项目的特点而定；上述案例的主要特点是需求的不稳定性，选择迭代式开发模型无疑是一种较好的选择。可以看到，上文中有提到“基线化”一词，有实施CMMI的企业或参加过CMMI过程改进活动的个人对这个词一定不陌生。CMMI模型中，要求对过程的产出物进行配置管理。过程域CM中，SP1.3 Create or release baselines 要求建立并发布基线。基线是经过评审并通过的一系列产出物，基线建立以后，后续的开发工作需以此作为基础。上述案例中，之所以提出基线化一词，意在强调阶段性地需求需要经过评审并确定之后，以此指导后续开发工作。此外，越来越多的人关注软件项目开发过程中风险管理环节。风险管理过程是用于识别潜在的问题，并策划应对策略，在需要时实施相应动作以消除不利影响。在CMMI模型中，有专门一个PA对风险管理进行描述和要求。上述案例中，正是识别到由于ClearQuest升级而带来的API不兼容性风险，并针对于风险采取了利用阀值控制等措施。软件开发过程中，我们会遇到各种各样的风险，而且这些风险一旦发生，会给项目的顺利进行带来严重威胁，因此在项目计划时，就要制定一个严密的风险管理计划，并且对于风险情况进行严格的跟踪，这样才可能把风险对项目所带来的影响降低，至最小。
[有关亚远景团队]
　　　亚远景科技有限公司不仅具有经验丰富，兢兢业业工作的咨询团队，在企业中更存在一股强大的开发力量。在进行软件开发过程中，开发人员经常会遇到各种各样的非具体技术解决上的有关流程等问题向咨询顾问寻求解决方案，这样，既可以保证软件开发项目的顺利进行，也方便咨询顾问进一步了解当前软件开发的一切相关问题，从而达到互助互利，共同进步的目的，其工作模式在业界受到广泛好评与一致认可。