软件项目管理CMMI入门与精通.docx

软件项目管理CMMI入门与精通.docx

《软件项目管理CMMI入门与精通.docx》由会员分享，可在线阅读，更多相关《软件项目管理CMMI入门与精通.docx（33页珍藏版）》请在冰点文库上搜索。

软件项目管理CMMI入门与精通

软件研发CMMI探密

1．初识cmmi

2．CMMI一级—初始级

3．CMMI二级

4．CMMI三级

5．CMMI四级

6．CMMI五级

7．CMMI与ISO的区别和联系

8．CMMI在项目中软件研发实际应用

一、初始CMMI

CMMI是由卡基梅隆大学软件工程学院（SoftwareEngineeringInstitute，简称SEI）1984年受美国国防部要求开始研究在软件产业建立一套工程制度，用来评估和改善软件开发公司的过程和能力，并协助软件开发人员持续改善流程的成熟度以与软件质量，从而提升软件开发项目与公司的管理能力，最终达到软件开发功能正确、缩短开发进度、降低开发成本、确保软件质量的目标。

1986年正式开始研究CMM能力成熟度模型（CapabilityMaturityModel，简称CMM），于1991年正式推出了软件能力成熟度模型（CapabilityMaturityModelForSoftware，简称SW-CMM）,两年后1993年正式推出SW_CMM1.0。

后来又根据CMM1.0在各个行业领域发展成了CMMs，其中包括系统工程能力成熟度模型（SystemsEngineeringCapabilityMaturityModel,SE-CMM）、整合产品发展能力成熟度模型（IntegratedProductDevelopmentCapabilityMaturityModel,IPD-CMM）、人力资源管理能力成熟度模式（PeopleCapabilityMaturityModel,P-CMM）等应用模型。

由于各行业架构的不同，SEI于2000年12月公布了能力成熟度整合模型（CapabilityMaturityModel-Integrated,CMMI）对此进行整合。

后来经过不断改进，就形成了今天的CMMI1.2,1.3版本。

CMMI相关基本概念：

CMMI-CapabilityMaturityModuleIntegration（软件过程能力成熟度集成模型），是将原来的CMM-SW/SE等等整合为一个模型，目前使用的版本叫CMMI-DEV（Development）v1.2。

模型有两种表示方法：

连续型与阶段型，国一般说的几级几级指的是阶段型表示法。

CMMI模型包含项目管理类、过程管理类、工程类、支持类四大领域，包含22个PA（ProcessArea过程域）。

每个PA包括有特定目标（SG）特定实践（SP）与各PA所共同包括的通用目标（GG）通用实践（GP）。

SEI-SoftwareEngineeringInstitute（卡耐基梅陇大学软件工程研究所）

SCAMPI-StandardCMMIAppraisalMethodforProcessImprovement是一种评估的方法，一般分为ClassA/B/C三种级别。

二．CMMI一级-初始级

初始级是原始的方式，类似手工作坊式生产。

没有项目的相关规则，项目成员工作主要凭个人能力和习惯，一般项目中也极少有关于过程方面的规定，不论采用什么方法、遵循什么样的开发步骤，最后只要把代码写出来了就可以了，软件开发的主要活动就是编码和调试。

很少有项目计划，顶多有个项目时间表，需求、设计等工程文档也很少有。

三.CMMI二级-受管理级

二级主要定义了7个过程域（PA）来指导软件项目开展：

1、项目计划（PP-ProjectPlanning）:

实际上就是建立PMP与生命周期模型。

PP中主要有三个特定目标（SG-SpecificGoals）：

1）、SG1 EstablishEstimates项目估算—主要包括对项目的围、属性、生存周期、工作量和成本四个SP

2）、SG2 DevelopaProjectPlan制定项目计划—主要有编制预算和进度,识别风险，项目数据的管理计划，规划项目资源，知识和技能的计划，“项目干系人”的介入计划，制定项目计划等SP。

