CMMI申报实施要点

实施要点

基本思想

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是个辅助，辅助我们对公司做积累，也帮助我们个人做必要的积累。公司需要逐步走向更高的管理水平，发展平台。