[转]CMMI Level-3 各个过程域SP的分析

 

共性实践（GP）

CMMI标准中每个级别包含几个PA，每个PA又包含几个Goal，而每个Goal又包含几个Practice。实际上Goal分为两类，一类是Specific Goal（特定目标，简称SG），一类是Geniric Goal（通用目标，简称GG）。SG包含的Practic叫做Specific Practic（特定实践，简称SP），GG包含的Practic叫做GeniricPractic（通用实践，简称GP）。

 

大家如果去看看CMMI的标准，会发现每个PA的SP内容都不一样的，但GP看上去基本类似，只是个别的单词换掉。实际上CMMI的制定者对这些内容进行了精心的提炼，他们总结出不管是哪个PA，都需要有类似的要求，这些要求就被总结成GG和GP。GG（Generic Goal）有以下几种层次：

GG1：达到特殊目标的要求

GG2：制度化一个可管理的过程

GG3：制度化一个已定义的过程

GG4：制度化一个定量管理的过程

GG5：制度化一个持续改进的过程

 

GG1非常简单，只要所有SG都满足了，GG1就满足了。

GG2就复杂很多，要求制度化一个可管理的过程，GG2包含10个GP（Generic Practice），内容涉及到方针、计划、资源、责任、人员培训、配置管理、干系人的管理、计划跟踪、QA、高级别领导检查等十方面的内容，这些内容，每个PA都有要求，要全部满足这些要求是不那么容易的。

GG3只有两个GP，分别是建立已定义的过程以及收集改进的信息，尽管只有两个GP，但要建立覆盖所有SP的已定义过程是不容易的，并且要不断的收集该PA的改进信息。

 

在进行阶段式评估的时候，对于GG，只需要评估GG2、GG3就可以了，但如果进行连续式的评估，就可能需要评估GG4、GG5。如果一个PA能达到GG4的要求，说这个PA达到了定量管理的层次，达到4级的要求。如果一个PA能达到GG5的要求，说明这个PA在定量管理的层次上能持续地优化，达到了5级的要求。

 

GP2.1 方针

对每一个PA，公司都应该有相应的高层次的要求来指导该方面的工作，也就是所谓的方针。方针这东西很很容易被认为是虚的东西，我们需要仔细体会方针，这个GP是公司商业目标与过程的结合点，过程是否能为商业目标带来价值，很大程度上就看这个方针是怎样定的，并且要把方针贯彻到过程中。

 

我们以PP这个PA为例子，如果微软要定PP的方针，我想会是：

1.赋予小组成员权力，每个人都承担项目管理的责任；

2.保持灵巧，预测变化；

3.由底而上的估算办法；

......

在MSF中，我们会看到很多微软进行项目管理的一些原理和法则，

可参考《解开MSF团队管理的秘密》

http://cmmionline.net/blogs/msf/archive/2007/04/22/525.aspx

这些法则，指导着如何做项目计划，不同的这些方针指导下，做出来的过程是不一样的。

 

每个公司都有自己的特点、商业目标、企业文化等，最开始我们可能难以制定出详细具体的过程，但首先要把这些过程的指导原则想好，方针是过程的灵魂，过程是否有魅力，是否可以让大家“愉快地”执行，关键就是看过程的方针了。

在我们公司，所有过程都遵循这样的一个方针，就是简单有效，我们要求所有过程都是必须用来执行的，做不到的过程不做，没有效果的过程不要，因为有这样一个原则，我们需要发动所有执行过程的同事来参与制定过程，以保证“简单有效”。我们除了有简单有效这样的一个大原则，每个PA又会制定自己相应的方针。

大家在制定方针内容的时候，要从高层及执行过程的员工两个层面同时下手，整理出简单的有效的容易记忆的方针，并且在以后不断更新这个方针，保证这个方针能不断促进公司的发展。

 

GP 2.2是制定和维护计划GP 2.3说的提供足够的资源GP 2.4说的是分配相应职责和权限

GP2.3 Provide adequate resourcesfor performing XXX process,developing the work products,and providing theservices of the process.

GP2.4 Assign responsibility and authority for performing the process,developingthe work products,and providing the services of XXX process.

 

2.3说的提供足够的资源，保证该PA可以顺畅执行。

2.4说的是分配相应职责和权限，保证该PA可以顺畅执行。

 

所谓的资源，包括但不限于以下的内容：

1)硬件，如电脑、投影、会议室等；

2)软件，如办公软件、开发平台等；

3)文档，如模板、指南等；

4)人员，就是做这个事情的人了

从评估的角度来说，必须有证据证明提供了这些资源，并且这些资源是足够的能支撑该PA的正常运作的。

 

所谓的分配职责和权限，就是所公司应该为该PA提供足够的各种层次的人员，人员也是一种资源，在这点上与GP2.3有点重复，GP2.4更强调的是每种人员都有足够的合适的职责和权限来完成工作。通常职位说明、立项登记通知中的人员配备、还有计划中的各人的职责说明都可以作为评估时候的证据。

 

GP2.5培训人员相关的技能

GP2.5 Traing the people performingor supporting XXX process as needed.

培训人员相关的技能，保证该PA的顺利执行。

 

为了保证各PA能顺畅执行，公司、项目内部可能会安排很多培训和学习，内容会涉及到项目管理、技术等各个方面，这些培训的内容就可能会覆盖到各个PA，通常一个培训可以覆盖多个PA，另外要特别说明，自学、技术研究等这些内容，也是GP2.5的证据。

 

不过对于OT这个PA会比较特殊，简单的说就是培训的培训，可能需要安排一些外部的培训才能保证做培训工作的员工有能力做好培训的工作。另外对于OPF、OPD、OID这些PA， 也可能需要一些外部培训。

 

GP2.6把工作产品放置于合适的配置管理之下

GP2.6 Place designed work productsof XXX process under appropriate levels of configuration management.

大意是：把工作产品放置于合适的配置管理之下。

 

配置管理包含几种层次：

1.权限管理

2.版本管理

3.基线管理

某某工作产品要进行配置管理，并不意味非要进行很重型的配置管理，根据实际需要采取合适的方式就可以了。如：很多公司的项目计划，可能经常要进行细化，那么这些变更之需要做好版本管理，甚至只需要保存当前版本就可以了，没有必要每次都要来几次基线级别的变更控制。而需求的变化，通常是影响重大的，那就可能要进行基线级别的变更控制了。

所有的PA都会产生一些工作产品，不同的PA不同的工作产品，需要配置管理的程度是不一样的，各企业根据情况自己选择。

 

对于CM这个PA的GP2.6，就有点意思了，就是配置管理这个PA的配置管理如何做呢？

CM这个PA会有什么工作产品呢？可能有配置管理计划、配置管理记录、检查表之类的东西吧，这些工作产品是不是需要在哪个地方保存起来？是不是可能要有版本控制？访问权限的控制？其实这些就是配置管理的工作了。

 

GP2.7按照计划识别和管理相关干系人的参与

GP2.7 Identify and involve therelevant stakeholders of XXX process as planned.

中文大意是：按照计划识别和管理相关干系人的参与。

 

为保证不同的PA的活动能正常有序进行，必须事先识别出哪些人需要参加该PA的活动，在计划中标示出来，并标示出这些人需要参与什么活动，这就是“Identity”。

而“Involve”的意思有两个方面，在计划的时候，要让这些干系人同意或者了解这个计划，另外在计划执行过程中，要按计划要求让这些干系人参加相关的活动。

 

不同的PA的相关干系人是不一样的，以PP为例，内部干系人有：项目组成员、高层领导，外部干系人可能有：客户、提供硬件或者服务的第三方等。

 

GP 2.8是跟踪计划的执行

GP2.2 Establish and maintain theplan for performing XXX process.

GP2.8 Monitor and control XXX process against the plan for performing theprocess and take appropriate corrective action.

2.2是制定和维护计划，2.8是跟踪计划的执行，必要时采取纠正行动。

 

每个PA都有这两个GP，意味着所有PA都需要有相应的计划及计划跟踪，这个道理也是很显然的，做任何事情都应该有计划嘛。这样是不是说CMMI要求每个PA都需要写一个计划文档呢？这当然不是啦，通常我们在一个项目计划中，就会包含了需求、设计、开发、测试等各方面的工作，这个计划其实包含了很多PA的计划。CMMI只是要求大家在编写计划的时候要考虑到每个PA，并不是要求写多少份文档。

 