3）、SG3ObtainCommitmenttothePlan获得对计划的承诺

主要SP有:

审查从属计划,协调工作与资源配置,获得计划承诺等

2、项目计划跟踪与控制（PMC-ProjectMonitoringandControl）:

项目PMP与变更控制等。

3、需求管理（RM）：

需求跟踪与变更控制。

4、供应商协议管理（SAM）：

供应商选择标准、评估、评价等。

5、度量（MA）,初级的度量，感知级：

本身是CMML4与的要求，他应该和CMMI:

L4中的QPM联系起来，这个的MA比较简单，在评估时候，存在写KPI，有简单的度量就可以了。

要求比较低。

6、配置管理（CM）：

有一个CVS或VSS工具即可。

7、 产品与过程质量保证（PPQA）：

成立QA机构，主要是质量保证、质量控制与评审。

四、CMMI3级：

已定义级

2级其实有很多问题还没有解决的，细心的人会发现，2级对软件工程活动的指导很弱，如：

需求开发、设计、编码、测试等。

在3级，你会发现：

1）有指导需求开发的需求开发（RequirementsDevelopment）这个PA；

2）有指导设计、编码工作的技术解决方案（TechnicalSolution）这个PA；

3）有指导如何保证工作产品满足要求的确认（Verification）；

4）有指导如何保证软件产品满足真实使用环境要求的（Validation）；

5）还有指导如何把软件产品各组件集成在一起并保证能在相应的硬件载体运行正常的产品集成（ProductIntegration）；

2级的PP与PMC是直接与项目管理有关的两个PA，在3级，对项目管理的要求进一步提高：

6）集成项目管理（IntegratedProjectManagement）：

3级的项目管理，要求利用组织级的财富库进行项目估算，并且利用财富库裁剪出项目自己的过程，并用这个过程来管理项目。

7）风险管理（RiskManagement）：

2级只有PP的SP2.2中提到要识别风险，而在3级专门有一个PA对风险管理提出更高的要求。

大家不知道有没有发现，2级的PA都是直接针对项目提出要求的。

3级的IPM和RSKM，除了对项目级提出要求，另外也对组织级提出了要求，IPM要求有组织级的资产库，RSKM要求要有组织级的风险管理策略等。

另外，3级有几个“O”开头的PA，这几个PA都是直接对组织级的提出要求。

8）组织过程焦点（OrganizationalProcessFocus）：

这个PA要求组织成立SEPG来推动过程改进的工作，要求识别、计划、实施改进过程，保证组织过程能持续改进。

9）组织过程定义（OrganizationalTraining）：

这个PA要求组织级建立财富库，财富库容要包括标准的过程、裁剪库、度量库、生命周期模型等。

10）组织培训（OrganizationalTraining）：

要求组织根据商业目标要求准备并提供培训。

3级还有一个很特别的PA：

11）决策分析与解决方案（DecisionAnalysisandResolution）：

这个PA提供了一个如何做出最佳决策的方法指导。

软件行业很多重要的决策，如设计方案、采购方案等，都可以应用这个PA提供的办法，另外也可以在组织过程改进中应用决策分析的办法。

总结一下3级的几个重要特点：

1）明确规定了需求开发、设计、编码、测试、集成等软件开发各过程的要求。

2）对项目管理提出了更高的要求，要利用组织级的数据来管理项目。

3）出现了专门针对组织级的PA，要求有专门的组织来负责过程改进的工作。

4）提供了一个做出最佳决策的指导，而这个方法可以用于软件工程，也可以用于组织级过程改进。

由这些特点大家可以看到，3级已经对软件开发的各个方面有了详细的要求，2级很多不明细的地方全部已经明确。

一个达到3级的企业，肯定会定义了很多软件开发各个方面的过程，并且会有组织级的财富库。

所以3级叫“已定义”级。

补充说明：

