下载文档原格式
CMMI基础培训CMMI包括18个过程域：1评估2投标3合同评审、立项4总体计划(项目启动)5原形开发6需求分析7总体设计(概要设计)8详细设计9功能开发10代码走查11产品集成12集成测试13试运行(用户测试\上线运行)14初验15初验维护16终验17终验维护18结项报告在CMMI评级过程中，上面的18个过程域都必须提供证据，即所谓的PIID。
名词解释：PIID：Practice Instantiation Indicator Document实践的实施证据文档SR - Senior Management, PL - Project Lead, DEV - Developer, SQA, SCM. RM, SEPG随着人们对CMM研究的不断深入，其他学科也结合本系统的特点，陆续推出了自己的CMM 模型。
例如，人力资源能力成熟度模型、系统工程能力成熟度模型等等：（1）SW-CMM (Software CMM) 软件CMM（2）SE-CMM (System Engineering CMM) 系统工程CMM（3）SA-CMM (Software Acquisition CMM) 软件采购CMM（4）IPT-CMM (Integrated Product Team CMM) 集成产品群组CMM（5）P-CMM (People CMM) 人力资源能力成熟度模型CMMI三级18个过程域中属于项目管理类的过程域:A、PP\PMC\RSKM\VAL\SAMB、PP\IPM\PMC\RSKM\SAMC、RD\PP\IPM\PMC\RSKM\SAMD、REQA\PP\PMC\IPM\SAMREQM: Requirements Management（需求管理）PP: Project PlanningPMC: Project Monitoring and Control（项目监控）MA: Measurement and Analysis（度量分析）PPQA: Process and Product Quality Assurance（过程、产品质量保证）CM: Configuration ManagementRD: Requirements DevelopmentVER: Verification（文档评审、系统测试）VAL: Validation（项目验收、发布许可）TS: Technical Solution方案选择表PI: Product Integration（产品集成）OPF:Organizational Process Focus(组织过程焦点)OPD:Organizational Process Definition(组织过程定义)OT: Organizational Training(组织培训)IPM: Integrated Project Management(集成项目管理)RSKM: Risk ManagementDAR:Decision Analysis and ResolutionCMMI2级简述如果对项目的范围、规模、性质、任务、工作量、费用等都不了解的情况下，是不可能做出计划的，所以做好计划的第一步就是要把这些东西搞清楚。
对CMMI3的学习和思考【IT168 专稿】近来笔者所在公司正在为过CMMI3做各种准备，对公司的员工进行了一些相关的培训，作为项目管理人员的我，在学习CMMI3的过程中，也有了自己的一点对于CMMI3的思考。
CMMI将软件过程中的很多步骤都通过步骤规范起来，它并没有告诉我们应该怎么去做，而只是告诉我们应该做些什么。
因为软件过程中的每一步都需要经过思考、决策、有依据才能得出过程的结果，所以减少了每一步发生错误的可能性。
一．CMMI概述CMMI是Capacity Maturity Model Integrated的简称，即集成的软件能力成熟度模型，CMM是CMMI的早期版本，它主要用于软件工程，而CMMI是一种综合性模型，它是工程实施和管理方法，它在软件与系统集成以外的如科研、工程等领域都得到了广泛的应用。
CMMI是一个由理论和经验部分组成的模型。
它有连续式和阶段式两种表述方式，其中连续式主要用于衡量一个企业的项目能力，而阶段式主要用来衡量一个企业的成熟度。
在连续式表述下，企业在接受评估时可以选择自己希望评估的项目来进行评估，所以评估通过率相对比较大，但它反映的那个相对比较窄，因为它仅仅反映该企业的该项目或类似项目达到了对应的等级。
而用阶段式来进行评估时，需由评估师自己来挑选内部的任何项目或其中的某一部分来进行评估。
阶段式的CMMI有5个等级，如下：第一级（初始级）：在该等级下，项目的目标虽然得以实现，但它的实现带有很多的偶然性和风险性，该级对人员的依赖性比较大，性能依赖个人的能力，且随个人固有的性能、知识和动机的不同而变化。
第二级（受管理级）：在该等级下，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需要为过程建立明确的目标，并能实现成本、进度和质量目标等。
在这种情况下，组织已经营造了一个稳定的、受控的开发环境，项目已经在受控制的状态下运行。
该级包括如下7个过程域：需求管理（RM）、项目策划（PP）、项目监督与控制（PMC）、供方协定管理（SAM）、测量与分析（MA）、过程和产品质量保证（PPQA）和配置管理（CM）。
SW-CMM/CMMI的探讨一、引言中国进入WTO后，软件企业的国际化进程也随之加快，CMM/CMMI认证在国内的软件企业相当流行，软件企业都希望借此改进研发的开发过程，随着一些大型软件企业完成CMM认证，也为相当多的中小软件企业带来了希望。
那么CMMI 相对于人们熟悉的SW-CMM 有些什么异同？其变化的原因是什么？SW-CMM 到CMMI 的过渡是势在必行的吗？针对这些问题，本文将SW-CMM 与CMMI 从多个方面和不同的层次进行了对比，剖析了其演变的原因，探讨了其发展前景，并对于企业从SW-CMM 到CMMI 的过渡提出了切实可行的建议。
二、CMM概述1．SW-CMM的产生和发展SW-CMM（Software Capability Maturity Model,下称CMM）是由美国卡内基·梅隆（Carnegie-Mellon University）的软件工程所（Software Engineering Institute，下称SEI）提出的一套对软件过程的管理、改进和评估的模式和方法。
CMM最早被应用于美国国防部，用于评估承接军事项目的软件企业的能力。
由于这些军事项目投资巨大，需要一种科学的评估办法对软件企业进行评审，这是CMM最早期的应用。
1991年，SEI正式提出了CMM1.0版本，并应用于商业软件行业中，取得了巨大的成功。
1993年，SEI根据以往的经验，并且广泛听取了行业专家的意见，推出了CMM1.1，这就是我们现在广泛使用的版本。
十几年来，CMM的改进工作一直在持续进行着，按照SEI的计划，CMM 重复级.0版本将于1997年推出，然后经讨论和修改，于1999年发布CMM2.0。
但此版本因为美国国防部的要求而推迟发布。
2．CMM的基本概念过程（Process）：为实现给定目标所执行的一系列操作步骤。
软件过程（Software Process）：指人们用于开发和维护软件及相关产品的一系列活动、方法、实践和革新。
CMMI 22个PA缩写及主要内容关键字：CMMI,CMMI PA CMMI 22个PA缩写EPG：工程过程组（Engineering Process Group）MSG：管理指导组/高层管理组（Management Steering Group）SPI：软件过程改进（Software Process Improvement）PAT：过程行动组（Process Action Team）PA：过程域（Process Area）PP：项目策划（Project Planning）PMC：项目监控（Project Monitoring and Control）IPM：集成的项目管理（Integrated Project Management）RSKM：风险管理（Risk Management）CM：配置管理（Configuration Management）PPQA：过程和产品质量保证（Process and Product Quality Assurance）MA：度量和分析（Measurement and Analysis）DAR：决策分析和解决方案（Decision Analysis and Resolution）REQM：需求管理（Requirements Management）RD：需求开发（Requirements Development）TS：技术解决方案（Technical Solution）PI：产品集成（Product Integration）Ver：验证（Verification）Val：确认（Validation）OPF：组织过程焦点（Organization Process Focus）OPD：组织过程定义（Organization Process Definition）OT：组织培训（Organizational Training）主要内容有：1． CM：（Configuration Management）软件配置管理。
CMMI 22个PA缩写及主要内容CMMI 22个PA缩写EPG：工程过程组（Engineering Process Group）MSG：管理指导组/高层管理组（Management Steering Group）SPI：软件过程改进（Software Process Improvement）PAT：过程行动组（Process Action Team）PA：过程域（Process Area）PP：项目策划（Project Planning）PMC：项目监控（Project Monitoring and Control）IPM：集成的项目管理（Integrated Project Management）RSKM：风险管理（Risk Management）CM：配置管理（Configuration Management）PPQA：过程和产品质量保证（Process and Product Quality Assurance）MA：度量和分析（Measurement and Analysis）DAR：决策分析和解决方案（Decision Analysis and Resolution）REQM：需求管理（Requirements Management）RD：需求开发（Requirements Development）TS：技术解决方案（Technical Solution）PI：产品集成（Product Integration）Ver：验证（Verification）Val：确认（Validation）OPF：组织过程焦点（Organization Process Focus）OPD：组织过程定义（Organization Process Definition）OT：组织培训（Organizational Training）22个PA的主要内容有：1．CM：（Configuration Management）软件配置管理。
IPD集成产品开发流程IPD（Integrated Product Development）集成产品开发流程是一种全面的、协同的产品开发方法论，通过整合不同团队和部门的资源和专长，实现产品从概念到上市的全过程管理。
下面是IPD集成产品开发流程的详细介绍。
1.调研和需求分析在产品开发的初期阶段，需要进行市场调研和需求分析，了解市场的需求，并明确产品的定位和目标。
通过用户调研、竞品分析等方式，确定产品的关键特性和功能要求。
2.概念设计在确定产品的需求之后，进行概念设计。
通过原型、草图和模型等形式，对产品的外观、功能和交互进行初步设计。
概念设计是一个迭代的过程，不断优化和改进设计方案。
3.详细设计在概念设计阶段确定了产品的基本形态之后，进入详细设计阶段。
通过CAD、CAE等工具，进行产品的结构设计和工艺设计。
在详细设计阶段，需要考虑产品的制造工艺、成本、质量和可靠性等因素。
4.原型制造和测试在详细设计完成之后，制造产品的原型。
原型是对设计的验证，通过测试和评估，确保产品的功能和性能符合需求。
如果存在问题，需要对设计进行调整，并再次制作原型进行测试。
5.试制和工程验证在通过原型测试之后，进行小规模试制，并进行工程验证。
通过试制和验证，确保产品设计的可行性，并解决生产制造过程中可能遇到的问题。
6.生产制造和质量控制在试制和工程验证通过之后，进入正式的生产制造阶段。
在这个阶段，需要建立质量控制体系，确保产品的质量符合要求，并满足市场需求。
7.上市和售后服务在产品生产制造完成之后，进行上市和销售。
同时需要建立售后服务体系，及时处理用户的问题和反馈。
在IPD集成产品开发流程中，需要强调团队的协同和跨部门合作，通过有效的沟通和协调，确保各个环节的顺利进行。
同时，需要进行项目管理，对项目的进展、资源和进度进行有效管理。
此外，IPD集成产品开发流程还可以应用一些现代化的工具和技术，比如专业的项目管理软件、CAD、CAE等工具，以提高开发效率和质量。
CMMI3级18个过程域CMMI（Capability Maturity Model Integration）是一种用于评价和改进组织的软件工程能力的模型。
CMMI模型将软件工程能力分为不同的级别，目前最高级别是CMMI级别5、在CMMI模型中，共有18个过程域，每个过程域都包含一组过程目标和过程实践。
下面将介绍CMMI级别3中的18个过程域，并对每个过程域进行详细解析。
1. 要求开发（Requirements Development）：该过程域涉及确定、分析和记录系统和软件需求的活动。
它包括需求的获取、管理、分析和验证。
2. 要求管理（Requirements Management）：该过程域涉及组织和控制项目的需求。
它包括需求的识别、跟踪、控制和变更管理。
3. 项目计划和监控（Project Planning and Monitoring）：该过程域涉及制定和维护项目计划，并监控项目活动的执行。
它包括识别和规划项目活动、建立项目计划、监控项目进展和基于此进行调整。
4. 项目监控和控制（Project Monitoring and Control）：该过程域涉及监控和控制项目执行过程中的工作和活动。
它包括收集和分析项目绩效数据、对比实际和计划绩效，对项目进展进行控制。
5. 供应商协议管理（Supplier Agreement Management）：该过程域涉及与供应商达成协议，并管理和监控供应商的活动。
它包括选择供应商、与供应商协商、管理和控制供应商的交付和绩效。
6. 产品集成（Product Integration）：该过程域涉及对各个组成部分进行整合，形成最终产品。
它包括定义和实施产品集成策略、执行产品集成和验证集成后的产品。
7. 风险管理（Risk Management）：该过程域涉及识别、评估和控制项目和产品的风险。
它包括制定风险管理计划、识别和评估风险、并采取相应的风险缓解措施。
8. 决策分析和解决方案评估（Decision Analysis and Resolution）：该过程域涉及通过分析和评估不同的解决方案，制定决策。
1. CMM分哪几个成熟度等级？每个等级的名称是什么？有什么含义？2. CMMI是在什么历史条件下产生的？与CMM之间的关系是怎样的？3. CMMI有哪两种表现形式？CMMI与CMM相比，在过程域方面有什么变化？4. 什么是软件过程的改进？CMM/CMMI对于指导软件过程改进有什么意义？5. RUP的静态结构和动态结构是怎样的？静态结构由哪五种元素组成？各自代表什么？动态结构中的周期、阶段、迭代、里程碑等等之间是一种怎样的关系？6. RUP提倡的6大最佳实践是什么？怎样认识这些最佳实践？7. 什么是制品？RUP中有哪些制品集？各种典型的制品属于哪一类制品集？ 8. 什么是软件配置管理？它能解决软件开发中的哪些问题？9. 什么是开发团队中的SQA、SEPG、项目经理、软件架构师？他们的职责是什么？10 CMM有哪18个软件过程域？它们的主要活动各是什么？11. 什么是软件需求管理？在RUP中，需求规程的输出结果是什么？12. 什么是软件复杂度？怎样降低软件复杂度？13. 什么是软件危机？它的表现是什么？解决软件危机的途径是什么？14. 怎样进行软件过程评估？主要的评估手段有哪些？15. 软件开发中有哪几种典型的测试？它们各自解决什么问题？16. 什么是软件过程的可视性？怎样提高软件过程的可视性？17. 什么是软件系统架构？怎样表示架构？什么是模型？它们之间是什么关系？18. 什么是基线？有什么特点？起什么作用？19. 什么是软件过程的财富库？它有哪些组成部分？由哪一个关键过程域维护它？20.什么是用例？用例模型起什么作用？21. 软件过程的不确定性表现在哪些方面？有哪些解决办法？22. 什么是迭代开发？与顺序开发相比，它有什么优点？23. 什么是软件缺陷？怎样对缺陷进行管理？24. RUP提倡的开发周期中有哪些阶段？每个阶段的名称是什么？各自解决什么问题？评价准则是什么？2. 能力成熟度模型的基本出发点是什么？能力成熟度模型由哪些部分组成？答：能力成熟度模型是一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。
CMMI3级过程域CMMI (Capability Maturity Model Integration) 是由美国国防部发起的一种软件过程成熟度模型，它对软件和系统开发过程进行了评估和改进，旨在提高组织的软件开发能力。
CMMI 将过程分为若干级别，从初始级别到最高级别，即 CMMI5 级，每个级别由一些过程域 (Process Area, PA) 组成。
CMMI3 级是一个中间级别，对于组织来说已经达到了一定的成熟度，具备一定的过程能力。
1. 需求管理 (Requirements Management)：确保需求的准确和及时管理，包括需求的收集、分析、追踪和验证。
2. 项目计划与监控 (Project Planning and Monitoring)：制定和管理项目计划，确保项目按照计划进展，并对项目的进度、资源和风险进行监控和控制。
3. 项目质量管理 (Project Quality Management)：制定和实施项目质量计划，监控和改进项目的质量，确保交付的产品和服务符合质量要求。
4. 项目配置管理 (Project Configuration Management)：管理项目的配置项，包括版本控制、变更控制和配置项的状态管理。
5. 项目度量与分析 (Project Measurement and Analysis)：收集和分析项目数据，评估项目绩效，并通过度量和分析驱动项目改进。
6. 项目风险管理 (Project Risk Management)：在项目各个阶段识别和评估风险，制定和实施风险应对措施，以降低项目风险。
7. 项目决策与问题解决 (Project Decision and Problem Solving)：制定和实施适当的决策和问题解决方法，以支持项目的成功实施。
8. 技术解决方案 (Technical Solution)：开发和维护具有高质量且满足需求的技术解决方案，包括架构设计、系统开发和集成。
Product Integration Process产品集成过程Prepared by拟制谢建洪Date日期2011-7-9Reviewed by 评审人SEPG teamDate日期2011-7-20Approved by批准Date日期2011-12-20Revision Record 修订记录Table of Contents 目录1 P urpose 目的 (5)2 S cope 范围 (5)3 A bbreviations and Acronyms 术语和缩略语 (5)4 P olicy 方针 (5)5 P rocess Description 过程描述 (5)5.1 Roles and Responsibilities 角色和职责 (6)5.2 Entrance Criteria 入口准则 (6)5.3 Input 输入 (6)5.4 Activities 活动 (6)5.4.1 Flow Chart 流程图 (7)5.4.2 制定产品集成计划 (8)5.4.3 准备产品集成 (9)5.4.4 集成实施 (9)5.4.5 工作产品 (10)5.5 Output 输出 (10)5.6 Exit Criteria 出口准则 (10)6 R esource and Tools 资源与工具 (10)7 C onfiguration Management and Assets 配置管理和资产 (10)8 T raining 培训 (10)9 P rocess Measurement 过程度量 (10)10 Tailoring Guidelines 裁剪指南 (11)11 技能要求 1012 Verification 验证 (12)13 Related Process 相关过程 12 1Table List 表目录表1术语与缩略语 (5)Figure List 图目录图1产品集成流程图 (8)1Purpose 目的为确保创维数字技术有限公司（以下简称创维数字）在软件开发项目中的工作产品质量稳定，对产品集成过程进行规范化描述，特制定本文档。
“产品集成”过程是把产品构件组装成产品，确保所集成的产品恰当地发挥作用，确保交付产品正确运行。
2Scope 范围本文档定义了在软件开发工作中对产品集成进行管理的标准流程。
产品集成是指把产品组件组装为更加复杂的产品组件或完整的产品，包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。
本文档的读者为项目组所有相关人员。
3 Abbreviations and Acronyms 术语和缩略语表1术语与缩略语4 Policy 方针1、集成必须要首先确定好模块需求和顺序；2、集成的环境必须要干净；3、需要集成的文件不能够有中间文件。
5Process Description 过程描述5.1 Roles and Responsibilities 角色和职责5.2 Entrance Criteria 入口准则可集成的产品构件开发完成、外部构件准备到位5.3 Input 输入 《需求规格说明书》。
《软件设计说明书》或《软件详细设计说明书》。
“产品构件及其说明资料”5.4 Activities 活动建立产品集成方案制订详细的产品集成规程审核执行测试打包交付产品或产品构审核 检查 检查 核查集成的产品构件 支持 审核 集成 测试 集成产品构件 提供 提供 确认集成用的产品构件 审核 管理 管理接口审核 审查 审查接口描述的完备性 支持 建立 测试 建立产品集成环境 评审 支持 审核 支持 理解 管理 制订 制定详细的产品集成规评审 支持 审核 理解 理解 管理 建立 建立集成产品方案 技术管理委员产品线 项目经理 开发小组 测试小组 配置管理小组设计小组 活动/角色建立产品集成环境审查接口的完备性管理接口5.4.1Flow Chart 流程图图1产品集成流程图5.4.2制定产品集成计划PM根据项目计划制定产品集成计划。
集成计划描述了模块集成的顺序、软件环境、硬件环境、测试环境和资源需求，所采用的集成方法等，并输出到《产品集成计划》模板中。
产品集成需要有项目组指定专人负责，由PM指定专人集成。
5.4.3准备产品集成5.4.3.1建立集成环境集成前建立编译、集成的环境，包括硬件环境、网络环境、软件环境（如：Linux、UCOS等），确认关键系统的版本（如：STM、依赖库等）。
必须确保集成用的机器是干净的机器，即不安装与编译、集成无关的程序。
如果项目有特殊的要求，可以在项目计划中给予明确。
5.4.3.2确定集成规程集成时机：一般单元测试阶段完成后，就可以开始做产品集成。
集成频率：在条件允许的情况下，建议项目组每天集成或者每几天集成一次，或者在项目进入集成测试阶段每天集成多次。
集成时间：集成时间需要统一规定。
例如项目组可以规定某天下午15:00打包，15:00前每个开发人员必须提交所有源码以供集成。
确定将要集成的关键模块，集成的顺序，集成的方法，需要测试的接口、集成验证的规程等。
从配置库中获取正确的待集成文件之前，CMO必须取消开发人员在配置库“写”的操作权限。
注意编译的中间产物不能放入配置库中，如obj文件等，避免导致编译工具发现已经有编译好的中间文件，不再重新编译生成新的文件。
5.4.3.3准备待集成的文件在集成前，开发人员在单元测试完成后将各自的最新源代码、外部依赖库文件和产品集成注意事项提交到配置库。
CMO取消开发人员在配置库“写”的操作权限。
5.4.4集成实施1.集成负责人必须从配置库中获取正确的待集成文件及版本到集成指定机器；2.集成负责人使用编译、集成工具进行编译、集成，并根据集成验证规程检查编译、集成是否通过；3.若集成通过：集成负责人将集成通过的包，部署至指定的测试机器上；并将集成后的包提交到配置库，集成结束。
4.若集成不通过：（1）集成负责人同时通知开发人员来修改源代码或补提交源代码；（2）开发人员在完成代码修改或补提交后，通知集成负责人再次集成，跳至1执行；（3）如果因其它原因无法在当天完成代码的修改或补提交，若经项目经理同意这部分代码不用集成，则由开发人员来通知集成负责人再次集成，跳至第1步执行。
5.集成负责人将本次集成的情况记录在《产品集成计划》。
6.集成过程中，项目经理应定期检查集成环境是否符合规定的要求。
7.项目结项，集成负责人应将该项目的集成环境给予清除。
5.4.5工作产品打包集成的EXE文件、JAR文件、WAR、lib文件等等。
5.5 Output 输出集成后的产品或产品组件。
《产品集成计划》。
5.6 Exit Criteria 出口准则产品或产品组件集成完毕并核查通过。
6 Resource and Tools 资源与工具项目经理协调并提供产品集成所需的资源和工具，例如电脑、办公环境，工具和软件等以及与外部的协调。
7 Configuration Management and Assets 配置管理和资产产品集成过程中所有的输出都要纳入到配置库或者资产库中进行管理。
8 Training 培训参与产品集成相关人员，应具备相应的能力、技术和对本过程的理解与掌握，若掌握，则可免修，否则，高层经理需为其安排有关培训。
9 Process Measurement 过程度量参与产品集成的人数；集成的产品构件数；产品集成时间；集成测试时间集成测试BUG数据；集成测试BUG率；10 Tailoring Guidelines 裁剪指南项目经理可以根据项目的实际情况裁剪或简化上述活动。
11技能要求设计小组–熟悉通用的设计与开发技术；–熟悉公司技术力量和产品积累；–熟悉建模工具的操作使用开发小组–具有识别“标准设计表示方法”的能力；–精通实现“产品构件”的开发工具–熟悉文档编辑工具；–熟悉产品安装及维护流程；–熟悉产品的使用方法和技巧测试小组–熟悉通用的测试方法；–熟悉通用的测试工具项目经理–熟悉项目管理；–熟悉客户行业的业务知识；–精通通用的设计与开发技术；–熟悉公司技术力量和产品积累；–熟悉需求开发及分析方法；–熟悉办公软件的操作使用；–熟悉建模工具的操作使用。
12 Verification 验证用户对集成后的产品进行接收验证。
QA定期评审项目跟踪和监控的活动和工作产品，对里程碑处的审计活动和工作产品进行评审和审计，并报告其结果，具体流程参见质量保证过程定义。
13 Related Process 相关过程《设计过程》《需求开发与管理》《产品与过程质量保证》《交付与维护》14 Reference Materials 参考文献软件工程规范；公司事务性工作流程；软件能力成熟度模型（CMMI-SE/SW）；IT项目管理；GB/T 11457 软件工程术语；GB 8566 计算机软件开发规范；GB 8567 计算机软件产品开发文件编制指南。