不过在PP与PMC中，也需要有计划及计划跟踪，这样对于PP这个PA来说，就需要有计划的计划，并对这个计划的计划进行跟踪，对于PMC来说，就需要有计划跟踪的计划，并要对计划跟踪的计划进行跟踪，比较绕:(

不知道大家的项目计划文档中，有没有列出什么时候更新计划？什么时候需要开项目例会？其实这些内容，就是计划的计划以及计划跟踪的计划了。另外，在项目立项通知，或者是启动文档中，也可能会有要写出第一份计划的时间要求，这些就是第一份计划的计划了。

 

 

 

GP2.9客观地检查是否有遵循相关的过程、标准等。

GP2.9 Objectively evaluateadherence of XXX processn against its process description,standards,andprocedures,and address noncompliance.

大意是：客观地检查是否有遵循相关的过程、标准等。

 

每个PA都有GP2.9，意味着所有的PA都必须有相应的一些标准、过程，要有人对这些PA的过程进行客观的评估、检查。一般来说，我们的QA都能做到这些要求，不过对于PPQA这个PA，就有点麻烦了，QA的QA该如何进行呢？

自己的工作是不能被自己检查的，通常QA部门的领导会对QA工作进行检查，公司的高层领导或者独立部门也会对QA的工作进行检查，另外外部评审（如ISO审核、CMMI评估）也是QA的QA的证据。

 

GP2.10高级别的领导检查该过程的活动、状态和结果，并解决问题。

GP2.10 Review theactivities,status,and results of XXX process with highter level management andresolve issues.

中文大意是：高级别的领导检查该过程的活动、状态和结果，并解决问题。

 

CMMI中的要求是高层领导(hight management)，而CMMI中的是高级别领导(highter level management)，只要比进行该活动的人员级别高一点的领导就可以了，而不要求非要是高层领导不可。这是CMMI比CMM进步和更合理的一个地方，毕竟高层领导不太可能面面俱到，什么地方都要检查。

 

不管是CMM还是CMMI都强调有领导来检查工作，其意义就是从领导这个层面对工作产品和活动进行把关，领导能看到的东西可能会更多，另外领导能提供一些帮助和资源，来解决一般员工无法解决的问题。

 

GP3.1建立和维护该过程的制度。GP3.2在计划和执行该过程中

GP3.1 Establish and maintain thedescription of a XXX process.

中文大意是：建立和维护该过程的制度。

 

GP3.2 Collect workproducts,measures,measurement results,and improvement information derived fromplanning and performing XXX process to support the future use and improvementof the organization's processes and process assets.

中文大意是：在计划和执行该过程中，收集相关的工作产品、度量数据、度量结果和改进信息，用来支援将来的使用和改进组织的过程资产库。

 

GP3.1是要求建立组织级的关于该过程的制度、标准、模版等全套体系，要求覆盖该PA所有的SP和GP。做2级评估的时候，2级的PA不需要评估GP3.x，但如果要评估3级或者以上级别，2级的PA就需要评估GP3.x。

只通过2级评估的2级PA与通过3级评估的2级PA，会有哪些不同呢？难道只通过2级评估的PA，没有任何组织级别的规定吗？如果我们仔细看GP2.1方针、GP2.2计划、GP2.3资源、GP2.4责任、GP2.5培训、GP2.6配置管理、GP2.7干系人、GP2.8计划跟踪、GP2.9QA、GP2.10高级别领导检查，对于GP2.1、GP2.3、GP2.4应该是有组织级别的规定的，对于GP2.2、GP2.5、GP2.6、GP2.7、GP2.8、GP2.9、GP2.10应该会在项目计划中有规定，而其中的GP2.5、GP2.6、GP2.9、GP2.10可能会在计划中有规定，也可能会在组织级别的过程中有规定。

也就是说通过2级评估的2级PA组织级别都会有一些规定，但这些规定可能没有覆盖全部的SP、GP，通过3级评估的2级PA，组织级别都应该有相应的过程能覆盖该PA全部的SP和GP。

 

GP3.2 体现的是持续改进，每个过程都应该收集相应的改进信息。该GP要求我们在做过程改进的时候，要注意收集各PA的改进信息，把过程改进落到实处，要求人人参与。做好GP3.2这个GP，能让大家充分体会到过程改进的好处，一起为过程改进贡献力量。

 

 

 

 二级2级简述

一个处于“无序化”生产的软件公司，要进行过程改进，首要是改进什么呢？

 

做任何事情都需要计划，做软件开发这样复杂的工作更加需要计划，所以2级中有项目计划(PP)以及项目计划跟踪与控制(PMC)两个PA，分别对指定计划以及计划的执行给出了详细的标准。

 

人是会死的，需求是会变的。需求变更是每个软件公司最头疼的问题，需求变更也是导致项目进度拖延、成本高涨的主要原因。如何管理好需求呢？需求管理(RM)给出了详细的指引。

 

软件生产越来越复杂，有时候我们需要采购一些组件，用于项目中。另外一个方面，纯软件的项目比例也慢慢缩小，很多软件是基于一定的硬件的，而不少硬件也是需要采购的。如何采购到合适的软硬件，如何保证采购工作不影响项目成功呢？供应商协议管理(SAM)会给你一个解答。

 

软件是比较难进行量化管理的，但作为公司的管理者，总会想知道成本、进度、缺陷方面的一些数据，以了解项目的情况。CMMI2级，已经对度量提出了要求，详细情况见度量(MA)这个PA。

 

如何保证软件生产过程中各类工作产品协调一致，配置管理(CM)会给出指导。

 

如何保证每个工作产品以及生产工作产品的过程是遵照规定执行的呢？产品与过程质量保证(PPQA)有明确的指引。

 

2级一共有以下PA：

 

1)项目计划(PP)

 

2)项目计划跟踪与控制(PMC)

 

3)需求管理(RM)

 

4)供应商协议管理(SAM)

 

5)度量(MA)

 

6)配置管理(CM)

 

7)产品与过程质量保证(PPQA)

 

 

 

度量(Measurement and Analysis)

CMMI在2级就已经出现对度量方面的要求了，在CMM的时候，没有专门的KPA描述度量的要求，因为这样曾出现过一些2、3级做得很好的企业，要花几倍的功夫才能做到4、5级，主要是因为度量的工作之前没有打好基础。我们来看看，CMMI2级的MA，有怎样的一些要求。

 

SG1:Measurement objectives and activities are aligned with identified informationneeds and objectives. 这个SG主要讲述的是，组织级要明确实际的需要，定出度量的目标，并根据此目标，定义合适的度量方法、过程等。

 

SP1.1:Establish and maintain measurement objectives that are derived from indentifiedinformation needs and objectives.

 

建立和维护度量目标，这些度量目标是源自特定的需要的。

 

如：质量、进度、成本是项目管理的三大要素，为了更好地管理这三个方面，可能需要分别对这些方面采取度量手段。也就是说，采取任何度量手段之前，要考虑清楚为什么要进行这个度量。

 

SP1.2:Specify measures to address the measurement objectives.

 

制定度量办法满足度量目标的要求。

 

明确了为什么要进行度量后，要把度量目标转化成可以实际操作的具体的度量办法。如：度量的目的是，要保证软件的质量，为了实现这么目标，定义出对缺陷进行度量、对评审发现的问题进行度量等度量办法。

 

SP1.3:Specify how measurement data will be obtained and stored.

 

制定度量数据的收集及存储办法。

 

SP1.4:Specify how measurement data will be analyed and reported.

 

制定度量数据的分析和报告方法。

 

SG2:Mesurement results the adreess identified information needs and objectives areprovided. 这个SG主要讲述的是：根据组织级定义的要求，进行度量工作，收集、分析、存储、报告度量信息等。

 

SP2.1:Obtain specified measurement data.

 

收集指定的度量数据。

 

要根据SP1.3指定的收集办法来收集度量数据。

 

SP2.2:Analyze and interpret measurement data.

 

分析和说明度量数据。

 

根据SP1.4指定的办法，对度量数据进行分析，并说明这些数据的意义。

 

SP2.3:Manage and store measurement data,measurement specifications,and analysisresults.

 

管理和存储度量数据、度量规范及度量结果。

 

根据SP1.3指定的存储办法，对度量数据及相关文档进行存储和管理。

 

SP2.4:Report results of measurement and analysis activities to all relevantstakeholders.

 

向相关人员报告度量结果及分析度量活动情况。

 

度量的数据、情况，需要让该知道的人知道。

 

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

 

度量工作有很多学问，所有的度量工作，都需要回答这些问题：

 

1.度量的目的是什么？

 

2.谁来做这个度量？

 

3.什么时候做这个度量？

 

4.如何做这个度量？

 

5.怎样记录度量的数据？记录到哪里？

 

6.谁会使用这些数据？

 

7.如何分析这些数据？

 

8.谁来分析这些数据？

 

9.分析的结果如何使用？

 

以上的这些问题，其实都可以找到与之对应的SP。

 

配置管理(Configuration Management)

SG1:Baselines of identified work products are established. 建立已识别的工作产品的基线。

 

配置项与基线的区别：

 

配置项是需要进行配置管理的最小单位，如：一份文档、一片段代码等。

 

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

 

一般配置项的管理等级是：权限控制、版本控制。而基线的管理等级除了具备以上管理外，还需要非常严格的变更控制办法。

 

SP1.1:Identify the configuration items,components,and related work products that willbe placed under configuration management.

 

识别需要放于配置管理系统中的配置项、组件和相关工作产品。

 

SP1.2:Establish and maintain a configuration management and change management systemfor controling work products.

 

中文大意是：建立和维护一个配置管理系统，用于控制工作产品。

 

SP1.3:Create or release baselines for internal use and for delivery to the customer.

 

建立和释放基线，用于内部使用或者交付给客户。

 

做好配置管理工作，首先做好两步：

 

1)识别需要进行配置管理的东西。

 

2)建立一个配置管理系统来管理需要进行配置管理的东西。

 

然后做好两个事情：

 

1)对一般的配置项进行管理。

 

2)对基线级别的配置项进行基线级别的管理。

 

SG2:Changes to work products under configration management and tracked andcontrolled.

 

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

 

SP2.1:Track change requests for the configuration items.

 

跟踪配置项的变更需求。例如：记录变更的原因、时间、提出人等。

 

SP2.2:Control changes to the configuration items.

 

控制配置项的变更。一个配置项发生了变化，与它相关的配置项也会可能需要相应改变，需要跟踪和控制整个过程，直到全部变化结束。

 

SP2.1SP2.2 并没有明确指出是针对配置项还是针对基线的，其实两者都使用，不过是针对配置项还是基线，都需要记录变更需求，另外要跟踪和控制变化，只是针对配置项和针对基线，做的程度不太一样而已。

 

SG3:Integrity of baselines is established and maintained.

 

建立和维护基线的完整性。什么意思呢？我们看看下面两个SP就知道了。

 

SP3.1:Establish and maintain records describing configuration items.

 

建立和维护描述配置项的记录。简单的说，所有的配置管理活动，如变更需求、控制变化的过程、配置项状态等都需要进行必要的记录。

 

SP3.2:Perform configuration audits to maintain integrity of the configurationbaselines.

 

执行配置审计来维护配置基线的完整性。

 

什么叫配置审计呢？配置审计分为功能审计和物理审计。

 

功能审计：指工作产品是否满足一定的功能要求，这个工作一般不由配置管理员负责，而是通过文档的评审、软件的测试进行。

 

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

 

配置项要进入配置库前，都应该经历审计，保证其符合要求，保证后续工作产品的正确性。如果是基线级别的工作产品要进入配置库，需要接受更加严格的审计。

 