3级还有另外3个PA上文没有提到，分别是

IntegratedTeaming、OrganizationalEnvironmentforIntegration：

对大型软件团队提出了要求，一般情况下中小型软件企业可以NA。

IntegratedSupplierManagement：

如果软件企业需要管理大量的供应商，则需要考虑这个PA。

这3个PA大部分情况下不需要考虑，将暂时不展开详细的讨论。

五、CMMI4级：

定量管理级

4级只有两个PA，就是：

   组织过程性能（OrganizationalProcessPerformance）

   定量项目管理（QuantitativeProjectManagement）

   OPP是对组织级的要求，组织需要统计出组织级的基线；

QPM是对项目的要求，项目要用组织级的基线来控制项目过程。

六、CMMI5级：

持续优化级

5级就只有OID和CAR两个PA，两个PA对3个可以提高企业生产力的途径进行了指引，只要把OID、CAR做好，企业就可以“持续改进”了。

其实一个软件企业，要提高生产力，有3方面途径：

     1）改进过程，使现有的过程更强更有效。

     2）引入新技术，提高生产力。

     3）对工作出出现的问题进行原因分析，避免以后再次出现。

OID-组织革新与部署（OrganizationalInnovationandDeployment）这个PA给出了明确的指引。

   工作中发现的每个问题，其实都是改进的机会，但实际工作中发现的问题可能非常多，需要选择最有价值的问题进行深入分析，并避免其再次发生。

通过不断地修复问题，组织的生产力就会不断提升。

  CAR--原因分析与解决方案（CausalAnalysisandResolution）这个PA给出了明确的指引。

附：

常见PA下SG。

PP项目计划：

SG1Estimatesofprojectplanningparametersareestablishedandmaintained.

建立和维护用于项目计划的各类参数的估算。

（建立估算）

SG2：

Aprojectplanisestablishedandmaintainedasthebasisformanagingtheproject.

建立和维护项目计划，这个计划要作为项目管理的基础。

（建立计划）

SG3：

Commitmentstotheprojectplanareestablishedandmaintained.

建立和维护对项目计划的承诺。

项目计划要被相关的人评审和认可。

（取得承诺）

PMC项目计划跟踪与控制

SG1:

Actualperformanceandprogressoftheprojectaremonitoredagainsttheprojectplan.

根据计划，跟踪项目的实际性能和过程。

SG2:

Correctiveactionsaremanagedtoclosurewhentheproject'sperformanceorresultsdeviatesignificantlyfromtheplan.项目的性能或者结果明显偏离计划时，要采取纠正措施保证按计划进行。

RM需求管理：

SG1Requirementsaremanagedandinconsistencieswithprojectplansandworkproductsareidentified.管理需求并且识别出需求与项目计划、工作产品不一致的地方。

这句话有两层意思：

1.需求要被管理，

被管理的意思又有两层：

一是需求要被确认，

二是要控制需求变更

2.需求要用来指导下游的工作产品，如：

计划、设计、测试等

MA度量

SG1:

Measurementobjectivesandactivitiesarealignedwithidentifiedinformationneedsandobjectives.这个SG主要讲述的是，组织级要明确实际的需要，定出度量的目标，并根据此目标，定义合适的度量方法、过程等。

SG2:

Mesurementresultstheadreessidentifiedinformationneedsandobjectivesareprovided.

这个SG主要讲述的是：

根据组织级定义的要求，进行度量工作，收集、分析、存储、报告度量信息等。

SG1主要从组织级的角度定义度量的做法，SG2就是按照已定义的做法，在实际工作中开展度量的工作。

CM配置管理

SG1:

Baselinesofidentifiedworkproductsareestablished.

建立已识别的工作产品的基线。

配置项与基线的区别：

配置项是需要进行配置管理的最小单位，如：

一份文档、一片段代码等。

基线是配置项的一种，基线需要进行更加严格的管理。

