CMMI简明培训教材-18过程域

1、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:PracticeInstantiationIndicatorDocument实践的实施证据文档SR-SeniorManagement,PL-ProjectLead,DEV-Developer,SQA,SCM.RM,SE

2、PG随着人们对CMM研究的不断深入，其他学科也结合本系统的特点，陆续推出了自己的CMM模型。例如，人力资源能力成熟度模型、系统工程能力成熟度模型等等：(1) SW-CMM(SoftwareCMM)软彳CMM(2) SE-CMM(SystemEngineeringCMM)系统工程CMM(3) SA-CMM(SoftwareAcquisitionCMM)软件采购CMM(4) IPT-CMM(IntegratedProductTeamCMM)集成产品群组CMM(5) P-CMM(PeopleCMM)人力资源能力成熟度模型CMMI三级18个过程域中属于项目管理类的过程域：A、PPPMCRSKMVALS

3、AMB、PPIPMPMCRSKMSAMCRDPPIPMPMCRSKMSAMD、REQAPPPMCIPMSAMREQM:RequirementsManagement(需求管理)PP：ProjectPlanningPMC:ProjectMonitoringandControl（项目监控）MA:MeasurementandAnalysis（度量分析）PPQA:ProcessandProductQualityAssurance（过程、产品质量保证）CM:ConfigurationManagementRD:RequirementsDevelopmentVER:Verification（文档评审、系统测试

4、）VAL:Validation（项目验收、发布许可）TS:TechnicalSolution方案选择表PI:ProductIntegration（产品集成）OPF:OrganizationalProcessFocus（t织过程焦点）OPD:OrganizationalProcessDefinition（组织过程定义）OT:OrganizationalTraining（组织培训）IPM:IntegratedProjectManagement（集成项目管理）RSKM:RiskManagementDAR:DecisionAnalysisandResolutionCMMI2级简述如果对项目的范围、规模

5、、性质、任务、工作量、费用等都不了解的情况下，是不可能做出计划的，所以做好计划的第一步就是要把这些东西搞清楚。PP这个PA的第一个SpecificGoals,中文大意是：建立和维护用于项目计划的各类参数的估算，英文原文是：Estimatesofprojectplanningparametersareestablishedandmaintained.下面我们再详细看看，到底做计划之前，需要搞清楚什么东西？SP1.1:EstimatetheScopeoftheProject.估计项目的范围，如项目的目标、任务、工作产品等。这里通常就是指WBS(top-levelworkbreakdownstruc

6、ture),试想一下，我们做计划之前不是常常要先对任务进行分解吗？SP1.2:EstablishEstimatesofWorkProductandTaskAttributes.估计工作产品及任务的属性。做计划的时，我们会先列出这个项目要产生的工作产品，以及这个项目要完成的任务等，然后我们需要分析这些任务、工作产品的规模、工作量、复杂度、代码行数等所谓的属性。CMMI并没有规定一定要分析什么属性，具体由企业自己来选择适合自己需要分析的属性。在CMM模型的时候，项目计划这个PA硬性规定了需要分析的几大属性，CMMI模型中已经改进，不再强制要求。分析这些属性的目的是对任务、工作产品等更加了解，以便于

7、做好计划。SP1.3Definetheprojectlife-cyclephasesuponwhichtoscopetheplanningeffort.定义项目生命周期。写计划的其中一个步骤是要考虑用什么生命周期模型，是瀑布型？螺旋？还是别的？选择怎样的模型，CMMI并没有规定，企业可以选择常见的生命周期模型，也可以自己定义自己的模型。CMMI3级简述2级其实有很多问题还没有解决的，细心的人会发现，2级对软件工程活动的指导很弱，如：需求开发、设计、编码、测试等。在3级，你会发现：1)有指导需求开发的需求开发(RequirementsDevelopment)这个PA；2)有指导设计、编码工作的技

8、术解决方案(TechnicalSolution)这个PA；3)有指导如何保证工作产品满足要求的验证(Verification)；4)有指导如何保证软件产品满足真实使用环境要求的(Validation)；5)还有指导如何把软件产品各组件集成在一起并保证能在相应的硬件载体运行正常的产品集成(ProductIntegration)；2级的PP与PMC是直接与项目管理有关的两个PA,在3级，对项目管理的要求进一步提高：6)集成项目管理(IntegratedProjectManagement):3级的项目管理，要求利用组织级的财富库进行项目估算，并且利用财富库裁剪出项目自己的过程，并用这个过程来管理项目

9、。7)风险管理(RiskManagement):2级只有PP的SP2.2中提到要识别风险，而在3级专门有一个PA对风险管理提出更高的要求。大家不知道有没有发现，2级的PA都是直接针对项目提出要求的。3级的IPM和RSKM,除了对项目级提出要求，另外也对组织级提出了要求，IPM要求有组织级的资产库，RSKM要求要有组织级的风险管理策略等。另外，3级有几个“O”开头的PA,这几个PA都是直接对组织级的提出要求。8)组织过程焦点(OrganizationalProcessFocus):这个PA要求组织成立SEPG来推动过程改进的工作，要求识别、计划、实施改进过程，保证组织过程能持续改进。9)组织过程