配置管理的学问非常多，欢迎大家提出问题。

 

过程与产品质量保证(Process and Product Quality Assurance)

SG1: Adherence of the performedprocess and associated work products and services to applicable processdescriptions,standards,and procedures is objectively evaluated.

中文大意是：依据一定的标准的客观地评估被执行的过程及相应的工作产品。这里要注意几点：

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

2)评估要客观。

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

 

SP1.1: Objectively evaluate thedesigned performed processes against the applicable processdescriptions,standards,and procedures.

中文大意是：依据一定的标准客观地评价过程。

 

SP1.2: Objectively evaluate thedesignated work products and services against the applicable processdescriptions,standards,and procedures.

中文大意是：依据一定的标准客观地评价工作产品。

 

如何检查软件生产活动，保证按照组织的相应规定进行了，无非就是两个方面，一个是看看活动的过程是否按照组织的要求进行，另外一个方面就是看看活动过程中产生的工作产品是否符合组织的要求，例如是否符合模板要求、是否有要求的内容等。

这两个SP看上去简单，其实要做好，要做到两点：

1)组织定义的过程、工作产品的模版一定要明确、合理，并且具有可检查性。

2)QA对要理解要检查的过程和工作产品。

 

SG2: Noncompliance issues areobjectively tracked and communicated,and resolution is ensured.

中文大意是：发现的问题要客观地被跟踪、沟通并解决。

 

SP2.1: Communicate quality issuesand ensure resolution of noncompliance issues with the staff and managers.

中文大意是：要和员工和管理者进行沟通，并保证解决问题。这个SP有两点要求：

1.QA发现的问题一定要与相关的员工和管理者进行有效的沟通。

2.要保证发现的问题最后被解决。

 

SP2.2: Establish and maitainrecords of the quality assurance activities.

中文大意是：建立和维护质量保证活动的记录。

 

PPQA只有4个SP，非常简单，但要做好很不容易，下面列举一下QA工作中常见的问题：

1.QA与被检查者的关系不好。

2.被检查者以应付的心态应付QA的检查。

3.QA经常埋怨被检查者不按规定干活。

4.被检查者埋怨QA不理解项目的状况，指挥按条条框框办事。

 

这些问题，总结起来无非是以下的原因：

1.过程本身制定就很有问题，很难按照过程执行。

2.QA缺少软件开发经验，对过程理解不深。

3.QA没有更关注问题的预防，在过程未进行之前，没有对执行过程者进行相应的教育，让过程执行者明白这个过程的道理。

4.QA没有去了解项目的背景以及相关的技术，无法对项目组成员提供有效的执行过程的指导，只能依据条条框框进行指引，项目组无法理解过程的价值。

 

简单的说只有两个方面，一个就是过程本身的质量，一方面就是QA的水平了。

 

有人可能会说，过程就算是错的，也需要执行，在执行中持续改进。这个观点在某些情况下是不对的，要看过程错的程度。如果过程错到根本无法执行，这样强硬执行的话，肯定吃力不讨好。

在刚建立过程的时候，不宜太死，可以适当宽松，另外应该鼓励项目组定义自己的做法，然后QA就按照项目组自已定义的做法来监督执行。通过不断的积累，就可以建立比较完善的过程。

 

项目计划(Project Planning)

大家都明白这样的一个道理：做事情要有计划，有一个不成熟的计划总比没有计划要好，软件开发这么复杂的活动，更加需要计划。那么应该怎样做好一个计划呢？

 

如果对项目的范围、规模、性质、任务、工作量、费用等都不了解的情况下，是不可能做出计划的，所以做好计划的第一步就是要把这些东西搞清楚。PP这个PA的第一个SpecificGoals，中文大意是：建立和维护用于项目计划的各类参数的估算，英文原文是：Estimates ofproject planning parameters are established and maintained.

 

下面我们再详细看看，到底做计划之前，需要搞清楚什么东西？

 

SP1.1：Estimate the Scope ofthe Project. 估计项目的范围，如项目的目标、任务、工作产品等。这里通常就是指WBS(top-levelwork breakdown structure)，试想一下，我们做计划之前不是常常要先对任务进行分解吗？

 

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

 

SP1.3Define the project life-cycle phases upon which to scope the planning effort. 定义项目生命周期。写计划的其中一个步骤是要考虑用什么生命周期模型，是瀑布型？螺旋？还是别的？选择怎样的模型，CMMI并没有规定，企业可以选择常见的生命周期模型，也可以自己定义自己的模型。

 

SP1.4Estimate the project effort and cost for the work products and task based onestimation rationale. 可以把SP1.4看作是SP1.2的延续，要根据工作产品及任务的属性估算出项目的规模和成本。

 

SG1说的是如何准备估算的问题，为做计划打好基础，而SG2说的就是要建立计划了。

 

SG2：A project plan isestablished and maintained as the basis for managing the project. 中文大意是：建立和维护项目计划，这个计划要作为项目管理的基础。那么项目计划要包含什么内容呢？

 

SP2.1Establish and maintain the project's budget and schedule. 建立和维护项目的预算和进度。

 

SP2.2Identify and analyze project riskes. 识别和分析项目风险。

 

SP2.3Plan then managemanet of project data. 计划对项目数据的管理。什么是“项目数据”呢？在项目开发过程中，会产生各类文档、代码等，我们再写项目计划的时候，要考虑好如何管理开发过程中产生的工作产品、数据等，例如存放的位置、访问权限控制。通常我们需要文档分类存放，设定一些个人工作区、项目组共享区等，计划好这些东西的管理 注册会计师培训，目的就是为了让工作更加有条理。

 

细心的人可能会发现，这个SP怎么有点象CM这个PA呢？没错，CM也讲的也是管理工作产品，与这个SP是有相似之处的，CM是从配置管理的角度来讲述的，而这个SP就从项目管理的角度来讲述的。详细情况，我们再论述CM的时候再谈。

 

SP2.4 Plan for necessary resources to perform the project . 计划必要的资源来执行计划。资源包括：人、计算机、设备、工具、办公室等。|

 

SP2.5 Plan for knowledge and skills needed to perform the project. 计划需要的知识和技能来执行计划。这点经常是做计划的时候被遗忘的，项目经理应该根据项目组成员情况和项目的特点，找出项目组还没有掌握的知识和技能，安排需要的培训，让项目组成员掌握相应的技能。

 

SP2.6 Plan the involvement of indentified stakeholders. 识别干系人并计划他们的参与。计划要考虑客户、高层领导、与本项目相关的第三方等相关人员可能的参与，规划他们参与的时间点，参与的工作产品等。例如：要计划客户什么时候参与需求调研，计划客户什么时候需要准备好软硬件环境，以便安装系统等。

 

SP2.7 Establish and maintain the overall project plan content. 建立和维护全面的项目计划内容。就是就是要把上面提到的SP2.1到SP2.6的内容全部要写下来，要文档化。

 

到现在为止，似乎项目计划就完成了，是这样吗？项目计划只由一个人制定的吗？只跟一个人有关系吗？

 

SG3：Commitments to theproject plan are established and maintained. 建立和维护对项目计划的承诺。项目计划要被相关的人评审和认可。

 

SP3.1 Review all plans that affect the project to understand project commitments.项目计划可能会有好多个子计划，如开发计划、测试计划、培训计划等，这些计划都应该被相关人员复查，保证大家理解一致。

 

SP3.2 Reconcile the project plan to reflect available and estimated resources. 调整计划，使计划在有限的资源内是可行的。计划要受到资源的限制，通过评审要发现不协调的地方，适当调整计划，保证计划可行。

 

SP3.3 Obtain commitment from relevant stakeholders responsible for performing andsupporting plan excecution. 得到相关人员的承诺，保证执行和支持计划。计划通过评审，就以为这所有参加评审的人承诺按照计划的要求完成自己的任务，同时他也会支持他人按计划完成任务。

 

PP有三个SG，分别是建立估算、建立计划、取得承诺，大家如果仔细阅读每个SP，大家会发现做好一个计划是不容易的，要考虑的东西很多。另外，还必须用这个计划来管理项目，更详细的内容我们看计划跟踪与控制这个PA吧。

 

需求管理(Requirements Management)

人是会死的，需求是会变的。相信大家都经历了很多需求变更的痛苦，项目被拖延，成本高涨，十有七八是需求管理没有做好导致的。有哪一些需求管理方面的常见问题呢，这里列举一下：

 

1.因为项目进度赶等原因，在很多需求还没有明确情况下，便开始开发的工作。

 

2.开始客户只能提出模糊的需求，客户喜欢先让你做个东西给他看，然后他才可能逐渐提出真正的需求，而需求调研人员，对此没有什么好的处理办法。

 

3.客户以种种原因不签需求，项目组在不签需求的情况下，便开始开发工作。

 

4.客户不承认之前提出来的需求，项目组又不能得失客户，项目成员苦不堪言。

 

5.需求经常变化，无法控制。

 

6.设计、代码与需求不对应，特别是需求变更时，不知道应该修改哪部分，也不知道会有哪些影响。

 

......

 

这方面的问题可真是“罄竹难书”了，需求管理这个PA提供了能解决以上大部分问题的最佳实践。

 

RM(RequirementsManagement)只有一个Specific Goals:Manage Requirements

 

Requirementsare managed and inconsistencies with project plans and work products areidentified.

 

中文大意是：

 

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

 

这句话有两层意思：

 

1.需求要被管理，被管理的意思又有两层：一是需求要被确认，二是要控制需求变更

 

2.需求要用来指导下游的工作产品，如：计划、设计、测试等

 

下面简单介绍一下这个Specific Goals下的5个SpecificPractice：

 

第一个SP是：理解需求。

 

开发者应该理解客户的需求，如果这点做不到，后面的工作是没有意义的。所以，那种在没有理解需求的情况下，就仓促开发的做法是不合适的。

 