一般配置项的管理等级是：

权限控制、版本控制。

而基线的管理等级除了具备以上管理外，还需要非常严格的变更控制办法。

SG2:

Changestoworkproductsunderconfigrationmanagementandtrackedandcontrolled.

跟踪和控制置于配置管理系统下的工作产品的变更。

SG3:

Integrityofbaselinesisestablishedandmaintained.

建立和维护基线的完整性。

功能审计：

指工作产品是否满足一定的功能要求，这个工作一般不由配置管理员负责，

而是通过文档的评审、软件的测试进行。

物理审计：

就是检查工作产品是否符合格式、版本号等方面的要求，一般有配置管理元负责。

配置项要进入配置库前，都应该经历审计，保证其符合要求，保证后续工作产品的正确性。

如果是基线级别的工作产品要进入配置库，需要接受更加严格的审计。

PPQA产品与过程质量保证

SG1:

Adherenceoftheperformedprocessandassociatedworkproductsandservicestoapplicable

processdescriptions,standards,andproceduresisobjectivelyevaluated.

依据一定的标准的客观地评估被执行的过程与相应的工作产品。

这里要注意几点：

1）要有一定的标准，这是基础。

2）评估要客观。

3）要对过程、产品都进行评估

SG2:

Noncomplianceissuesareobjectivelytrackedandcommunicated,andresolutionisensured.

发现的问题要客观地被跟踪、沟通并解决。

RD需求开发

RD有三个SG，SG1开发客户需求，SG2开发产品需求，SG3分析和确认需求。

前两个SG讲述的是需求开发由顶而下、由粗到细的过程，SG3讲述的是需求分析和确认的过程。

SG1:

Stakeholderneeds,expectations,constraints,andinterfacesarecollectedandtranslatedinto

customerrequirements.干系人的需要、期望、约束和接口要求被收集并转化为客户需求。

SG2:

Customerrequirementsarerefinedandelaboratedtodevelopproductand

product-componentsrequirements.客户需精确和详细的，以用来开发产品需求和产品组件需求。

SG3:

Therequirementsareanalyzedandvalidated,andadefinitionofrequiredfunctionalityisdeveloped.需求被分析和确认，并定义出具体的功能性需求。

TS技术解决方案这个PA，主要讲述的是设计、开发、实施方面的问题。

在CMM中，对设计、开发、实施方面的要比较简单的。

SG1:

Productorproduct-componentsolutionsareselectedfromalternativesolutions.

从候选方案中选择产品或者产品组件的解决方案。

SG2:

Productorproduct-componentsdesignsaredeveloped.

开发产品或者产品组件设计。

SG3:

Productcomponents,andassociatedsupportdocumentation,areimplementedfromtheirdesigns.实施产品设计并开发相应的支持文档。

PI产品集成-简单的说就是把组成产品的所有软件组件组装起来，使之运行在目标环境上，

产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。

系统越复杂，集成就显得越发重要。

微软的每日构建，极限开发中的持续集成，都是对产品集成的基本原则，

其基本道理就是随时保证组成最终产品接口一致，能顺畅运行，能随时拿得出可运行的版本。

SG1Preparationforproductintegrationisconducted.准备产品的集成。

SG2Theproduct-componentinterfaces,bothinternalandexternal,arecompatible.

产品组件的接口，包括部和外部的，都是兼容。

SG1的SP的工作产品一般会是集成计划、接口说明、集成标准等文档，SG1的主要任务是完成这些文档，

而SG2的主要任务就是检查接口是否一致，并在发生接口变化的时候，管理接口的变化，使之保持一致。

SG3Verifiedproductcomponentsareassembledandtheintegrated,verified,and

validatedproductisdelivered.验证产品组件被装配和集成，经过验证和确认的产品被交付。

SG3主要讲的是执行集成的过程，并交付产品给客户。

VER确认