10、定义(OrganizationalTraining):这个PA要求组织级建立财富库，财富库内容要包括标准的过程、裁剪库、度量库、生命周期模型等。10)组织培训(OrganizationalTraining):要求组织根据商业目标要求准备并提供培训级还有一个很特别的PA:11）决策分析及解决方案（DecisionAnalysisandResolution）:这个PA提供了一个如何做出最佳决策的方法指导。软件行业很多重要的决策，如设计方案、采购方案等，都可以应用这个PA提供的办法，另外也可以在组织过程改进中应用决策分析的办法。总结一下3级的几个重要特点：1）明确规定了需求开发、设计、编码、测试、集

11、成等软件开发各过程的要求。2）对项目管理提出了更高的要求，要利用组织级的数据来管理项目。3）出现了专门针对组织级的PA,要求有专门的组织来负责过程改进的工作。4）提供了一个做出最佳决策的指导，而这个方法可以用于软件工程，也可以用于组织级过程改进。由这些特点大家可以看到，3级已经对软件开发的各个方面有了详细的要求，2级很多不明细的地方全部已经明确。一个达到3级的企业，肯定会定义了很多软件开发各个方面的过程，并且会有组织级的财富库。所以3级叫“已定义”级。补充说明：3级还有另外3个PA上文没有提到，分别是IntegratedTeaming、OrganizationalEnvironmentforI

12、ntegration:对大型软件团队提出了要求，一般情况下中小型软件企业可以NAoIntegratedSupplierManagement:如果软件企业需要管理大量的供应商，则需要考虑这个PA。这3个PA大部分情况下不需要考虑，将暂时不展开详细的讨论。CMMI4级简述2、3级已经对软件开发的方方面有了详细的指引，4级还会有什么更高的要求呢？4级叫定量管理，那什么叫定量管理？微软的MSF达至ijCMMI几级水平呢？是不是所有企业都适合做CMMI4级呢?大家都知道软件开发是智力劳动，量化谈何容易。作为企业老板来说，希望能对自己的软件生产过程进行强有力的控制，量化管理自然就会提到议程。4级的定量管理

13、是有一定的基础要求的，进行定量管理的项目必须是性质近似的，生产过程类似的，这样才可能在一段时间类积累了一堆有同类可比性的数据，对这些数据进行统计分析后才可能得出用于项目控制的基线。简单的说，所谓的定量管理，就是利用经验数据得出的指标，对将来的项目进行管理。如果一个企业已技术创新为主，项目间可比性低，这样是不太可能做4级的。就好象微软，微软不断的研发新产品、新技术，微软也是不太可能做到4级的。微软的MSF,大概就达到CMMI3的水平。首先要向大家澄清一个误区，软件企业并不是越高级越好的，其实4级的管理不太适用于创新型的企业，因为无法形成基线。当然创新性的企业，也可能会有相对稳定的过程，这些过程是

14、可以实施4级管理的。4级只有两个PA,就是：组织过程性能(OrganizationalProcessPerformance)定量项目管理(QuantitativeProjectManagement)OPP是对组织级的要求，组织需要统计出组织级的基线；QPM是对项目的要求，项目要用组织级的基线来控制项目过程。两个PA都很复杂，其中OPP的SP1.4建立性能基线，SP1.5建立性能模型，两者工作量就可以是2、3级几个PA的总和。CMMI5级简述5级的企业，是如何做到持续改进”呢？其实一个软件企业，要提高生产力，有3方面途径：1)改进过程，使现有的过程更强更有效。2)引入新技术，提高生产力。3)对工