当然，如果想通过做原型来获取需求不在此列，另外，大家也千万不要误解，在没有完全理解需求前一定不能开展开发工作，如果部分需求已经掌握，有部分需求还没有掌握，那也是可以先开展已掌握部分需求的设计、编码工作的，这时需要考虑没有确定部分的需求对这些工作可能带来的影响。

 

这个SP的英文原文是：Develop an understanding with therequirements providers on the meaning of the requirements.

 

第二个SP是：确认需求，就是要和客户签署需求。

 

我想大家都非常理解这点的重要性，但大家可能会说，说得容易，客户就是不签，咋办？客户不签需求，主要是两方面的原因：

 

1)客户不确定需求。

 

2)客户担心签了需求后，他就不好变了。

 

对于原因一，解决办法就是大家需要把SP1理解需求做好，如何把需求理解做好，更详细的内容可以参考3级的需求开发(RD)，这里先不详细解说。

 

对于原因二，要消除客户的顾虑，首先签署需求不是单方面的约束，其实也是对开发方的约束，就是说我们要承诺做出这样的一个东西，如果做不出来，客户可以追究我们的责任，另外一个方面，要跟客户说清楚，需求是可以变的，现在签署只是标志着当前的一个工作里程碑，当前签订的需求，是我们后续工作的一个基准。

 

大家可能又会问如果只能确定一部分需求，客户还是不愿意签，咋办？那就先签确定部分的需求呗！

 

这个SP的英文原文是：Obtain commitment to therequirements from the project participants.

 

第三个SP是：管理需求变更。

 

需求不是不可以变，只不过需要管理。客户今天说改这，明天改那，后天又不算数，咋办？怎样才算管理需求变更呢？

 

1.要充分理解客户提出来的需求变更，深究其原因，不能客户一说变就变，超过一半的客户变更要求，其实都是不合理的，或者是有其它更好的替代办法的。

 

2.客户提出来的变更要求，要书面记录，并让客户确认，和客户讨论需求变更过程来往的邮件要保存好，和客户面谈、聊电话后，要发邮件总结当此会谈达成的要点共识，总之就是要有书面记录。

 

3.客户提出来的需求变更，要分析所有的影响，包括增加多少的工作量，需要修改或者增加哪些设计文档代码等，可能会引发什么风险等。所有这些要列出清单，反馈给客户，让客户确认。

 

4.如果需求变更导致项目成本和进度变化太大，超出可承受范围，则需要高层领导出面，和客户协商调整费用。

 

这个SP的英文原文是：Manage changes to the requirementsas they evolve during the project.

 

第四个SP是：维护需求的双向跟踪。

 

需求是用来指导后续工作的，所以需求与计划、设计、编码、测试等后续工作都需要维护好对应的关系，这个工作与第三个SP是关系密切的，如果这个关系没有维护好，那么SP1.3也不可能做好。

 

这样是不是双向跟踪就能做好呢？不是，双向跟踪的意思不是由A能找到B，由B又能找到A就叫双向跟踪。双向跟踪是只纵向和横向跟踪，前面提到的只是纵向跟踪，纵向跟踪的意思是上下游工作产品之间的跟踪关系。而横向跟踪指的是需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等。其中一个需求变化了，有可能影响另外一些需求，其中一个设计变了也可能影响另外一些设计。

 

所以，这个双向跟踪网络，将会是一个很强的网络，任何一点发生变化，能找出全部受牵连的地方。

 

这个SP的英文原文是：Maintain bidirectional traceabilityamong the requirements and the project plans and work products.

 

第五个SP是：识别出需求与下游工作产品不一致的地方。

 

这里有两层意思：

 

1.需求变更时，利用双向跟踪表找出需要修改的地方，并用跟踪表来发现不一致的地方并调整。

 

2.编写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品的时候，要注意要与需求保持一致。

 

这个SP的英文原文是：Identify inconsistencies betweenthe project plans and work products and the requirements.

 

供应商协议(Supplier Agreement Management)

做软件开发的，不免要购买一些软硬件。软件可能是中间件、控件、插件、组件等，硬件可能是一些服务器、PDA、单片机等。只要稍微复杂的项目，都不可避免的会有采购的问题，就算目前没有采购，以后也会不可避免。另外也有可能把项目的一部分外包给第三方来做。

 

作为一个想改进过程的企业，是不应该规避这个问题的。采购的软硬件或者是外包，都会从根本上影响项目的成本、进度和质量，采购和外包可以认为是风险最大的活动之一。

 

那怎样才能把采购活动做好了？SAM有两个SG，第一个SG讲述的是要和供应商签署协议，第二个SG主要讲述的是履行供应商协议，下面我们详细介绍一下。

 

SG1：Agreement with thesuppliers are established and maintained. 建立和维护与供应商的协议。

 

SP 1.1: Determine the type ofacquisition for each product or product component to be acqured. 中文大意是：确定每个产品或者产品组件需要采购什么类型的东西。项目会因为技术原因、时间原因等需要采购一些软硬件来满足项目的需求。在前协议之前，应该先确定到底需要采购什么类型的东西。另外也可能把项目的一部分外包给第三方来做，那么也需要先确定外包什么东西。

 

SP 1.2: Select suppliersbased on an evaluation of their ability to meet the specified requirements andestablished criteria. 中文大意是：评估供应商是否具备满足指定的需求以及一定的标准，选择合适的供应商。选择供应商，首先是供应商必须能提供符合项目需求的产品或者服务。另外，采购通常是公司级的活动，或者会有专门的采购部门，采购活动本身会有一些对供应商的特定要求，如：资质、信誉等。选择合适的供应商，需要从这两方面来考虑。

 

SP 1.3:  Establish and maintain formal agreements withthe supplier. 与供应商签订和维护正式的协议。确定要采购的内容，选定供应商后，就需要和供应商签订协议，明确双方权利义务了。协议同时会对供应商提供的产品和服务提出规格要求、时间要求、价钱要求等。这个协议非常重要，对双方具有法律效用，也是用来管理供应商活动的基准。

 

SG2: Agreements with thesuppliers are satisfied by both the project and the supplier. 中文大意是：与供应商签署的协议要满足项目组和供应商双方的要求。

 

SP 2.1: Review candidate COTSproducts to ensure they satisfy the specified requirements that are coveredunder a supplier agreement. 检查候选的产品或者服务，保证其符合供应商协议中规定的要求。这个SP的关键点其实不是检查，而是需要在供应商协议中写清楚对产品或者服务的要求，越明确越好。要做好SP 2.1，其实要先把SP 1.3做好。

 

SP 2.2: Perform activitieswith the supplier as specified in the supplier agreement. 执行供应商协议中制定的活动，例如什么时候交付样品、提交报告，什么时候付款等。由这条我们可以看到，签署供应商协议的时候，一定要把双方需要什么时候做什么事情写清楚，然后就要按照要求执行。

 

SP 2.3: Ensure that thesupplier agreement is satisfied before accepting the acquired product. 在接受产品之前，要确保满足供应商协议中的要求。简单的说，就是在接受产品或者服务之前要验收，验收的标准就是供应商协议中的要求。由这个SP我们可以看到，供应商协议需要列清楚验收的标准。

 

SP 2.4: Transition theacquired products from the supplier to the project. 验收通过后，就把产品由供应商那里转交到项目的手中。转交一般会有一些签署交接单、运输、培训之类的工作，一般来说比较简单，但如果要交接的东西比较多，而且对运输要求高的，可能就比较复杂。

 

SAM这个PA，简单的说可以分为4点：

 

1)分析项目什么东西需要采购或者外包。

 

2)选择合适的供应商。

 

3)和供应商签署协议，协议要写明产品规格要求、验收要求、双方的活动、交付要求等，尽可能明细。

 

4)履行供应商协议。

 

项目跟踪和控制(Project Monitoring and Control)

计划不是用来看的，是用来执行的。PP讲述了如何做计划，PMC讲述的就是如何跟踪计划的执行并在实际情况偏离计划时采取纠正行动。

 

我们先看看SG1，SG1讲述的是如何根据计划来跟踪计划的执行问题。

 

SG1:Actual performance and progress of the project are monitored against theproject plan.

 

中文大意是：根据计划，跟踪项目的实际性能和过程。

 

那么我们要跟踪计划什么内容呢？简单的说，计划里面写了什么东西，就要跟踪什么东西。我们回顾一下PP是怎样说项目计划有什么内容的？计划要有估算、进度、数据包的管理、技能准备、干系人的参与等内容，所以项目跟踪也需要踪以上内容。

 

SP1.1 Monitor the actual values of the project planning  parameters against the project plan. 项目计划的参数就是指项目的范围、规模、性质、任务、工作量、费用等，每个企业都可以根据实际需要确定这些参数。在项目进行过程中，要密切关注这些参数的实际情况与计划估计的情况是否一致。

 

SP1.2 Monitor commitments against those identified in the project plan. 简单地说就是要跟踪项目成员承诺的任务是否按时间按要求完成，跟踪其他干系人是否能完成承诺的事情，如：第三方是否能如期交付软件、硬件、接口等。

 

SP1.3 Monitor risk against those identified in the project plan. 跟踪项目计划中已经识别出来的风险，要考虑风险是否发生了变化，同时也要考虑有没有新的风险产生。

 

SP1.4 Monitor the management of project data against the project plan. 项目计划中计划了数据包的管理，实际项目进展中，要落实这些工作。什么是数据包，请参考“项目计划”这个帖的说明。

 

SP1.5 Monitor stakeholder involvement against the project plan. 跟踪项目干系人的参与。如计划了什么时候要开始什么任务，什么时候客户要开始准备系统环境等，需要依据计划去跟踪。

 

SP1.6 Periodicall review the project's progress,performance,and issues. 定期检查项目的进度、性能和问题。定期并不是指按照一定周期，只有有计划去检查，在某些时间点去做检查，就叫定期。另外什么是项目性能？简单的说就是项目按计划执行的实际能力，如任务完成能力、项目组成员的实际水平、文档的质量、代码的质量等。那什么是“issues(问题)”呢？凡是影响项目不能按计划进行的情况，都是问题。

 

