CMMI3全过程域翻译讲解
1CMMI GG2制度化已管理的过程
institutionalize a managed process: The Process is institutionalized as a managed process.
制度化已管理的过程：将过程制度化为一个已管理的过程。
GP2.1建立组织纺方针
Establish and maintain an organizational policy for planning and performing the project planning process.
建立和维护一个组织级方针来规划和执行项目策划过程。
GP2.2规划过程
Establish and maintain the plan for performing the project planning process.
建立和维护执行项目策划过程的计划。
GP2.3提供资源
Provide adequate resources for performing the project planning process, developing the work products, and providing the services of the process.
提供充足的资源来执行项目策划过程，开发工作产品和提供过程服务。
GP2.4分配职责
Assign responsibility for performing the process, developing the work products, and providing the services of the project planning process.
分配项目策划过程的职责和权力来执行过程、开发工作产品和提供过程服务。
GP2.5培训人员
Train the people performing or supporting the project planning process as needed.
按照需要培训人员来执行或支持项目策划过程。
GP2.6管理配置
Place designated work products of the project planning process under appropriate levels of control.
将项目策划过程中指定的工作产品纳入适当级别的配置管理。
GP2.7 确定并纳入相关人员
Identify and involve the relevant stakeholders of the project planning process as planned.
按照计划识别并纳入项目策划过程的相关干系人。
GP2.8监控流程
Monitor and control the project planning process against the plan for performing the process and take appropriate corrective action.
按照本过程的执行计划监控项目策划过程，并采取适当纠正措施。
GP2.9 客观评价符合度
Objectively evaluate adherence of the project planning process against its process description, standards, and procedures, and address noncompliance.
按照过程描述、标准和规程，客观地评介项目策划过程的符合度，并解决不符合问题。GP2.10 与高层管理人员审查本过程的状况
Review the activities, status, and results of the project planning process with higher level management and resolve issues.
与高层管理人员审查项目策划过程的活动、状况和结果，并解决问题。
2CMMI GG3 制度化已定义过程
Institutionalize a Defined Process: The process is institutionalized as a defined process.
制度化已定义过程:将过程制度化为一个已定义的过程。
GP3.1建立已定义过程
Establish and maintain the description of a defined project planning process
建立并维护已定义的项目策划过程的说明
GP3.2搜集改进信息
Collect work products, measures, measurement results, and improvement information derived from planning and performing the project planning process to support the future use and improvement of the organization's processes and process assets.
搜集在计划和执行项目策划过程中所产生的工作产品、度量、度量结果及改进信息，从而支持组织过程与过程资产库未来的改进与使用。
说明：
GG、GP 为所有过程都需要满足或执行的目标和实践，因此以上斜体部分用于各PA的替换。
CMMI2 PA ----Project Planning （PP）
做好计划的第一步就是要把项目的范围、规模、性质、任务、工作量、费用等搞清楚。
SG1
Estimates of project planning parameters are established and maintained
建立和维护用于项目计划的各类参数的估算
SP1.1
Estimate the Scope of the Project. 估计项目的范围
如项目的目标、任务、工作产品等。这里通常就是指WBS(top-level work breakdown structure)，试想一下，我们做计划之前不是常常要先对任务进行分解吗？
SP1.2
Establish Estimates of Work Product and Task Atrributes.
估计工作产品及任务的属性。
做计划的时，我们会先列出这个项目要产生的工作产品，以及这个项目要完成的任务等，然后我们需要分析这些任务、工作产品的规模、工作量、复杂度、代码行数等所谓的属性。
CMMI并没有规定一定要分析什么属性，具体由企业自己来选择适合自己需要分析的属性。
在CMM模型的时候，项目计划这个PA硬性规定了需要分析的几大属性，CMMI模型中已经改进，不再强制要求。分析这些属性的目的是对任务、工作产品等更加了解，以便于做好计划。
SP1.3
Define the project life-cycle phases upon which to scope the planning effort.
定义项目生命周期。
写计划的其中一个步骤是要考虑用什么生命周期模型，是瀑布型？螺旋？还是别的？选择怎样的模型，CMMI并没有规定，企业可以选择常见的生命周期模型，也可以自己定义自己的模型。
SP1.4
Estimate the project effort and cost for the work products and task based on estimation rationale. 根据工作产品及任务的属性估算出项目的规模和成本。
SP1.4从某种意义上来说是SP1.2的延续
SG1说的是如何准备估算的问题，为做计划打好基础，而SG2说的就是要建立计划了。
SG2：
A project plan is established and maintained as the basis for managing the project.
建立和维护项目计划，这个计划要作为项目管理的基础。
SP2.1
Establish and maintain the project's budget and schedule.
建立和维护项目的预算和进度。
SP2.2
Identify and analyze project riskes. 识别和分析项目风险。
SP2.3
Plan then managemanet of project data. 计划对项目数据的管理。
什么是“项目数据”呢？在项目开发过程中，会产生各类文档、代码等，我们再写项目计划的时候，要考虑好如何管理开发过程中产生的工作产品、数据等，例如存放的位置、访问权限控制。通常我们需要文档分类存放，设定一些个人工作区、项目组共享区等，计划好这些东西的管理，目的就是为了让工作更加有条理。
SP 2.4
Plan for necessary resources to perform the project . 计划必要的资源来执行计划。
资源包括：人、计算机、设备、工具、办公室等。
SP 2.5
Plan for knowledge and skills needed to perform the project.
计划需要的知识和技能来执行计划。
这点经常是做计划的时候被遗忘的，项目经理应该根据项目组成员情况和项目的特点，找出项目组还没有掌握的知识和技能，安排需要的培训，让项目组成员掌握相应的技能。
SP 2.6
Plan the involvement of indentified stakeholders.
识别干系人并计划他们的参与。
计划要考虑客户、高层领导、与本项目相关的第三方等相关人员可能的参与，规划他们参与的时间点，参与的工作产品等。例如：要计划客户什么时候参与需求调研，计划客户什么时候需要准备好软硬件环境，以便安装系统等。
SP 2.7
Establish and maintain the overall project plan content.
建立和维护全面的项目计划内容。
就是就是要把上面提到的SP2.1到SP2.6的内容全部要写下来，要文档化。
SG3：
Commitments to the project plan are established and maintained.
建立和维护对项目计划的承诺。项目计划要被相关的人评审和认可。
SP 3.1
Review all plans that affect the project to understand project commitments.
所有计划均应被相关人员复查，保证大家理解一致。
这些计划包括项目的多个子计划，如风险计划、配置计划、开发计划、测试计划等。
SP 3.2
Reconcile the project plan to reflect available and estimated resources.
调整计划，使计划在有限的资源内是可行的。
计划要受到资源的限制，通过评审要发现不协调的地方，适当调整计划，保证计划可行。
SP 3.3
Obtain commitment from relevant stakeholders responsible for performing and supporting plan excecution. 得到相关人员的承诺，保证执行和支持计划。
计划通过评审，可认为所有参加评审的人承诺按照计划的要求完成自己的任务，同时他也会支持他人按计划完成任务。
PP有三个SG，分别是建立估算、建立计划、取得承诺，大家如果仔细阅读每个SP，大家会发现做好一个计划是不容易的，要考虑的东西很多。另外，还必须用这个计划来管理项目，更详细的内容我们看计划跟踪与控制这个PA吧。
PP有三个SG，分别是建立估算、建立计划、取得承诺。
CMMI2 PA ----Project Monitoring and Control（PMC）
PP讲述了如何做计划，PMC讲述的就是如何跟踪计划的执行并在实际情况偏离计划时采取纠正行动。
SG1:
Actual performance and progress of the project are monitored against the project plan.
根据计划，跟踪项目的实际执行情况与执行过程。
如何跟踪计划什么内容呢？简单的说，计划里面写了什么东西，就要跟踪什么东西。计划要有估算、进度、数据包的管理、技能准备、干系人的参与等内容，所以项目跟踪也需要踪以上内容。
SP 1.1
Monitor the actual values of the project planning parameters against the project plan.
监控实际情况与计划估计的参数情况是否一致。
项目计划的参数就是指项目的范围、规模、性质、任务、工作量、费用等，每个企业都可以根据实际需要确定这些参数。
SP 1.2
Monitor commitments against those identified in the project plan.
监控项目计划时得到的各承诺的执行情况。
简单地说就是要跟踪项目成员承诺的任务是否按时间按要求完成，跟踪其他干系人是否能完成承诺的事情，如：第三方是否能如期交付软件、硬件、接口等。
SP 1.3
Monitor risk against those identified in the project plan.
监控项目计划中已经识别出来的风险。
要考虑风险是否发生了变化，同时也要考虑有没有新的风险产生。
Monitor the management of project data against the project plan.
项目计划中计划了数据包的管理，实际项目进展中，要落实这些工作。
SP 1.5
Monitor stakeholder involvement against the project plan.
跟踪项目干系人的参与。
如计划了什么时候要开始什么任务，什么时候客户要开始准备系统环境等，需要依据计划去跟踪。
SP 1.6
Periodically review the project's progress, performance, and issues.
周期性地检查项目的进度、执行和问题。
项目执行是指项目按计划执行的实际能力，如任务完成能力、项目组成员的实际水平、文档的质量、代码的质量等。
项目问题是指影响项目不能按计划进行的情况。
SP 1.7
Review the accomplishments and results of the project at selected project milestones.
按照项目选定的里程碑检查项目情况。
项目里程碑一般会是：需求确定、架构设计完成、软件发布等关键路径上的关键节点。SP1.6强调的是定期去检查项目状况，SP1.7强调的是要在关键节点检查项目状况，两个SP 是有某种程度的重叠的。
SG1讲述的是如何跟踪计划执行的，而SG2讲述的是当实际情况明显偏离计划的时候，要采取纠正行动。
SG2:
Corrective actions are managed to closure when the project 's performance or results deviate significantly from the plan.
项目的执行或者结果明显偏离计划时，要采取纠正措施保证按计划进行。
Collect and analyze the issues and determine the corrective actions necessary to address the issues. 收集和分析问题，并确定必要的纠正措施来解决这些问题。
SP 2.2
Take corrective action on identified issues. 针对识别出来的问题实施纠正行动。
SP 2.3
Manage corrective actions to closure. 管理纠正行动保证问题被解决。
实际情况与计划情况有偏差是正常的，原因可能是计划本身做得不太好，也可能是实际工作没有到位。SG2强调的是要分析原因，找出问题根源，采取适当的行动，解决问题，使项目按照计划进行。
通常情况下，偏离计划的情况大多数是进度推迟、预算变大等超出计划估计的情况，作为项目管理者不应该轻易改变计划，而使计划与实际一致，而是应该努力改善实际情况，否则计划的意义就丧失了。但凡事也有例外，确实有可能做计划的时候定了一个“不可能完成”的计划，这是就确实需要变更计划。但凡是涉及到预算变更、关键节点推迟等关键变化，公司应该制定严格的变更控制制度，公司高层应该参与这些关键变更的评审，以保证计划的严肃性。
CMMI2 PA----Requirements Management（REQM）
SG1
Specific Goals:Manage Requirements
Requirements are managed and inconsistencies with project plans and work products are identified.管理需求并且识别出需求与项目计划、工作产品不一致的地方。
这句话有两层意思：
1.需求要被管理，被管理的意思又有两层：一是需求要被确认，二是要控制
需求变更
2.需求要用来指导下游的工作产品，如：计划、设计、测试等
SP1：Develop an understanding with the requirements providers on the meaning of the requirements. 理解需求。
开发者应该理解客户的需求，如果这点做不到，后面的工作是没有意义的。所以，那种在没有理解需求的情况下，就仓促开发的做法是不合适的。
当然，如果想通过做原型来获取需求不在此列，另外，大家也千万不要误解，在没有完全理解需求前一定不能开展开发工作，如果部分需求已经掌握，有部分需求还没有掌握，那也是可以先开展已掌握部分需求的设计、编码工作的，这时需要考虑没有确定部分的需求对这些工作可能带来的影响。
SP2：Obtain commitment to the requirements from the project participants.确认需求。
就是要和客户签署需求。
我想大家都非常理解这点的重要性，但大家可能会说，说得容易，客户就是不签，咋办？客户不签需求，主要是两方面的原因：
1)客户不确定需求。
2)客户担心签了需求后，他就不好变了。
对于原因一，解决办法就是大家需要把SP1理解需求做好，如何把需求理解做好，更详细的内容可以参考3级的需求开发(RD)，这里先不详细解说。
对于原因二，要消除客户的顾虑，首先签署需求不是单方面的约束，其实也是对开发方的约束，就是说我们要承诺做出这样的一个东西，如果做不出来，客户可以追究我们的责任，另外一个方面，要跟客户说清楚，需求是可以变的，现在签署只是标志着当前的一个工作里程碑，当前签订的需求，是我们后续工作的一个基准。
大家可能又会问如果只能确定一部分需求，客户还是不愿意签，咋办？那就先签确定部分的需求呗！
SP3：Manage changes to the requirements as they evolve during the project.管理需求变更。
需求不是不可以变，只不过需要管理。客户今天说改这，明天改那，后天又不算数，咋办？怎样才算管理需求变更呢？
1.要充分理解客户提出来的需求变更，深究其原因，不能客户一说变就变，超过一半的客户变更要求，其实都是不合理的，或者是有其它更好的替代办法的。
2.客户提出来的变更要求，要书面记录，并让客户确认，和客户讨论需求变更过程来往的邮件要保存好，和客户面谈、聊电话后，要发邮件总结当此会谈达成的要点共识，总之就是要有书面记录。
3.客户提出来的需求变更，要分析所有的影响，包括增加多少的工作量，需要修改或者增加哪些设计文档代码等，可能会引发什么风险等。所有这些要列出清单，反馈给客户，让客户确认。
4.如果需求变更导致项目成本和进度变化太大，超出可承受范围，则需要高层领导出面，和客户协商调整费用。
SP4：Maintain bidirectional traceability among the requirements and the project plans and work products.维护需求的双向跟踪。
需求是用来指导后续工作的，所以需求与计划、设计、编码、测试等后续工作都需要维护好对应的关系，这个工作与第三个SP是关系密切的，如果这个关系没有维护好，那么SP1.3也不可能做好。
这样是不是双向跟踪就能做好呢？不是，双向跟踪的意思不是由A能找到B，由B 又能找到A就叫双向跟踪。双向跟踪是只纵向和横向跟踪，前面提到的只是纵向跟踪，纵向跟踪的意思是上下游工作产品之间的跟踪关系。而横向跟踪指的是需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等。其中一个需求变化了，有可能影响另外一些需求，其中一个设计变了也可能影响另外一些设计。
所以，这个双向跟踪网络，将会是一个很强的网络，任何一点发生变化，能找出全部受牵连的地方。
SP5：Identify inconsistencies between the project plans and work products and the requirements. 识别出需求与下游工作产品不一致的地方。
这里有两层意思：
1.需求变更时，利用双向跟踪表找出需要修改的地方，并用跟踪表来发现不一致的地方并
调整。
2.编写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品的时候，要
注意要与需求保持一致。
CMMI2 PA----Measurement and Analysis (MA)
SG1:
Measurement objectives and activities are aligned with identified information needs and objectives.
组织级要明确实际的需要，定出度量的目标，并根据此目标，定义合适的度量方法、过程等。
SP1.1: Establish and maintain measurement objectives that are derived from indentified information 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:
Measurement results the address identified information needs and objectives are provided.
根据组织级定义的要求，进行度量工作，收集、分析、存储、报告度量信息等。
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 analysis results.
管理和存储度量数据、度量规范及度量结果。
根据SP1.3指定的存储办法，对度量数据及相关文档进行存储和管理。
SP2.4: Report results of measurement and analysis activities to all relevant stakeholders.
向相关人员报告度量结果及分析度量活动情况。
SG1主要从组织级的角度定义度量的做法，SG2就是按照已定义的做法，在实际工作中开展度量的工作。
度量工作有很多学问，所有的度量工作，都需要回答这些问题： 度量的目的是什么？
谁来做这个度量？
什么时候做这个度量？
如何做这个度量？
怎样记录度量的数据？记录到哪里？
谁会使用这些数据？
如何分析这些数据？
谁来分析这些数据？
分析的结果如何使用？
以上问题都可找到与之对应的SP .
CMMI2 PA----Configuration Management (CM)
没有有效的配置管理可能会出现的问题：
1)软件在开发环境没有问题，测试的时候也没有问题，但发布给客户的时候就有问
题。
2)修改一个缺陷后，以前已经解决的缺陷又再次出现。
3)以前已经搞定的问题，无缘无故再次出现。
4)需求变更后，必须问最熟悉的人才知道需要修改那部分的文档、代码来实现新的
需求。
5)找不回之前某个版本的设计、代码。
要做好配置管理工作，先要把工作产品的依赖关系画出来，找出关键的工作产品，然后决定每个工作产品需要的管理层次。配置管理大概有以下的管理层次：
1)不需要管理的。
2)需要保存起来便可。
3)要保存起来，并且要对访问权限进行控制，可能某些人只能读，某些人能读写。
4)需要进行版本管理。
5)需要进行基线级别的管理，即需要进行变更管理。
这些考虑好后，才考虑用什么工具对工作产品进行管理。
SG1:
Baselines of identified work products are established. 建立已识别的工作产品的基线。
SP1.1: Identify the configuration items,components,and related work products that will be placed under configuration management.
识别需要放于配置管理系统中的配置项、组件和相关工作产品。
SP1.2: Establish and maintain a configuration management and change management system for controling work products.
建立和维护一个配置管理系统，用于控制工作产品。
SP1.3: Create or release baselines for internal use and for delivery to the customer.
建立和释放基线，用于内部使用或者交付给客户。
配置管理Step 1：
1)识别需要进行配置管理的东西。
2)建立一个配置管理系统来管理需要进行配置管理的东西。
配置管理Step 2：
1)对一般的配置项进行管理。
2)对基线级别的配置项进行基线级别的管理。
配置项与基线的区别：
配置项是需要进行配置管理的最小单位，如：一份文档、一片段代码等
基线是配置项的一种，基线需要进行更加严格的管理。
一般配置项的管理等级是：权限控制、版本控制。
基线的管理等级除了具备以上管理外，还需要非常严格的变更控制办法。
SG2:
Changes to work products under configration management and tracked and controlled.
跟踪和控制置于配置管理系统下的工作产品的变更。
SP2.1: Track change requests for the configuration items.
跟踪配置项的变更需求。
例如：记录变更的原因、时间、提出人等。
SP2.2: Control changes to the configuration items.
控制配置项的变更。
一个配置项发生了变化，与它相关的配置项也会可能需要相应改变，需要跟踪和控制整个过程，直到全部变化结束。
SP2.1 SP2.2 并没有明确指出是针对配置项还是针对基线的，其实两者都使用，不过是针对配置项还是基线，都需要记录变更需求，另外要跟踪和控制变化，只是针对配置项和针对基线，做的程度不太一样而已。
SG3: Integrity of baselines is established and maintained.
建立和维护基线的完整性。
SP3.1: Establish and maintain records describing configuration items.
建立和维护描述配置项的记录。
简单的说，所有的配置管理活动，如变更需求、控制变化的过程、配置项状态等都需要进行必要的记录。
SP3.2: Perform configuration audits to maintain integrity of the configuration baselines.
执行配置审计来维护配置基线的完整性。
什么叫配置审计呢？
配置审计分为功能审计和物理审计。
功能审计：指工作产品是否满足一定的功能要求，这个工作一般不由配置管理员负责，而是通过文档的评审、软件的测试进行。
物理审计：就是检查工作产品是否符合格式、版本号等方面的要求，一般有配置管理人员负责。
配置项要进入配置库前，都应该经历审计，保证其符合要求，保证后续工作产品的正确性。如果是基线级别的工作产品要进入配置库，需要接受更加严格的审计。
CMMI2 PA----Process and Product Quality Assurance
SG1:
Adherence of the performed process and associated work products and services to applicable process descriptions,standards,and procedures is objectively evaluated.
依据一定的标准客观地评估被执行的过程及相应的工作产品。
这里要注意几点：
1)要有一定的标准，这是基础。
2)评估要客观。
3)要对过程、产品都进行评估。
SP1.1: Objectively evaluate the designed performed processes against the applicable process descriptions,standards,and procedures.
依据一定的标准客观地评价过程。
SP1.2: Objectively evaluate the designated work products and services against the applicable process descriptions,standards,and procedures.
依据一定的标准客观地评价工作产品。
如何检查软件生产活动，保证其按照组织的相应规定进行了，无非就是两个方面，一个是看看活动的过程是否按照组织的要求进行，另外一个方面就是看看活动过程中产生的工作产品是否符合组织的要求，例如是否符合模板要求、是否有要求的内容等。
这两个SP看上去简单，其实要做好，要做到两点：
1)组织定义的过程、工作产品的模版一定要明确、合理，并且具有可检查性。
2)QA对检查的过程和工作产品要有所理解。
SG2:
Noncompliance issues are objectively tracked and communicated,and resolution is ensured. 发现的问题要客观地被跟踪、沟通并解决。
SP2.1: Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers.
要和员工和管理者进行沟通以确保问题得以解决。
这个SP有两点要求：
1.QA发现的问题一定要与相关的员工和管理者进行有效的沟通。
2.要保证发现的问题最后被解决。
SP2.2: Establish and maitain records of the quality assurance activities.
建立和维护质量保证活动的记录。
QA工作中常见的问题：
1.QA与被检查者的关系不好。
2.被检查者以应付的心态应付QA的检查。
3.QA经常埋怨被检查者不按规定干活。
4.被检查者埋怨QA不理解项目的状况，指挥按条条框框办事。
这些问题，总结起来无非是以下的原因：
1.过程本身制定就很有问题，很难按照过程执行。
2.QA缺少软件开发经验，对过程理解不深。
3.QA没有更关注问题的预防，在过程未进行之前，没有对执行过程者进行相应的
教育，让过程执行者明白这个过程的道理。
4.QA没有去了解项目的背景以及相关的技术，无法对项目组成员提供有效的执行
过程的指导，只能依据条条框框进行指引，项目组无法理解过程的价值。
简单的说只有两个方面，一个就是过程本身的质量，一方面就是QA的水平了。
有人可能会说，过程就算是错的，也需要执行，在执行中持续改进。这个观点在某些情况下是不对的，要看过程错的程度。如果过程错到根本无法执行，这样强硬执行的话，肯定吃力不讨好。
在刚建立过程的时候，不宜太死，可以适当宽松，另外应该鼓励项目组定义自己的做法，然后QA就按照项目组自已定义的做法来监督执行。通过不断的积累，就可以建立比较完善的过程。
CMMI2 PA----Supplier Agreement Management (SAM)
做软件开发的，不免要购买一些软硬件。软件可能是中间件、控件、插件、组件等，硬件可能是一些服务器、PDA、单片机等。只要稍微复杂的项目，都不可避免的会有采购的问题，就算目前没有采购，以后也会不可避免。另外也有可能把项目的一部分外包给第三方来做。作为一个想改进过程的企业，是不应该规避这个问题的。采购的软硬件或者是外包，都会从根本上影响项目的成本、进度和质量，采购和外包可以认为是风险最大的活动之一。
那怎样才能把采购活动做好了？SAM有两个SG，第一个SG讲述的是要和供应商签署协议，第二个SG主要讲述的是履行供应商协议，下面我们详细介绍一下。
SG1：
Agreement with the suppliers are established and maintained.
建立和维护与供应商的协议。
SP 1.1: Determine the type of acquisition for each product or product component to be
acquired.
确定每个产品或者产品组件需要采购什么类型的东西。
项目会因为技术原因、时间原因等需要采购一些软硬件来满足项目的需求。在前协议之前，应该先确定到底需要采购什么类型的东西。另外也可能把项目的一部分外包给第三方来做，那么也需要先确定外包什么东西。
SP 1.2: Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria.
评估供应商是否具备满足指定的需求以及一定的标准，选择合适的供应商。
选择供应商，首先是供应商必须能提供符合项目需求的产品或者服务。另外，采购通常是公司级的活动，或者会有专门的采购部门，采购活动本身会有一些对供应商的特定要求，如：资质、信誉等。选择合适的供应商，需要从这两方面来考虑。
SP 1.3: Establish and maintain formal agreements with the supplier.
与供应商签订和维护正式的协议。
确定要采购的内容，选定供应商后，就需要和供应商签订协议，明确双方权利义务了。协议同时会对供应商提供的产品和服务提出规格要求、时间要求、价钱要求等。这个协议非常重要，对双方具有法律效用，也是用来管理供应商活动的基准。
SG2:
Agreements with the suppliers are satisfied by both the project and the supplier.
与供应商签署的协议要满足项目组和供应商双方的要求。
SP 2.1: Review candidate COTS products to ensure they satisfy the specified requirements that are covered under a supplier agreement.
检查候选的产品或者服务，保证其符合供应商协议中规定的要求。
这个SP的关键点其实不是检查，而是需要在供应商协议中写清楚对产品或者服务的要求，越明确越好。要做好SP 2.1，其实要先把SP 1.3做好。
SP 2.2: Perform activities with the supplier as specified in the supplier agreement.
执行供应商协议中制定的活动。
例如什么时候交付样品、提交报告，什么时候付款等。由这条我们可以看到，签署供应商协议的时候，一定要把双方需要什么时候做什么事情写清楚，然后就要按照要求执行。
SP 2.3: Ensure that the supplier agreement is satisfied before accepting the acquired product. 在接受产品之前，要确保满足供应商协议中的要求。
简单的说，就是在接受产品或者服务之前要验收，验收的标准就是供应商协议中的要求。由这个SP我们可以看到，供应商协议需要列清楚验收的标准。
SP 2.4: Transition the acquired products from the supplier to the project.
验收通过后，就把产品由供应商那里转交到项目的手中。
转交一般会有一些签署交接单、运输、培训之类的工作，一般来说比较简单，但如果要交接的东西比较多，而且对运输要求高的，可能就比较复杂。
SAM这个PA，简单的说可以分为4点：
1)分析项目什么东西需要采购或者外包。
2)选择合适的供应商。
3)和供应商签署协议，协议要写明产品规格要求、验收要求、双方的活动、交付要
求等，尽可能明细。
4)履行供应商协议。
3CMMI3概述
2级其实有很多问题还没有解决的，它对软件工程活动的指导很弱，如：需求开发、设计、编码、测试等。
3级新增了以下PA：
1)有指导需求开发的需求开发(Requirements Development)
2)有指导设计、编码工作的技术解决方案(Technical Solution)
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级的OPD、OPD、OT都是直接对组织级的提出要求。
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级叫“已定义”级。
CMMI3 PA ---- Product Integration(PI)
什么是产品集成？简单的说就是把组成产品的所有软件组件组装起来，使之运行在目标环境上，产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。系统越复杂，集成就显得越发重要。
微软的每日构建，极限开发中的持续集成，都是对产品集成的基本原则，其基本道理就是随时保证组成最终产品接口一致，能顺畅运行，能随时拿得出可运行的版本。
SG1
Preparation for product integration is conducted.准备产品的集成。
SP1.1
Determine the product-component integration sequence.决定产品组件的集成顺序。
如：要考虑清楚先编译那个组件，哪个组件和哪个先联调，然后加入哪个组件调试，最后怎样进行整体联调，要把次序考虑清楚。
SP 1.2
Establish and maintain the environment needed to support the integration of the product components. 建立和维护用于支持产品组件集成的环境。
这些环境包括硬件环境、网络环境、数据环境等。
SP 1.3
Establish and maintain procedures and criteria for integration of the product components. 建立和维护产品组件集成的过程及标准。
这里提到了过程，与SP1.1似乎有点重复，SP1.1只强调考虑集成的现有顺序，而SP1.3要需要考虑具体的集成过程，除了集成顺序，还需要考虑每一步的验证办法、成功标准等。
The product-component interfaces,both internal and external,are compatible.
产品组件的接口，包括内部和外部的，都是兼容。
SG1的SP的工作产品一般会是集成计划、接口说明、集成标准等文档，SG1的主要任务是完成这些文档，而SG2的主要任务就是检查接口是否一致，并在发生接口变化的时候，管理接口的变化，使之保持一致。
SP2.1
Review interface description for coverage and completeness.
检查接口描述，保证覆盖性和完整性。
通常我们通过评审接口说明的办法来检查接口的完整性、覆盖性。
SP2.2
Manage internal and external interface definitions,designs,and changes for products and product components.
管理产品和产品组件的内部和外部接口的定义、设计及变更。
各组件之间是有关系的，我们需要对这些关系进行管理，保证组件间保持一致。SG3
Verified product components are assembled and the integrated,verified,and validated product is delivered.
验证产品组件被装配和集成，经过验证和确认的产品被交付。
SG3主要讲的是执行集成的过程，并交付产品给客户。
SP3.1
Confirm,prior to assembly,that each product component required to assemble the product has been properly identified,functions according to its description,and that the product-component interfaces comply with the interface descriptions.
在装配之前，确认每一个被装配的产品组件已经被清楚定义，各功能符合描述要求、产品组件接口符合接口描述的要求。
简单的说就是在集成前，做全面的检查工作，保证各部分符合既定的要求。
Assemble product components according to the product integration sequence and available procedures.
根据产品集成顺序和相关过程集成产品组件。
SP3.3
Evaluate assembled product components for interface compatibility.
评估产品组件的接口兼容性。
SP3.4
Package the assembled product or product component and deliver it to the appropriate customer.
打包组装的产品和产品组件并交付给合适的用户。
CMMI3 PA ---- Requirements Development(RD)
需求开发和需求管理有什么区别呢？
需求管理强调的是需求的确认以及需求变更的控制，而需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。
CMMI和CMM相比，增加了很多专门针对软件工程的PA，其中需求开发(RD)就是其中之一。需求开发这个PA，从很高的层次描述了如何做好需求开发。要理解好本PA，需要先理解清楚以下几个关键的概念：
1)客户需求(Customer Requirements)
2)产品需求(Product Requirements)
3)产品组件需求(Product Component Requirements)
客户需求是可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户的需要是什么。
产品需求是能满足客户需求，并对软件产品规格进行了详细描述的需求，软件设计师可以根据产品需求进行设计、编码等工作。
产品组件需求，是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等，这些可以认为是产品组件需求。
从另外一个角度，需求可以分为功能性需求和非功能性需求两类，功能性需求就是系统具备怎样的功能，能做什么事情，而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求，都会包含功能需求和非功能需求。
以“短信订餐系统”为例，其实这个系统，客户需求很简单，就是要解决部分员工不方便订餐的问题。我们看到，如果我们没有抓住这个客户需求，一开始就认为非要做一个短讯系统，那么就会陷入例子的陷阱中。要解决这个客户需求，办法之一就是做短讯