15、作出出现的问题进行原因分析，避免以后再次出现。改进过程、引入新技术都是有风险的，不能盲目改进过程，也不能盲目引入新技术，新过程、新技术也不能一下子推广到整个组织，可能需要先试行，然后逐步推广到整个组织，在实施过程中，需要监控整个情况并评估改进的效果。组织革新与部署(OrganizationalInnovationandDeployment)这个PA给出了明确的指弓I。工作中发现的每个问题，其实都是改进的机会，但实际工作中发现的问题可能非常多，需要选择最有价值的问题进行深入分析，并避免其再次发生。通过不断地修复问题，组织的生产力就会不断提升。原因分析及解决方案(CausalAnalysisand

16、Resolution这个PA给出了明确的指引。5级就只有OID和CAR两个PA,两个PA对3个可以提高企业生产力的途径进行了指弓I,只要把OID、CAR做好，企业就可以持续改进”了。CMMI-ACQ随着信息与网络科技之快速发展与应用普及，对政府机关及民间企业都造成极大的冲击。政府机关对内要因应民意高涨与服务水平要求不断提升，对外则需面对国际间追求提升国家竞争力的压力；民间企业则由于产业环境的激烈竞争，迫使企业必须重新思考与评估内部的营运活动，辨识企业的核心能力，集中资源专注于核心活动以创造竞争优势。因此，藉由委外导入信息技术，提供高效率、低成本，富有弹性而快速反应的服务，已势必成为政府机关及民

17、间企业一股不可遏止的潮流。信息业务委外虽可对组织产生效益，但也会带来一些风险。根据StandishGroupInternational在报告中说明，有15%的软件项目终究没有完成，并有超过80%的软件项目延宕，并且超过预算；2000年的统计报告中，只有26%的软件项目成功，另外的74%都是失败。多位学者从影响委外绩效之原因、委外的困难、委外成功因素等不同观点作出研究，归纳出信息系统委外所遭遇最主要的困难为质量不确定、项目时间的延长与成本超乎预算。所以，为了在合理的成本与预定时程内，交付高质量的软件，软件工程领域的专家学者们，不断地研究改善各种软件开发技术与方法。然在软件筹获组织为提高委外软件质

18、量而要求软件开发组织的资格评鉴或管理能力认证之余，却往往因本身的筹获流程相对不成熟，没有标准的作业程序，无法做好软件筹获规划、监控等重要工作项目，进而影响软件委外项目的成功。基于上述问题，CMU/SEI相继发展了软件筹获能力成熟度模式(SoftwareAcquisitionCapabilityMaturityModel,SA-CMM)、能力成熟度整合模式筹获模块(CMMIAcquisitionModule,CMMI-AM)及能力成熟度整合模式筹获(CMMIforACQuition,CMMI-ACQ),用以评估及改善软件筹获流程。SA-CMM介绍能力成熟度模式(CMM)是由美国卡内基美隆大学软件

19、工程学院所发展，以作为软件生产全面质量管理与流程改善的架构。1987年第一次发表研究成果，并于1991年正式发表CMMV1.0版。一般称CMM通常是指软件能力成熟度模式SW-CMM,相较SW-CMM之于软件组织为改善其软件开发效能，SA-CMM则为软件筹获组织为改善信息委外流程，以达到筹获高质量交付软件的成熟度评估模式。简言之，在藉由订定契约而获得软件的流程中，SW-CMM描述的是一个好的软件开发者所必须要具有的能力，而SA-CMM描述的则是一个好的软件筹获者所必须要具有的能力。成熟度等级重点关键流程领域5最佳化级持续流程改善筹获创新管理持续流程改善4ah电级/E里目理定量筹获管理定量流程管理

20、3已定流程标准训练计划管理筹获风险管理合约执行管理项目执义级化行管理使用者需求流程定义及维护2可重基础的项移转支持评估合约追踪与监督项目管理需求发展复级目管理及管理招标软件筹获规划1初始级胜任的人们及英雄式主义StagedCont流程管理专案管理支援筹获Level5组织创新与发展原因分析与解决方案Level4组织流程绩效量化专案管理Level3组织流程专注组织流程定义组织训练整合专案管理风险管理决策分析与解决方案筹获需求发展筹获技术解决方案筹获确认筹获验证Level2需求管理专业规划专业监控建构管理流程与产品品质保证度量与分析筹获管理招标与供应商管理SCAMPI的变化CMMIVersion1.

21、2SCAMPIAAppraisalMethodChangesSCAMPIA类评估方法v1.2变更的主要方面1 .减少评估方法的复杂度和模糊性2 .在需要的地方提供附加指导3 .强化评估规划和实施4 .强化了对评估的报告5 .定义评估的有效期限6 .强化对主任评估师的要求减少复杂度删除了对评估工具(例如：调查表)的要求目前仅需要两种类型的客观证据： 文档 访谈下列章节在方法定义文档(MDD)中被修订： 交换2.2节验证和确认客观证据”和2.3节文档化客观证据”的顺序，这样任务的顺序能够放映评估过程的自然顺序 为了更好地描述每个过程，把验证客观证据”和确认初步的发现(findings)分开改变了术

22、语实例(Instantiation)”的使用： 实例(Instantiation)目前被定义成：模型相关实践在一个组织单元内的实施； 实例(Instantiation)针对项目和组织级实体的应用被项目(Project)或"支持团队SupportGroup)替代减少模糊性澄清评定不予评级(NotRated)”的概念 模型范围之外的过程域(PAs)被定为:范围之外(OutofScope)。例如，对于一个成熟度3级的评估，成熟度4级和五级的过程域被定为范围之外(OutofScope)” 对于没有充足数据评定的过程域，评级为：不予评级(NotRated) 在模型范围内但在组织范围外的过程域(

23、PAs)被定为：不适用(NotApplicable)。仅有一个过程域SAM能被定为不适用(NotApplicable)(这由评估团队决定)。实践特征表被修订：澄清了虚拟访谈和实况访谈的使用把面对面访谈(face-to-faceinterviews)”改变为白头访谈(oralinterviews)”附加指导扩大了预评审(readinessreviews)指导涵盖的范围，包括团队和后勤准备对使用虚拟方法提供附加指导(例如，对访谈和简报等)为可选实践提供附加指导(例如，附录C:可选实践识别和特征指导)强化评估规划和评估实施组织单元取样(sampling)被修订为：(详细参见：方法定义文档MDD)强化组织取样的要素和限制(例如，识别出最小数量的聚焦项目)增加报告取样决策的标准目前实施评估阶段必须在90天内完成目前评估团队成员必须签署最终评估发现(finalfin