SP1.7 Review the accomplishments and results of the project at selected projectmilestones. 在项目选定的里程碑检查项目情况。项目里程碑一般会是：需求确定、架构设计完成、软件发布等关键路径上的关键节点。SP1.6强调的是定期去检查项目状况，SP1.7强调的是要在关键节点检查项目状况，两个SP是有某种程度的重叠的。

 

SG1讲述的是如何跟踪计划执行的，而SG2讲述的是当实际情况明显偏离计划的时候，要采取纠正行动。

 

SG2:Corrective actions are managed to closure when the project 's performance orresults deviate significantly from the plan.

 

中文大意是：项目的性能或者结果明显偏离计划时，要采取纠正措施保证按计划进行。

 

SP2.1 Collect and analyze the issues and determine the corrective actionsnecessary to address the issues. 收集和分析问题，并确定必要的纠正措施来解决这些问题。

 

SP2.2 Take corrective action on identified issues. 针对识别出来的问题实施纠正行动。

 

SP2.3 Manage corrective actions to closure. 管理纠正行动保证问题被解决。

 

实际情况与计划情况有偏差是正常的，原因可能是计划本身做得不太好，也可能是实际工作没有到位。SG2强调的是要分析原因，找出问题根源，采取适当的行动，解决问题，使项目按照计划进行。

 

通常情况下，偏离计划的情况大多数是进度推迟、预算变大等超出计划估计的情况，作为项目管理者不应该轻易改变计划，而使计划与实际一致，而是应该努力改善实际情况，否则计划的意义就丧失了。但凡事也有例外，确实有可能做计划的时候定了一个“不可能完成”的计划，这是就确实需要变更计划。但凡是涉及到预算变更、关键节点推迟等关键变化，公司应该制定严格的变更控制制度，公司高层应该参与这些关键变更的评审，以保证计划的严肃性。

 

在3级的IPM还有4级的QPM，做项目计划的时候合理性会越来越得到保障，另外用于管理项目的参数也会越来越多，并且会有量化的管理目标。详细的内容以后再论述。

 

三级3级简述

2级其实有很多问题还没有解决的，细心的人会发现，2级对软件工程活动的指导很弱，如：需求开发、设计、编码、测试等。在3级，你会发现：

 

1)有指导需求开发的需求开发(Requirements Development)这个PA；

 

2)有指导设计、编码工作的技术解决方案(Technical Solution)这个PA；

 

3)有指导如何保证工作产品满足要求的验证(Verification)；

 

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

 

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

 

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

 

6)集成项目管理(Integrated Project Management)：3级的项目管理，要求利用组织级的财富库进行项目估算，并且利用财富库裁剪出项目自己的过程，并用这个过程来管理项目。

 

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

 

大家不知道有没有发现，2级的PA都是直接针对项目提出要求的。3级的IPM和RSKM，除了对项目级提出要求，另外也对组织级提出了要求，IPM要求有组织级的资产库，RSKM要求要有组织级的风险管理策略等。另外，3级有几个“O”开头的PA，这几个PA都是直接对组织级的提出要求。

 

8)组织过程焦点(Organizational Process Focus)：这个PA要求组织成立SEPG来推动过程改进的工作，要求识别、计划、实施改进过程，保证组织过程能持续改进。

 

9)组织过程定义(Organizational Training)：这个PA要求组织级建立财富库，财富库内容要包括标准的过程、裁剪库、度量库、生命周期模型等。

 

10)组织培训(Organizational Training)：要求组织根据商业目标要求准备并提供培训。

 

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

 

11)决策分析及解决方案(Decision Analysis and Resolution)：这个PA提供了一个如何做出最佳决策的方法指导。软件行业很多重要的决策，如设计方案、采购方案等，都可以应用这个PA提供的办法，另外也可以在组织过程改进中应用决策分析的办法。

 

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

 

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

 

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

 

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

 

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

 

由这些特点大家可以看到，3级已经对软件开发的各个方面有了详细的要求，2级很多不明细的地方全部已经明确。一个达到3级的企业，肯定会定义了很多软件开发各个方面的过程，并且会有组织级的财富库。所以3级叫“已定义”级。

 

补充说明：

 

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

 

Integrated Teaming、Organizational Environment for Integration：对大型软件团队提出了要求，一般情况下中小型软件企业可以NA。

 

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

 

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

 

需求开发(Requirements Development)

CMM的时候，是没有需求开发这个PA的，需求开发和需求管理有什么区别呢？

 

需求管理强调的是需求的确认以及需求变更的控制，而需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。

 

以上两个关于需求开发的例子，都是反面教材，都没有能很好地把握需求，一个没有抓住问题的关键，一个没有能找到真正的需求提供者来获取需求。

 

CMMI和CMM相比，增加了很多专门针对软件工程的PA，其中需求开发(RD)就是其中之一。需求开发这个PA，从很高的层次描述了如何做好需求开发。要理解好本PA，需要先理解清楚以下几个关键的概念：

 

1)客户需求(CustomerRequirements)

 

2)产品需求(ProductRequirements)

 

3)产品组件需求(ProductComponent Requirements)

 

客户需求是可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户的需要是什么。

 

产品需求是能满足客户需求，并对软件产品规格进行了详细描述的需求，软件设计师可以根据产品需求进行设计、编码等工作。

 

产品组件需求，是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等，这些可以认为是产品组件需求。

 

从另外一个角度，需求可以分为功能性需求和非功能性需求两类，功能性需求就是系统具备怎样的功能，能做什么事情，而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求，都会包含功能需求和非功能需求。

 

以前面提到的“短信订餐系统”为例，其实这个系统，客户需求很简单，就是要解决部分员工不方便订餐的问题。我们看到，如果我们没有抓住这个客户需求，一开始就认为非要做一个短讯系统，那么就会陷入例子的陷阱中。要解决这个客户需求，办法之一就是做短讯订餐系统，但更合适的办法可能就是打电话回公司让别人代订午饭了。

 

我们很多需求开发没有做好的原因，大部分是没有把握好客户需求，直接进入软件的细节，去讨论要做什么功能，界面要怎样设计去了，而忘记了软件的根本目的是为了解决什么问题。

 

当我们明确客户需求后，就应该把客户需求转变成产品需求和产品组件需求，客户需求一般都是比较高层次的，而且描述也会比较简单，不能作为日后验收的标准，我们需要对软件的规格进行说明。一般来说，我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候，要注意产品需求和产品组件需求，必须和客户需求对应起来，通常是多对多的关系。为什么要对应起来？我们要保证，软件的每一个界面，每一个功能都是有用的，都是“源自”客户需求的，这样才能保证我们做的事情都是正确的事情，防止被不相干的事情干扰。

 

我们经常抱怨客户的需求在变，其实80%的原因是没有把握住客户需求，其实客户经常变的是产品需求或者是产品组件需求，客户需求是很少变的，就是因为我们没有把握住客户到底想要什么、需要什么，导致我们认为客户太难“服侍”了。只有把握住客户真正的需求，我们才能抓住根本，万变不离其中。

 

接着下来，我们将从每个SG和每个SP来详细讲解需求开发这个PA。

 

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

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

 

SG1: Stakeholderneeds,expectations,constraints,and interfaces are collected and translated intocustomer requirements.

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

 

SP 1.1: Elicit stakeholderneeds,expectations,constrains,and interfaces for all phases of the product lifecycle.

导出干系人对整个产品生命周期各阶段的需要、期望、约束和接口要求等。这句话要包含了几个要点：

1)干系人：干系人除了指甲方的领导、系统的最终用户，还包括使用本系统的第三方以及与本系统有交互的第三方系统的拥有者、使用者等。

2)产品生命周期各阶段：干系人对系统的期望不一定只限于软件功能的，可能还包括数据的整理、资料录入、安装培训、维护要求等，干系人可能对软件生产的过程阶段都会提出他的要求，获取需求的时候，要注意干系人在软件生命周期不同阶段有什么要求。

3)需要、期望、约束、接口要求：甲方一般会对系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性，满足一些什么接口要求和约束条件等，都会有大致的想法。需求调研工作，首先要注意搞清楚这些内容。

4)导出：客户的原始想法可能是不明确的，或者是客户一时难表达完整的，我们需要用一定的方法，让客户能完整无遗漏准确地表达出他的想法。通常我们可以通过原型、图示、类比、问卷等办法来导出客户的需求。

 

SP 1.2: Transform stakeholderneeds,expectations,constraints,and interfaces into customer requirements.

转化干系人的需要、期望、约束和接口要求为客户需求。

SP1.1讲述的是通过一些方法记录客户原始的需求信息，而SP1.2讲述的就是把客户原始的需求信息整理成正式的客户需求，通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。

 

SG2: Customer requirements arerefined and elaborated to develop product and product-components requirements.

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

SG1讲述的是导出客户需求，而SG2讲述的是由客户需求到产品需求、产品组件需求的过程。

 

SP 2.1: Establish and maintainproduct and product-component requirements,which are based on the customerrequirements.

建立和维护产品和产品组件需求，这些产品和产品组件需求是基于客户需求的。产品和产品组件需求，是比较细致的需求，会详细描述软件与用户是怎样交互的，用户需要输入什么，系统会输出什么等都会比较详细描述出来。而客户需求一般只描述能实现什么功能、解决什么问题等，比较高层次。

客户需求一般是难以验证是否已实现的，而产品需求和产品组件需求是对软件规格的描述，是可以用来做为验收的标准的。

 

SP 2.2: Allocate the requirementsfor each product component.

分配需求给每一个产品组件。

这个SP将需求开发与技术解决方案联系起来，所有的需求应该与设计的产品组件对应起来，保证需求驱动后续的设计工作，同时也保证设计都是为了需求服务的。SP2.2是对SP2.1的进一步细化。

 

SP 2.3: Identify interfacerequirements

