CMMI-CSDN博客

CMMI是英文Capability Maturity Model Integration的缩写

CMM标准共分五个等级，从第1级到第5级分别为：初始级、可重复级、定义级、管理级和优化级
CMMI对软件企业主要有三种好处
第一、CMMI能保证软件开发的质量与进度，能对“杂乱无章、无序管理”的软件开发过程进行规范
第二、CMMI有利于成本控制。
第三、CMMI有助于提高软件开发者的职业素养。
第四、软件产品进入国际市场的通行证。

不仅可以为软件企业在国际竞争中获得一张“通行证”，更重要的是它可以给一个软件企业提供一套国际
标准的管理方法论以及对自身软件过程进行评价和改进的行动指南。
组织机构：
epg:软件工程过程组
qa质量保证组
eg软件工程组
成熟度等级是不可以跳跃的：每一个成熟度等级都为下一级的实现提供必要的基础
特殊目标(SG):管理需求，识别项目计划和与工作产品的不一致性
特殊实践(SP):管理需求变更，在项目实施期间对需求进行管理
通用目标(GG):是因为同样的目标出现在过个过程域中，每一个过程域都有一个通用目标
通用实践(GP):保证与过程相关的过程都有效可重复、可持续的行为(用来达成通用目标)

依据所采用的CMMI不同领域(采购、服务和开发),它所包括的过程域不同。下表列出在所有CMMI各领域中的过程域,这16个过程域的集合被称为CMMI核心过程域。
协助组织改进他们的绩效
缩写          名称                                                                            过程域                                   成熟度级别
CAR          因果分析和解决（Causal Analysis and Resolution）            支撑(Support)                          L5
CM            配置管理（Configuration Management）                           支撑(Support)                          L2
DAR          决策分析和解决（Decision Analysis and Resolution）          支撑(Support)                          L3
IPM           集成项目管理（Integrated Project Management）           项目管理（Project Management）   L3
MA            度量和分析（Measurement and Analysis）                       支撑(Support)                          L2
OPD          组织过程定义（Organizational Process Definition）         过程管理（Process Management）   L3
OPF           组织过程关注（Organizational Process Focus）            过程管理（Process Management）    L3
OPM          组织绩效管理（Organizational Performance Management）过程管理（Process Management）  L5
OPP           组织过程绩效（Organizational Process Performance）    过程管理（Process Management）    L4
OT            组织级的培训（Organizational Training）                      过程管理（Process Management）    L3
PMC          项目监控（Project Monitoring and Control）                项目管理（Project Management）    L2
PP             项目计划（Project Planning）                                     项目管理（Project Management）    L2
PPQA         过程和产品质量保证（Process and Product Quality Assurance）          支撑(Support)          L2
QPM          量化的项目管理（Quantitative Project Management）    项目管理（Project Management）    L4
REQM        需求管理（Requirements Management）                   项目管理（Project Management）      L2
RSKM        风险管理（Risk Management）                                项目管理（Project Management）   L3

成熟度级别
   Level 1 : 初始阶段
   不确定的工作方式
   没有固定流程、无法提供稳定环境、资源,无法估计人力,无法有效运用,经常超出项目时程和预算
   成功经验无法重复，偶而会成功、大都只靠少数有经验的人才能完成。
   Level 2:管理阶段
   建立了基本的项目管理过程。按部就班地发展系统、追踪费用、根据项目进度表来进行发展。对于相似的项目，可以重复使用以前的经验及成果。
   Level 3 : 定义阶段
   软件开发的工程活动和管理活动已标准化，且被集结成为一个组织的标准的流程资产。
   所有软件的发展和维护都在这个标准基础上制定与执行。
   Level 4 : 量化管理阶段
   对于软件开发过程和产品质量都有很好的归纳，产品成果和发展过程都可以用数量方式控制。
   可界定流程变异之特殊原因，并适当的矫正该特殊原因之症结，以防再度发生。
   强调对软件开发过程及产品质量的定量管理。
   Level 5 : 优化阶段
   经由发展过程的定量反馈机制，不断产生新的思想，并研拟新的技术来优化相关过程。
   组织及项目必须追求持续的、可度量的过程改进。包括缺陷预防、技术更新管理和流程改造管理

需求分析过程描述
1、由部门经理组建临时项目组，并指定PM(项目管理人员)、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM(项目管理人员)制定需求阶段日程表，该表须通过研发经理审核。
3、PM(项目管理人员)指示配置管理员建立配置库。
4、由PM(项目管理人员)与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表
5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。
6、PM(项目管理人员)与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。
7、项目组人员与客户进行沟通，编写需求清单列表。
8、PM(项目管理人员)组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。
   架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中
   对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则
(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，
采用讨论表决的方法选择并确定最终的技术方案。关于自行开发和采购复用的分析，

如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用；
本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购；
否则，由项目组自行开发。
   架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。
10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，
   直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。
11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。
12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。
13、PM、测试负责人与临时项目组确定项目关键参数。
     工作量、工期、日程、人数
   成本/预算（由于本公司的项目的绝大部分成本是人力成本，
   对估计成本的管理等同于估计工作量的管理，
   对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的管理。）质量目标
14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。
15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。
16、PM、测试负责人编制项目计划书。
17、PM、测试负责人编制项目日程表。
18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。
19、PM指示配置管理员建立配置基线。
20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。