CMMI
CMMI
早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI 在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。
目录
展开
简介
CMMI 的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。
CMMI家族包括CMMI for Development, CMMI for Service和CMMI for Acquisition三个套装产品。
CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型
自从1994 年SEI 正式发布软件CMM 以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在：n 不能集中其不同过程改进的能力以取得更大成绩；
n 要进行一些重复的培训、评估和改进活动，因而增加了许多成本；
n 遇到不同模型中有一些对相同事物说法不一致，或活动不协调，甚至相抵触。
于是，希望整合不同CMM 模型的需求产生了。1997 年，美国联邦航空管理局（FAA）开发了FAA-iCMMSM（联邦航空管理局的集成CMM），该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。
CMMI 与CMM 最大的不同点在于：CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。
CMMI 有两种表示方法，一种是大家很熟悉的，和软件CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续
式表现方法则通过将CMMI 中过程区域分为四大类：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。[1]
。
编辑本段评估
预备工作
评估实践证明：在进行CMMI评估之前，制定一个正确的评估计划并将其文档化，确保有一个富有经验的、受过培训且具有适当资格的小组能被用来评估，为执行评估过程做准备，是十分必要的。
我们所说的文档化CMMI评估计划的结果，包括：要求，协定，估价，风险，剪裁方法，以及与评估相关的实际考虑（例如：日程安排，后勤，组织的背景信息）。此外，还应当获取并记录发起方对于CMMI评估计划的正式批准。在制定评估计划之前，应对CMMI评估输入中反映出来的协议文档化，该协议将有助于CMMI评估目标和关键评估计划参数的共同理解。在对驱动计划过程的关键参数达成共同理解的基础上，CMMI评估发起方和SCAMPI主任评估师应就评估计划达成一致；发起者和评估小组领导应就已计划的评估中技术和非技术细节达成一致。这个计划在执行其他的计划和准备阶段活动中需要进一步细化。
而通过CMMI评估小组的准备工作，将产生一支富有经验的、受过培训的且定位准确的小组准备执行CMMI评估任务。该小组的成员都应当获得了完成他们各自的任务所必备的知识，或者他们之前所拥有的知识被证实足以完成相关任务。评估小组领导者已经给每一个人提供了为完成他们各自的任务所需的对技能进行实践的机会，或者证实这些技能在过去已经得到了示范。小组成员相互了解，同时开始计划他们如何协调一致的工作。还应该做到：准备好的小组是为评估目标而服务的，小组的成员已提供培训且培训结果被记录，在必要的时候，对他们所做的因知识或技能不足的补救工作已经完成。我们认为，无论CMMI评估小组领导者是从头培训一支全新的评估小组，还是通过从富有经验的小组成员中选择来组建一个小组，确保他们与CMMI评估小组领导者能组成一个成功的集体是其责任。此外，在对CMMI评估进行的预备工作的过程中，我们还应当对模型剪裁的原则有所了解：
1.在某些应用中，计划模板和例行的程序能够根据评估的需要进行调整，这和当地的过程所有权一样，有助于交流；
2.一个结构化的计划工艺组有利于只有有限的评估经验的组织，这样
一个工艺就像缓和策略样，对于发现风险是一个很有价值的机会；
3.案例研究材料提供了各种各样的选择来扩充小组培训内容以增强那
些更需要培训的重点；
4.富有经验的评估小组领导者在没有案例分析的情况下，同样可以管
理和模拟评估行为；
5.在小组所有已获得培训成员的集合中，对小组的建立工作进行管理
以确保其团队凝聚力是十分重要的，因此，很多的小组建立练习是可以利
用的，小组的规模、技能、组成部分都是本方法的裁剪内容；
6.所采用工具可以包括评估计划模板，样例，和计划模板中嵌入式的
程序上的帮助，此外，为了估计评估约束的影响，估算工作表和方法也是
很有用处的。
总之，CMMI评估是一个十分复杂的过程，更由于其具有的不确定性，
在评估的实践中，一定要做到有备无患。真理来自于实践，我们相信，随
着越来越多的软件组织着手CMMI评估，越来越多的成功经验将为我们所利
用和借鉴。
评估方法
自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 连续式描述
系统工程 or 软件工程 or 两者皆有
使用连续式描述可以根据企业需要选择流程改进顺序，降低企业风险，这给通过ISO做流程改进提供了一个方便的比较。使用能力度(Capability)来衡量。
阶段式描述提供了已经过验证的流程改进顺序，方便从CMM移植过来。使用成熟度(Maturity)来衡量流程改进。
系统工程包括整个系统的开发，可能包括软件也可能不包括。
软件工程用于软件系统的开发，主要集中在使用系统的·科学的·量化的方法来开发·运行·维护软件。
cmm是项目管理
由美国卡内基梅隆大学的软件工程研究所(SEI)创立的
CMM(Capability Maturity Model 软件能力成熟度模型)认证评估，在过去的十几年中，对全球的软件产业产生了非常深远的影响。CMM共有五个等级，分别标志着软件企业能力成熟度的五个层次。从低到高，软件开发生产计划精度逐级升高，单位工程生产周期逐级缩短，单位工程成本逐级降低。据SEI统计，通过评估的软件公司对项目的估计与控制能力约提升40%到50%；生产率提高10%到20%，软件产品出错率下降超过1/3。
对一个软件企业来说，达到CMM2就基本上进入了规模开发，基本具备了一个现代化软件企业的基本架构和方法，具备了承接外包项目的能力。CMM3评估则需要对大软件集成的把握，包括整体架构的整合。一般来说，通过CMM认证的级别越高，其越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。因此，是否能够通过CMM认证也成为国际上衡量软件企业工程开发能力的一个重要标志。
CMM是目前世界公认的软件产品进入国际市场的通行证，它不仅仅是对产品质量的认证，更是一种软件过程改善的途径。参与CMM评估的博科负责人表示，通过CMM的评估认证不是目标，它只是推动软件企业在产品的研发、生产、服务和管理上不断成熟和进步的手段，是一种持续提升和完善企业自身能力的过程。如果一家公司最终通过CMMI的评估认证，标志着该公司在质量管理的能力已经上升到一个新的高度。
编辑本段等级
1．初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
2．可重复级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
3．已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
4．量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
5．优化管理级
过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性：
每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。
能力度等级：属于连续式表述，共有六个能力度等级(0~5)，每个能力度等级对应到一个一般目标，以及一组一般执行方法和特定方法。
0 不完整级
1 执行级
2 管理级
3 定义级
4 量化管理级
5 最佳化级
编辑本段评估方式
自我评估：用于本企业领导层评价公司自身的软件能力。
主任评估：使本企业领导层评价公司自身的软件能力，向外宣布自己企业的软件能力
CMMI的评估类型：
软件组织的关于具体的软件过程能力的评估。
软件组织整体软件能力的评估（软件能力成熟度等级评估）。
编辑本段CMMI的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益
编辑本段研发背景
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版本。
但是，美国国防部办公室要求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为企业的过程构建和改进提供了指导和框架作用；同时为企业评审自己的过程提供了可参照的行业基准。
编辑本段源模型
软件能力成熟度模型2.0版，C稿；电子行业协会临时标准（EIA/IS）731；集成产品开发能力成熟度模型（IPD-CMM）v0.98。
编辑本段原则
（1）、强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。
（2）、仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。
（3）、选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。
（4）、过程改进要与组织的商务目标一致，与发展战略紧密结合。
编辑本段目标
（1）、为提高组织过程和管理产品开发、发布和维护能力提供保障。
（2）、帮助组织客观评价自身能力成熟度和过程域能力，为过程改进建立优先级以及执行过程改进。
编辑本段方法
（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组成的模型。当按一种概念性的可伸展的方式编写，并产生了用于定义组织的特定目标过程模版，定义的模版构件将定义一个模型以适用于任何工程或其他方面。
编辑本段与CMM差别
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 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-IPI
CMM-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 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 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 PB 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 QA Software Quality Assurance 软件质量保证
57 QA Quality Assurance 质量保证
58 QAP Software Quality Assurance Plan 质量保证计划
59 QPM Quantitative Project Management 量化项目管理
60 RD Requirements Development 需求开发
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 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了，大体做法
1、决定实施CMMI
2、EPG接受培训，理解CMMI
3、EPG根据自己理解的CMMI和实际情况开发一大堆漂漂亮亮的过程文档、流程图、表格、模板、检查单、作业指南。
4、大家边听着EPG的解释(包括培训、答疑)，边执行这些过程标准，然后审计(内、外)
将目前的最佳实践记录下来、写下来、文档化下来。
很多新的EPG在做了一段时间后无奈的发现自己居然沦落成了一个过程标准解说员、甚至文档管理员。自己工作大部分时间是面对文档，或者督促别人写文档
EPG最主要的工作应该深入到研发第一线，帮助研发人员解决研发过程中面临的最严重的实际问题(当然是解决方案要上升到过程高度，而不应是单个问题或个人)，甚至哪怕是一些不严重但以你的项目经验知道该如何解决的问题上。总体说来就是掌握项目进展中的任何细微的技术难点要点，并主动记录下来。
为什么这么说呢?CMMI实施的主要宗旨就是以每个项目为采集数据的
源头，达到企业整体效益提升和资源重用。真正有价值的东西，是需要一线人员在实际工作中遇到问题，解决问题，并总结问题，不是一个一线工作的流水帐。就象一份研发人员的日报。写了上午做什么，下午做什么。这对企业的积累有什么用处呢?他工作过程中，遇到什么问题，他是怎么解决的，走过什么弯路，实验过几种方法，失败了，失败的原因是什么，最后选择了什么方法，可能不是最好的，但完成了任务，达到了效率和资源分配的平衡。这些东西才可能是未来类似项目中，遇到类似问题时，可能有参考价值的。通常也是EPG个人职业生涯的技术积累。只有公司里每个员工，把自己认为最有价值的积累贡献出来。才可能达到公司有价值的积累。而决不是形式上写的上午下午每个小时的流水帐。
编辑本段人员素质
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正式评估
由SEI授权的主任评估师领导，采用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)评估方法，对企业的能力成熟度进行正式的评估，颁发证书，通过SEI网站向全球发布企业信息。
由TMMi 基金会编写 测试成熟度模型集成专业人士资格认证测试成熟度模型培训大纲 发布V1.1 版本 编辑: Erik van Veenendaal 版权通告 受限于版权条款的不限制分发 爱尔兰TMMi 基金会版权所有
本TMMi基金会资料按照现有的状况来提供。 TMMi基金会未就任何事项作出任何形式的担保，无论明示的或暗示的，包括但不限于适用性或适销性担保、排他性担保、或使用本资料所获得结果的担保。TMMi基金会未就不存在专利、商标或版权侵权作出任何形式的担保。 本文档中对任何商标的使用，并非有意以任何方式侵犯商标所有人的权利。允许为内部使用而复制本文档及制作本文档的衍生品，但所有复制品及衍生品中需包含版权及“非担保”声明。为外部及商业使用而复制本文档或制作本文档衍生品的，应向TMMi基金会请求允许。 下列注册商标和服务标志在 TMMi 基金会的文档中被用到：CMMI?, TMMi?. CMMI 是由卡内基梅隆大学在美国专利与商标局注册。 TMMi?是 TMMi 基金会的注册商标。 贡献者 Andrew Goslin (UK) Klaus Olsen (Denmark) Meile Posthuma (The Netherlands) Geoff Thompson (UK) Erik van Veenendaal (The Netherlands) Brian Wells (UK)
版本修改 这一节仅供参考
Table of Contents 1 简介 (4) 1.1文档目的 (4) 1.2测试成熟度模型集成专业人士资格认证 (4) 1.3 TMMi 评估师 (4) 1.4 业务价值 (5) 1.5详细程度 (5) 1.6资料来源 (5) 2.学习目标 (6) 2.1学习认知级别 (6) 2.2 学习目标 (7) 2.2.1 测试改进的背景 (7) 2.2.2 TMMi模型概述 (7) 2.2.3 TMMi成熟度级别 (8) 2.2.4 TMMi的结构 (8) 2.2.5 TMMi模型 (8) 2.2.6 TMMi的评估 (9) 2.2.7 TMMi的实施 (9) 3. 认证考试 (11) 3.1 考试结构 (11) 3.2 考题分布 (11) 4. 培训机构 (12)
测试成熟度模型集成Test Maturity Model Integration （TMMI）
目录 1 测试成熟度模型集成（TMMI） (4) 1.1 介绍 (4) 1.2 背景和历史 (4) 1.3 起源 (5) 1.4 TMMI的领域 (6) 1.4.1 软件和系统工程 (6) 1.4.2 测试级别 (6) 1.4.3 TMMI和CMMI (6) 1.4.4 评定 (6) 1.4.5 改善的方法 (7) 2 TMMI成熟度水平 (7) 2.1 概述 (7) 2.2 级别1 初始的 (8) 2.3 级别2 可管理的 (9) 2.4 级别3 可定义的 (9) 2.5 级别4 可测量的 (10) 2.6 级别5 可优化的 (11) 3 TMMI的结构 (12) 3.1 必需的，可预料的和提供信息的组件 (12) 3.1.1 必需的组件 (12) 3.1.2 期望的组件 (12) 3.1.3 信息组件 (13) 3.2 TMMI的组件 (13) 3.2.1 成熟度级别 (13) 3.2.2 过程域 (13) 3.2.3 目标 (14) 3.2.4 介绍性说明 (14) 3.2.5 范围 (14) 3.2.6 特定目标 (14) 3.2.7 通用目标 (14) 3.2.8 特定的实践 (14) 3.2.9 典型工作产品 (15) 3.2.10 子实践 (15) 3.2.11 通用实践 (15) 3.2.12 通用实践细节 (15) 3.2.13 支持性信息组件 (15) 3.3 通用目标和通用实践 (16) 3.3.1 GG 2 制度化可管理过程 (17) 3.3.2 GG 3 制度化已定义的过程 (19) 3.4 对通用实践过程域的支持 (20) 3.4.1 GP2.2计划过程 (20) 3.4.2 GP2.5培训人员 (20)
容器安全成熟度模型 虽然越来越多的企业开始采用容器化的云原生应用，但传统的安全措施却无力应对新技术发展带来的挑战。当下云原生虽说异常火热，却没有一个清晰的路线图，能够指明在容器化过程中，各个阶段该如何做好安全。由于容器化的每个阶段都会带来新的安全挑战，企业必须在做好基础架构的同时，确保每个阶段的安全。可以预见，从第一个容器化应用开发到管理数千个容器过程中，安全需求也在不断变化。 容器安全成熟度模型，旨在帮助企业在采用容器和容器扩容过程中能够更好理解并成功应对所产生的各类安全挑战。 01 一、引言
无论应用是在容器中运行，还是在虚拟机、主机上运行，发生安全事件的后果都是相同的。此外，在安全事件发生后，无论打多少补丁，也无法挽回已泄露的敏感数据。据调查报告《2020年容器与Kubernetes安全状况》显示，94％的受访者表示，在过去12个月中发生了容器安全事件。 在过去12个月中遭遇过容器安全问题类型和比例 在很多情况下，企业并不完全了解容器化架构所面临的安全挑战，更不用说如何主动应对这些挑战。这时，常见的做法就是将之前的安全策略应用到容器中来，但这并不一定适合新的应用体系架构和开发工作流程。总得来说，就是容器使用率不断提高，但安全总是落后一步。 下文将针对容器安全成熟度模型进行详细解释，旨在帮助企业更好了解需要部署哪些重要工具，采取哪些措施，来满足当前和未来容器安全需求。 二、容器安全成熟度模型
第1阶段：实验学习 在这个阶段，主要是开发人员自己学习如何在机器上使用容器。例如，通过一些不进入生产系统的项目做练习。在这一阶段，所涉及的应用大多是一些基本应用。 这阶段可能持续数月之久。由于只有个别开发人员在学习和测试容器，因此只要项目不是用于生产，就不需要专用的安全工具，也不需要改变以往安全策略。与往常一样，开发人员只需确保安全编码。但是，这个阶段安全也是声明式的和自动化的，是开发工作流程的一部分，而不是在完成应用构建后才解决安全问题。 虽说，在该阶段安全并不太重要，也不会犯什么错误。但是，如果组织机构打算扩展容器化项目，则需要确保让每个人都了解，安全风险和复杂性会在扩展后迅速增加。在第1阶段和第2阶段之间的安全挑战存在巨大差异的，这会让许多组织机构措手不及。 第2阶段：正式启动 在这个阶段，容器化已不再是个别开发人员的业余项目，而是由团队或业务部门开展一部分正式项目。这时，开发团队会用容器创建一个用于生产的新应用或将现有应用容器化。 大多数组织机构在开发其第一个容器化应用时，可能会使用下列其中一种方法： ?将现有应用容器化 ?将现有应用的一部分内容容器化 ?从头开始在容器中开发新应用
1.术语解释 (1)过程域 过程域是一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对 该过程域的改善具有重要作用的一组条件。 (2)过程改善 是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这 一程序的结果 (3)专用目标 每一个过程域中都有一个或多个“专用目标”，用于描述满足该过程域必须呈现的 一些独有特征 (4)共用目标 每一个过程域中都有一个或多个“共用目标”，用于描述实现制度化的该过程必须 呈现的特征 (5)专用实践 每一个过程域中都有一个或多个“专用实践”，这些专用实践被被认为对于达到该 过程域的专用目标是重要的活动，即期望以专用实践所描述的活动，会导致达到一 个过程域的专用目标。 (6)共用实践 每一个过程域中都有一个或多个“共用实践”，被认为对于要达到该过程域相关的 共用目标的重要的活动。 (7)能力等级 是指遵循一个过程可达到的预期结果的程度。所谓能力等级，是指在单一过程域中 已达到的过程改善。换句话说，能力等级是为了管理，对过程改善程度所设定的几 个“台阶”。 (8)成熟度模型：是指达到预先定义的一组过程域所有目标的一种过程改善等级 2.简答题 (1)CMMI提出所基于的基本思想 CMMI提出所基于的基本思想是过程路径思想，通过过程把软件质量的3个支撑点 ---受训的人员、规程和方法、工具和设计进行集成，以开发所期望的系统\产品。 为此，CMMI紧紧围绕开发、维护和运行，把经过证明的“最佳实践”放在一个结 构中。该结构有乃至于指导组织确定其过程的发送优先次序；有乃至于指导这些改 善的实施，以提高其过程能力和成熟度，并且还支持其他领域（如获取和服务）能 力成熟度模型开发。 (2)什么是过程制度化？在CMMI中把过程制度化分为几个等级？简要回答每一个等 级的主要特征。 所谓的过程制度化，是指过程被渗透在执行工作的方式中，执行的工作有一定的承 诺，并且在组织范围内是一致的。 已执行过程、已管理过程、已定义过程、已定量管理过程、持续优化过程 (3)简述CMMI模型的模型部件及部件间的关系 过程域、专用目标、专用实践、共用目标、共用实践、典型工作产品、子实践、共 用实践的精华、意图陈述、简介性注释、相关过程域 CMMI是有一些过程域组成；过程域有自己的确定专用目标和共用目标。过程域及
PCMM（人员能力成熟度模型）介绍 PCMM（People Capability Maturity Model，人员能力成熟度模型）是美国宾州大学SEI（软件工程学院）沿用CMM（Capability Maturity Model，软件开发能力成熟度模型）的框架所开发出的一套指导企业持续提升人力资源管理能力的方法论和知识体系。 一、5个成熟度层级 PCMM将企业的人力资源管理能力分为5个层级。 1）初始级 在初始级，组织人力资源管理工作仅仅是事务性的，诸如基本的人事管理和工资奖金发放等。人力资源管理部门可能象征性地提供了一些表格，如绩效评估或职位描述，却没有为这些文件的合理使用提供指导或培训。 各级管理者缺乏基本的人力资源管理培训，在管理下属的能力是建立在以往的经验及其个人的“管人技巧”上。甚至一些管理者们并不接受开发组织人力资源是他们个人的主要职责。他们从事人员管理活动，比如，面试应征者，在没有准备的情况下作绩效评估，其结果是使应征者败兴而归或不合理的人事决策。 在初始级，组织的员工能力是未知的，因为组织没有为测试或提高这些能力作任何努力。员工们只是积极努力地完成自己的工作任务，因为没有任何激励措施来使他们的动机与组织的业务指标相一致。当员工们觉得其他企业有着更好的工作环境以及更好的职业发展前景时，就会离职，因此组织的员工流动率相当高。由于有经验的员工不断流失，组织始终是一些新手，因此，组织的知识和技术水平并不随时间的推移而提高，因为组织必须为那些有见识的已经离开组织的职员替补新职员。 2）可重复级 主要目标是消除妨碍员工正常工作的主要障碍，为持续改进开发人力资源的
总第255期2011年第1期 计算机与数字工程 Computer&D ig ital Eng ineer ing V o l.39No.1 71软件审查能力成熟度模型* 曹悦1)张靖2) (华中科技大学电子与信息工程系1)武汉430074)(海军工程大学计算机系2)武汉430033) 摘要软件审查是提高软件过程质量和生产率的一种方法。文章介绍了审查能力成熟度模型,该模型用于评估一个组织软件审查实践的层次,为审查改进提供框架。 关键词审查;能力成熟度;质量 中图分类号T P393 I nspection Capability Maturity Model Cao Y ue1)Z hang Jing2) (Department of Electronics and Infor mation Eng ineering,H uazho ng U niversity of Science and Technology1),Wuhan430074) (Department of Com puter Science,N aval U niversit y of Eng ineer ing2),W uhan430033) A bstract Softw are inspect ion is an important method of improv ing qua lity and pr oductiv ity of softw are pro cess.T his paper int rodues inspect ion capability matur ity mo del(ICM M).T his model can be used to assess t he lev el of softw ar e inspec-t ion in an o rg anizat ion and to be a fr amew or k for inspection impr ovement. Key Words inspection,capabilit y maturit y model,quality Class Nu mber T P393 1引言 软件审查是提高软件过程质量和生产率的一种有效方法[1]。其基本目标是在软件工程的早期,通过协助软件开发人员标识和修复工作中的错误以改进软件质量。它以温伯格的/非自我程序设计0的概念为基础,在开发和维护过程的每一个环节进行审查。在很多问题的发现上,审查不仅比测试更有效,而且还可以在纠正成本较小的前提下尽早更正错误。表1给出了审查和测试发现错误的概率。 但是软件审查还没有在大多数组织中广泛应用,其自身还需要改进。本文介绍审查能力成熟度模型(ICM M),该模型可以评价组织的软件审查实践等级并提出审查改进的框架。ICM M与SM mm[2]、T MM[3]模型类似均用于软件相关过程评估和改进,在参考集成能力成熟度模型(CM-M I)[4]的基础上对软件审查进行建模,是CMM I模型的有益补充。审查能力成熟度的基础源于CM-M I并采纳其思想拓展到审查领域。 表1检测错误的概率(%) 阶段发现错误概率 设计审查57.7 代码审查62.7 单元测试72.9 算法测试8.3 集成测试46.1 需求测试45.7 ICM M延续CM MI的成熟度等级思想,从初始级到最优级共分为5个等级。每个成熟度等级都包含若干子过程,所有定义的需求均满足时才达到该等级。ICM M并不专注于特定类型的审查,例如需求或代码审查。它也不试图定义一种理想的审查过程,因为在不同情况下过程会变化。模型涵盖所有类型审查中普遍存在的最重要的元素。同 *收稿日期:2010年7月13日,修回日期:2010年8月20日 作者简介:曹悦,女,研究方向:电子与信息工程。张靖,女,讲师,研究方向:软件测试。
企业信息化成熟度阶段分类模型分析 从企业信息化基础条件和信息系统应用水平两个方面提出了企业信息化成熟度的13个评价指标，根据对66家企业的调研结果，采用主成分分析方法对13个评价指标进行了降维分析，得出了企业信息化成熟度综合评价指标。根据这些综合指标对66家企业的数据进行了聚类分析，提出了企业信息化成熟度阶段分类模型，得出企业信息化的五个发展阶段：即信息化准备阶段、信息系统引入阶段、信息系统集成共享阶段、信息系统企业外延伸阶段、信息系统决策支持阶段。 研究企业信息化成熟度等级模型就是研究企业信息化从不成熟到成熟的过程演变规律，为企业评估其目前的信息化发展阶段，制定信息化发展战略提供帮助。20世纪60年代以来，在信息系统的研究中，信息化成熟过程引起了广泛关注。国外提出了很多信息化成熟度模型，例如：Nolan模型、Synnott模型、Mische 模型、Hanna模型、Edgar Schein模型、Boar模型、业务-IT联盟成熟度模型等，其中Nolan模型最著名。在20世纪70年代，Nolan通过对200多个公司、部门信息系统实践的总结，分别以计算机在组织中的应用规模以及组织在IT应用上的资源投入大小为横纵坐标，提出了信息系统进化的4阶段模型：初始、传播、控制和成熟阶段。随着信息技术的发展，Nolan在4阶段模型的基础上又提出了6阶段模型，增加了“集成”和“数据管理”两个阶段。不同的国家，信息化起点不同，信息化的路径也不可能完全一样。为此，国内很多学者尝试研究适合中国企业的信息化成熟度模型。文献[2]提出4阶段模型：引入、集成、流程变革、战略变革。文献[3]提出6阶段模型：企业进入、数字化生存、单点数字化、联合自动化、决策支持自动化、敏捷一虚拟化的企业。文献[7]提出5阶段模型：技术支撑级、资源集成级、管理优化级、战略支持级和持续改善级。文献[8]提出了6阶段模型：原始信息化、信息化初级、单个信息系统、信息系统集成、信息网络化集成决策和网上企业。文献[9]提出了5阶段模型：引入、渗透、膨胀、调整、集成。但这些研究对模型提出过程的阐述都比较笼统，没有具体说明模型是如何提出的。为此，作者通过对66家企业的问卷调查，采用主成分分析和聚类分析方法，提出了信息化成熟度模型。 1 企业信息化成熟度评价指标体系 计算机及所构成的硬件环境是企业进行信息化的基础条件，各种信息系统的应用则体现了企业信息化的应用水平。因此，企业信息化成熟度评价指标体系包括企业信息化基础条件建设和信息系统应用水平两个方面的指标，具体指标体系如图1所示。
软件能力成熟度模型:CMM 五个级别介绍 CMM 为企业的软件过程能力提供了一个阶梯式的进化框架, 阶梯共有五级。第一级只是一个起点,任何准备按 CMM 体系进化的企业都自然处于这个起点上,并通过它向第二级迈进。除第一级外,每一级都设定了一组目标, 如果达到了这组目标,则表明达到了这个成熟级别,可以向下一级别迈进。 从纯粹的个人行为发展到有计划有步骤的组织行为… 第一级:初始级 (Initial; 第二级:可重复级 (Repeatable; 第三级:已定义级 (Defined; 第四级:受管理级 (Managed; 第五级:优化级 (Optimizing。 初始级 初始级的软件过程是未加定义的随意过程, 项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范, 但若这些规范未能覆盖基本的关键过程要求, 且执行没有政策、资源等方面的保证时,那么它仍然被视为初始级。 关注点: 工作方式处于救火状态,不断的应对突如其来的危机; 工作组:软件开发组、工程组; 提高: 需要建立项目过程管理,建立各种计划,开展 QA 活动。
可重复级 根据多年的经验和教训,人们总结出软件开发的首要问题不是技术问题而是管理问题。因此, 第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程, 可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面; 其中项目管理过程又分为计划过程和跟踪与监控过程。 通过实施这些过程,从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。 关注点: 规则化 引入需求管理、项目管理、质量管理、配置管理、子合同管理等; 引入工作组:测试组、评估组、质量保证组、配置管理组、合同组、文档支持组、培训组; 提高: SEPG 、建立软件过程库和文档库 已定义级 在可重复级定义了管理的基本过程, 而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准, 并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程, 裁剪出与项目适宜的过程, 并且按照过程执行。过程的裁剪不是随意的,在使用前必须经过企业有关人员的批准。 关注点: 文档化,标准的一致的;
工业互联网成熟度评估模型 本文出自工业互联网产业联盟发布的《工业互联网成熟度评估白皮书》。 本白皮书旨在为企业提供一套评价自身实践的方法论，为企业找到工业互联网实施中的主要问题、改进方向和建设路径。与此同时，业界各方力量的应用和反馈也将不断促进联盟修正该方法论中存在的问题，为工业互联网发展提供更科学更准确的指导。 一、工业互联网成熟度评估提出的原因 （一）工业互联网应用浪潮来袭 随着工业互联网概念兴起，美德先导应用不断涌现，目前德国工业4.0平台已有140多个应用案例，美国IIC有接近50 个应用案例，主要聚焦在生产管理优化、物流仓储优化、质量管理优化、产线柔性部署、产品服务价值化等领域。与此同时，我国产业界也加快了面向各类场景的工业互联网应用探索。2016 年，工信部相关部门组织实施了10 个工业互联网试点示范项目，AII 联盟也评选出了首批12 个工业互联网优秀案例。然而，目前我国工业互联网应用与发达国家相比还存在总体发展水平较低、行业间企业间基础差异较大、大规模推广难度巨大、缺乏工业互联网评估体系和实施指南等问题。 （二）联盟需构建先导性的标准化模型 从国内外已有的主要成熟度模型来看，德国构建了工业4.0 成熟度评级模型，但因两国发展基础不同，建设水平不同，并不能直接用于我国工业互联网成熟度评估。AII 联盟作为推进我国工业互联网政产学研用协同发展的公共平台，需要率先开展研究，针对我国自身特点，制定一套评估模型和方法，推进工业互联网理论与实践。 （三）为企业提供一个便利的自我评价工具 当前产业界对工业互联网的理解不统一，企业对自身工业互联网发展的定位、现状和发展路径不明确，缺乏一致的方法论来评判具体实践。联盟希望通过工业互联网成熟度评估体系的制定助力企业了解自身建设水平，发现存在的问题，并获取相关的诊断建议。该评估模型并不是为了创造一套复杂的理论，而是希望以提供互联网服务的方式为企业提供一个便利的自我评价工具。 （四）为政产研用搭建一个持续透明的信息窗口 工业互联网成熟度评估模型的制定并不是一蹴而就的，当前的 1.0 版本主要是结合现阶段工业互联网发展的特点和先进实践而得出的，将来还有持续发展、反复迭代的过程，需要借助产业界各类主体的意见和建议深化模型，并结合企业对模型的应用结果和反馈，不断更替或补充更符合不同阶段实际情况的评估因素，不断修正完善评估指标、权重和评估问卷设置等。这个过程不仅能助力政府部门了解我国工业互联网的最佳实践，也能帮助应用企业和解决方案服务商建立透明的信息窗口，促进产学研结合。
流程再造新工具：PEMM框架 作者：迈克尔·哈默 翻译：陈桂华为什么流程再造屡屡失败，主要原因就在于企业能力与流程不匹配。本文介绍的新工具能帮助企业解决这个问题。 “流程管理”早已成为企业日常运作的一部分。17年前，我在《哈佛商业评论》 (参见Reengineering Work：Don't Automate，Obliterate，1990年7／8月号) 上首次提出这一全新概念，引发了颇多争议。而如今，世界各地的企业都在通过业务流程再造来推行企业变革。所谓业务流程是指从原材料进入企业到产品流出企业这一运营链条上的所有工作。企业进行业务流程再造，不仅能够大幅提高绩效，还能为客户提供更大的价值，为股东创造更多的利润。很少有企业高管会质疑这一点。事实上，各行各业的企业，无论其规模大小，几乎都因为关注、衡量和重新设计了面向内部和外
部客户的流程，而在成本、质量、速度和赢利能力等关键指标上取得了显著改善。 不过遗憾的是，失败的例子也比比皆是。2000年以来，我亲历了数百家企业为了重获生机而建立或再造业务流程的过程。尽管有良好的意愿和必要的投资，但许多企业不是进展缓慢，就是成效甚微。即使是那些成功变革的企业，也是历经千辛万苦才“守得云开见月明”。不可否认，所有的变革项目推行起来都困难重重，然而流程变革则更为艰难。一般人都以为，设计新的业务流程就是重新安排工作流程，只需要确定谁来做什么事，在哪里做，按照什么顺序来做就行了。然而情况并没有这么简单。要让新流程发挥作用，企业必须从更广层面上重新界定工作，提供更多培训以支持这些工作，并培养一线员工的决策能力：还要调整奖励制度，不仅关注结果，也要考虑过程。除此之外，企业必须重塑组织文化，强调团队合作、个人责任感以及客户重要性，重新界定管理者的职责，鼓励他们监管流程，而不是监督具体活动，培养员工而不是监督员工，最后，企业需要协调信息系统，以确保跨部门流程的运行顺畅，而不只是支持单个部门。 在我研究的多数企业中，高管们常常为了流程重组而绞尽脑汁。他们知道，要发挥流程的作用，就得改变很多东西．但究竟需要改变什么，改变多少、何时改变，他们又不清楚。他们的迷茫引发了种种混乱：决策犹豫不决、计划杂乱不清，争辩无休无止、讨论无果而终，无端的自满和绝望，再三失误和重复劳动，一再延期和半途而废。他们不停地相互询问：我们是否一开头就做错了?我们怎么才能知道事情有没有进展?完成变革后，企业会呈现什么样的面貌?另外，对于哪些因素有助于推动基于流程的变革，高管们往往意
CMMI CMMI 早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI 在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。 目录
展开 简介 CMMI 的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。 CMMI家族包括CMMI for Development, CMMI for Service和CMMI for Acquisition三个套装产品。 CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型 自从1994 年SEI 正式发布软件CMM 以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在：n 不能集中其不同过程改进的能力以取得更大成绩； n 要进行一些重复的培训、评估和改进活动，因而增加了许多成本； n 遇到不同模型中有一些对相同事物说法不一致，或活动不协调，甚至相抵触。 于是，希望整合不同CMM 模型的需求产生了。1997 年，美国联邦航空管理局（FAA）开发了FAA-iCMMSM（联邦航空管理局的集成CMM），该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。 CMMI 与CMM 最大的不同点在于：CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。 CMMI 有两种表示方法，一种是大家很熟悉的，和软件CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续
课程3 交换机与交换机、交换机与路由器之间通过两个或多个端口并行连接同时传输以提供更高带宽、更大吞吐量的封装技术是（c）。 A、堆叠 B、级联 C、端口汇聚 D、干线汇聚 质量管理中需要关注几个阶段的问题？ c A) 3个阶段 B) 4个阶段 C) 5个阶段 D) 2个阶段 以下不属于组织管理中建议成熟的组织形式的是？ACD （P43）适用范围 A、梯队型组织 b、服务或复合型组织 c、项目型组织 d、技术型组织 下列说法正确的是？ABCD (P80) A、路由器是互联网的主要节点设备 b、转发策略称为路由选择，也是路由器名称的由来 C、路由器通过路由决定数据的转发 d、路由器构成了Internet的骨架 员工关怀的方式建议（ABC） A、生日祝福礼物 b、定期组织团队活动 c、节假日慰问 d、强制休假 供应商管理的原则包括？BCD A、选择比我们差的供应商确保客户不流失b、考核明晰、严格审查C、统一形象统一流程 d、引进合理竞争 系统调试的主要工作应进行记录，调试记录包括？ABCD (p71) A、调试时间、对象、人员b、调试内容和方案 C、调试的输入输出数据及分析 d、调试结论 以下属于防火墙的硬件体系结构的是？BCD P82 A、PC计算机架构 b、通用CPU架构 C、ASIC架构 d、网络处理器架构 技术型组织管理的关键点包括？ABC A、设立技术带头人 b、明确责任分工和考核要求 c、加强项目和服务管理能力 d、设立考核要求明确重点即可，衡量和核算方法无需考虑 确保系统稳定，需要关注？BCD A、客户预算 b、IT系统稳定 c、自己团队稳定 d、合作伙伴稳定 下列属于智能大厦计算机网络系统需求的是？ACD A、功能性需求 b、替代需求 c、空间和用户数需求d、应用系统需求 下列对于智能化集成系统的描述错误的是？BC A、其功能应以满足建筑物的使用功能为目标，确保对各类系统之间的信息资源加以共享和优化管理b、其配置应具有各智能化系统进行数据通信、信息采集和综合处理的能力 C、其是由智能化系统信息共享设施建设和信息化采集功能实施构成 D、其是将不同功能的建筑智能化系统，通过统一的信息平台实现集成，以形成具有信息汇集、资源共享及优化管理等综合功能的系统。 1、人员管理中客户的定义是（D） A、负责运维服务提供和操作的人员b、使用服务的人员C、确保运维项目正常交付的人员d、负责服务评价、验收和付费的人员 2、下列哪一项是供应商管理的完工阶段的工作？D A、收集资质 b、技术能力测试 c、向外援工程师在此明确现场服务规范，要求严格遵守 D、外援工程师 提交技术服务单，配合项目经理确认服务实施状况 3、系统稳定强调冗余备份和（A）。 A、应急响应 b、提前规划 c、技术先进 d、业务集中 4、服务型组织的劣势体现在？C A、沟通成本高，需要工具支持 b、技术问题推诿 C、对员工解读业务
初探数据管理能力成熟 度模型D M M Revised by Petrel at 2021
初探数据管理能力成熟度模型DMM 专家简介：梁铭图，新炬网络首席架构师，拥有十年以上数据库运维、数据分析、数据库设计以及系统规划建设经验，长期为国内电信运营商的大型IT系统进行系统软件运维、数据架构规划、设计和实施以及大型IT系统数据建模工作，在数据架构管理以及数据资产管理方面有着深入的研究。 1、什么是DMM 企业数据管理能力成熟度模型DataManagementMaturity（DMM）是由CMMi协会于2014年发布的。它可以用来评估和提升组织的数据管理水平，帮助组织跨越业务与IT之间的鸿沟。DMM模型沿用了软件能力成熟度集成模型（CMMI）的一些基本原则、结构和证明方法。 CMMI协会认为，DMM模型帮助组织建立一个关于它们数据资产应该如何管理的通用术语和共识。它五个连续的能力层面提供一个清晰路径，提升25个过程域，反映到所有数据管理的基本科目中。 通过提供一个结构化和标准的实践框架，DMM可以促进组织建立它们自已的数据管理成熟度路线图。DMM帮助组织更为熟练地管理它们关键数据资产，推动主动的战术和战略支持，提供一个一致性以及可对比的基准用来测量长时间的进展。它是一个强大的工具，用来创建一个共享的愿景和术语，阐明所有利益相关者的角色，增加业务接触以及强化数据治理。 2、DMM面向的对象 模型面向于每一个想要高效管理自身数据资产的组织。已经使用DMM模型的公司，所涉及的行业范围非常广泛，包括IT、航空、金融和政府。 DMM可以裁剪以适应任何组织的需求，它可以应用于整个组织、一个业务线条，或者一个多利益相关者的主要项目。 3、DMM能力模型 与CMMI类似，DMM也根据企业的数据管理能力提出五个层次：
为什么内部审计师要关注软件开发流程和软件开发项目管理 【字体：大中小】【打印】本章的主要内容 ·为什么内部审计师要关注软件开发流程和软件开发项目管理 ·软件流程能力成熟度模型 ·内部审计师与软件流程能力成熟度模型 ·信息系统项目管理 ·项目管理与内部审计人员 为什么内部审计师要关注软件开发流程和软件开发项目管理 ·软件质量影响组织业务正常有效运营。 ·内部审计师作为公司治理和完整内部控制框架的一个必要组成部分，对于公司软件开发流程管理控制也具有监督、咨询职能。软件质量属性 ·软件的质量属性 –功能性 –可靠性 –易用性 –效率 –可维护性 –可移植性 内部审计师在软件开发流程管理中的职责 为什么内部审计师要关注软件开发流程和软件开发项目管理 【字体：大中小】【打印】本章的主要内容 ·为什么内部审计师要关注软件开发流程和软件开发项目管理 ·软件流程能力成熟度模型 ·内部审计师与软件流程能力成熟度模型 ·信息系统项目管理
·项目管理与内部审计人员 为什么内部审计师要关注软件开发流程和软件开发项目管理 ·软件质量影响组织业务正常有效运营。 ·内部审计师作为公司治理和完整内部控制框架的一个必要组成部分，对于公司软件开发流程管理控制也具有监督、咨询职能。 软件质量属性 ·软件的质量属性 –功能性 –可靠性 –易用性 –效率 –可维护性 –可移植性 内部审计师在软件开发流程管理中的职责 软件流程能力成熟度模型CMM 【字体：大中小】【打印】 一、什么是CMM ·Capability Maturity Model –企业软件流程的能力、成熟度模型 –是用来确定一个企业的软件流程的成熟程度 以及指明如何提高该成熟度的参考模型。 二、CMM的基本概念 ·组织（organization）。管理软件项目，能对项目进行评估和流程改进的实体，如政府机关、公司、服务部门等。 ·项目（project）。由组织承担的，并需要组织中各部门通力合作完成的指定产品的开发和维护任务。任何一个项目都涉及经费、成本和进度计划。这里的产品包括硬件、软件或其他构件。 ·软件流程（software process）。软件开发人员为开发和维护软件及相关产品所实施的一系列步骤，这些步骤涉及方法、工具以及人的组织和行为。软件产品的质量取决于软件开发和维护流程的质量，与其他产品的开发流程一样，软件流程也必须进行严格管理，因为只有严格管理才能保证效益和质量。 ·组织的标准软件流程（organization’s standardsoftware process）。组织内部使用的软件流程，它描述软件流程要素和要素之间的关系，用它可以建立某一具体项目的软件流程。
数据库，作为企业重要IT基础设施之一，在数字化中扮演着重要的角色。其是否运行平稳、是否处于最佳状态、是否可方便的扩展等，进而是否能满足业务现状及未来发展，这些对于企业至关重要。要达到上述目标，取决于两个方面：数据库产品自身能力、数据库服务能力。可以说“产品+服务”，决定了最终的结果如何。但在很长一段时间里，对于前者（产品）有很多手段去了解、评估；但对于后者（服务）却少有有效的衡量方法。在过去的三、四十年里，传统数据库市场主要是以国外大型商业数据库为主，其服务能力经过多年积累已相对成熟、完善，并构建起一整套标准及相应的配套服务团队。但随着近些年来数据库市场有了明显的变化，一是以开源为主导数据库方案在很多公司得以使用；二是国产数据库也层出不穷，并愈发呈现蓬勃发展之势；三是分布式、云化技术特点为代表的新数据库形态逐步被人认知并投入使用。针对这种新的变化，过去按单一产品作为衡量标准就不太合适，急需一种通用的行业标准来度量数据库服务能力。 近期，信通院发表的《数据库服务能力成熟度模型》，由此应运而生。它的推出，有助于企业决策者，找到数据库服务重点，获取当前数据库整体现状，识别其中的不足并找准关键问题及差异，进而提供数据库服务能力的改进方向和意见，规划企业未来的数据库发展蓝图。本文根据之前信通院发表的《数据库服务能力成熟度》为基础，加以个人的一些理解分析。当前这一标准，正处于规范发布阶段，其具体细节和评价方式、标准还有待落实，也希望更多数据库从业者参与其中。为提高国内数据库整体服务质量，贡献
自己的一份力量。本文部分内容引用信通院发布《数据库服务能力成熟度》报告及网名“失速的脑细胞”的一篇文章。 原文参考：https://www.doczj.com/doc/7212564363.html,/p/d672951c5c1a 1. 成熟度模型概述 人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。 1).评估标准：能力框架与能力域 此次发布的数据库服务成熟度模型，将能力框架划分为三个能力域，分别是：规划设计能力、实施部署能力和运维运营能力。其可对应到数据库从选型评估、规划设计、部署实施、运维保障、开发优化等多个方面。在三个能力域内，又进一步划分为27个能力项，其中规划设计能力域包含8个能力项，实施部署能力包含7个能力项，运维运营能力包含12个能力项。具体 可参考下图：
工业互联网成熟度评估模型
工业互联网成熟度评估模型 本文出自工业互联网产业联盟发布的《工业互联网成熟度评估白皮书》。 本白皮书旨在为企业提供一套评价自身实践的方法论，为企业找到工业互联网实施中的主要问题、改进方向和建设路径。与此同时，业界各方力量的应用和反馈也将不断促进联盟修正该方法论中存在的问题，为工业互联网发展提供更科学更准确的指导。 一、工业互联网成熟度评估提出的原因 （一）工业互联网应用浪潮来袭 随着工业互联网概念兴起，美德先导应用不断涌现，目前德国工业 4.0平台已有140多个应用案例，美国 IIC有接近 50 个应用案例，主要聚焦在生产管理优化、物流仓储优化、质量管理优化、产线柔性部署、产品服务价值化等领域。与此同时，我国产业界也加快了面向各类场景的工业互联网应用探索。2016 年，工信部相关部
门组织实施了 10 个工业互联网试点示范项目，AII 联盟也评选出了首批 12 个工业互联网优秀案例。然而，目前我国工业互联网应用与发达国家相比还存在总体发展水平较低、行业间企业间基础差异较大、大规模推广难度巨大、缺乏工业互联网评估体系和实施指南等问题。 （二）联盟需构建先导性的标准化模型 从国内外已有的主要成熟度模型来看，德国构建了工业 4.0 成熟度评级模型，但因两国发展基础不同，建设水平不同，并不能直接用于我国工业互联网成熟度评估。AII 联盟作为推进我国工业互联网政产学研用协同发展的公共平台，需要率先开展研究，针对我国自身特点，制定一套评估模型和方法，推进工业互联网理论与实践。 （三）为企业提供一个便利的自我评价工具 当前产业界对工业互联网的理解不统一，企业对自身工业互联网发展的定位、现状和发展路径不明确，缺乏一致的方法论来评判具体实践。联盟希望通过工业互联网成熟度评估体系的制定助力企业了解自身建设水平，发现存在的问题，并
南京福瑞泽信息科技有限公司CMMI软件能力成熟度模型集成认证指南 一、 简介 CMMI全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成（也有称为：软件能力成熟度集成模型），于2002年正式发布，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。 CMMI模型已经成为业界主要的过程管理模型，CMMI模型有两种表示方式，连续表示模型和分级表示模型。其中分级表示模型依次划分为五个等级(初始级、可重复级、已定义级、已管理级、优化级)，标志着软件企业能力成熟度的五个层次。级别越高，表示软件组织的成熟能力也越高，CMMI5是目前世界软件界对能力成熟度要求最高、申请难度最大、级别最高的评估，通过CMMI5级评估标志着本公司的质量管理和过程改进已跻身于全球软件业的顶尖水平。 软件企业申请认证CMMI不同的级别标准要求，要审时度势自身情况。一方面了解公司现有质量体系、实施过程、实施效果的运行情况;另一方面要根据企业规模、公司实力、管理需求等综合要素，不可好大喜功，一味选择CMMI更高级别的认证。在申请的CMMI认证时，有的企业从CMMI2开始、有的企业从CMMI3开始、有的CMMI3通过后跳过CMMI4而直接申请CMMI5、有的就从CMMI2、CMMI3、CMMI4、CMMI5逐步申请认证。 二、 申报条件 符合下列条件的服务外包企业可提出申请： 1、有进出口经营权或对外经济合作经营资格； 2、近两年在进出口业务管理、财务管理、税收管理、外汇管理、海关管理等方面无违法行为； 3、已与一家或多家服务外包发包商签订中长期提供服务外包业务合同，企业提供服务外包业务年收入不低于150万美元（离岸服务外包业务收入占70％以上）； 4、具有服务外包承接能力及服务外包市场开拓和项目管理人员，大学（含大专）毕业及以上学历员工占公司员工总数70%以上。 （一）人力资源 实施中会涉及到EPG过程改进小组、QA、试点项目团队等人力资源： ●专职人员：1-2名 即在CMMI实施推广期内，基本上100%的时间投入。
工业互联网成熟度评估 模型 HUA system office room 【HUA16H-TTMS2A-HUAS8Q8-HUAH1688】
工业互联网成熟度评估模型 本文出自工业互联网产业联盟发布的《工业互联网成熟度评估白皮书》。 本白皮书旨在为企业提供一套评价自身实践的方法论，为企业找到工业互联网实施中的主要问题、改进方向和建设路径。与此同时，业界各方力量的应用和反馈也将不断促进联盟修正该方法论中存在的问题，为工业互联网发展提供更科学更准确的指导。 一、工业互联网成熟度评估提出的原因 （一）工业互联网应用浪潮来袭 随着工业互联网概念兴起，美德先导应用不断涌现，目前德国工业 4.0平台已有140多个应用案例，美国 IIC有接近 50 个应用案例，主要聚焦在生产管理优化、物流仓储优化、质量管理优化、产线柔性部署、产品服务价值化等领域。与此同时，我国产业界也加快了面向各类场景的工业互联网应用探索。2016 年，工信部相关部门组织实施了 10 个工业互联网试点示范项目，AII 联盟也评选出了首批 12 个工业互联网优秀案例。然而，目前我国工业互联网应用与发达国家相比还存在总体发展水平较低、行业间企业间基础差异较大、大规模推广难度巨大、缺乏工业互联网评估体系和实施指南等问题。 （二）联盟需构建先导性的标准化模型
从国内外已有的主要成熟度模型来看，德国构建了工业4.0 成熟度评级模型，但因两国发展基础不同，建设水平不同，并不能直接用于我国工业互联网成熟度评估。AII 联盟作为推进我国工业互联网政产学研用协同发展的公共平台，需要率先开展研究，针对我国自身特点，制定一套评估模型和方法，推进工业互联网理论与实践。 （三）为企业提供一个便利的自我评价工具 当前产业界对工业互联网的理解不统一，企业对自身工业互联网发展的定位、现状和发展路径不明确，缺乏一致的方法论来评判具体实践。联盟希望通过工业互联网成熟度评估体系的制定助力企业了解自身建设水平，发现存在的问题，并获取相关的诊断建议。该评估模型并不是为了创造一套复杂的理论，而是希望以提供互联网服务的方式为企业提供一个便利的自我评价工具。 （四）为政产研用搭建一个持续透明的信息窗口 工业互联网成熟度评估模型的制定并不是一蹴而就的，当前的 1.0 版本主要是结合现阶段工业互联网发展的特点和先进实践而得出的，将来还有持续发展、反复迭代的过程，需要借助产业界各类主体的意见和建议深化模型，并结合企业对模型的应用结果和反馈，不