定义接口需求。接口需求包括系统与第三方的系统的接口要求，也包括系统本身各组件、各子系统、各部分之间的接口要求。通常这些接口需求在客户需求级别的时候，并不是很明细，需要对客户需求进一步细分成产品需求、产品组件需求，然后发掘出接口需求。SP2.3也是对SP2.1的进一步深化。

 

SG3: The requirements are analyzedand validated,and a definition of required functionality is developed.

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

 

SP 3.1: Establish and maintainoperational concepts and associated scenarios.

建立和维护操作场景及相关情景。

 

SP 3.2: Establish and maintain a definitionof required functionality.

建立和维护功能定义。

 

SP3.1和SP3.2是对需求描述的要求，要求描述出具体需求的操作场景、上下文，具体的操作步骤，对功能的详细描述等。通常我们可以通过UML的Use Case图或者是序列图等来表达这些内容。

 

SP 3.3: Analyze requirements toensure that they are necessary and sufficient.

分析需求以确认需求是必须和充分的。

 

SP 3.4: Analyze requirements tobalance stakeholder needs and constrains.

分析需求平衡以平衡干系人的需要和约束。

 

SP3.3和SP3.4是对需求的准确性、全面性、可实现性方面的要求，除了要取得全面准确地需求，还需要平衡约束条件，保证需求在约束条件下是可实现的。

 

SP 3.5: Validate requirements toensure the resulting product will perform as intended in the user's environmentusing multiple techniques as appropriate.

用各种合适的方法确认需求，确保最终产品能在用户的环境中按照设想运行。

这是需求开发的最后一步了，需求导出过程中尽管用了很多办法，但需求确认的时候，仍然需要采取办法确保获取的需求是符合最终的使用场景要求。

 

SP3.3、SP3.4和SP3.5，通常是通过需求评审来满足的。

 

技术解决方案(Technical Solution)

技术解决方案这个PA，主要讲述的是设计、开发、实施方面的问题。在CMM中，对设计、开发、实施方面的要求是比较简单的。

 

SG1:Product or product-component solutions are selected from alternative solutions.

 

从候选方案中选择产品或者产品组件的解决方案。这个目标的主要内容就是制定选择的标准，设计候选方案，针对产规格依据选择标准，从候选方案中选出合适的方案。

 

SP1.1Develop detailed alternative solutions and selection criteria.

 

开发详细的候选方案及选择的标准。

 

SP1.2Evolve the operational concept,scenarios,and environments to describe theconditions,operating modes,and operating states specific to each productcomponent.

 

针对每个产品组件描述操作概念、场景、环境、操作模式和操作状态等。

 

SP1.3 Select the product-component solutions that best satisfy the criteriaestablished.

 

选择最符合要求的产品组件设计方案。

 

SG1讲述的是如何找出最合适的设计方案，我们很多开发人员，做编码之前都不太喜欢认真思考设计方案，迫于时间压力，不仔细考虑设计方案是否合适，就直接开展工作，这样做的风险是非常大的。

 

SP1.1讲述的是先考虑好我们设计方案的选择标准，并找出可能的候选方案。

 

SP1.2要求我们对产品的规格进行详细的表述，因为我们的方案是要满足这些规格的，也只有这样，我们才能更好地找出合适的解决方案。

 

SP1.3讲述的就是根据选择标准选出最佳方案。

 

有人可能有这样的疑问，有些项目很简单，或者设计方案很明确，没有必要搞什么候选方案和选择标准，直接设计就可以了。设计方案除了针对整个项目的大的设计方案，还包括组成产品的各个组件的设计方案，绝大部分情况下，一个项目肯定会有部分地方技术不太明确需要仔细分析的。另外，不管怎样，都应该根据项目的实际情况，定出这个项目的设计标准，就算只有一个方案，也需要用该设计标准来检验该方案。大部分情况下，认为不需要考虑多个设计方案、不考虑设计标准，都是“懒惰”思想作怪，不做这样的考虑，项目的风险是比较大的。

 

SG2:Product or product-components designs are developed.

 

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

 

最佳候选方案确定后，就可以开展具体的设计工作了。

 

SP2.1Develop a design for the product or product components.

 

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

 

SP2.2Establish and maintain a technical data package.

 

建立和维护技术数据包。这个Practice的字面意思比较难理解，其实意思很简单，就是要建立和维护一套管理所有设计文档、数据的方法或者体制，对设计过程的数据、文档进行有效的管理。

 

SP2.3Design comprehensive product-component interfaces in terms of established andmaintained criteria.

 

根据所建立和维护的标准，设计合适的产品组件接口。

 

SP2.4Evaluate whether the product components should be developed,purchased,or resuedbased on established criteria.

 

根据制定的标准评估哪些产品组件需要开发、购买或者重用。

 

SG3:Product components,and associated support documentation,are implemented fromtheir designs.

 

实施产品设计并开发相应的支持文档。

 

SP3.1Implement the designs of the product components.

 

实施产品组件的设计，简单地说就是依据设计进行编码活动了。

 

SP3.2Develop and maintain the end-use documentation.

 

开发和维护最终用户文档，如用户手册、安装手册、管理员手册等。

 

产品集成(Product Integration)

什么是产品集成？简单的说就是把组成产品的所有软件组件组装起来，使之运行在目标环境上，产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。系统越复杂，集成就显得越发重要。

 

微软的每日构建，极限开发中的持续集成，都是对产品集成的基本原则，其基本道理就是随时保证组成最终产品接口一致，能顺畅运行，能随时拿得出可运行的版本。

 

SG1Preparation for product integration is conducted.

 

准备产品的集成。

 

SP1.1Determine the product-component integration sequence.

 

决定产品组件的集成顺序。如：要考虑清楚先编译那个组件，哪个组件和哪个先联调，然后加入哪个组件调试，最后怎样进行整体联调，要把次序考虑清楚。

 

SP1.2 Establish and maintain the environment needed to support the integration ofthe product components.

 

建立和维护用于支持产品组件集成的环境。这些环境包括硬件环境、网络环境、数据环境等。

 

SP1.3 Establish and maintain procedures and criteria for integration of theproduct components.

 

建立和维护产品组件集成的过程及标准。这里提到了过程，与SP1.1似乎有点重复，SP1.1只强调考虑集成的现有顺序，而SP1.3要需要考虑具体的集成过程，除了集成顺序，还需要考虑每一步的验证办法、成功标准等。

 

SG2The product-component interfaces,both internal and external,are compatible.

 

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

 

SG1的SP的工作产品一般会是集成计划、接口说明、集成标准等文档，SG1的主要任务是完成这些文档，而SG2的主要任务就是检查接口是否一致，并在发生接口变化的时候，管理接口的变化，使之保持一致。

 

SP2.1Review interface description for coverage and completeness.

 

检查接口描述，保证覆盖性和完整性。通常我们通过评审接口说明的办法来检查接口的完整性、覆盖性。

 

SP2.2Manage internal and external interface definitions,designs,and changes forproducts and product components.

 

管理产品和产品组件的内部和外部接口的定义、设计及变更。各组件之间是有关系的，我们需要对这些关系进行管理，保证组件间保持一致。

 

SG3Verified product components are assembled and the integrated,verified,andvalidated product is delivered.

 

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

 

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

 

SP3.1Confirm,prior to assembly,that each product component required to assemble theproduct has been properly identified,functions according to its description,andthat the product-component interfaces comply with the interface descriptions.

 

在装配之前，确认每一个被装配的产品组件已经被清楚定义，各功能符合描述要求、产品组件接口符合接口描述的要求。简单的说就是在集成前，做全面的检查工作，保证各部分符合既定的要求。

 

SP3.2Assemble product components according to the product integration sequence andavailable procedures.

 

根据产品集成顺序和相关过程集成产品组件。

 

SP3.3Evaluate assembled product components for interface compatibility.

 

评估产品组件的接口兼容性。

 

SP3.4Package the assembled product or product component and deliver it to theappropriate customer.

 

打包组装的产品和产品组件并交付给合适的用户

 

验证(Verification)

验证就是按照既定的标准，检查工作产品是否符合要求。工作产品可能是文档也可能是软件本身。而检查的办法一般是同行评审或者是软件测试。

 

那什么是同行评审呢？比方说：A君是做软件设计的，B君也是做软件设计的，A君写了一份设计文档，让B君这个同行（因为大家都是做设

 

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

 

 

 

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

 

的成本。

 

 

 

这个PA有3个SpecificGoals,SG1讲述的是做好验证的准备，SG2、SG3分别讲述的是执行验证的两种办法，一种是同行评审，一种是执行

 

验证（通常就是测试）。

 

 

 

如果测试是在用户实际生产环境下进行的，例如：验收测试、客户试用系统等，这时这类工作就属于确认(Validation)了，请参考关于“

 

确认(Validation)”的帖。

 

 

 

SG1Preparation for verification is conducted.

 

准备验证的工作。

 

 

 

SP1.1Select the work products to be verified and the verifaction methords that willbe used for each.

 

选择需要验证的工作产品以及每个工作产品的验证办法。

 

组织会定义要进行同行评审的工作产品，如：计划文档、需求文档、设计文档、代码等，并且规定了每种文档的同行评审办法。组织也会

 

定义需要进行测试的软件产品，比方说要进行单元测试、集成测试、系统测试等。

 

 

 

SP1.2Establish and maintain the environment needed to support verification.

 

建立和维护支持验证所需的环境。

 

对于同行评审来说，支持环境可能就是会议室、投影、电脑、事先准备好的文档等。

 

对于测试来说，支持环境可能就是测试的软件环境、数据环境、硬件环境等。

 

 

 

SP1.3Establish and maintain verification procedures and criteria for the selectedwork products.

 

建立和维护工作产品的验证过程及准则。

 

对于同行评审来说，验证过程就是同行评审开展的过程相关规定，如要事先发资料、通知大家到会、会议的组织、会议记录等等，准则可

 

能就是每个工作产品的评审标准。

 

对于测试来说，验证过程就是测试过程的相关规定，准则就是需求规格说明书，或者说是测试通过的标准。

 

 

 