与验证不同，验证强调的是在开发过程中对工作产品进行检查，尽早发现问题。

而确认强调的是，在真实的使用环境中，确保软件能达到预期的效果。

开发环境与真实环境是不可避免存在差异的，为了有效地避免在开发环境中没有问题，但一到真实环境就出现问题的情况，确认的工作是非常重要的。

确认不一定在项目后期才进行，这个PA没有对确认的时间有任何的规定。

作为一般的常识，我们应该尽快安排软件的确认工作，如：

尽快发出一个小版本，在实际环境中运行起来，尽快发现确认中的问题。

一般来说，调试、试用、验收测试等都是确认的工作。

SG1Preparationforvalidationisconducted.准备确认工作。

SG2Theproductorproductcomponentsarevalidatedtoensurethattheysuitable

foruseintheirintendedoperatingenvironment.执行确认，确保产品或者产品组建在目标操作环境下满足使用的要求。

VAL验证

验证就是按照既定的标准，检查工作产品是否符合要求。

工作产品可能是文档也可能是软件本身。

而检查的办法

一般是同行评审或者是软件测试。

那什么是同行评审呢？

比方说：

A君是做软件设计的，B君也是做软件设计的，

A君写了一份设计文档，让B君这个同行（因为大家都是做设计的）来给给意见，这样就使同行评审。

同行评

审的目的就是让有同样工作经验和技能的人来评审自己的工作产品，发现尽量多的问题。

验证这个PA其目的是

希望软件企业在软件开发整个过程中，做好相应的检查工作，把尽量问题发现前面，保证了项目的可控性，降低

开发的成本。

这个PA有3个SpecificGoals,SG1讲述的是做好验证的准备，SG2、SG3分别讲述的是执行验

证的两种办法，一种是同行评审，一种是执行验证（通常就是测试）。

如果测试是在用户实际生产环境下进行的，

例如：

验收测试、客户试用系统等，这时这类工作就属于确认（Validation）了，

请参考关于“确认（Validation）”的容。

SG1Preparationforverificationisconducted.准备验证的工作。

SG2Peerreviewsareperformedonselectedworkworkproducts.对指定的工作产品进行同行评审。

SG3Selectedworkproductsareverifiedagainsttheirspecifiedrequirements.根据指定的要求验证工作产品。

这里的验证既包括同行评审也包括测试，但因为SG2专门是针对同行评审的，

这个SG可以理解成主要针对除了同行评审外的其它验证活动。

IPM

SG1Theprojectisconductedusingadefinedprocessthatistailoredfrom

theorganization’ssetofstandardprocess.

项目依据项目定义的过程执行，这个项目定义的过程是通过组织的标准过程裁剪出来的。

什么叫“项目定义过程”？

什么叫“裁剪”？

3级的软件企业，会有很多项目开发方面的各个过程，而且根据不同的情况，可能会有不同的过程。

也有可能同一个过程，允许不同类型的项目的做法或者执行的力度等不太一样。

组织过程中会有明确的]指导，告诉使用这个过程的项目，如何根据项目本身的特点，来选择或者制定自己项目应该执行的过程。

这个指导，就是裁剪指南，根据这个指导定义项目应该执行的过程，就是“裁剪”，定义出来的项目应该执行的过程就是“项目定义过程”。

“裁剪”不一定是减少步骤地，增加步骤，修改步骤等都是“裁剪”，注意是“裁剪”而不是“裁减”。

SG2Coordinationandcollaborationoftheprojectwithrelevantstakeholdersisconducted.

协调和项目相关的干系人

RSKM风险管理

RSKM有3个SG，SG1主要就是讲述组织级的要求，而SG2、SG3重点讲述项目如何进行风险管理活动。

SG1Preparationforriskmanagementisconducted.做好风险管理的准备。

SG2Risksareidentifiedandanalyzedtodeterminetheirrelativeimportance.

识别风险并分析决