折叠 编辑本段 版本介绍软件过程改善是当前软件管理工程的核心问题， 50多年来计算机的发展使人们认识到要高效率、高质量和低成本地开发软件，必须改善软件生产过程。基于模型的过程改进是指采用能力模型来指导组织的过程改进，使之过程能力稳定的进行改善，该组织也能变得更加成熟。 CMMI的成功促使其他学科也相继开发类似的过程改进模型，例如系统工程、需求工程、人力资源、集成产品开发、软件采购等等，从CMM衍生出了一些改善模型，比如:SW-CMM,SE-CMM,IPD-CMM等。不过，在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆。CMMI就是为了解决怎么保持这些模式之间的协调。 CMMI 1.3是2010年11月SEI 发布的CMMI模型的最新版本。CMMI 1.3包括CMMI采购模型1.3版、CMMI开发模型1.3版、CMMI服务模型1.3版。 CMMI开发模型1.3版(CMMI-DEV 1.3)与CMMI开发模型1.2版相比，做了如下改进: 1)将过程域"组织级创新与部署"(Organizational Innovation and Deployment,OID)更名为"组织绩效管理"(Organizational Performance Management, OPM),并增加了一个新的特定目标与几个新的特定实践。 2)对模型架构进行了改进，简化对多个模型的使用。 过程域Process Area:过程域。简单的说就是做好一个事情的某一个方 2、3级共有18个过程域(PA),主要内容如下，分四大类: 折叠 过程管理1. OPD:(Organizational Process Definition)组织级过程定义。建立和维护有用的组织过程资产。 2. OPF:(Organizational Process Focus)组织级过程焦点。在理解现有过程强项和弱项的基础上计划和实施组织过程改善。 3. OT:(Organizational Training)组织培训管理。增加组织各级人员的技能和知识，使他们能有效地执行他们的任务。 折叠 项目管理4. PP:(Project Plan)项目计划。保证在正确的时间有正确的资源可用。为每个人员分配任务、协调人员。根据实际情况，调整项目。 5. PMC:(Project Monitoring and Control)项目监督与控制。通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。 6.SAM:(Supplier Agreement Management)供应商协议管理。旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。 7.IPM:(Integrated Project Management)集成项目管理。根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。 8. RSKM:(Risk Management)风险管理。识别潜在的问题，以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。 折叠 工程管理9.RD:(Requirement Development)需求开发。需求开发的目的在于定义系统的边界和功能、非功能需求，以便涉众(客户、最终用户)和项目组对所开发的内容达成一致。 10.REQM(Requirement Management)需求管理。需求管理的目的是在客户和软件项目之间就需要满足的需求建立和 维护一致的约定。 11.TS:(Technical Solution)技术解决方案。在开发、设计和实现满足需求的解决方案。解决方案的设计和实现等都围绕产品、产品组件和与过程有关的产品。 12.PI:(Product Integration)产品集成。从产品部件组装产品，确保集成产品功能正确并交付产品。 13.VAL:(Validation)确认。确认证明产品或产品部件在实际应用下满足应用要求。 14.VER:(Verification)验证。验证确保选定的工作产品满足需求规格。 折叠 支持管理15. CM:(Configuration Management)配置管理。建立和维护在项目的整个软件生存周期中软件项目产品的完整性 。 16.PPQA:(Process and Product Quality Assurance)过程和产品质量保证。为项目组和管理层提供项目过程和相关工作产品的客观信息。 17.MA:(Measurement and Analysis)测量与分析。开发和维持度量的能力，以便支持对管理信息的需要。作为改进、了解、控制决策。 18. DAR:(Decision Analysis and Resolution)决策分析与解决。应用正式的评估过程依据指标评估候选方案，在此基础上进行决策。 第4级除第2、3级所涵盖的18个流程领域外，增加: 19. OPP :(Organizational Process Performance)组织过程性能。建立与维护组织过程性能的量化标准，以便使用量化方式的管理项目。 20. QPM(Quantitative Project Management) 量化的项目管理，量化管理项目已定义的项目过程，以达成项目既定的质量和过程性能目标。 第5级包含第2级到第4级的20个流程领域外，增加: 21. OPM:(Organizational Performance and Management)组织的绩效与管理，选择并推展渐进创新的组织过程和技术改善，改善应是可度量的，所选择及推展的改善需支持基于组织业务目的的质量及过程执行目标。 22. CAR:(Causal Analysis and Resolution)因果分析与解决。识别缺失的原因并进行矫正，进一步的防止未来再次发生。 其他术语: Life Cycle:(Software Life Cycle Model)项目管理的生命周期。关注的是项目的过程管理。 MA:(Measurement & Analysis)。开发并持续发展度量能力以满足项目管理的信息需求。 Milestone Review:(Milestone Review)阶段评审。在阶段结束时评审项目的状态并确定项目是否应该进入下一阶段。 Process Tailoring:(Process Tailoring)过程裁剪。为了使组织定义的标准过程能够适合于组织项目管理，不论该项目是提供产品还是服务。 Review:(Review)评审。可以有效提高系统，软件及产品的质量。 Testing:软件测试。 折叠 编辑本段 发展历史折叠 CMMI的起源随着人们对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) 人力资源能力成熟度模型 为了以示区别，国内外很多资料把CMM叫做SW-CMM。按照SEI原来的计划，CMM的改进版本2.0应该在1997年11月完成，然后在取得版本2.0得实践反馈意见之后，在1999年完成准CMM2.0版本。 折叠 发展简介自从1994 年SEI正式发布软件CMM以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在: n 不能集中其不同过程改进的能力以取得更大成绩; n 要进行一些重复的培训、评估和改进活动，因而增加了许多成本; n 遇到不同模型中有一些对相同事物说法不一致，或活动不协调，甚至相抵触。 于是，希望整合不同CMM 模型的需求产生了。1997 年，美国联邦航空管理局(FAA)开发了FAA-iCMMSM(联邦航空管理局的集成CMM)，该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM 和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。CMM与CMMI最大的不同点和区别: CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即:系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。 CMMI有两种表示方法，一种是大家很熟悉的，和软件CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是:阶段式表现方法仍然把CMMI中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI中过程区域分为四大类:过程管理、项目管理、工程管理以及支持管理。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。 折叠 研发背景CMMI的成功促使其他学科也相继开发类似的过程改进模型，例如系统工程、需求工程、 人力资源、集成产品开发、软件采购等等，从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)人力资源能力成熟度模型 美国国防部办公室要求SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫的项目CMMI，原因是在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆， CMMI就是为了解决怎么保持这些模式之间的协调。 CMMI(Capability Maturity Model Integration)即能力成熟度集成模型，这是美国国防部的一个设想，他们想把所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件采购方法的改革;第二，建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。就软件而言，CMMI是SW-CMM的修订本。 它兼收了SW-CMM 2.0版C稿草案和SPA中更合理、更科学和更周密的优点。SEI在发表CMMI-SE/SW 1.0版时，宣布大约用两年的时间完成从CMM到CMMI的过渡。 CMMI项目更为工业界和政府部门提供了一个集成的产品集，其主要目的是消除不同模型之间的不一致和重复，降低基于模型改善的成本。CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。 由业界、美国政府和卡内基·梅隆大学软件工程研究所率先倡导的能力成熟度模型集成(CMMI)项目致力于帮助企业缓解这种困境。 与原有的能力成熟度模型类似，CMMI也包括了在不同领域建立有效过程的必要元素，反映了业界普遍认可的"最佳"实践;专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。在此前提下，CMMI为企业的过程构建和改进提供了指导和框架作用;同时为企业评审自己的过程提供了可参照的行业基准。 折叠 关键元素CMMI自出道以来，它所达到的目标就没有变过，第一个是质量，第二个是时间表，第三就是要用最低的成本。不过特别强调的是，CMMI不是传统的、仅局限于软件开发的生命周期，它应该被运用于更广泛的一个范畴--工程设计的生命周期。TSP的建立，也是为了支持CMMI的这样一个系统。那么CMMI究竟是什么呢?它并不是一个过程，也不是告诉你怎么去做一件事情。如果用一句话来概括什么是CMMI，它就是各个进程的一个关键的元素，在很多领域里面一个集成的点。它是这样的一个基本架构，能够用来度量你的有效性和实用性;能够找出这样的一些机会，继续改进的机会，包括在商业目标、策略还有降低项目的风险等方面。 折叠 编辑本段 评估折叠 预备工作评估实践证明:在进行CMMI评估之前，制定一个正确的评估计划并将其文档化，确保有一个富有经验的、受过培训且具有适当资格的小组能被用来评估，为执行评估过程做准备，是十分必要的。 我们所说的文档化CMMI评估计划的结果，包括:要求，协定，估价，风险，剪裁方法，以及与评估相关的实际考虑(例如:日程安排，后勤，组织的背景信息)。此外，还应当获取并记录发起方对于CMMI评估计划的正式批准。在制定评估计划之前，应对CMMI评估输入中反映出来的协议文档化，该协议将有助于CMMI评估目标和关键评估计划参数的共同理解。在对驱动计划过程的关键参数达成共同理解的基础上，CMMI评估发起方和SCAMPI主任评估师应就评估计划达成一致;发起者和评估小组领导应就已计划的评估中技术和非技术细节达成一致。这个计划在执行其他的计划和准备阶段活动中需要进一步细化。 而通过CMMI评估小组的准备工作，将产生一支富有经验的、受过培训的且定位准确的小组准备执行CMMI评估任务。该小组的成员都应当获得了完成他们各自的任务所必备的知识，或者他们之前所拥有的知识被证实足以完成相关任务。评估小组领导者已经给每一个人提供了为完成他们各自的任务所需的对技能进行实践的机会，或者证实这些技能在过去已经得到了示范。小组成员相互了解，同时开始计划他们如何协调一致的工作。还应该做到:准备好的小组是为评估目标而服务的，小组的成员已提供培训且培训结果被记录，在必要的时候，对他们所做的因知识或技能不足的补救工作已经完成。我们认为，无论CMMI评估小组领导者是从头培训一支全新的评估小组，还是通过从富有经验的小组成员中选择来组建一个小组，确保他们与CMMI评估小组领导者能组成一个成功的集体是其责任。此外，在对CMMI评估进行的预备工作的过程中，我们还应当对模型剪裁的原则有所了解: 1.在某些应用中，计划模板和例行的程序能够根据评估的需要进行调整，这和当地的过程所有权一样，有助于交流; 2.一个结构化的计划工艺组有利于只有有限的评估经验的组织，这样一个工艺就像缓和策略样，对于发现风险是一个很有价值的机会; 3.案例研究材料提供了各种各样的选择来扩充小组培训内容以增强那些更需要培训的重点; 4.富有经验的评估小组领导者在没有案例分析的情况下，同样可以管理和模拟评估行为; 5.在小组所有已获得培训成员的集合中，对小组的建立工作进行管理以确保其团队凝聚力是十分重要的，因此，很多的小组建立练习是可以利用的，小组的规模、技能、组成部分都是本方法的裁剪内容; 6.所采用工具可以包括评估计划模板，样例，和计划模板中嵌入式的程序上的帮助，此外，为了估计评估约束的影响，估算工作表和方法也是很有用处的。 总之，CMMI评估是一个十分复杂的过程，更由于其具有的不确定性，在评估的实践中，一定要做到有备无患。真理来自于实践，我们相信，随着越来越多的软件组织着手CMMI评估，越来越多的成功经验将为我们所利用和借鉴。 折叠 评估方法SEI将CMMI的评估过程分为Class A、B 、C三种类型: Class A类评估:是正式的标准过程，目的是获得评估等级，评估过程需执行所有的评估步骤 ，在CMMI标准中需要满足ARC要求 ( Appraisal Requirement for CMMI ) ，需要组建正式评估小组，并需要SEI授权的主任评估师领导评估组进行评估。根据被评估的CMMI的不同级别，评估组人数通常为4-9人，评估天数为5-10天，被评估企业派人参加ATM。评估方式为文件审查和人员访谈，评估输出物为最终评估报告，并由主任评估师向SEI注册评估结果。具体评估过程详细描述参见SCAMPI ( Standard CMMI Appraisal Method for Process Improvement) "标准的CMMI评估方法"。企业做CMMI评估并向SEI注册，都是采用本类评估。 Class B类评估:只需要满足部分的ARC要求，并可以只收集更少的信息，但必须包括从访谈方式获得的信息，不需要最终产生组织的成熟度级别，评估组的负责人既可以是SEI授权主任评估师，也可以由组织内部有经验的成员担当，可以认为是组织内部的评估过程，可以在过程改进过程中的诊断过程中使用，也可以在组织发展过程中进行阶段性评估审计时使用。 Class C类评估:是一种非正式评估过程，满足更少的ARC要求，组织快速浏览过程，只确定相对较少过程域，不需要SEI授权评估师给出组织成熟度级别。一般是针对特定少数或一个项目，或针对少数过程、或一个过程在组织中执行的情况进行评估，通常是在组织发展过程中进行。 自1991年起，CMM出现了很多模型，覆盖了各种各样的专业领域。其中著名的模型有系统工程·软件工程·软件采购·集成产品和流程开发等。然而当企业想要在组织内不同专业领域的流程改进，这些针对不同专业领域的模型在架构·内容和方法上的不同限制了组织成功实施改进的能力。此外，将这样模型在组织内部集成也提高了培训·认证和改进的费用。一套包括多个专业领域的模型加上整合的培训和认证支持将解决这些问题。 CMMI(Capability maturity model integration)是为了合并三个模型到一个框架中 Capability Maturity Model for Software (SW-CMM) v2.0 draft C, Electronic Industries Alliance Interim Standard (EIA/IS) 731 Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 正如其他CMM模型，CMMI提供了流程改进的指导，而不是流程或流程的描述。组织使用的实际流程取决于很多因素，包括应用领域·组织框架和规模。CMMI将许多经过验证的方法加入架构中，来帮组组织评价成熟度·某个软件流程的能力度，并且建立改进的优先顺序和实施改进。 从CMMI框架可以产生不同的CMMI模型，因此必须首先确定那种模型最适合企业流程改进的需要。 阶段式描述 or 连续式描述 阶段式描述:阶段式表述提供系统化与结构化的方式，一次一个阶段达到以模型为基础的过程改进。达成每一个阶段可确保有足够的过程基础建设，可作为下一个阶段过程改进的基础。过程域是以成熟度等级组织，并且对过程改进做一些推测工作。阶段式表述根据成熟度等级规定执行过程改进的顺序，它定义一个组织由初始级到已优化级的改进路径。达到每一个成熟度等级可确保有足够的过程基础建设，可作为下一个成熟度等级的基础，并且允许持续与渐进的改进。假如你不知道要选择哪一个过程开始进行改进，阶段式表述对你而言是一个好的选择。它给你一组特定的过程，针对每一个阶段进行改进。这组过程的决定，是来自于十多年过程改进的研究和经验。 连续式描述:当使用CMMI 模型进行过程改进时，连续式表述可提供最大的弹性。一个组织可以选择改进单一过程相关的问题点的绩效，或是可以使用多个领域以密切配合组织的经营目标。连续式表述也允许一个组织将不同的过程改进至不同的等级。但组织在选择上仍有一些限制，因为有一些过程域是彼此相依的。假如你知道在你的组织中需要改进的过程，以及了解CMMI 中过程域间的相依性。对你的组织而言，连续式表述是一个好的选择。 系统工程 or 软件工程 or 两者皆有 使用连续式描述可以根据企业需要选择流程改进顺序，降低企业风险，这给通过ISO做流程改进提供了一个方便的比较。使用能力度(Capability)来衡量。 阶段式描述提供了已经过验证的流程改进顺序，方便从CMM移植过来。使用成熟度(Maturity)来衡量流程改进。 系统工程包括整个系统的开发，可能包括软件也可能不包括。 软件工程用于软件系统的开发，主要集中在使用系统的·科学的·量化的方法来开发·运行·维护软件。 折叠 项目管理由美国卡内基梅隆大学的软件工程研究所(SEI)创立的CMM(Capability Maturity Model软件能力成熟度模型)认证评估，在过去的十几年中，对全球的软件产业产生了非常深远的影响。CMM共有五个等级，分别标志着软件企业能力成熟度的五个层次。从低到高，软件开发生产计划精度逐级升高，单位工程生产周期逐级缩短，单位工程成本逐级降低。据SEI统计，通过评估的软件公司对项目的估计与控制能力约提升40%到50%;生产率提高10%到20%，软件产品出错率下降超过1/3。 对一个软件企业来说，达到CMM2就基本上进入了规模开发，基本具备了一个现代化软件企业的基本架构和方法，具备了承接外包项目的能力。CMM3评估则需要对大软件集成的把握，包括整体架构的整合。一般来说，通过CMMI认证的级别越高，其越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。因此，是否能够通过CMMI认证也成为国际上衡量软件企业工程开发能力的一个重要标志。 CMMI是世界公认的软件产品进入国际市场的通行证，它不仅仅是对产品质量的认证，更是一种软件过程改善的途径。参与CMM评估的博科负责人表示，通过CMM的评估认证不是目标，它只是推动软件企业在产品的研发、生产、服务和管理上不断成熟和进步的手段，是一种持续提升和完善企业自身能力的过程。如果一家公司最终通过CMMI的评估认证，标志着该公司在质量管理的能力已经上升到一个新的高度。 折叠 编辑本段 等级1. 初始级 软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 2.可管理级 建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3. 已定义级 已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4. 量化管理级 分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。 5. 优化管理级 过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性: 每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。 能力度等级:属于连续式表述，共有六个能力度等级(0~5)，每个能力度等级对应到一个一般目标，以及一组一般执行方法和特定方法。 0 不完整级 1 已执行级 2 已管理级 3 已定义级 4 量化管理级 5 最优化级 折叠 编辑本段 实施要点折叠 基本思想1、解决软件项目过程改进难度增大问题 2、实现软件工程的并行与多学科组合 3、实现过程改进的最佳效益 折叠 源模型软件能力成熟度模型2.0版，C稿;电子行业协会临时标准(EIA/IS)731;集成产品开发能力成熟度模型(IPD-CMM)v0.98。 折叠 原则(1)、强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。 (2)、 仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。 (3)、 选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。 (4)、 过程改进要与组织的商务目标一致，与发展战略紧密结合。 折叠 目标综述 (1)为提高组织过程和管理产品开发、发布和维护的能力提供保障。 (2)帮助组织客观评价自身能力成熟度和过程域能力，为过程改进建立优先级以及执行过程改进。 初步目标 CMMI项目初步的目标(在2000年已达到，其发布的版本是CMMI-SE/SW和CMMI-SE/SW/IPPD模型)是集成三个特殊的过程改进模型:软件CMM、系统工程能力评估标准以及集成化产品和过程开发模型。 这项集成的目的是通过一种手段减少实现基于多学科模型的过程改进成本。 长期目标 CMMI项目长期的目标是为今后把其他学科(如获取过程和安全性)添加到CMMI中奠定基础。为了促进模型集成，CMMI产品开发组建立了一个自动的、可扩展的框架，其中可放入构件、培训资料构件以及评估资料。在已定义的规则控制下，更多的新学科能被加入到该框架中。 折叠 方法(1)、决定哪个CMMI模型等级最适合组织过程改进需要。 (2)、 选择模型的表示法是连续式还是阶段式。 (3)、 决定组织需要用到的模型中的知识领域。 (4)、 类似CMM提出的过程改进6步，集成化过程改进分成:开始集成过程改进,建造集成改善平台，集成传统过程，启动新过程，进行改进评估。 折叠 内容CMMI内容分为"Required"(必需的)、"Expected"(期望的)、"Informative"(提供信息的)三个级别，来衡量模型包括的质量重要性和作用。最重要的是"要求"级别，是模型和过程改进的基础。第二级别"期望"在过程改进中起到主要作用，但是某些情况不是必须的可能不会出现在成功的组织模型中。 "提供的信息"构成了模型的主要部分，为过程改进提供了有用的指导，在许多情况下他们对"必需"和"期望"的构件做了进一步说明。 "必需"的模型构件是目标，代表了过程改进想要达到的最终状态，它的实现表示了项目和过程控制已经达到了某种水平。当一个目标对应一个关键过程域，就称为"特定目标";对应整个关键过程域就称为"公用目标"。整个CMMI模型包括了54个特定目标，每个关键过程域都对应了一到四个特定目标。每个目标的描述都是非常简捷的，为了充分理解要求的目标就是扩展"期望"的构件。 "期望"的构件是方法，代表了达到目标的实践手段和补充认识。每个方法都能映射到一个目标上，当一个方法对一个目标是唯一就是"特定方法";而能适用于所有目标时就是"公用方法"。CMMI模型包括了186个特定方法，每个目标有两到七个方法对应。 CMMI包括了10种"提供的信息":目的，概括和总结了关键过程域的特定目标;介绍说明，介绍关键过程域的范围、性质和实际方法和影响等特征;引用，关键过程域之间的指向是通过引用;名字，表示了关键过程域的构件;方法和目标关系，关键过程域中方法映射到目标的关系表;注释，注释关键过程域的其他模型构件的信息来源;典型工作产品集，定义关键过程域中执行方法时候产生的工作产品;子方法，通过方法活动的分解和详细描述;学科扩充，CMMI对应学科是独立的，这里提供了对应特定学科的扩展;公用方法的详细描述，关键过程域中公用方法应用实践的详细描述。 CMMI提供了阶段式和连续式两种表示方法，但是这两种表示法在逻辑上是等价的。我们熟悉的SW-CMM软件能力成熟模型就是是阶段式的模型，SE-CMM系统工程模型是连续式模型，而IPD-CMM集成产品开发模型结合了阶段式和连续式两者的特点。 阶段式方法将模型表示为一系列"成熟度等级"阶段，每个阶段都有一组KPA指出一个组织应集中于何处以改善其组织过程，每个KPA用满足其目标的方法来描述，过程改进通过在一个特定的成熟度等级中满足所有KPA的目标而实现的。 连续式模型没有像阶段式那样的分散阶段，模型的KPA中的方法是当KPA的外部形式，并可应用于所有的KPA中，通过实现公用方法来改进过程。它不专门指出目标，而是强调方法。组织可以根据自身情况适当裁剪连续模型并以确定的KPA为改进目标。 两种表示法的差异反应了为每个能力和成熟度等级描述过程而使用的方法，他们虽然描述的机制可能不同，但是两种表示方法通过采用公用的目标和方法作为"必需"的和"期望"的模型元素，而达到了相同的改善目的。 CMMI面临的一个挑战就是创建一个单一的模型，可以从连续和阶段两个角度进行观察，包含相同的过程改进基本信息;处理相同范围的一个CMMI过程能够产生相同的结论。统一的CMMI(U-CMMI)是指产生一个只有公用方法和支持他们的KPA组成的模型。当按一种概念性的可伸展的方式编写，并产生了用于定义组织的特定目标过程模版，定义的模版构件将定义一个模型以适用于任何工程或其他方面。 折叠 工具组织在实践CMMI过程中，提升和改进研发管理能力的同时，也面临着辅助过程改进工具的挑战，缺少工具支撑，CMMI的规程、流程，尤其量化数据分析的推行成本非常高，往往使很多组织望而生畏;实践证明能够很好支撑CMMI落地的工具有:微软Project Server、IBM Rational系列工具、青铜器RDM研发管理系统、Techexcel DevSuite。CMMI工具至少要满足如下特点: 1. 以项目运作为主线条，至少包含计划进度管理、工时管理、文档管理、变更管理、风险问题管理、量化管理。 2. 强大的流程自定义能力，能够支撑不同组织根据自己的要求自定义相应的流程。 3. 量化数据收集与分析能力，能够自定义项目质量目标，根据项目质量数据自动汇总组织的能力基线;同时要有智能报表能力。 4. 知识管理能力，尤其要实现情境化知识管理，能够将项目历史实际数据直接作为知识进行分享、重用，知识管理要与操作人的行为关联。 5. 工程技术要全覆盖，至少要涵盖需求分析与需求管理、测试管理(测试计划、测试用例、测试执行)、需求跟踪管理、文档管理、评审与验证管理。 折叠 人员素质1、明白什么是有价值的积累，先是对你个人，然后才是顺便帮公司做了积累。 2、深入一线，发现她们并忠实地记录它们。CMMI里的SP、GP，只是帮助你，提醒你在哪个环节，哪些东西可能是有价值了。你去收集一下，别视而不见了。因为还有一个企业和你个人的角度不同，立场不同的问题。例如，REQM里收集需求，对个人技术方面的积累虽然不多，但对企业是至关重要的，一次需求变更，没详细写清楚，忘记了到客户那里去签字落实，可能就会给企业造成很大的损失。做为一个合格的EPG，是需要有这份责任和义务把每个环节都做到最好，这是职业道德所在。同时也是对自我延伸的一个好机会，学会一些和人的沟通，倾听，把专业的东西以平易的方式表达。这些也都算是EPG额外的收获。 通常情况下，为了按时按量完成项目，一线的骨干，对写日报、周报、文档都很不屑。EPG也很迁就，事后再补，这也不失为一个提高效率的好办法。但过去一个月半年了，我们正常人的记忆都能想象，很难记住细节。无非就是敷衍。这也在情理之中。你总不能让一个明天就要交东西的小组，今天晚上在通宵努力解决BUG的同时，还写什么报告，这也不尽人情。但作为EPG不能只把眼光集中在这妇人之心上。要想的更远。为什么会把项目推到这么晚，BUG还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素，甚至是开发人员常说的"手气问题"，"人品问题"。但这些是需要控制的，也是通过经验可以控制的，所谓艺高人胆大。艺的高低，就是经验的积累决定的。 那怎么解决这种两难的问题呢?逼着技术骨干写心得，人家没时间也的确压力很大。不写，公司又得不到有效积累，积累的都是垃圾流水。有个公司的办法和经验到可以借鉴一下: 公司内部搞了个BBS，把不同类型的工作分成不同的组，有纯技术的，JAVA组，C++组等，也有PPT组，甚至动画组，界面组。大家把自己平时的工作积累FTP上去，甚至制作方法，遇到问题和解决方法的文档都丢上去，开始怎么想，用了多少套方案，最后选择了什么。自我感觉如何。把这些心路历程都写成文档。丢到阳光下，大家评论。用点击率和"顶"的人数来说明谁写的是心得，谁在写垃圾。大家都是一个公司的，很容易实名。直接纳入考核机制中。做为一线人员，大家也有动力来写，自己的聪明才智有了展现的平台，虚荣心和荷包都得到了相应的满足。何乐而不为呢? EPG适时的评估大家的成果，并把他们分到项目里。帮助项目总结，甚至在平时遇到问题时，直接帮助技术人员做必要记录。项目进度松时，再督促项目人员完善内容。以达到对个人和公司积累的最大化。 EPG应该明白学习和积累是个终身的过程，对公司如此，对个人也是如此。CMMI是个辅助，辅助我们对公司做积累，也帮助我们个人做必要的积累。公司需要逐步走向更高的管理水平，发展平台。 折叠 实施流程阶段1:CMMI项目启动会 明确企业实施CMMI的商业目标，建立CMMI项目实施的沟通机制。 阶段2:CMMI基础培训和过程改进小组(EPG)组建 进行CMMI基础概念讲解，指导企业建立核心的过程改进小组。 阶段3:诊断 充分了解企业研发过程现状，识别企业现有软件过程与企业现阶段理应达到的CMMI成熟度级别的差距，提交诊断报告，进行过程改进的策划。 阶段4:过程域培训和文件定义 结合企业过程现状进行CMMI过程域培训，通过举例、案例分析等方式，让企业的EPG掌握过程文件定义技巧，结合企业实际情况有针对性的定义组织的研发过程，并确定过程产出物(如:需求报告) 阶段5:项目试点 选择代表公司核心业务的项目或者典型项目进行试点，通过试点来完善过程文件，从而为企业全面推广过程文件打下基础。 阶段6:组织推广 全员参与全面导入与执行CMMI。 阶段7:预评估 验证组织推广的结果，识别企业尚存缺陷并制定再次改善方案，准备充分，以便企业能够更好进行正式SCAMPI评估。 阶段8:SCAMPI A 正式评估 由SEI授权的主任评估师领导，采用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)评估方法，对企业的能力成熟度进行正式的评估，颁发证书，通过SEI网站向全球发布企业信息。 CMMI主要内容及各过程域的相互关系 CMMI 2、3级共有18个过程域(PA),主要内容如下，分四大类: 一、过程管理: 1. OPD:组织级过程定义。 2. OPF:组织级过程焦点。 3. OT:组织培训管理。 二、项目管理: 4. PP:项目计划。 5. PMC:项目监督与控制。 6. SAM:供应商协议管理。 7. IPM:集成项目管理。 8. RSKM:风险管理。 三、工程管理: 9. REQM:需求管理。 10. RD:需求开发。 11. TS:技术解决方案。 12. PI:产品集成。 13. VER:验证。 14. VAL:确认。 四、支持管理: 15. CM:配置管理。 16. PPQA:过程和产品质量保证。 17. MA:测量与分析。 18. DAR:决策分析与解决。 CMMI 4级除第2、3级所涵盖的18个过程域外，增加以下两个过程域: 19. OPP :组织过程性能。 20. QPM:量化的项目管理 。 CMMI 5级包含第2级到第4级的20个过程域外， 增加以下两个过程域: 21. OPM:组织绩效与管理。 22. CAR:因果分析与解决方案。 CMMI模型表述阶段式: 1、阶段式表述提供系统化与结构化的方式，一次一个阶段达到以模型为基础的过程改进。达成每一个阶段可确保有足够的过程基础建设，可作为下一个阶段过程改进的基础。 2、连续式:连续式表述可提供最大的弹性。一个组织可以选择改进单一过程相关的问题点的绩效，或是可以使用多个领域以密切配合组织的经营目标。 折叠 编辑本段 模型差别CMMI 模型的前身是 SW-CMM 和 SE-CMM，前者就是我们指的CMM。CMMI与SW-CMM的主要区别就是覆盖了许多领域;到目前为止包括四个下面领域: (1)软件工程(SW-CMM) 软件工程的对象是软件系统的开发活动，要求实现软件开发、运行、维护活动系统化、制度化、量化。 (2)系统工程(SE-CMM) 系统工程的对象是全套系统的开发活动，可能包括也可能不包括软件。系统工程的核心是将客户的需求、期望和约束条件转化为产品解决方案，并对解决方案的实现提供全程的支持。 (3)集成的产品和过程开发(IPPD-CMM) 集成的产品和过程开发是指在产品生命周期中，通过所有相关人员的通力合作，采用系统化的进程来更好地满足客户的需求、期望和要求。如果项目或企业选择IPPD进程，则需要选用模型中所有与IPPD相关的实践。 (4)采购(SS-CMM) 采购的内容适用于那些供应商的行为对项目的成功与否起到关键作用的项目。主要内容包括:识别并评价产品的潜在来源、确定需要采购的产品的目标供应商、监控并分析供应商的实施过程、评价供应商提供的工作产品以及对供应协议和供应关系进行适当的调整。 在以上模块中，企业可以选择软件工程，或系统工程，也可以都选择。集成的产品和过程开发和采购主要是配合软件工程和系统工程的内容使用。例如，纯软件企业可以选择CMMI中的软件工程的内容;设备制造企业可以选择系统工程和采购;集成的企业可以选择软件工程、系统工程和集成的产品和过程开发。CMMI中的大部分内容是适用各不同领域的，但是实施中会有显著的差别，因此模型中提供了"不同领域应用详解"。 CMM的基于活动的度量方法和瀑布过程的有次序的、基于活动的管理规范有非常密切的联系，更适合瀑布型的开发过程。而CMMI相对CMM更一步支持迭代开发过程和经济动机推动组织采用基于结果的方法:开发业务案例、构想和原型方案;细化后纳入基线结构、可用发布，最后定为现场版本的发布。虽然CMMI保留了基于活动的方法，它的确集成了软件产业内很多现代的最好的实践，因此它很大程度上淡化了和瀑布思想的联系。 在 CMMI 模型中在保留了CMM阶段式模式的基础上，出现了连续式模型，这样可以帮助一个组织以及这个组织的客户更加客观和全面的了解它的过程成熟度。同时，连续模型的采用可以给一个组织在进行过程改进的时候带来更大的自主性，不用再象CMM 中 一样，受到等级的严格限制。这种改进的好处是灵活性和客观性强，弱点在于由于缺乏指导，一个组织可能缺乏对关键过程域之间依赖关系的正确理解而片面的实施过程，造成一些过程成为空中楼阁，缺少其他过程的支撑。两种表现方式(连续的和阶段的)从他们所涵盖的过程区域上来说并没有不同，不同的是过程区域的组织方式以及对成熟度(能力)级别的判断方式。 CMMI 模型中比CMM 进一步强化了对需求的重视。在CMM 中，关于需求只有需求管理这一个关键过程域，也就是说，强调对有质量的需求进行管理，而如何获取需求则没有提出明确的要求。在CMMI的阶段模型中，3 级有一个独立的关键过程域叫做需求开发，提出了对如何获取优秀的需求的要求和方法。CMMI 模型对工程活动进行了一定的强化。在CMM中，只有3级中的软件产品工程和同行评审两个关键过程域是与工程过程密切相关的，而在CMMI中，则将需求开发，验证，确认，技术解决方案，产品集成这些工程过程活动都作为单独的关键过程域进行了要求，从而在实践上提出了对工程的更高要求和更具体的指导。CMMI中还强调了风险管理。不像在CMM 中把风险的管理分散在项目计划和项目跟踪与监控中进行要求，CMMI3级里单独提出了一个独立的关键过程域叫做风险管理。 折叠 编辑本段 名词术语1-20 1 AT Assessment Team 评审小组 2 ATM Assessment Team Member 评审小组成员 3 BA Baseline Assessment 基线评审 4 CAR Causal Analysis and Resolution 原因分析与决策 5 CBA CMM-Based Appraisal 基于CMM的评价 6 CBA-IPICMM-Based Appraisal for Internal Process Improvement 为内部过程改进而进行的基于CMM的评价(通常称为CMM评审) 7 CC Configuration Controller 配置管理员 8 CF Common Feature 公共特性 9 CFPS Certified Function Point Specialist 注册功能点专家 10 CI Configuration Item 配置项 11 CM Configuration Management 配置管理 12 CMM Capability Maturity Model 能力成熟度模型 13 CMMI Capability Maturity Model Integration 能力成熟度集成模型 14 COTS Commerce off the shelf 商业现货供应 15 DAR Decision Analysis and Resolution 决策分析与制定 16 DBD Database Design 数据库设计 17 DD Detailed Design 详细设计 18 DP Data Provider 数据提供者 19 DR Derived Requirement 派生需求 20 EPG Engineering Process Group 工程过程小组 21-40 21 FP Function Point 功能点 22 FPA Function Point Analysis 功能点分析 23 FR Functional Requirement 功能性需求 24 GA Gap Analysis 差距分析 25 ID Interface Design 接口设计 26 IFPUG International Function Point Users Group 国际功能点用户组织 27 IPM Integrated Project Management 集成项目管理 28 IR Interface Requirement 接口需求 29 KPA Key Process Area 关键过程域 30 KR Key Requirements 关键需求 31 LA Lead Assessor 主任评审员 32 MA Measurement and Analysis 测量与分析 33 MAT Metrics Advisory Team 度量咨询组 34 MCA Metrics Coordinator and Analyst 度量专员 35 ML matreraty library 度量数据库 36 NFR Non-functional Requirement 非功能性需求 37 OC Operational Concept 操作概念 38 OID Organizational Innovation and Deployment 组织革新与部署 39 OPD Organizational Process definition 组织过程定义 40 OPF Organizational Process focus 组织过程焦点 41-60 41 OPL Organizational Process Assets 组织过程财富 42 OPP Organaizational Process Perormance 组织过程性能 43 OSSP Organization's Set of Standard Process 组织标准过程集合 44 OT Organizational Training 组织级培训 45 PA Process Areas 过程域 46 PAT Process Action Team 过程行动小组 47 PAL Process Assets Library 过程财富库 48 PD Preliminary Design 概要设计 49 PDSP Project Defined Standard Processes 项目定义标准过程 50 PI Produce Integration 产品集成 51 PLC Product Life Cycle产品生命周期 52 PMC Project Monitoring and Control 项目监控 53 PP Project Planning 项目策划 54 PPQA Process and Product Quality Assurance 过程与产品质量保证 55 PPR Price Performance Ratio 性能价格比 56 SQA Software Quality Assurance软件质量保证 57 QA Quality Assurance 质量保证 58 QAP Software Quality Assurance Plan 质量保证计划 59 QPM Quantitative Project Management 量化项目管理 60 RD Requirements Development 需求开发 61-80 61 RM/ReqM Requirements Management 需求管理 62 RSKM Risk Management 风险管理 63 RTM Requirement Traceability Matrix 需求跟踪矩阵 64 SAM Supplier Agreement Management. 供应协议管理 65 SC Steering Committee 指导委员会 66 SCAMPI Standard CMMI Assessment Method for Process Improvement 过程改进CMMI标准评审方法 67 SCCB Software Configuration Control Board软件配置管理控制委员会 68 SCM Software Configuration Management 软件配置管理 69 SDP Software Development Plan 软件开发计划 70 SEI Software Engineering Institute (美国)软件工程学院 71 SEPG Software Engineering Process Group软件工程过程组 72 SPI Software Process Improvement软件过程改进 73 SPP Software Project Planning 软件项目策划 74 SPTO Software Project Tracking and Oversight 软件项目跟踪与监控 75 SR System Requirements 系统需求 76 SRS Software Requirement Specification软件需求规格 77 SSM Software Subcontract Management 软件分包管理 78 SSR Software System Requirement 软件系统需求 79 TS Technical Solution 技术解决方案 80 UC Use Case 用例 81-89 81 UID User Interface Design用户界面设计 82 VAL Validation 确认 83 VER Verification 验证 84 WBS Work Breakdown Structure工作分解结构 85 WP Work Products 工作产品 86 Pre-assessment 预评审 87 Baseline 基线 88 Quality Attribute 质量属性 89 Scenario 场景 折叠 编辑本段 CMMI的价值CMMI为企业带来价值主要体现在以下几个方面: 第一、能保证软件开发的质量与进度，能对"杂乱无章、无序管理"的项目开发过程进行规范。 第二、有利于成本控制。因为质量有所保证，浪费在修改、解决客户的抱怨方面的成本会降低很多。绝大多数情况是缺少规范制度，只是求快。项目完成后，要花很多时间修修补补，费用很容易失控。 第三、有助于提高软件开发者的职业素养。每一个具体参与其中的员工，无论是项目经理，还是工程师，甚至一些高层管理人的做事方法逐渐变得标准化、规范化。 第四、能够解决人员流动所带来的问题。公司通过过程改进，建立了财富库以共享经验， 而不是单纯依靠某些人员。 第五、有利于提升公司和员工绩效管理水平，以持续改进效益。通过度量和分析开发过程和产品，建立公司的效率指标。 折叠 编辑本段 区别很多初识CMMI评估的朋友都搞不清CMMI证书到底是哪里管理，是由哪个机构颁发的，什么样的证书才是正宗的，会不会有假证书，是不是也跟ISO一样都是由认证机构颁发的等等一系列的疑问。 先说ISO的管理办法:接触过ISO9001认证的朋友都知道，ISO9001是国际标准，企业可以根据自己的认可需求选择合适的认证机构，比如CQC，BSI，DNV等等这样的认证机构审核发证，而这些认证机构同时受到国家或国际等组织的监管，比如说认可机构的监管，在中国的认可机构就是CNAS，在英国的就是UKAS，美国的ANAB。就是说，企业的ISO9001证书要从认证机构发出来，而认证机构要得到认可机构的授权，这是国际通用的管理办法。另外说一下，而在中国的认可机构及在中国审核发证的国内外认证机构又是受政府监管如CNCA。就我们国家而言，你要得到一张有效的ISO证书，是要通过CNCA授权的国内外认证机构才可以审核并发证书。 CMMI评估，也有人称是CMMI认证，"认证"是国内的叫法习惯。要获得正宗的CMMI证书，是要经过主任评估师对企业的软件项目评估通过后才会颁发证书，这里要强调的是，发证书是以主任评估师的个人名义签发的，并不是由认证机构发的。而主任评估师是通过自己的努力参考SEI( Software Engineering Institute)的考试才获得资质的，有资质的主任评估师到企业去评估，评估结果符合SEI的要求才会把评估报告提交到SEI，SEI审核完评估报告后，才表明企业最终获得了有效的CMMI证书，SEI会把评估结果公布在SEI网站上供用户查询。因此，SEI是管理CMMI证书的唯一机构，SEI授权给评估师去开展评估工作。这里要说明一下，SEI本身是没有证书这个概念的，他只有注册这个概念，就是说，证书在中国才有这样的做法，对于SEI来说，SEI没有统一印发证书。 |
|
|
来自： 守山学堂 > 《630.5030 战略管理》