SG2Peer reviews are performed on selected work work products.

 

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

 

 

 

SP2.1Prepare for peer reviews of selected work products.

 

做好同行评审的准备。

 

如：把要评审的文档实现发给大家，准备好会议议程，准备好会议室、投影仪等。

 

 

 

SP2.2Conduct peer reviews on selected work products and identify issues resultingfrom the peer review.

 

执行同行评审并识别同行评审中发现的问题。

 

 

 

SP2.3Analyze data about preparation,conduct,and results of the peer reviews.

 

分析在同行评审准备、执行、结果方面的数据。例如：记录评审的准备、进行时间，发现的问题数量，对每个问题进行分析等。

 

 

 

SG3Selected work products are verified against their specified requirements.

 

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

 

这里的验证既包括同行评审也包括测试，但因为SG2专门是针对同行评审的，这个SG可以理解成主要针对除了同行评审外的其它验证活动。

 

 

 

SP3.1Perform verification on the selected work products.

 

对指定的工作产品进行验证。如：执行单元测试、集成测试、系统测试等。

 

 

 

SP3.2Analyze the results of all verification activities and identify correctiveaction.

 

分析验证的结果，并制定修正计划。这里强调的是：除了要分析发现的问题外，还需要采取行动修正这些问题。

 

确认(Validation)

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

 

而确认强调的是，在真实的使用环境中，确保软件能达到预期的效果。开发环境与真实环境是不可避免存在差异的，为了有效地避免在开发环境中没有问题，但一到真实环境就出现问题的情况，确认的工作是非常重要的。

 

确认不一定在项目后期才进行，这个PA没有对确认的时间有任何的规定。作为一般的常识，我们应该尽快安排软件的确认工作，如：尽快发出一个小版本，在实际环境中运行起来，尽快发现确认中的问题。

 

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

 

 

 

SG1Preparation for validation is conducted.

 

准备确认工作。

 

 

 

SP1.1Select products and product components to be validated and the validationmethods that will be used for each.

 

选择需要确认的产品、产品组件以及确认的方法。

 

 

 

SP1.2Establish and maintain the environment needed to support validation.

 

建立和维护支持确认的环境，如试用环境、验收环境的准备等。

 

 

 

SP1.3Establish and maintain procedures and criteria for valication.

 

建立和维护确认的过程及确认准则。

 

 

 

SG2The product or product components are validated to ensure that they suitablefor use in their intended operating environment.

 

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

 

 

 

SP2.1Perform validation on the selected products and product components.

 

执行产品及产品组建的确认工作。

 

 

 

SP2.2Analyze the results of the validation activities and identify issues.

 

分析确认活动的结果并识别出问题。

 

风险管理(Risk Management)

项目管理其实就是风险管理，把风险管理好了，项目也就管理好了。可见风险管理是多么重要啊！

 

在CMM的时候，还没有专门的PA是针对风险管理的。

 

CMMI2级的PP这个PA的SP2.2提到要识别风险，但这里的要求还是处于项目级别层次的。3级中的RSKM，已经把风险管理上升到组织层面，组织级需要对风险进行分类、定义风险的属性、制定风险的管理策略等。

 

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

 

 

 

SG1Preparation for risk management is conducted.

 

做好风险管理的准备。

 

 

 

SP1.1Determine risk sources and categories.

 

决定风险的来源和分类。

 

 

 

SP1.2Define the parameters use to analyze and categorize risks,and the parametersused to control the risk management effort.

 

定义用来风险的属性，这些属性是用来分析风险、分类风险以及用来进行风险管理的。

 

 

 

SP1.3Establish and maintain the strategy to used for risk management.

 

建立和维护用于风险管理的策略。

 

 

 

用SP1.1到SP1.3，要求逐步深化。SP1.1只要求确定风险来源及分类。SP1.2就要求定义清晰的风险属性，一般来说，风险会有原因、后果、严重级别、发生机率、类别等属性，每个企业可以根据自己需要定义属性。SP1.3所谓的风险管理策略，指得就是风险如何存储、记录、跟踪、采取什么缓解措施等所有关于风险管理的组织级别的要求。

 

 

 

SG2Risks are identified and analyzed to determine their relative importance.

 

识别风险并分析决定他们的相关重要性。

 

 

 

SP2.1Identify and document the risks.

 

识别和记录风险。

 

这里要求以比较正规的方式记录风险。

 

 

 

SP2.2Evaluate and categorize each identified risk using the defined risk categoriesand parameters,and determine its relative priority.

 

根据已经定义好的风险分类及属性，评估和分类每一个风险，并决定其优先级。

 

 

 

SG3Risks are handled and mitigated,where appropriate,to reduce adverse impacts onachieving objectives.

 

风险被管理并且缓解，以减少对项目管理目标的影响。

 

SG2主要讲的是识别和分析风险，SG3就是要管理风险及采取缓解措施了。

 

 

 

SP3.1Develop a risk mitigation plan for the most important risks to the project,asdefined by the risk management strategy.

 

根据风险管理策略对项目最重要的风险制定风险缓解计划。风险缓解措施是指，降低风险发生机率及风险发生时采取的减低影响的措施。

 

 

 

SP3.2Monitor the status of each risk periodically and implement the risk mitigationplan as appropriate.

 

周期性地跟踪风险状态，在需要的时候实施风险缓解计划。

 

风险：就是可能发生的问题，它是还没有发生的，我们需要采取措施去规避，去降低它发生的可能性的，当风险发生了，也就是风险变成问题了，这个时候要降低风险带来的影响。

 

 

 

问题：就是确确实实存在的问题，是已发生已发现的，需要去处理的。问题的范围包含缺陷，但一般我们会这样定义问题，问题指项目过程中发现的除了缺陷以外的问题，如文档评审发现的问题、同行评审发现的问题、计划中存在的问题等等。

 

 

 

缺陷：一般就是指通过测试软件或者用户使用软件发现的问题。

 

集成项目管理(Integrated Project Management)

集成项目管理（IPM）是2级的项目计划（PP）与项目计划跟踪与控制（PMC）的“升级版”，而4级的定量项目管理（QPM）又是集成项目管理的（IPM）的“升级版”。

 

3级与2级最大区别之一就是上升到组织级，项目管理也是一样，项目需要利用组织资产库定义项目自己的过程，考虑各种计划的集成。这是“集成”的其中一层意思，“集成”另外一层意思就是，要协调和管理好项目开展过程中各相关关系人。这两层意思，分别对应SG1和SG2。

 

SG1The project is conducted using a defined process that is tailored from theorganization’s set of standard process.

 

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

 

 

 

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

 

3级的软件企业，会有很多项目开发方面的各个过程，而且根据不同的情况，可能会有不同的过程。也有可能同一个过程，允许不同类型的项目的做法或者执行的力度等不太一样。组织过程中会有明确的指导，告诉使用这个过程的项目，如何根据项目本身的特点，来选择或者制定自己项目应该执行的过程。这个指导，就是裁剪指南，根据这个指导定义项目应该执行的过程，就是“裁剪”，定义出来的项目应该执行的过程，就是“项目定义过程”。

 

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

 

 

 

SP1.1Establish and maintain the project’s defined process.

 

建立和维护项目定义过程。

 

 

 

SP1.2Use the organizational process assets and measurement repository for estimatingand planning the project’s activities.

 

用组织的过程库及度量库来估算和计划项目的活动。

 

如：利用历史项目的估算数据，来估算本项目的工作量。

 

 

 

SP1.3Integrate the project plan and the other plans that affect the project todescribe the project’s defined process.

 

集成项目计划及其它影响项目定义过程的计划。

 

一个项目可能有很多计划，如：开发计划、测试计划、配置管理计划、QA计划、培训计划等等，需要协调好这些计划，让项目所有工作有序开展。

 

 

 

SP1.4Manage the project using the project plan,the other plans that affect theproject,and the project’s defined process.

 

用项目计划及相关计划、项目定义过程来管理项目。

 

SP1.3强调的是建立和协调好各类计划，SP1.4强调的是利用这些计划来管理项目，前者是制定，后者是执行。

 

 

 

SP1.5Contribute work products,measures,and documented experiences to the organizationalprocess assets.

 

提交工作产品、度量数据、文档化的经验等到组织过程资产库。

 

项目利用组织级资产库来进行估算、计划等活动，同样项目也需要把自己本身的有价值的经验、数据、文档等提交到资产库，供以后的项目使用。

 

 

 

SG2Coordination and collaboration of the project with relevant stakeholders isconducted.

 

协调和项目相关的干系人。

 

 

 

SP2.1Manage the involvement of the relevant stakeholders in project.

 

管理项目相关干系人的涉入。

 

包括：要识别出相关干系人，并安排适当的时候让其介入等。项目干系人可能是：甲方、供应商、第三方系统的拥有者等，所有影响这个项目成功的相关人和单位都是干系人。

 

 

 

SP2.2Participate with relevant stakeholders to identify,negotiate,and track criticaldependecies.

 

让相关干系人参与识别、协商、跟踪关键的倚赖关系。

 

很多情况下，项目会有很多倚赖与第三方的制约。如需要供应商在什么时候提供产品，需要第三方什么时候准备好第三方系统的接口，需要用户准备好安装环境等，所有这些都有可能严重影响项目的进度、成本，必须让这些相关干系人介入协商跟踪这些关键依赖关系。

 

 

 

SP2.3Resolve issues with relevant stakeholders.

 

和相关干系人解决问题。

 

这个SP是衔接SP2.1、SP2.2的，前两个SP肯定会发现很多问题，需要和干系人协商解决这些问题。

 

决策分析与解决方案(Decision Analysis and Resolution)

举个简单的例子：大家有没有到电脑城买过电脑？你是通过以下哪种方式买电脑的呢？

 

A.      随便找一家，装完走人。

 

B.      找个认识的人，让其帮忙。

 

C.      麻烦，买品牌机算了。

 

D.     货比三家后，选择比较合适的。

 

方案A，风险比较大，容易被人蒙，也可能买到高价货。

 

