CMMI-认证,cmmi认证多少钱

("需求管理域（REQM）SG1管理需求SP1.1获得对需求的理解（与需求提供者一起理解需求的定义）1.先判断需求提供者是否合适，即哪些人是合法的需求提供者，建立确认合适的需求提供者的准则。2.再判断提出的需求是否可接受，建立需求可接爱的准则。3.最后和需求提供者对需求达成一致理解。4.上述的准则可以定义在需注开发计划中，也可以体现为单独的检查单。5.该过程域的SP1.1SP1.2SP1.4在过程定义时可以放在需求开发过程中。SP1.3可以单独写一个过程，或者和配置管理的变更流程合并，SP1.5可以定在评审的过程中或问题处理的过程中。SP1.2获得对需求的承诺（取得项目成员对需求的承诺）1.此处的需求承诺是需求实现者对需求可实现的承诺不是客户对需求不变的承诺2.需求的承诺有2类时间点：一是需求刚建立时，二是需求变更时3.在需求承诺前，需要开发人员理解需求，一般SP1.1是本实践的基础4.承诺可以是书面的签字，也可以是电子的5.并非每个人都要对需求做出承诺，可以是项目组的核心成员作为代表6.开发组需要对客户有正式的承诺，该承诺一般体现在合同或项目任务书中7.开发人员的承诺可以是和计划的承诺合在一起，也可以单独承诺，承诺的时机可能不同SP1.3管理需求变更1.需求的变化是永恒的2.需求是渐变的，是积少成多的3.需求的小的变化也要管理4.不同规模的需注变更，控制的严格程度不同5.在组织内应该区分不同规模的需求变更，并定义不同的流程6.需求变更的重点是变更的波及范围分析，在做变更的影响分析时，要考虑对：其他需求、对设计、对编码、对测试、对进度、对工作量、对人员、对风险的影响7.需求变更要参考需求跟踪矩阵8.需求变更的控制组应该有客户参与9.客户的需求变更流程也应该规范10.在商务合同中要对需求变更的流程进行定义，规范双方的接口SP1.4维护需求的双向可跟踪性1.需求跟踪矩阵的主要作用验证需求的可实现性、可测试性进行需求变更的影响分析维护阶段，管理需求的变更2.何时使用需求跟踪矩阵需求、设计、测试用例评审时需求、设计、测试用例等变更时功能审计时3.需求跟踪矩阵分为纵向跟踪关系：客户需求到产品需求；需求到设计、测试用例、代码：需求责任分配横向跟踪关系：需求与需求之间的关系，该跟踪关系对产品集成过程有影响4.在需求、设计、测试用例评审时跟踪矩阵要一起评审SP1.5确认项目工作和需求间的差异1.在需求评审时、计划评审时、设计评审时、测试用例评审时要识别是否和需求一致2.在需求变更、设计变更、测试用例变更时，要判断是否和需求一致3.在日常工作中也可能发现和需求的不一致4.识别出的不一致问题要有记录，并跟踪问题的关闭项目规划（PP）SG1.项目估算SP1.1估算项目的范围SP1.2估算项目属性SP1.3定义项目生存周期阶段SP1.4估算工作量和成本SG2制定项目计划SP2.1编制预算和进度SP2.2识别项目风险SP2.3项目数据的管理计划SP2.4规划项目资源SP2.5知识和技能的计划SP2.6“项目干系人”的介入计划SG3获得对计划的承诺SP3.1审查从属计划SP3.2协调工作与资源配置SP3.3获得计划承诺如果对项目的范围、规模、性质、任务、工作量、费用等都不了解的情况下，是不可能做出计划的，所以做好计划的第一步就是要把这些东西搞清楚。SG1.项目估算，英文原文是：Estimatesofprojectplanningparametersareestablishedandmaintained.下面我们再详细看看，到底做计划之前，需要搞清楚什么东西？SP1.1：EstimatetheScopeoftheProject.估计项目的范围，如项目的目标、任务、工作产品等。这里通常就是指WBS(top-levelworkbreakdownstructure)，试想一下，我们做计划之前不是常常要先对任务进行分解吗？SP1.2:EstablishEstimatesofWorkProductandTaskAtrributes.估计工作产品及任务的属性。做计划的时，我们会先列出这个项目要产生的工作产品，以及这个项目要完成的任务等，然后我们需要分析这些任务、工作产品的规模、工作量、复杂度、代码行数等所谓的属性。CMMI并没有规定一定要分析什么属性，具体由企业自己来选择适合自己需要分析的属性。在CMM模型的时候，项目计划这个PA硬性规定了需要分析的几大属性，CMMI模型中已经改进，不再强制要求。分析这些属性的目的是对任务、工作产品等更加了解，以便于做好计划。SP1.3:Definetheprojectlife-cyclephasesuponwhichtoscopetheplanningeffort.定义项目生命周期。写计划的其中一个步骤是要考虑用什么生命周期模型，是瀑布型？螺旋？还是别的？选择怎样的模型，CMMI并没有规定，企业可以选择常见的生命周期模型，也可以自己定义自己的模型。SP1.4:Estimatetheprojecteffortandcostfortheworkproductsandtaskbasedonestimationrationale.可以把SP1.4看作是SP1.2的延续，要根据工作产品及任务的属性估算出项目的规模和成本。SG1说的是如何准备估算的问题，为做计划打好基础，而SG2说的就是要建立计划了。SG2.Aprojectplanisestablishedandmaintainedasthebasisformanagingtheproject.中文大意是：建立和维护项目计划，这个计划要作为项目管理的基础。那么项目计划要包含什么内容呢？SP2.1Establishandmaintaintheproject'sbudgetandschedule.建立和维护项目的预算和进度。SP2.2Identifyandanalyzeprojectriskes.识别和分析项目风险。SP2.3Planthenmanagemanetofprojectdata.计划对项目数据的管理。什么是“项目数据”呢？在项目开发过程中，会产生各类文档、代码等，我们再写项目计划的时候，要考虑好如何管理开发过程中产生的工作产品、数据等，例如存放的位置、访问权限控制。通常我们需要文档分类存放，设定一些个人工作区、项目组共享区等，计划好这些东西的管理，目的就是为了让工作更加有条理。细心的人可能会发现，这个SP怎么有点象CM这个PA呢？没错，CM也讲的也是管理工作产品，与这个SP是有相似之处的，CM是从配置管理的角度来讲述的，而这个SP就从项目管理的角度来讲述的。详细情况，我们再论述CM的时候再谈。SP2.4Planfornecessaryresourcestoperformtheproject.计划必要的资源来执行计划。资源包括：人、计算机、设备、工具、办公室等。SP2.5Planforknowledgeandskillsneededtoperformtheproject.计划需要的知识和技能来执行计划。这点经常是做计划的时候被遗忘的，项目经理应该根据项目组成员情况和项目的特点，找出项目组还没有掌握的知识和技能，安排需要的培训，让项目组成员掌握相应的技能。SP2.6Plantheinvolvementofindentifiedstakeholders.识别干系人并计划他们的参与。计划要考虑客户、高层领导、与本项目相关的第三方等相关人员可能的参与，规划他们参与的时间点，参与的工作产品等。例如：要计划客户什么时候参与需求调研，计划客户什么时候需要准备好软硬件环境，以便安装系统等。SP2.7Establishandmaintaintheoverallprojectplancontent.建立和维护全面项目计划内容。就是就是要把上面提到的SP2.1到SP2.6的内容全部要写下来，要文档化。到现在为止，似乎项目计划就完成了，是这样吗？项目计划只由一个人制定的吗？只跟一个人有关系吗？SG3.Commitmentstotheprojectplanareestablishedandmaintained.建立和维护对项目计划的承诺。项目计划要被相关的人评审和认可。SP3.1Reviewallplansthataffecttheprojecttounderstandprojectcommitments.项目计划可能会有好多个子计划，如开发计划、测试计划、培训计划等，这些计划都应该被相关人员复查，保证大家理解一致。SP3.2Reconciletheprojectplantoreflectavailableandestimatedresources.调整计划，使计划在有限的资源内是可行的。计划要受到资源的限制，通过评审要发现不协调的地方，适当调整计划，保证计划可行。SP3.3Obtaincommitmentfromrelevantstakeholdersresponsibleforperformingandsupportingplanexcecution.得到相关人员的承诺，保证执行和支持计划。计划通过评审，就以为这所有参加评审的人承诺按照计划的要求完成自己的任务，同时他也会支持他人按计划完成任务。PP有三个SG，分别是建立估算、建立计划、取得承诺，大家如果仔细阅读每个SP，大家会发现做好一个计划是不容易的，要考虑的东西很多。另外，还必须用这个计划来管理项目，更详细的内容我们看计划跟踪与控制这个PA吧。项目监控（PMC）SG1依据计划监督项目SP1.1监督项目计划的参数SP1.2监督承诺SP1.3监督项目风险SP1.4监督数据管理SP1.5监督干系人的介入SP1.6项目进展审查SP1.7里程碑审查SG2管理纠正措施SP2.1分析问题SP2.2采取纠正措施SP2.3管理纠正措施计划不是用来看的，是用来执行的。PP讲述了如何做计划，PMC讲述的就是如何跟踪计划的执行并在实际情况偏离计划时采取纠正行动。我们先看看SG1，SG1讲述的是如何根据计划来跟踪计划的执行问题。SG1.Actualperformanceandprogressoftheprojectaremonitoredagainsttheprojectplan.中文大意是：根据计划，跟踪项目的实际性能和过程。那么我们要跟踪计划什么内容呢？简单的说，计划里面写了什么东西，就要跟踪什么东西。我们回顾一下PP是怎样说项目计划有什么内容的？计划要有估算、进度、数据包的管理、技能准备、干系人的参与等内容，所以项目跟踪也需要踪以上内容。SP1.1Monitortheactualvaluesoftheprojectplanningparametersagainsttheprojectplan.项目计划的参数就是指项目的范围、规模、性质、任务、工作量、费用等，每个企业都可以根据实际需要确定这些参数。在项目进行过程中，要密切关注这些参数的实际情况与计划估计的情况是否一致。SP1.2Monitorcommitmentsagainstthoseidentifiedintheprojectplan.简单地说就是要跟踪项目成员承诺的任务是否按时间按要求完成，跟踪其他干系人是否能完成承诺的事情，如：第三方是否能如期交付软件、硬件、接口等。SP1.3Monitorriskagainstthoseidentifiedintheprojectplan.跟踪项目计划中已经识别出来的风险，要考虑风险是否发生了变化，同时也要考虑有没有新的风险产生。SP1.4Monitorthemanagementofprojectdataagainsttheprojectplan.项目计划中计划了数据包的管理，实际项目进展中，要落实这些工作。什么是数据包，请参考“项目计划”这个帖的说明。SP1.5Monitorstakeholderinvolvementagainsttheprojectplan.跟踪项目干系人的参与。如计划了什么时候要开始什么任务，什么时候客户要开始准备系统环境等，需要依据计划去跟踪。SP1.6Periodicallreviewtheproject'sprogress,performance,andissues.定期检查项目的进度、性能和问题。定期并不是指按照一定周期，只有有计划去检查，在某些时间点去做检查，就叫定期。另外什么是项目性能？简单的说就是项目按计划执行的实际能力，如任务完成能力、项目组成员的实际水平、文档的质量、代码的质量等。那什么是“issues(问题)”呢？凡是影响项目不能按计划进行的情况，都是问题。SP1.7Reviewtheaccomplishmentsandresultsoftheprojectatselectedprojectmilestones.在项目选定的里程碑检查项目情况。项目里程碑一般会是：需求确定、架构设计完成、软件发布等关键路径上的关键节点。SP1.6强调的是定期去检查项目状况，SP1.7强调的是要在关键节点检查项目状况，两个SP是有某种程度的重叠的。SG1讲述的是如何跟踪计划执行的，而SG2讲述的是当实际情况明显偏离计划的时候，要采取纠正行动。SG2.Correctiveactionsaremanagedtoclosurewhentheproject'sperformanceorresultsdeviatesignificantlyfromtheplan.中文大意是：项目的性能或者结果明显偏离计划时，要采取纠正措施保证按计划进行。SP2.1Collectandanalyzetheissuesanddeterminethecorrectiveactionsnecessarytoaddresstheissues.收集和分析问题，并确定必要的纠正措施来解决这些问题。SP2.2Takecorrectiveactiononidentifiedissues.针对识别出来的问题实施纠正行动。SP2.3Managecorrectiveactionstoclosure.管理纠正行动保证问题被解决。实际情况与计划情况有偏差是正常的，原因可能是计划本身做得不太好，也可能是实际工作没有到位。SG2强调的是要分析原因，找出问题根源，采取适当的行动，解决问题，使项目按照计划进行。通常情况下，偏离计划的情况大多数是进度推迟、预算变大等超出计划估计的情况，作为项目管理者不应该轻易改变计划，而使计划与实际一致，而是应该努力改善实际情况，否则计划的意义就丧失了。但凡事也有例外，确实有可能做计划的时候定了一个“不可能完成”的计划，这是就确实需要变更计划。但凡是涉及到预算变更、关键节点推迟等关键变化，公司应该制定严格的变更控制制度，公司高层应该参与这些关键变更的评审，以保证计划的严肃性。供应商协议管理(SAM)SG1签定供应商协议SP1.1确定采购方式SP1.2选择供应商SP1.3签定供应商协议SG2满足供应商协议SP2.1执行供应商协议SP2.2监督选定的供应过程SP2.3评价供应商产品SP2.4验收采购的产品SP2.5移交产品做软件开发的，不免要购买一些软硬件。软件可能是中间件、控件、插件、组件等，硬件可能是一些服务器、PDA、单片机等。只要稍微复杂的项目，都不可避免的会有采购的问题，就算目前没有采购，以后也会不可避免。另外也有可能把项目的一部分外包给第三方来做。作为一个想改进过程的企业，是不应该规避这个问题的。采购的软硬件或者是外包，都会从根本上影响项目的成本、进度和质量，采购和外包可以认为是风险最大的活动之一。那怎样才能把采购活动做好了？SAM有两个SG，第一个SG讲述的是要和供应商签署协议，第二个SG主要讲述的是履行供应商协议，下面我们详细介绍一下。SG1.Agreementwiththesuppliersareestablishedandmaintained.建立和维护与供应商的协议。SP1.1Determinethetypeofacquisitionforeachproductorproductcomponenttobeacqured.中文大意是：确定每个产品或者产品组件需要采购什么类型的东西。项目会因为技术原因、时间原因等需要采购一些软硬件来满足项目的需求。在前协议之前，应该先确定到底需要采购什么类型的东西。另外也可能把项目的一部分外包给第三方来做，那么也需要先确定外包什么东西。SP1.2Selectsuppliersbasedonanevaluationoftheirabilitytomeetthespecifiedrequirementsandestablishedcriteria.中文大意是：评估供应商是否具备满足指定的需求以及一定的标准，选择合适的供应商。选择供应商，首先是供应商必须能提供符合项目需求的产品或者服务。另外，采购通常是公司级的活动，或者会有专门的采购部门，采购活动本身会有一些对供应商的特定要求，如：资质、信誉等。选择合适的供应商，需要从这两方面来考虑。SP1.3Establishandmaintainformalagreementswiththesupplier.与供应商签订和维护正式的协议。确定要采购的内容，选定供应商后，就需要和供应商签订协议，明确双方权利义务了。协议同时会对供应商提供的产品和服务提出规格要求、时间要求、价钱要求等。这个协议非常重要，对双方具有法律效用，也是用来管理供应商活动的基准。SG2.Agreementswiththesuppliersaresatisfiedbyboththeprojectandthesupplier.中文大意是：与供应商签署的协议要满足项目组和供应商双方的要求。SP2.1ReviewcandidateCOTSproductstoensuretheysatisfythespecifiedrequirementsthatarecoveredunderasupplieragreement.检查候选的产品或者服务，保证其符合供应商协议中规定的要求。这个SP的关键点其实不是检查，而是需要在供应商协议中写清楚对产品或者服务的要求，越明确越好。要做好SP2.1，其实要先把SP1.3做好。SP2.2Performactivitieswiththesupplierasspecifiedinthesupplieragreement.执行供应商协议中制定的活动，例如什么时候交付样品、提交报告，什么时候付款等。由这条我们可以看到，签署供应商协议的时候，一定要把双方需要什么时候做什么事情写清楚，然后就要按照要求执行。SP2.3Ensurethatthesupplieragreementissatisfiedbeforeacceptingtheacquiredproduct.在接受产品之前，要确保满足供应商协议中的要求。简单的说，就是在接受产品或者服务之前要验收，验收的标准就是供应商协议中的要求。由这个SP我们可以看到，供应商协议需要列清楚验收的标准。SP2.4Transitiontheacquiredproductsfromthesuppliertotheproject.验收通过后，就把产品由供应商那里转交到项目的手中。转交一般会有一些签署交接单、运输、培训之类的工作，一般来说比较简单，但如果要交接的东西比较多，而且对运输要求高的，可能就比较复杂。SAM这个PA，简单的说可以分为4点：1)分析项目什么东西需要采购或者外包。2)选择合适的供应商。3)和供应商签署协议，协议要写明产品规格要求、验收要求、双方的活动、交付要求等，尽可能明细。4)履行供应商协议。度量分析（MA）SG协调度量和分析活动SP1.1确定度量目标SP1.2细化度量SP1.3确定数据收集和存储规程SP1.4确定分析规程SG2提供度量结果SP2.1收集度量数据SP2.2分析度量数据SP2.3存储数据和度量结果CMMI在2级就已经出现对度量方面的要求了，在CMM的时候，没有专门的KPA描述度量的要求，因为这样曾出现过一些2、3级做得很好的企业，要花几倍的功夫才能做到4、5级，主要是因为度量的工作之前没有打好基础。我们来看看，CMMI2级的MA，有怎样的一些要求。SG1.Measurementobjectivesandactivitiesarealignedwithidentifiedinformationneedsandobjectives.这个SG主要讲述的是，组织级要明确实际的需要，定出度量的目标，并根据此目标，定义合适的度量方法、过程等。SP1.1Establishandmaintainmeasurementobjectivesthatarederivedfromindentifiedinformationneedsandobjectives.建立和维护度量目标，这些度量目标是源自特定的需要的。如：质量、进度、成本是项目管理的三大要素，为了更好地管理这三个方面，可能需要分别对这些方面采取度量手段。也就是说，采取任何度量手段之前，要考虑清楚为什么要进行这个度量。SP1.2Specifymeasurestoaddressthemeasurementobjectives.制定度量办法满足度量目标的要求。明确了为什么要进行度量后，要把度量目标转化成可以实际操作的具体的度量办法。如：度量的目的是，要保证软件的质量，为了实现这么目标，定义出对缺陷进行度量、对评审发现的问题进行度量等度量办法。SP1.3Specifyhowmeasurementdatawillbeobtainedandstored.制定度量数据的收集及存储办法。SP1.4Specifyhowmeasurementdatawillbeanalyedandreported.制定度量数据的分析和报告方法。SG2.Mesurementresultstheadreessidentifiedinformationneedsandobjectivesareprovided.这个SG主要讲述的是：根据组织级定义的要求，进行度量工作，收集、分析、存储、报告度量信息等。SP2.1Obtainspecifiedmeasurementdata.收集指定的度量数据。要根据SP1.3指定的收集办法来收集度量数据。SP2.2Analyzeandinterpretmeasurementdata.分析和说明度量数据。根据SP1.4指定的办法，对度量数据进行分析，并说明这些数据的意义。SP2.3Manageandstoremeasurementdata,measurementspecifications,andanalysisresults.管理和存储度量数据、度量规范及度量结果。根据SP1.3指定的存储办法，对度量数据及相关文档进行存储和管理。SP2.4Reportresultsofmeasurementandanalysisactivitiestoallrelevantstakeholders.向相关人员报告度量结果及分析度量活动情况。度量的数据、情况，需要让该知道的人知道。SG1主要从组织级的角度定义度量的做法，SG2就是按照已定义的做法，在实际工作中开展度量的工作。度量工作有很多学问，所有的度量工作，都需要回答这些问题：1.度量的目的是什么？2.谁来做这个度量？3.什么时候做这个度量？4.如何做这个度量？5.怎样记录度量的数据？记录到哪里？6.谁会使用这些数据？7.如何分析这些数据？8.谁来分析这些数据？9.分析的结果如何使用？以上的这些问题，其实都可以找到与之对应的SP。过程和产品质量保证（PPQA）SG1客观地评价过程和工作成果SP1.1客观地评价过程SP1.2客观地评价工作成果和服务SG2提供客观的洞察SP2.1通报不符合项，并确保得到解决SP2.2建立记录SG1.Adherenceoftheperformedprocessandassociatedworkproductsandservicestoapplicableprocessdescriptions,standards,andproceduresisobjectivelyevaluated.中文大意是：依据一定的标准的客观地评估被执行的过程及相应的工作产品。这里要注意几点：1)要有一定的标准，这是基础。2)评估要客观。3)要对过程、产品都进行评估。SP1.1Objectivelyevaluatethedesignedperformedprocessesagainsttheapplicableprocessdescriptions,standards,andprocedures.中文大意是：依据一定的标准客观地评价过程。SP1.2Objectivelyevaluatethedesignatedworkproductsandservicesagainsttheapplicableprocessdescriptions,standards,andprocedures.中文大意是：依据一定的标准客观地评价工作产品。如何检查软件生产活动，保证按照组织的相应规定进行了，无非就是两个方面，一个是看看活动的过程是否按照组织的要求进行，另外一个方面就是看看活动过程中产生的工作产品是否符合组织的要求，例如是否符合模板要求、是否有要求的内容等。这两个SP看上去简单，其实要做好，要做到两点：1)组织定义的过程、工作产品的模版一定要明确、合理，并且具有可检查性。2)QA对要理解要检查的过程和工作产品。SG2.Noncomplianceissuesareobjectivelytrackedandcommunicated,andresolutionisensured.中文大意是：发现的问题要客观地被跟踪、沟通并解决。SP2.1:Communicatequalityissuesandensureresolutionofnoncomplianceissueswiththestaffandmanagers.中文大意是：要和员工和管理者进行沟通，并保证解决问题。这个SP有两点要求：1.QA发现的问题一定要与相关的员工和管理者进行有效的沟通。2.要保证发现的问题最后被解决。SP2.2:Establishandmaitainrecordsofthequalityassuranceactivities.中文大意是：建立和维护质量保证活动的记录。PPQA只有4个SP，非常简单，但要做好很不容易，下面列举一下QA工作中常见的问题：1.QA与被检查者的关系不好。2.被检查者以应付的心态应付QA的检查。3.QA经常埋怨被检查者不按规定干活。4.被检查者埋怨QA不理解项目的状况，指挥按条条框框办事。这些问题，总结起来无非是以下的原因：1.过程本身制定就很有问题，很难按照过程执行。2.QA缺少软件开发经验，对过程理解不深。3.QA没有更关注问题的预防，在过程未进行之前，没有对执行过程者进行相应的教育，让过程执行者明白这个过程的道理。4.QA没有去了解项目的背景以及相关的技术，无法对项目组成员提供有效的执行过程的指导，只能依据条条框框进行指引，项目组无法理解过程的价值。简单的说只有两个方面，一个就是过程本身的质量，一方面就是QA的水平了。有人可能会说，过程就算是错的，也需要执行，在执行中持续改进。这个观点在某些情况下是不对的，要看过程错的程度。如果过程错到根本无法执行，这样强硬执行的话，肯定吃力不讨好。在刚建立过程的时候，不宜太死，可以适当宽松，另外应该鼓励项目组定义自己的做法，然后QA就按照项目组自已定义的做法来监督执行。通过不断的积累，就可以建立比较完善的过程。配置管理（CM）SG1建立基线SP1.1识别配置项SP1.2建立配置管理系统SP1.3创建或发布基线SG2跟踪并控制变更SP2.1跟踪变更要求SP2.2控制变更SG3建立完整性SP3.1建立配置管理记录SP3.2执行配置审计配置管理的概念非常多，我们可不愿意做理论家，我们是非常务实的，我们先看看，如果没有有效的配置管理，可能会出现什么问题：1)软件在开发环境没有问题，测试的时候也没有问题，但发布给客户的时候就有问题。2)修改一个缺陷后，以前已经解决的缺陷又再次出现。3)以前已经搞定的问题，无缘无故再次出现。4)需求变更后，必须问最熟悉的人才知道需要修改那部分的文档、代码来实现新的需求。5)找不回之前某个版本的设计、代码。配置管理无非就是解决这些问题嘛，于是有人便用了一些什么工具，建立了什么基线，成立了什么变更控制委员会，对所有的变更进行严格的控制。这时有出现了以下问题：项目组苦不堪言，调整一下计划都需要提什么变更申请，修改什么设计文档也要经过一番审批，天啊，配置管理就是这样的吗？配置管理是对软件生产过程中的各类工作产品进行管理的办法，要做这个工作之前，应该先理清楚到底会有什么工作产品，这些工作产品的依赖关系是怎样的，哪些是重要的工作产品，不同的工作产品需要什么层次的管理。大概有以下的管理层次：1)不需要管理的。2)需要保存起来便可。3)要保存起来，并且要对访问权限进行控制，可能某些人只能读，某些人能读写。4)需要进行版本管理。5)需要进行基线级别的管理，即需要进行变更申请。大家可以看到，配置管理其实很讲学问的，要做好配置管理工作，先要把工作产品的依赖关系画出来，找出关键的工作产品，然后决定每个工作产品需要的管理层次。这些考虑好后，才考虑用什么工具对工作产品进行管理。SG1.Baselinesofidentifiedworkproductsareestablished.建立已识别的工作产品的基线。配置项与基线的区别：配置项是需要进行配置管理的最小单位，如：一份文档、一片段代码等。基线是配置项的一种，基线需要进行更加严格的管理。一般配置项的管理等级是：权限控制、版本控制。而基线的管理等级除了具备以上管理外，还需要非常严格的变更控制办法。SP1.1Identifytheconfigurationitems,components,andrelatedworkproductsthatwillbeplacedunderconfigurationmanagement.识别需要放于配置管理系统中的配置项、组件和相关工作产品。SP1.2Establishandmaintainaconfigurationmanagementandchangemanagementsystemforcontrolingworkproducts.中文大意是：建立和维护一个配置管理系统，用于控制工作产品。SP1.3Createorreleasebaselinesforinternaluseandfordeliverytothecustomer.建立和释放基线，用于内部使用或者交付给客户。做好配置管理工作，首先做好两步：1)识别需要进行配置管理的东西。2)建立一个配置管理系统来管理需要进行配置管理的东西。然后做好两个事情：1)对一般的配置项进行管理。2)对基线级别的配置项进行基线级别的管理。SG2.Changestoworkproductsunderconfigrationmanagementandtrackedandcontrolled.跟踪和控制置于配置管理系统下的工作产品的变更。SP2.1Trackchangerequestsfortheconfigurationitems.跟踪配置项的变更需求。例如：记录变更的原因、时间、提出人等。SP2.2Controlchangestotheconfigurationitems.控制配置项的变更。一个配置项发生了变化，与它相关的配置项也会可能需要相应改变，需要跟踪和控制整个过程，直到全部变化结束。SP2.1SP2.2并没有明确指出是针对配置项还是针对基线的，其实两者都使用，不过是针对配置项还是基线，都需要记录变更需求，另外要跟踪和控制变化，只是针对配置项和针对基线，做的程度不太一样而已。SG3.Integrityofbaselinesisestablishedandmaintained.建立和维护基线的完整性。什么意思呢？我们看看下面两个SP就知道了。SP3.1Establishandmaintainrecordsdescribingconfigurationitems.建立和维护描述配置项的记录。简单的说，所有的配置管理活动，如变更需求、控制变化的过程、配置项状态等都需要进行必要的记录。SP3.2Performconfigurationauditstomaintainintegrityoftheconfigurationbaselines.执行配置审计来维护配置基线的完整性。什么叫配置审计呢？配置审计分为功能审计和物理审计。功能审计：指工作产品是否满足一定的功能要求，这个工作一般不由配置管理员负责，而是通过文档的评审、软件的测试进行。物理审计：就是检查工作产品是否符合格式、版本号等方面的要求，一般有配置管理元负责。配置项要进入配置库前，都应该经历审计，保证其符合要求，保证后续工作产品的正确性。如果是基线级别的工作产品要进入配置库，需要接受更加严格的审计。需求开发（RD）SG1开发客户需求SP1.1获取客户的需要SP1.2生成客户需求SG2开发产品需求SP2.1建立产品需求和构件需求SP2.2分配产品构件需求SP2.3确定接口需求SG3分析和确认需求SP3.1建立操作概念和场景SP3.2定义功能需求SP3.3分析需求SP3.4平衡需求SP3.5确认需求CMM的时候，是没有需求开发这个PA的，需求开发和需求管理有什么区别呢？需求管理强调的是需求的确认以及需求变更的控制，而需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。以上两个关于需求开发的例子，都是反面教材，都没有能很好地把握需求，一个没有抓住问题的关键，一个没有能找到真正的需求提供者来获取需求。CMMI和CMM相比，增加了很多专门针对软件工程的PA，其中需求开发(RD)就是其中之一。需求开发这个PA，从很高的层次描述了如何做好需求开发。要理解好本PA，需要先理解清楚以下几个关键的概念：1)客户需求(CustomerRequirements)2)产品需求(ProductRequirements)3)产品组件需求(ProductComponentRequirements)客户需求是可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户的需要是什么。产品需求是能满足客户需求，并对软件产品规格进行了详细描述的需求，软件设计师可以根据产品需求进行设计、编码等工作。产品组件需求，是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等，这些可以认为是产品组件需求。从另外一个角度，需求可以分为功能性需求和非功能性需求两类，功能性需求就是系统具备怎样的功能，能做什么事情，而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求，都会包含功能需求和非功能需求。以前面提到的“短信订餐系统”为例，其实这个系统，客户需求很简单，就是要解决部分员工不方便订餐的问题。我们看到，如果我们没有抓住这个客户需求，一开始就认为非要做一个短讯系统，那么就会陷入例子的陷阱中。要解决这个客户需求，办法之一就是做短讯订餐系统，但更合适的办法可能就是打电话回公司让别人代订午饭了。我们很多需求开发没有做好的原因，大部分是没有把握好客户需求，直接进入软件的细节，去讨论要做什么功能，界面要怎样设计去了，而忘记了软件的根本目的是为了解决什么问题。当我们明确客户需求后，就应该把客户需求转变成产品需求和产品组件需求，客户需求一般都是比较高层次的，而且描述也会比较简单，不能作为日后验收的标准，我们需要对软件的规格进行说明。一般来说，我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候，要注意产品需求和产品组件需求，必须和客户需求对应起来，通常是多对多的关系。为什么要对应起来？我们要保证，软件的每一个界面，每一个功能都是有用的，都是“源自”客户需求的，这样才能保证我们做的事情都是正确的事情，防止被不相干的事情干扰。我们经常抱怨客户的需求在变，其实80%的原因是没有把握住客户需求，其实客户经常变的是产品需求或者是产品组件需求，客户需求是很少变的，就是因为我们没有把握住客户到底想要什么、需要什么，导致我们认为客户太难“服侍”了。只有把握住客户真正的需求，我们才能抓住根本，万变不离其中。接着下来，我们将从每个SG和每个SP来详细讲解需求开发这个PARD有三个SG，SG1开发客户需求，SG2开发产品需求，SG3分析和确认需求。前两个SG讲述的是需求开发由顶而下、由粗到细的过程，SG3讲述的是需求分析和确认的过程。下面详细阐述：SG1.Stakeholderneeds,expectations,constraints,andinterfacesarecollectedandtranslatedintocustomerrequirements.干系人的需要、期望、约束和接口要求被收集并转化为客户需求。SP1.1Elicitstakeholderneeds,expectations,constrains,andinterfacesforallphasesoftheproductlifecycle.导出干系人对整个产品生命周期各阶段的需要、期望、约束和接口要求等。这句话要包含了几个要点：1)干系人：干系人除了指甲方的领导、系统的最终用户，还包括使用本系统的第三方以及与本系统有交互的第三方系统的拥有者、使用者等。2)产品生命周期各阶段：干系人对系统的期望不一定只限于软件功能的，可能还包括数据的整理、资料录入、安装培训、维护要求等，干系人可能对软件生产的过程阶段都会提出他的要求，获取需求的时候，要注意干系人在软件生命周期不同阶段有什么要求。3)需要、期望、约束、接口要求：甲方一般会对系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性，满足一些什么接口要求和约束条件等，都会有大致的想法。需求调研工作，首先要注意搞清楚这些内容。4)导出：客户的原始想法可能是不明确的，或者是客户一时难表达完整的，我们需要用一定的方法，让客户能完整无遗漏准确地表达出他的想法。通常我们可以通过原型、图示、类比、问卷等办法来导出客户的需求。SP1.2Transformstakeholderneeds,expectations,constraints,andinterfacesintocustomerrequirements.转化干系人的需要、期望、约束和接口要求为客户需求。SP1.1讲述的是通过一些方法记录客户原始的需求信息，而SP1.2讲述的就是把客户原始的需求信息整理成正式的客户需求，通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。SG2.Customerrequirementsarerefinedandelaboratedtodevelopproductandproduct-componentsrequirements.客户需求是精确和详细的，以用来开发产品需求和产品组件需求。SG1讲述的是导出客户需求，而SG2讲述的是由客户需求到产品需求、产品组件需求的过程。SP2.1Establishandmaintainproductandproduct-componentrequirements,whicharebasedonthecustomerrequirements.建立和维护产品和产品组件需求，这些产品和产品组件需求是基于客户需求的。产品和产品组件需求，是比较细致的需求，会详细描述软件与用户是怎样交互的，用户需要输入什么，系统会输出什么等都会比较详细描述出来。而客户需求一般只描述能实现什么功能、解决什么问题等，比较高层次。客户需求一般是难以验证是否已实现的，而产品需求和产品组件需求是对软件规格的描述，是可以用来做为验收的标准的。SP2.2Allocatetherequirementsforeachproductcomponent.分配需求给每一个产品组件。这个SP将需求开发与技术解决方案联系起来，所有的需求应该与设计的产品组件对应起来，保证需求驱动后续的设计工作，同时也保证设计都是为了需求服务的。SP2.2是对SP2.1的进一步细化。SP2.3Identifyinterfacerequirements定义接口需求。接口需求包括系统与第三方的系统的接口要求，也包括系统本身各组件、各子系统、各部分之间的接口要求。通常这些接口需求在客户需求级别的时候，并不是很明细，需要对客户需求进一步细分成产品需求、产品组件需求，然后发掘出接口需求。SP2.3也是对SP2.1的进一步深化。SG3.Therequirementsareanalyzedandvalidated,andadefinitionofrequiredfunctionalityisdeveloped.需求被分析和确认，并定义出具体的功能性需求。SP3.1Establishandmaintainoperationalconceptsandassociatedscenarios.建立和维护操作场景及相关情景。SP3.2Establishandmaintainadefinitionofrequiredfunctionality.建立和维护功能定义。SP3.1和SP3.2是对需求描述的要求，要求描述出具体需求的操作场景、上下文，具体的操作步骤，对功能的详细描述等。通常我们可以通过UML的UseCase图或者是序列图等来表达这些内容。SP3.3Analyzerequirementstoensurethattheyarenecessaryandsufficient.分析需求以确认需求是必须和充分的。SP3.4Analyzerequirementstobalancestakeholderneedsandconstrains.分析需求平衡以平衡干系人的需要和约束。SP3.3和SP3.4是对需求的准确性、全面性、可实现性方面的要求，除了要取得全面准确地需求，还需要平衡约束条件，保证需求在约束条件下是可实现的。SP3.5Validaterequirementstoensuretheresultingproductwillperformasintendedintheuser'senvironmentusingmultipletechniquesasappropriate.用各种合适的方法确认需求，确保最终产品能在用户的环境中按照设想运行。这是需求开发的最后一步了，需求导出过程中尽管用了很多办法，但需求确认的时候，仍然需要采取办法确保获取的需求是符合最终的使用场景要求。SP3.3、SP3.4和SP3.5，通常是通过需求评审来满足的。技术方案（TS）SG1选择产品构件方案SP1.1开发候选方案和选择准则SP1.2选择产品构件方案SG2设计SP2.1设计产品或构件SP2.2建立技术数据包SP2.3设计接口SP2.4分析“制作、购买或重用”SG3实现产品设计SP3.1实现构件的设计SP3.2编写产品支持文档项目工期紧，常常成为很多事情的理由。因为赶时间，拿到需求后，不考虑哪种设计方案更合适，想到什么办法就用什么办法来做，甚至是没有设计可言，直接编码，写设计文档变成了浪费时间的一个事情。我面试过很多应聘我们公司软件设计师职位的人，不少人进行设计的时候，眼光都放得不够开，不知道微软提供了很多可重用的代码，直接自己编码实现数据操作、日志处理、权限认证等事情，结果浪费了时间，而且还不能保证自己的代码是没有问题的。微软的代码都是经过严格测试的，设计架构良好的，可直接使用或者稍加修改则可以为自己所用。不知道您的工作中，在设计方面是否有这样的一些问题：1)无设计文档2)有设计文档，但形同虚设3)设计时没有考虑可以重用以前项目或者第三方的代码或组件4)没有用需求来驱动设计5)设计没有考虑多过一个的方案6)没有考虑清楚设计的原则和标准7)设计的弹性不够、架构落后？8)代码与设计脱节？9)到处都是面条式代码......请大家一起来列举一下设计、编码方面的“罪状”。技术解决方案这个PA，主要讲述的是设计、开发、实施方面的问题。在CMM中，对设计、开发、实施方面的要求是比较简单的。SG1.Productorproduct-componentsolutionsareselectedfromalternativesolutions.从候选方案中选择产品或者产品组件的解决方案。这个目标的主要内容就是制定选择的标准，设计候选方案，针对产规格依据选择标准，从候选方案中选出合适的方案。SP1.1Developdetailedalternativesolutionsandselectioncriteria.开发详细的候选方案及选择的标准。SP1.2Evolvetheoperationalconcept,scenarios,andenvironmentstodescribetheconditions,operatingmodes,andoperatingstatesspecifictoeachproductcomponent.针对每个产品组件描述操作概念、场景、环境、操作模式和操作状态等。SP1.3Selecttheproduct-componentsolutionsthatbestsatisfythecriteriaestablished.选择最符合要求的产品组件设计方案。SG1讲述的是如何找出最合适的设计方案，我们很多开发人员，做编码之前都不太喜欢认真思考设计方案，迫于时间压力，不仔细考虑设计方案是否合适，就直接开展工作，这样做的风险是非常大的。SP1.1讲述的是先考虑好我们设计方案的选择标准，并找出可能的候选方案。SP1.2要求我们对产品的规格进行详细的表述，因为我们的方案是要满足这些规格的，也只有这样，我们才能更好地找出合适的解决方案。SP1.3讲述的就是根据选择标准选出最佳方案。有人可能有这样的疑问，有些项目很简单，或者设计方案很明确，没有必要搞什么候选方案和选择标准，直接设计就可以了。设计方案除了针对整个项目的大的设计方案，还包括组成产品的各个组件的设计方案，绝大部分情况下，一个项目肯定会有部分地方技术不太明确需要仔细分析的。另外，不管怎样，都应该根据项目的实际情况，定出这个项目的设计标准，就算只有一个方案，也需要用该设计标准来检验该方案。大部分情况下，认为不需要考虑多个设计方案、不考虑设计标准，都是“懒惰”思想作怪，不做这样的考虑，项目的风险是比较大的。SG2.Productorproduct-componentsdesignsaredeveloped.开发品或者产品组件设计。最佳候选方案确定后，就可以开展具体的设计工作了。SP2.1Developadesignfortheproductorproductcomponents.开发产品或者产品组件的设计。SP2.2Establishandmaintainatechnicaldatapackage.建立和维护技术数据包。这个Practice的字面意思比较难理解，其实意思很简单，就是要建立和维护一套管理所有设计文档、数据的方法或者体制，对设计过程的数据、文档进行有效的管理。SP2.3Designcomprehensiveproduct-componentinterfacesintermsofestablishedandmaintainedcriteria.根据所建立和维护的标准，设计合适的产品组件接口。SP2.4Evaluatewhethertheproductcomponentsshouldbedeveloped,purchased,orresuedbasedonestablishedcriteria.根据制定的标准评估哪些产品组件需要开发、购买或者重用。SG3.Productcomponents,andassociatedsupportdocumentation,areimplementedfromtheirdesigns.实施产品设计并开发相应的支持文档。SP3.1Implementthedesignsoftheproductcomponents.实施产品组件的设计，简单地说就是依据设计进行编码活动了。SP3.2Developandmaintaintheend-usedocumentation.开发和维护最终用户文档，如用户手册、安装手册、管理员手册等。产品集成（PI）SG1准备产品集成SP1.1确定集成次序SP1.2建立产品集成环境SP1.3建立产品集成规程和准则SG确保接口兼容SP2.1审查接口描述的完备性SP2.2管理接口SG3组装产品构件和交付产品SP3.1确认产品集成已准备就绪SP3.2组装产品构件SP3.3核查组装的产品构件SP3.4打包并交付产品或构件什么是产品集成？简单的说就是把组成产品的所有软件组件组装起来，使之运行在目标环境上，产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。系统越复杂，集成就显得越发重要。微软的每日构建，极限开发中的持续集成，都是对产品集成的基本原则，其基本道理就是随时保证组成最终产品接口一致，能顺畅运行，能随时拿得出可运行的版本。SG1.Preparationforproductintegrationisconducted.准备产品的集成。SP1.1Determinetheproduct-componentintegrationsequence.决定产品组件的集成顺序。如：要考虑清楚先编译那个组件，哪个组件和哪个先联调，然后加入哪个组件调试，最后怎样进行整体联调，要把次序考虑清楚。SP1.2Establishandmaintaintheenvironmentneededtosupporttheintegrationoftheproductcomponents.建立和维护用于支持产品组件集成的环境。这些环境包括硬件环境、网络环境、数据环境等。SP1.3Establishandmaintainproceduresandcriteriaforintegrationoftheproductcomponents.建立和维护产品组件集成的过程及标准。这里提到了过程，与SP1.1似乎有点重复，SP1.1只强调考虑集成的现有顺序，而SP1.3要需要考虑具体的集成过程，除了集成顺序，还需要考虑每一步的验证办法、成功标准等。SG2.Theproduct-componentinterfaces,bothinternalandexternal,arecompatible.产品组件的接口，包括内部和外部的，都是兼容。SG1的SP的工作产品一般会是集成计划、接口说明、集成标准等文档，SG1的主要任务是完成这些文档，而SG2的主要任务就是检查接口是否一致，并在发生接口变化的时候，管理接口的变化，使之保持一致。SP2.1Reviewinterfacedescriptionforcoverageandcompleteness.检查接口描述，保证覆盖性和完整性。通常我们通过评审接口说明的办法来检查接口的完整性、覆盖性。SP2.2Manageinternalandexternalinterfacedefinitions,designs,andchangesforproductsandproductcomponents.管理产品和产品组件的内部和外部接口的定义、设计及变更。各组件之间是有关系的，我们需要对这些关系进行管理，保证组件间保持一致。SG3.Verifiedproductcomponentsareassembledandtheintegrated,verified,andvalidatedproductisdelivered.验证产品组件被装配和集成，经过验证和确认的产品被交付。SG3主要讲的是执行集成的过程，并交付产品给客户。SP3.1Confirm,priortoassembly,thateachproductcomponentrequiredtoassembletheproducthasbeenproperlyidentified,functionsaccordingtoitsdescription,andthattheproduct-componentinterfacescomplywiththeinterfacedescriptions.在装配之前，确认每一个被装配的产品组件已经被清楚定义，各功能符合描述要求、产品组件接口符合接口描述的要求。简单的说就是在集成前，做全面的检查工作，保证各部分符合既定的要求。SP3.2Assembleproductcomponentsaccordingtotheproductintegrationsequenceandavailableprocedures.根据产品集成顺序和相关过程集成产品组件。SP3.3Evaluateassembledproductcomponentsforinterfacecompatibility.评估产品组件的接口兼容性。SP3.4Packagetheassembledproductorproductcomponentanddeliverittotheappropriatecustomer.打包组装的产品和产品组件并交付给合适的用户。验证（VER）SG1准备验证SP1.1准备同行评审SP1.2建立验证环境SP1.3建立验证规程和准则SG2执行同行评审SP2.1准备同行评审SP2.2执行同行评审SP2.3分析同行评审数据SG3验证选定的工作成果SP3.1执行验证SP3.2分析验证结果验证就是按照既定的标准，检查工作产品是否符合要求。工作产品可能是文档也可能是软件本身。而检查的办法一般是同行评审或者是软件测试。那什么是同行评审呢？比方说：A君是做软件设计的，B君也是做软件设计的，A君写了一份设计文档，让B君这个同行（因为大家都是做设计的）来给给意见，这样就使同行评审。同行评审的目的就是让有同样工作经验和技能的人来评审自己的工作产品，发现尽量多的问题。验证这个PA其目的是希望软件企业在软件开发整个过程中，做好相应的检查工作，把尽量问题发现前面，保证了项目的可控性，降低开发的成本。这个PA有3个SpecificGoals,SG1讲述的是做好验证的准备，SG2、SG3分别讲述的是执行验证的两种办法，一种是同行评审，一种是执行验证（通常就是测试）。如果测试是在用户实际生产环境下进行的，例如：验收测试、客户试用系统等，这时这类工作就属于确认(Validation)了，请参考关于“确认(Validation)”的帖。SG1.Preparationforverificationisconducted.准备验证的工作。SP1.1Selecttheworkproductstobeverifiedandtheverifactionmethordsthatwillbeusedforeach.选择需要验证的工作产品以及每个工作产品的验证办法。组织会定义要进行同行评审的工作产品，如：计划文档、需求文档、设计文档、代码等，并且规定了每种文档的同行评审办法。组织也会定义需要进行测试的软件产品，比方说要进行单元测试、集成测试、系统测试等。SP1.2Establishandmaintaintheenvironmentneededtosupportverification.建立和维护支持验证所需的环境。对于同行评审来说，支持环境可能就是会议室、投影、电脑、事先准备好的文档等。对于测试来说，支持环境可能就是测试的软件环境、数据环境、硬件环境等。SP1.3Establishandmaintainverificationproceduresandcriteriafortheselectedworkproducts.建立和维护工作产品的验证过程及准则。对于同行评审来说，验证过程就是同行评审开展的过程相关规定，如要事先发资料、通知大家到会、会议的组织、会议记录等等，准则可能就是每个工作产品的评审标准。对于测试来说，验证过程就是测试过程的相关规定，准则就是需求规格说明书，或者说是测试通过的标准。SG2.Peerreviewsareperformedonselectedworkworkproducts.对指定的工作产品进行同行评审。SP2.1Prepareforpeerreviewsofselectedworkproducts.做好同行评审的准备。如：把要评审的文档实现发给大家，准备好会议议程，准备好会议室、投影仪等。SP2.2Conductpeerreviewsonselectedworkproductsandidentifyissuesresultingfromthepeerreview.执行同行评审并识别同行评审中发现的问题。SP2.3Analyzedataaboutpreparation,conduct,andresultsofthepeerreviews.分析在同行评审准备、执行、结果方面的数据。例如：记录评审的准备、进行时间，发现的问题数量，对每个问题进行分析等。SG3.Selectedworkproductsareverifiedagainsttheirspecifiedrequirements.根据指定的要求验证工作产品。这里的验证既包括同行评审也包括测试，但因为SG2专门是针对同行评审的，这个SG可以理解成主要针对除了同行评审外的其它验证活动。SP3.1Performverificationontheselectedworkproducts.对指定的工作产品进行验证。如：执行单元测试、集成测试、系统测试等。SP3.2Analyzetheresultsofallverificationactivitiesandidentifycorrectiveaction.分析验证的结果，并制定修正计划。这里强调的是：除了要分析发现的问题外，还需要采取行动修正这些问题。确认（VAL）SG1准备确认SP1.1选择待确认的产品SP1.2建立确认环境SP1.3建立确认规程和准则SG2确认产品或构件SP2.1执行确认SP2.2分析确认结果与验证不同，验证强调的是在开发过程中对工作产品进行检查，尽早发现问题。而确认强调的是，在真实的使用环境中，确保软件能达到预期的效果。开发环境与真实环境是不可避免存在差异的，为了有效地避免在开发环境中没有问题，但一到真实环境就出现问题的情况，确认的工作是非常重要的。确认不一定在项目后期才进行，这个PA没有对确认的时间有任何的规定。作为一般的常识，我们应该尽快安排软件的确认工作，如：尽快发出一个小版本，在实际环境中运行起来，尽快发现确认中的问题。一般来说，调试、试用、验收测试等都是确认的工作。SG1.Preparationforvalidationisconducted.准备确认工作。SP1.1Selectproductsandproductcomponentstobevalidatedandthevalidationmethodsthatwillbeusedforeach.选择需要确认的产品、产品组件以及确认的方法。SP1.2Establishandmaintaintheenvironmentneededtosupportvalidation.建立和维护支持确认的环境，如试用环境、验收环境的准备等。SP1.3Establishandmaintainproceduresandcriteriaforvalication.建立和维护确认的过程及确认准则。SG2.Theproductorproductcomponentsarevalidatedtoensurethattheysuitableforuseintheirintendedoperatingenvironment.执行确认，确保产品或者产品组建在目标操作环境下满足使用的要求。SP2.1Performvalidationontheselectedproductsandproductcomponents.执行产品及产品组建的确认工作。SP2.2Analyzetheresultsofthevalidationactivitiesandidentifyissues.分析确认活动的结果并识别出问题。组织过程焦点（OPF）SG1确定过程改进机会SP1.1建立过程改进机会SP1.2评估组织过程SP1.3识别组织和过程改机会SG2规划和实施过程改进SP2.1制定过程行动计划SP2.2实施过程行了动计划SG3部署组织过程财富SP3.1部署组织过程财富SP3.2部署标准过程SP3.3监督实施SP3.4将过程相关的经验纳入组织过程财富要做这个PA，组织要成立EPG（EngineerProcessGroup）专门负责过程改进的工作。这个组是整个公司过程改进的动力源头、策划中心、执行中心、培训中心。很多公司的过程改进没有做好，很大部分的原因是EPG的成员没有选择好。EPG成员绝对不能清一色都是“理论派”，没有具体项目经验的。这是最低要求，如果是我的话，我是一个“理论派”都不会让进EPG的。EPG的成员加起来应该有项目管理、需求、设计、开发、测试等软件各个方面的经验，并且要有至少一名超级高手对整个软件生命过程都非常熟悉而且很聪明的一个人。OPF的每个Practice都不是很困难就可以做到CMMI的要求，但要做到有效，大家都感觉到过程是在改进中，对工作有用，这就比较困难了。很多通过CMMI3级评估的企业，虽然通过了评估，但企业对过程改进的感觉并不是很好，大部分是由于EPG成员的功力不够，做出来的过程实际意义不大导致的。下面我们看看这个PA的要求：SG1.Strengths,weakness,andimprovementopportunitiesfortheorganization’sprocessesareidentifiedperiodicallyandasneeded.定期地识别组织过程的不足、改进机会。SP1.1Establishandmaintainthedescriptionoftheprocessneedsandobjectivesfortheorganization.建立和维护组织的过程改进需求及目标。组织的改进活动，不是为了过级的改进，改进活动是商业目标驱动的，组织的领导要经常问自己，为什么要改进？什么需要改进？SP1.2Appraisetheprocessesoftheorganizationperiodicallyandasneededtomaintainanunderstandingoftheirstrengthsandweakness.定期地评估过程，理解过程的强项和弱项。组织可以通过内部的评估、外部的评估等办法，发掘组织过程的强项和弱项。SP1.3Identifyimprovementstotheorganization’sprocessesandprocessassets.识别组织过程及过程资产库的改进机会。SG2.Improvementsareplannedandimplemented,organizationalprocessassetsaredeployed,andprocess-relatedexperiencesareincorporatedintotheorganizationalprocessassets.改进被计划和实施，组织过程财富库被部署，以及过程相关的经验等提交到组织过程财富库。SP2.1Establishandmaintainprocessactionplanstoaddressimprovementstotheorganization’sprocessesandprocessassets.针对组织过程及过程财富库的改进机会，建立和维护改进计划。简单的说就是要建立改进计划，该改进计划是针对组织的改进需要的。SP2.2Implementprocessactionplansacrosstheorganization.在组织内实施改进计划。SP2.3Deployorganizationalprocessassetsacrosstheorganization.在组织内部署组织过程财富库。SP2.4Incorporateprocess-relatedworkproducts,measures,andimprovementinformationderivedfromplanningandperformingtheprocessintotheorganizationalprocessassets.提交从改进计划及执行过程中产生的过程相关的工作产品、度量、改进信息到组织过程财富库。简单地说就是，过程改进活动中产生的有价值的东西要提交到财富库中。这些东西一般是：改进计划、过程文档、经验总结、能体现生产力的数据等。组织过程定义（OPD）SG1创建组织过程财富SP1.1建立标准过程SP1.2建立生存周期模型描述SP1.3建立裁剪准则和指南SP1.4建立组织度量库SP1.5建立组织过程财富库SP1.6建立工作环境标准OPF主要关注要有人来负责过程改进的工作，OPD关注的是组织级要有财富库作为整个组织的知识库。什么是财富库，简单的说就是对组织有用的东西都可以纳入到财富库中，财富库可以包含：过程、生命周期模型、裁剪指南、度量库等。如果把OPD进行扩展，就是一个组织如何进行知识管理的问题了，知识可以包括两类，非技术类和技术类，非技术类包括：标准过程、规章制度、流程、项目管理经验、度量数据等等，技术类包括：设计、代码库、重用组件等。组织除了要对知识进行分类外，还需要建立知识的收集、分析、存储、使用的策略及具体可操作的办法。SG1.Asetoforganizationalprocessassetsisestablishedandmaintained.建立和维护组织过程财富库。SP1.1Establishandmaintaintheorganization’ssetofstandardprocesses.建立和维护组织的标准过程。SP1.2Establishandmaintainthedescriptionsofthelife-cyclemodelsapprovedforuseintheorganization.建立和维护被批准用于组织的软件生命周期。SP1.3Establishandmaintainthetailoringcriteriaandguidelinesfortheorganization’ssetofstandardprocesses.建立和维护用于组织标准过程的裁剪标准和指南。SP1.4Establishandmaintaintheorganization’smeasurementrepository.建立和维护组织度量数据库。SP1.5Establishandmaintaintheorganization’sprocessassetlibrary.建立和维护组织过程财富库。组织培训（OT）SG1建立组织培训能力SP1.1确定战略培训需求SP1.2确定由组织负责的培训需求SP1.3建立组织培训计划SP1.4建立培训能力SG2提供必要的培训SP2.1交付培训SP2.2建立培训记录SP2.3评价培训效果有效的培训要求对需要、策划、教学设计及适当的培训媒介（例如，规范手册与计算机软件）进行评估，并需要一个培训过程数据的存储库。如同一个组织过程，培训的主要组件，包括一套可管理的培训课程开发计划、计划书、适当掌握特定学科及其他知识领域的人员，以及度量培训效果的机制。对过程培训需要的识别，主要依据执行组织标准过程所需的技能进行。某些技能可以通过课堂培训以外的方式进行有效的传授（例如非正式的指导）；其他技能则需要较正式的培训方式，如课堂、网络培训、辅导性自学，或正式的在职培训计划等。对每种情形采用正式或非正式的培训方式，应根据对培训需要、待处理的性能差距的评估来决定。本过程域所使用的“培训”这一术语，泛指所有的这些学习活动。培训成功与否，应根据执行新的及持续性的企业活动时，使用培训中获取的技能与知识的有效性来度量。技能与知识可能属于技术性、组织性或人际关系性。技术技能是指项目或过程所需的设备、工具、资料、数据，以及过程的使用能力。组织技能是指根据员工的组织结构、角色与职责、一般性工作原则与方法等范围内的行为。人际关系技能是指项目与支持小组能够成功执行组织与社会关系所需的自我管理、沟通、人际关系能力。SG1.EstablishanOrganizationalTrainingCapability建立组织培训能力建立并维护组织的培训能力,支持组织的管理任务和技术任务。组织识别培训需求，以开发执行企业活动所需的技能与知识。一旦需要被识别，就应开展满足这些需要的培训计划。集成团队成员必须接受跨功能培训、领导力培训、人际关系技能培训，以及集成适当的商业与技术功能所需的技能培训。由于潜在的广泛需求范围，以及参与者的不同背景，可能要求那些并未参与需求开发的相关干系人，参加产品设计所需的跨专业培训，以充分地了解需求范围及其相关关系，以更好地承诺需求。SP1.1EstablishtheStrategicTrainingNeeds建立战略性培训需要建立并维护组织的战略性培训需要。战略性培训需要强调，通过弥补重要知识的差距、引进新技术或实施重大行为变更等长期目标，建立一种能力。战略性计划通常面向今后二至五年。除了传统开发环境中的一般技能，IPPD还需要领导技能与人际关系技能。IPPD环境中，强调的特定技能包括：集成所有适当的商业与技术功能及其过程的能力与他人协调与合作的能力典型的工作产品1.培训需要2.评估分析子实践1.分析组织的战略性商业目标与过程改进计划，识别未来潜在的培训需要。2.将组织的战略性培训需要文档化。培训需要的分类包括（但并不局限于）以下方面：过程的分析和文档化工程类（例如，需求分析、设计、测试、配置管理、质量保证）交付的服务供应商的选择和管理管理类（例如，估算管理、跟踪管理、风险管理）恢复运行和持续运行3.确定执行组织标准过程集所需的角色与技能。4.将执行组织标准过程集的各类角色所需的培训文档化。5.将维护安全的、保密的、持续的商业运行所需的培训文档化。6.必要时修订组织的战略需要和所需的培训。SP1.2DetermineWhichTrainingNeedsAretheResponsibilityoftheOrganization确定哪些培训需要由组织负责确定哪些培训需要应由组织负责，哪些由个别项目或支持小组负责。组织培训除了满足战略性培训需要外，还满足了项目与支持小组间的共同培训需求。项目与支持小组的主要责任是，识别与处理他们自身的特定培训需要。组织的培训人员，只需负责跨项目与支持小组的共同培训需要（例如，多项目共同的工作环境培训）。然而，在培训资源允许以及组织培训优先的情况下，与项目及支持小组协商之后，组织培训人员可以满足他们一些额外的培训需求。典型的工作产品1.项目与支持小组共同的培训需要2.培训承诺子实践1.分析由不同项目与支持小组所识别的培训需要。对项目和支持小组的需要进行分析，目的在于有效地识别出组织范围内有哪些共性的培训需要。类似的分析活动可以预测项目级和支持小组层级，未来有哪些培训需要。2.与不同的项目和支持小组协商，如何满足他们特定的培训需要。组织培训人员能否提供支持，取决于培训资料是否可用，以及培训的优先排序。项目或支持小组适当开展的培训，举例如下：项目有关应用领域或服务领域的培训项目或支持小组使用的专有工具和方法的培训有关安全性、保密性和人员因素的培训3.将提供给项目与支持小组的培训承诺文档化。SP1.3EstablishanOrganizationalTrainingTacticalPlan建立组织培训实施计划建立并维护组织的培训实施计划。组织培训实施计划，是将培训交付实施的计划，这些培训属于组织的职责，对个人有效执行其任务也是必要的。该计划强调近期培训的实施，并根据变更（如需要与资源），以及培训效果的评估，进行定期的调整。典型的工作产品1.组织培训实施计划子实践1.建立计划内容组织的培训实施计划通常包括以下内容：培训需要培训主题依据培训活动及其存在的依赖关系制定的进度安排培训的方法培训资料的需求和质量标准培训任务、角色和职责需要的资源，包括工具、设备、环境、人员、技能和知识2.建立对计划的承诺要想保证计划有效地执行，关键要将负责执行与支持计划的人员的承诺文档化。3.必要时修订计划与承诺SP1.4EstablishTrainingCapability建立培训能力建立并维护培训能力，满足组织的培训需要。典型的工作产品1.培训资料与支持成果子实践1.选择适当的方法，满足特定的组织培训需要。影响培训方法的选择包含很多因素，例如对象特定的知识、成本和进度、工作环境等。选择方法时要考虑到最有效的方式可能受到某些限制。有关培训方法，举例如下：课堂培训计算机辅助工具按照指南自学正式的学徒式培训和监督计划视频教学注入式教学自带午餐的午餐时间讨论会结构化的基于工作的培训2.确定内部开发培训教材或从外部购买教材。对比内部开发培训与外部购买培训的成本和效益。确认购买知识或技能的模式是否有效的标准，举例如下：性能目标项目是否有时间准备实施培训商业目标内部专家培训是否适用外部获取培训是否适用有关外部培训，举例如下：客户提供的培训商业上适用的培训课程学术性计划专业会议研讨会3.开发或取得培训资料。培训可以由项目、支持小组、组织内部或外部组织提供。不管属于哪种培训，组织的培训专员都应该协调获取和交付培训课程。有关培训资料，举例如下：课程计算机辅助工具视频资料4.培养或寻求合格的讲师。要想确保内部的讲师具备必要的知识和技能，可以定义一些识别讲师、培养讲师和讲师资质的标准。如果是外部培训，组织的培训专员可以调查培训提供方如何确定讲师，这也可以作为后续选择讲师或连续与对方合作的一个参考因素。5.在组织培训课程中描述培训内容。培训说明中提供的信息，举例如下：培训覆盖的主题培训对象参加培训的前提条件和需要哪些准备培训目标培训的时间长度提前预习完成课程的标准免修的标准6.必要时修订培训资料与支持成果。培训资料等需要修订的情形，举例如下：培训需要出现变更（例如，培训的主题需要采用新技术）评估培训时发现需要进行变更（例如，培训有效性的调查评估、培训计划的性能评价，导师评价表）SG2.ProvideNecessaryTraining提供必要的培训为个人提供必要的培训，使其能够有效地履行职责。选择受训的人员时，应考虑以下内容：受训目标人选的背景受训的必备条件人员履行职责所需的技能与能力所有专业都需要跨专业的技术管理培训，包括项目管理管理人员需要接受适当的组织过程培训需要对所有适当专业的基本原理进行培训，以支持人员的质量管理、配置管理及其他相关支持功能需要提供关键功能领域的能力开发需要维护个人的能力与资格，以维护及运行多项目共同的工作环境SP2.1DeliverTraining实施培训按照组织的培训实施计划开展培训典型的工作产品1.实施的培训课程子实践1.选择需要接受培训从而有效开展工作的受训人员。培训的目的在于向组织内部各种角色的人员，传授知识和技能。有些人可能已经具备了必要的知识和技能，这些人就可以免修，但应该注意免修的权利不能滥用。2.安排培训日程，包括任何必要的资源（如设备、讲师）。应该策划培训的日程安排。培训往往与预期的工作绩效直接挂钩。因此，最佳的培训往往是考虑与最近的工作绩效相关，有一定的期望值，类似的期望包括：针对某特有工具的培训针对某个规程，为即将实施这些规程的人提供培训3.进行培训。有经验的讲师会将培训设计成一种演练。如果条件允许，会模拟实际的场景，在此基础上进行培训。这种方法包括素质开发的工具、方法和程序的集成。培训与工作职责密切相关，基于工作所开展的活动，以及其他外部的经验，都会增强培训的效果。4.跟踪培训是否按计划实施。SP2.2EstablishTrainingRecords建立培训记录建立并维护组织的培训记录。本实践的范围是在组织层次上实施培训。对于项目或支持小组发起的培训，其培训记录的建立与维护，由各自项目或支持小组负责。典型的工作产品1.培训记录2.更新组织知识库的培训子实践1.将每门课程或培训活动中，顺利通过或者未通过的人员都进行记录。2.将所有免修的人员进行记录。要将免修的理由文档化，培训负责人以及免修人员的管理者都应该对免修申请进行审核批准。3.将所有顺利完成指定培训的人员进行记录。4.让适当的人员可以获取培训记录，并作为后续分派工作的参考因素。培训组织往往会开发一个技能矩阵，培训记录就是该矩阵的一部分，对人员的经验和教育背景，以及组织所发起的培训进行了概要介绍。SP2.3AssessTrainingEffectiveness评估培训效果评估组织培训计划的效果。应该有一个判断培训效果的过程（也就是培训满足组织需要的程度）。针对项目与组织目标，可采用度量方法评估培训的收益。应特别关注各种培训方法，例如将培训团队视为一个集成的工作单位。实施度量时，应该让课程参与者了解性能目标，该目标应是明确的、明显的、可验证的。对培训效果的评估，应被用来修订在“建立培训能力”这一特定实践中所描述的培训资料。典型的工作产品1.培训效果调查2.培训实施性能评估3.讲师评估表4.培训测验子实践1.评估正在进行或已完成的项目，确定人员的知识水平能否满足项目的工作。2.针对已建立的组织、项目或个人的学习（或绩效）目标，提供一种途径来评估每项培训课程的效果。3.针对培训活动能否满足学员的需要，获取学员的评价。集成化项目管理（IPM）SG1应用项目定义过程SP1.1建立项目定义过程SP1.2利用组织过程财富规划项目活动SP1.3建立项目工作环境SP1.4集成计划SP1.5利用集成计划管理项目SP1.6充实组织过程财富SG2与相关干系人协调和合作SP2.1管理干系人的介入SP2.2管理依存关系SP2.3解决协调问题集成项目管理（IPM）是2级的项目计划（PP）与项目计划跟踪与控制（PMC）的“升级版”，而4级的定量项目管理（QPM）又是集成项目管理的（IPM）的“升级版”。3级与2级最大区别之一就是上升到组织级，项目管理也是一样，项目需要利用组织资产库定义项目自己的过程，考虑各种计划的集成。这是“集成”的其中一层意思，“集成”另外一层意思就是，要协调和管理好项目开展过程中各相关关系人。这两层意思，分别对应SG1和SG2。SG1.Theprojectisconductedusingadefinedprocessthatistailoredfromtheorganization’ssetofstandardprocess.项目依据项目定义的过程执行，这个项目定义的过程是通过组织的标准过程裁剪出来的。什么叫“项目定义过程”？什么叫“裁剪”？3级的软件企业，会有很多项目开发方面的各个过程，而且根据不同的情况，可能会有不同的过程。也有可能同一个过程，允许不同类型的项目的做法或者执行的力度等不太一样。组织过程中会有明确的指导，告诉使用这个过程的项目，如何根据项目本身的特点，来选择或者制定自己项目应该执行的过程。这个指导，就是裁剪指南，根据这个指导定义项目应该执行的过程，就是“裁剪”，定义出来的项目应该执行的过程，就是“项目定义过程”。“裁剪”不一定是减少步骤地，增加步骤，修改步骤等都是“裁剪”，注意是“裁剪”而不是“裁减”。SP1.1Establishandmaintaintheproject’sdefinedprocess.建立和维护项目定义过程。SP1.2Usetheorganizationalprocessassetsandmeasurementrepositoryforestimatingandplanningtheproject’sactivities.用组织的过程库及度量库来估算和计划项目的活动。如：利用历史项目的估算数据，来估算本项目的工作量。SP1.3Integratetheprojectplanandtheotherplansthataffecttheprojecttodescribetheproject’sdefinedprocess.集成项目计划及其它影响项目定义过程的计划。一个项目可能有很多计划，如：开发计划、测试计划、配置管理计划、QA计划、培训计划等等，需要协调好这些计划，让项目所有工作有序开展。SP1.4Managetheprojectusingtheprojectplan,theotherplansthataffecttheproject,andtheproject’sdefinedprocess.用项目计划及相关计划、项目定义过程来管理项目。SP1.3强调的是建立和协调好各类计划，SP1.4强调的是利用这些计划来管理项目，前者是制定，后者是执行。SP1.5Contributeworkproducts,measures,anddocumentedexperiencestotheorganizationalprocessassets.提交工作产品、度量数据、文档化的经验等到组织过程资产库。项目利用组织级资产库来进行估算、计划等活动，同样项目也需要把自己本身的有价值的经验、数据、文档等提交到资产库，供以后的项目使用。SG2.Coordinationandcollaborationoftheprojectwithrelevantstakeholdersisconducted.协调和项目相关的干系人。SP2.1Managetheinvolvementoftherelevantstakeholdersinproject.管理项目相关干系人的涉入。包括：要识别出相关干系人，并安排适当的时候让其介入等。项目干系人可能是：甲方、供应商、第三方系统的拥有者等，所有影响这个项目成功的相关人和单位都是干系人。SP2.2Participatewithrelevantstakeholderstoidentify,negotiate,andtrackcriticaldependecies.让相关干系人参与识别、协商、跟踪关键的倚赖关系。很多情况下，项目会有很多倚赖与第三方的制约。如需要供应商在什么时候提供产品，需要第三方什么时候准备好第三方系统的接口，需要用户准备好安装环境等，所有这些都有可能严重影响项目的进度、成本，必须让这些相关干系人介入协商跟踪这些关键依赖关系。SP2.3Resolveissueswithrelevantstakeholders.和相关干系人解决问题。这个SP是衔接SP2.1、SP2.2的，前两个SP肯定会发现很多问题，需要和干系人协商解决这些问题。风险管理（RSKM）SG1风险管理准备SP1.1确定风险来源和类别SP1.2定义风险参数SG2识别和分析风险SP2.1识别风险SP2.2风险评估、分类和确定优先级SG3缓解风险SP3.1制定风险缓解计划SP3.2实施风险缓解计划有这样的说法：项目管理其实就是风险管理，把风险管理好了，项目也就管理好了。可见风险管理是多么重要啊！在CMM的时候，还没有专门的PA是针对风险管理的。CMMI2级的PP这个PA的SP2.2提到要识别风险，但这里的要求还是处于项目级别层次的。3级中的RSKM，已经把风险管理上升到组织层面，组织级需要对风险进行分类、定义风险的属性、制定风险的管理策略等。RSKM有3个SG，SG1主要就是讲述组织级的要求，而SG2、SG3重点讲述项目如何进行风险管理活动。SG1.Preparationforriskmanagementisconducted.做好风险管理的准备。SP1.1Determinerisksourcesandcategories.决定风险的来源和分类。SP1.2Definetheparametersusetoanalyzeandcategorizerisks,andtheparametersusedtocontroltheriskmanagementeffort.定义用来风险的属性，这些属性是用来分析风险、分类风险以及用来进行风险管理的。SP1.3Establishandmaintainthestrategytousedforriskmanagement.建立和维护用于风险管理的策略。用SP1.1到SP1.3，要求逐步深化。SP1.1只要求确定风险来源及分类。SP1.2就要求定义清晰的风险属性，一般来说，风险会有原因、后果、严重级别、发生机率、类别等属性，每个企业可以根据自己需要定义属性。SP1.3所谓的风险管理策略，指得就是风险如何存储、记录、跟踪、采取什么缓解措施等所有关于风险管理的组织级别的要求。SG2.Risksareidentifiedandanalyzedtodeterminetheirrelativeimportance.识别风险并分析决定他们的相关重要性。SP2.1Identifyanddocumenttherisks.识别和记录风险。这里要求以比较正规的方式记录风险。SP2.2Evaluateandcategorizeeachidentifiedriskusingthedefinedriskcategoriesandparameters,anddetermineitsrelativepriority.根据已经定义好的风险分类及属性，评估和分类每一个风险，并决定其优先级。SG3.Risksarehandledandmitigated,whereappropriate,toreduceadverseimpactsonachievingobjectives.风险被管理并且缓解，以减少对项目管理目标的影响。SG2主要讲的是识别和分析风险，SG3就是要管理风险及采取缓解措施了。SP3.1Developariskmitigationplanforthemostimportantriskstotheproject,asdefinedbytheriskmanagementstrategy.根据风险管理策略对项目最重要的风险制定风险缓解计划。风险缓解措施是指，降低风险发生机率及风险发生时采取的减低影响的措施。SP3.2Monitorthestatusofeachriskperiodicallyandimplementtheriskmitigationplanasappropriate.周期性地跟踪风险状态，在需要的时候实施风险缓解计划。决策分析与解决方案（DAR）SG1评价侯选方案SP1.1建立决策分析指导原则SP1.2建立评价准则SP1.3确定候选解决方案SP1.4选择评价方法SP1.5评价候选方案SP1.6选择解决方案什么叫决策分析？举个简单的例子：大家有没有到电脑城买过电脑？你是通过以下哪种方式买电脑的呢？A.随便找一家，装完走人。B.找个认识的人，让其帮忙。C.麻烦，买品牌机算了。D.货比三家后，选择比较合适的。方案A，风险比较大，容易被人蒙，也可能买到高价货。方案B，宝全部压在那个认识的人身上。我是不愿意当那个“认识的人”的，吃力不讨好的苦差。方案C，比较保险，但可能买不到性价比比较好的电脑。方案D，全部依赖于你的个人能力了，能不能买到性价比高的电脑，全靠你自己了。当然，方案有很多，以上只是举一些例子。如果我们总结一下，买到好电脑的方案都有什么特征呢？1.购买者清晰了解自己对电脑的配置要求以及自己价钱的承受能力。2.购买者有清晰的选择标准，如：服务态度、售后服务、价钱、品牌等。3.购买者清楚知道不可能购买到十全十美的电脑，他知道哪些东西对他更重要。简单的说，决策分析就是根据一定的选择标准，在一些候选方案中选出合适的方案。一般来说，经过决策分析后得出来的决策，科学性更高，实施该方案成功概率会比较高。但实施决策分析本身的成本也比较高，一般我们只在重大问题采取决策分析的办法，例如：大家购买房子就需要决策分析一下了，但今晚去哪里吃饭，恐怕就不需要决策分析一下了。SG1.Desicisionsarebasedonanevaluationofalternativesusingestablishedcriteria.决策是根据一定的标准对可选方案进行评估的基础上的进行的。这个PA只有一个SG。SP1.1Establishandmaintainguidelinestodeterminewhichissuesaresubjecttoaformalevaluationprocess.建立和维护一个指南，该指南规定了哪些问题需要进行决策分析过程。这个SP的意思就是，组织级应该有一个规定（项目级可以裁剪），说明什么情况下要进行决策分析。前面提到，决策分析的成本是比较大的，一般只用在特别有价值的决定上。一般来说，我们会在供应商选择、设计方案选择、是否发布等方面采用决策分析。例如今晚吃什么饭的小问题，就不需要决策分析了。SP1.2Establishandmaintainthecriteriaforevaluatingalternatives,andtherelativerankingofthesecriteria.建立和维护评估可选方案及选择标准优先级的准则。进行方案选择时，需要一些标准，并且要明确这些标准的权重，哪些标准需要更有限考虑一点。对于这些方面的考虑，需要制定相应的标准。一般来说，组织级应该定义这样的标准，供项目组使用。SP1.3Identifyalternativesolutionstoaddressissues.识别可选方案来解决问题。以前面购买电脑为例，要解决的问题就是按照一定的配置要求和价钱承受力来购买最合适的电脑。根据这样的要求，可以列出多个候选的购买方案。同样，我们在软件开发过程中，经常需要解决一些问题（如选择购应商，进行架构设计等），为了解决这些问题，要列出可以解决这些问题的可能方案。SP1.4Selecttheevaluationmethods.选择评估的办法。评估标准制定了，还需要确定评估的办法，例如：采用什么方式进行评估？按照什么步骤？如何打分？一般来说，都会使用结构性的分析办法来进行评估的。SP1.5Evaluatealternativesolutionsusingtheestablishedcriteriaandmethods.根据已制定的标准和办法，对可选方案进行评估。SP1.6Selectsolutionsfromthealternativesbasedontheevaluationcriteria.根据评估的标准从候选方案中选出解决方案。组织过程绩效（OPP）SG1建立性能基线和模型SP1.1选择过程SP1.2建立过程性能度量SP1.3建立质量和过程性能目标SP1.4建立过程性能基线SP1.5建立过程性能模型OPP是对组织级提出要求的，组织要根据公司的商业目标、企业的实际情况，选择要进行性能分析、量化管理的子过程，制定组织的质量和过程方面的量化的目标，建立基线和模型。这些量化的目标、基线、模型，要用于进行项目管理。具体内容见QPM。OPP最核心的问题就是要进行SPC（统计过程控制），SPC不容易理解，大家可以先看：http://cmmionline.net/blogs/zongshu/archive/2006/08/22/146.aspxhttp://cmmionline.net/files/17/datamgt/entry190.aspxSG1.Baselinesandmodelsthatcharacterizetheexpectedprocessperformanceoftheorganization'ssetofstandardprocessesareestablishedandmaintained.这个PA只有一个SG，要建立和维护基线和模型，这些基线和模型能体现组织过程性能。SP1.1Selecttheprocessesorprocesselementsintheorganization'ssetofstandardprocessesthataretobeincludedintheorganization'sprocessperformanceanalyses.在组织标准过程库中选择过程或过程元素，用于分析组织过程性能。简单的说，要选择哪些子过程进行SPC。SP1.2Establishandmaintaindefinitionsofthemeasuresthataretobeincludedintheorganization'sprocessperformanceanalyses.建立和维护用来进行组织过程性能分析的度量。SP1.1选择了哪些子过程进行SPC，SP1.2就是更进一步，确定具体的度量办法。SP1.3Establishandmaintainquantitativeobjectivesforqualityandprocessperformancefortheorganization.建立和维护质量和组织过程性能的量化管理目标。定下用于项目管理的量化管理目标，这个目标应该包括质量方面以及组织过程性能方面。SP1.4Establishandmaintaintheorganization'sprocessperformancebaselines.建立和维护组织过程性能基线。SP1.5Establishandmaintaintheprocessperformancemodelsfortheorganization'ssetofstandardprocesses.建立和维护过程性能模型。定量管理（QPM）SG1定量项目管理SP1.1建立项目目标SP1.2组成项目定义过程SP1.3选择用于定量管理的子过程SP1.4管理项目性能SG2统计管理子过程性能SP2.1选择度量和分析技术SP2.2运用统计方法理解过程序变动SP2.3监督选定的子过程性能SP2.4记录统计管理数据定量项目管理与一般的量化管理很不同，不是在项目管理过程中用到数据，就算是定量项目管理。定量项目管理要求过程是稳定的，过程要稳定，需要满足很多条件，企业的过程要做到稳定，要付出很多努力。建议先看以下内容，先理解什么是稳定的过程。用数据管理过程几个直接与项目管理相关的PA(PP、PMC、IPM、RSKM、QPM、CAR)SG1.Theprojectisquatitativelymanagedusingqualityandprocess-performanceobjectives.用质量和过程性能目标对项目进行量化管理。SP1.1Establishandmaintaintheproject’squalityandprocess-performanceobjectives.建立和维护项目质量及过程性能目标。要建立项目的质量及过程性能两个方面的量化目标，如何制定量化的目标是关键，要做到这一步，需要有完整而有效的度量体系。要做好4级这个PA，做好2级的度量(MA)是关键之一。一般来说，项目质量方面的量化目标有：缺陷发现率、问题发现率等，过程性能目标有：CPI、SPI、生产力效率、返工率等。SP1.2Selectthesubprocessesthatcomposetheproject’sdefinedprocessbasedonhistoricalstabilityandcapabilitydata.根据历史的稳定的有能力的数据选择组成项目定义过程的子过程。IPM要求根据裁剪库和裁剪指南，裁减出项目定义过程，而这个SP在IPM的要求上提高一级，要求利用组织稳定的有能力的数据，选择子过程组合成项目定义过程。SP1.3Selectthesubprocessedoftheproject’sdefinedprocessthatwillbestatisticallymanaged.选择要进行统计管理的子过程，组成项目定义过程。SP1.2的子过程和这里的子过程不太一样，两者可能是一样的，但SP1.3的子过程是指要进行统计过程控制的子过程，这个子过程必须是稳定的有能力的过程。SP1.4Monitortheprojecttodeterminewhethertheproject’sobjectivesforqualityandprocessperformancewillbesatisfied,andidentifycorrectiveactionasappropriate.跟踪项目判断项目是否满足质量目标、过程性能目标，并在适当的时候采取修正行动，保证项目满足质量目标、过程性能目标。SG2.Theperformanceofselectedsubprocesseswithintheproject’sdefinedprocessisstatisicallymanaged.对项目的子过程进行统计管理，也就是要对项目子过程进行SPC。SG1强调的是确定项目的量化管理目标，选择子过程组成项目定义过程，并根据量化目标进管理项目。SG2则对项目的子过程的管理提出了要求。项目的子过程可能是需求过程、设计过程、编码过程、测试过程等等，每个企业可以根据自己实际的需要，选择有重要价值的子过程进行统计过程控制。SP2.1Selectthemeasuresandanalytictechniquestobeusedinstatisicallymanagingtheselectedsubprocesses.选择要进行统计过程控制的子过程的度量及分析技术。统计过程控制对度量、数据分析的要求很高，企业需制定一套完整的、有效的收集数据、分析数据、使用数据的方法、制度，用于需要进行统计过程控制的子过程。SP2.2Establishandmaintainanunderstandiingofthevariationoftheselectedsubprocessesusingtheselectedmeasuresandanalytictechniques.我们用上限和下限对进行SPC的过程进行管理，在这个过程中，我们会收集到很多数据点，这些数据点会在中值上下波动，波动有可能在上下限范围内，也有可能超出上下限。企业需要建立对这些波动的理解指南，帮助项目组理解这些数据波动的原因，并能采取适当的修正行动。SP2.3Monitortheperformanceoftheselectedsubprocessestodeterminetheircapabilitytosatisfytheirqualityandprocess-performanceobjectives,andindentifycorrectiveactionasnecessary.跟踪选定的子过程，判断是否满足它们的质量及过程性能目标，并在必要的时候采取修正行动。SP2.2是SP2.3的基础，首先我们要理解这些波动的原因，然后判断是否正常，判断是否超出了既定的目标，并根据具体的原因采取适当的修正措施。SP2.4Recordstatisticalandqualitymanagementdataintheorganization’smeasurementrepository.在组织的度量库中记录统计的有质量的管理数据。把定量项目管理中的有价值的度量数据，记录到组织的度量库中。这些数据可以用来分析，并用来计算新的基线，更新模型等等。组织革新与部署(OID)SG选择改进SP1.1收集和分析改进建义SP1.2识别革新SP1.3试点改进SP1.4选择用于部署的改进SG2部署改进SP2.1计划部署SP2.2管理部署SP2.3度量改进效果原因分析与解决方案SG1确定缺陷原因SP1.1选择待分析的缺陷数据SP1.2分析原因SG2解决产生缺陷的根源SP2.1实施行动建议SP2.2评价变更的效果SP2.3记录数据SG1.Processandtechnologyimprovementsthatcontributetomeetingqualityandprocess-performanceobjectivesareselected.选择满足质量和过程性能目标的过程和技术改进。根据组织的质量和过程性能目标，选择需要改进的过程和技术。SP1.1Collectandanalyzeprocess-andtechnology-improvementproposals.收集和分析过程的和技术方面的改进建议。SP1.2Identifyandanalyzeinnovativeimprovementsthatcouldincreasetheorganization’squalityandprocessperformance.识别和分析革新改进机会，这个改进能提升组织的质量和过程的性能。SP1.3Pilotprocessandtechnologyimprovementstoselectwhichonestoimplement.试行过程和技术的改进，来选择哪些进行实施。在组织的部分范围内，实行这些新过程新技术，看看哪些时候在组织内全面推广实施。SP1.4Selectprocess-andtechnology-improvementproposalsfordeploymentacrosstheorganization.选择过程和技术改进的建议在组织内推广实施。SG2.Measurableimprovementstotheorganization’sprocessesandtechnologiesarecontinuallyandsystematicallydeployed.组织过程和技术的可测量的改进，被持续地系统地部署。要持续地系统地推动这个组织过程和技术改进，这些改进是可以被测量的。SP2.1Establishandmaintaintheplansfordeployingtheselectedprocessandtechnologyimprovements.建立和维护用来部署选定过程和技术改进的计划。SP2.2Managethedeploymentoftheselectedprocessandtechnologyimprovements.对选定的过程和技术改进部署进行管理。就是说要根据计划来跟踪新技术、新过程的部属工作。SP2.3Measuretheeffectsofthedeployedprocessandtechnologyimprovements.测量被部署的过程和技术改进的效果，就是说要量化评估改进的效果。",)