方案B，宝全部压在那个认识的人身上。我是不愿意当那个“认识的人”的，吃力不讨好的苦差。

 

方案C，比较保险，但可能买不到性价比比较好的电脑。

 

方案D，全部依赖于你的个人能力了，能不能买到性价比高的电脑，全靠你自己了。

 

当然，方案有很多，以上只是举一些例子。如果我们总结一下，买到好电脑的方案都有什么特征呢？

 

1.       购买者清晰了解自己对电脑的配置要求以及自己价钱的承受能力。

 

2.       购买者有清晰的选择标准，如：服务态度、售后服务、价钱、品牌等。

 

3.       购买者清楚知道不可能购买到十全十美的电脑，他知道哪些东西对他更重要。

 

 

 

简单的说，决策分析就是根据一定的选择标准，在一些候选方案中选出合适的方案。一般来说，经过决策分析后得出来的决策，科学性更高，实施该方案成功概率会比较高。但实施决策分析本身的成本也比较高，一般我们只在重大问题采取决策分析的办法，例如：大家购买房子就需要决策分析一下了，但今晚去哪里吃饭，恐怕就不需要决策分析一下了。

 

 

 

SG1Desicisions are based on an evaluation of alternatives using establishedcriteria.

 

决策是根据一定的标准对可选方案进行评估的基础上的进行的。

 

这个PA只有一个SG。

 

 

 

SP1.1Establish and maintain guidelines to determine which issues are subject to aformal evaluation process.

 

建立和维护一个指南，该指南规定了哪些问题需要进行决策分析过程。

 

这个SP的意思就是，组织级应该有一个规定（项目级可以裁剪），说明什么情况下要进行决策分析。前面提到，决策分析的成本是比较大的，一般只用在特别有价值的决定上。一般来说，我们会在供应商选择、设计方案选择、是否发布等方面采用决策分析。例如今晚吃什么饭的小问题，就不需要决策分析了。

 

 

 

SP1.2Establish and maintain the criteria for evaluating alternatives,and therelative ranking of these criteria.

 

建立和维护评估可选方案及选择标准优先级的准则。

 

进行方案选择时，需要一些标准，并且要明确这些标准的权重，哪些标准需要更有限考虑一点。对于这些方面的考虑，需要制定相应的标准。一般来说，组织级应该定义这样的标准，供项目组使用。

 

 

 

SP1.3Identify alternative solutions to address issues.

 

识别可选方案来解决问题。

 

以前面购买电脑为例，要解决的问题就是按照一定的配置要求和价钱承受力来购买最合适的电脑。根据这样的要求，可以列出多个候选的购买方案。同样，我们在软件开发过程中，经常需要解决一些问题（如选择购应商，进行架构设计等），为了解决这些问题，要列出可以解决这些问题的可能方案。

 

 

 

SP1.4Select the evaluation methods.

 

选择评估的办法。

 

评估标准制定了，还需要确定评估的办法，例如：采用什么方式进行评估？按照什么步骤？如何打分？一般来说，都会使用结构性的分析办法来进行评估的。

 

 

 

SP1.5Evaluate alternative solutions using the established criteria and methods.

 

根据已制定的标准和办法，对可选方案进行评估。

 

 

 

SP1.6Select solutions from the alternatives based on the evaluation criteria.

 

根据评估的标准从候选方案中选出解决方案。

 

组织过程聚焦(Organizational Process Focus)

要做这个PA，组织要成立EPG（EngineerProcess Group）专门负责过程改进的工作。这个组是整个公司过程改进的动力源头、策划中心、执行中心、培训中心。

 

很多公司的过程改进没有做好，很大部分的原因是EPG的成员没有选择好。EPG成员绝对不能清一色都是“理论派”，没有具体项目经验的。这是最低要求，如果是我的话，我是一个“理论派”都不会让进EPG的。EPG的成员加起来应该有项目管理、需求、设计、开发、测试等软件各个方面的经验，并且要有至少一名超级高手对整个软件生命过程都非常熟悉而且很聪明的一个人。

 

OPF的每个Practice都不是很困难就可以做到CMMI的要求，但要做到有效，大家都感觉到过程是在改进中，对工作有用，这就比较困难了。很多通过CMMI3级评估的企业，虽然通过了评估，但企业对过程改进的感觉并不是很好，大部分是由于EPG成员的功力不够，做出来的过程实际意义不大导致的。

 

下面我们看看这个PA的要求：

 

SG1Strengths,weakness,and improvement opportunities for the organization’sprocesses are identified periodically and as needed.

 

定期地识别组织过程的不足、改进机会。

 

SP1.1Establish and maintain the description of the process needs and objectives forthe organization.

 

建立和维护组织的过程改进需求及目标。

 

组织的改进活动，不是为了过级的改进，改进活动是商业目标驱动的，组织的领导要经常问自己，为什么要改进？什么需要改进？

 

 

 

SP1.2Appraise the processes of the organization periodically and as needed tomaintain an understanding of their strengths and weakness.

 

定期地评估过程，理解过程的强项和弱项。

 

组织可以通过内部的评估、外部的评估等办法，发掘组织过程的强项和弱项。

 

 

 

SP1.3Identify improvements to the organization’s processes and process assets.

 

识别组织过程及过程资产库的改进机会。

 

 

 

SG2Improvements are planned and implemented 会计中级职称培训,organizational process assets aredeployed,and process-related experiences are incorporated into theorganizational process assets.

 

改进被计划和实施，组织过程财富库被部署，以及过程相关的经验等提交到组织过程财富库。

 

 

 

SP2.1Establish and maintain process action plans to address improvements to theorganization’s processes and process assets.

 

针对组织过程及过程财富库的改进机会，建立和维护改进计划。

 

简单的说就是要建立改进计划，该改进计划是针对组织的改进需要的。

 

 

 

SP2.2Implement process action plans across the organization.

 

在组织内实施改进计划。

 

 

 

SP2.3Deploy organizational process assets across the organization.

 

在组织内部署组织过程财富库。

 

 

 

SP2.4Incorporate process-related work products,measures,and improvement informationderived from planning and performing the process into the organizationalprocess assets.

 

提交从改进计划及执行过程中产生的过程相关的工作产品、度量、改进信息到组织过程财富库。

 

简单地说就是，过程改进活动中产生的有价值的东西要提交到财富库中。这些东西一般是：改进计划、过程文档、经验总结、能体现生产力的数据等。

 

 

 

最后补充说明一下，5级的OID是OPF的“升级版”，我们稍候时间再介绍“OID”。

 

组织过程定义(Organizational Process Definition)

OPF主要关注要有人来负责过程改进的工作，OPD关注的是组织级要有财富库作为整个组织的知识库。

 

什么是财富库，简单的说就是对组织有用的东西都可以纳入到财富库中，财富库可以包含：过程、生命周期模型、裁剪指南、度量库等。

 

如果把OPD进行扩展，就是一个组织如何进行知识管理的问题了，知识可以包括两类，非技术类和技术类，非技术类包括：标准过程、规章制度、流程、项目管理经验、度量数据等等，技术类包括：设计、代码库、重用组件等。组织除了要对知识进行分类外，还需要建立知识的收集、分析、存储、使用的策略及具体可操作的办法。

 

 

 

SG 2 set of organizational process assets isestablished and maintained.

 

建立和维护组织过程财富库。

 

 

 

SP1.1 Establish and maintainthe organization’s set of standard processes.

 

建立和维护组织的标准过程。

 

 

 

SP1.2 Establish and maintainthe descriptions of the life-cycle models approved for use in the organization.

 

建立和维护被批准用于组织的软件生命周期。

 

 

 

SP1.3 Establish and maintainthe tailoring criteria and guidelines for the organization’s set of standardprocesses.

 

建立和维护用于组织标准过程的裁剪标准和指南。

 

 

 

SP1.4 Establish and maintainthe organization’s measurement repository.

 

建立和维护组织度量数据库。

 

 

 

SP1.5 Establish and maintainthe organization’s process asset library.

 

建立和维护组织过程财富库。

 

组织培训(Organizational Training)

SG 2 training capability that supports theorganization’s management and technical roles is established and maintained.

 

建立和维护支持组织管理和技术角色的培训能力。

 

这个翻译比较拗口难懂，大意就是组织要针对组织的管理能力、各方面的技术需要等建立一套比较完整的培训体系。

 

 

 

SP1.1 Establish and maintainthe strategic training needs of the organization.

 

建立和维护组织的策略性的培训需求。

 

组织要从宏观上根据组织的商业目标、现实情况，找出需要进行培训的大方向，这些培训需求都是为公司的商业目标服务的。

 

 

 

SP1.2 Determine whichtraining needs are the responsibility of the organization and which will beleft to the individual project of support group.

 

决定哪些培训需求是针对组织级的，哪些是针对单独的项目和支持组的。

 

有些培训要求是针对全部人的，但部分培训要求可能是针对个别的项目组或者是个别的部门、个别的小组的。这个SP的意思就是要把组织级的培训大方向，往下细分给各部门、小组、项目甚至个人。

 

 

 

SP1.3 Establish and maintain anorganizational training tactical plan.

 

建立和维护组织的战略性的培训计划。

 

 

 

SP1.4 Establish and maintaintraining capability to address organizational training needs.

 

建立和维护培训能力来满足组织培训需求。

 

这个“培训能力”是主要是指培训的材料、工作产品、文档等。

 

 

 

SG2 Training necessary forindividuals to perform their roles effectively is provided.

 

提供必要的培训给相应的个体、小组、部门等，使之能更有效地执行职责。

 

 

 

SP2.1 Deliver the trainingfollowing the organizational training tactical plan.

 

根据培训计划执行培训工作。

 

 

 

SP2.2 Establish and maintainrecords of the organizational training.

 

连理和维护组织培训记录。

 

 

 

SP2.3 Assess theeffectiveness of the organization’s training program.

 

评估组织培训程序的效果。

 

评估的对象包括：培训的效果、培训过程的效果等。