CMMI3 和 CMMI 4

²             CMMI 3. 0

2.1 SPP模型...0

2.2 SPP过程域的目的...4

2.3 SPP与CMMI的关系...5

2.4 SPP文档结构与规范细分...6

2.5 SPP角色与职责表...8

2.6机构软件过程改进的政策... 9

2.6.1目标... 9

2.6.2机构领导的支持... 9

2.6.3质量管理的政策... 10

2.6.4软件工程过程小组的政策... 10

2.6.5质量保证小组的政策... 11

2.6.7项目团队的政策... 11

2.7 SPP裁剪与扩充的指导方针...12

²             CMMI4. 12

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

²  CMMI 3

       “精简并行过程”（Simplified Parallel Process，SPP）是基于CMMI以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”，它由众多的过程规范和文档模板组成。SPP主要用于指导国内IT企业持续地改进其软件过程能力。

此处“精简并行”的含义是：

（1）对CMMI 3级以内各过程域的内容和要求作了“精简”处理。

（2）在产品生命周期之内，项目管理过程、项目研发过程和机构支撑过程“并行”开展。

本章是SPP的综述文章，它对SPP的思想方法以及企业的软件过程改进政策作了全面介绍。阅读本章有助于读者更好地理解和应用SPP的所有过程规范和文档模板。

建议用户（企业）根据自身情况（如发展战略、研发实力等）适当地修改SPP，然后推广使用。

 

学习后，感觉很好。

2.1SPP模型

SPP模型把产品生命周期划分为6个阶段，分别为：

²  产品概念阶段，记为PH0。

²  产品定义阶段，记为PH1。

²  产品开发阶段，记为PH2。

²  产品测试阶段，记为PH3。

²  用户验收阶段，记为PH4。

²  产品维护阶段，记为PH5。

在SPP模型中，软件项目的过程有三大类：项目管理过程、项目研发过程和机构支持过程。软件项目过程：除了上述三类过程可以细分为19个主要过程域，分布在PH0到PH5的各个阶段。

项目管理过程包含6个过程域，分别为：

²  立项管理

²  结项管理

²  项目规划

²  项目监控

²  风险管理

²  需求管理

项目研发过程包含8个过程域，分别为：

² 需求开发

² 技术预研

² 系统设计

² 实现与测试

² 系统测试

² Beta测试

² 客户验收

² 技术评审

机构支撑过程包含5个过程域，分别为：

²  配置管理

²  质量保证

²  培训管理

²  外包与采购管理

²  服务与维护

SPP模型如图2-1所示。SPP模型的主要特征和优点有：

一、直观的过程模型

SPP模型将项目管理、项目研发、机构支撑所包含的工作划分为相对独立的三类过程，各个过程域之间的关系直观明了。这样，机构领导、项目经理、开发人员、测试人员、质量保证人员、外包与采购管理人员等人根据SPP模型，很容易知道自己“应该在什么时候、按照什么规范做什么事情”。所以SPP模型有助于使机构内的各个职能单位有条不紊地开展工作。

二、容易裁剪与扩充

SPP模型的三类过程贯穿了产品的整个生命周期，19个最常见的过程域都合理地安排在产品生命周期中的某些阶段。用户可以根据自己产品的特征，适当地裁剪或扩充SPP的过程域，很容易制定出最适合于本产品的过程模型。

 

 

图2-1  SPP模型

 

2.2 SPP过程域的目的

SPP 所有19个过程域的目的如表2-1所示。

项目管理过程域	目的
立项管理	采纳符合机构最大利益的立项建议，通过立项管理使该建议成为正式的项目。杜绝不符合机构最大利益的立项建议被采纳，避免浪费机构的资源、资金、时间等。
结项管理	在项目开发工作结束后，对项目的有形资产和无形资产进行清算、对项目进行综合评估以及总结经验教训等。
项目规划	为项目的研发和管理工作制定合理的行动纲领（即项目计划），以便所有相关人员按照该计划有条不紊地开展工作。
项目监控	周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源等，不断地了解项目的进展情况，以便当项目实际进展显著偏离计划时能够及时采取纠正措施。
风险管理	在风险产生危害之前识别它们，从而有计划地消除或削弱风险。
需求管理	在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
项目研发过程域	目的
需求开发	通过调查与分析，获取用户需求并定义产品需求。
技术预研	在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，尽可能早地发现并解决开发过程中将会遇到的技术障碍。
系统设计	设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。
实现与测试	依据系统设计文档，编写并测试整个系统的代码。在SPP中，实现与测试是“编程、代码审查、单元测试、集成测试、缺陷管理与改错”的综合表述。
系统测试	对最终系统进行全面的测试，确保最终系统满足产品需求并且遵循系统设计。
Beta测试	在产品正式销售之前，开发方将产品交付给一些潜在的客户免费试用，请他们对产品进行测试，并获取他们对产品的建议。
客户验收	客户依据合同对产品进行审查和测试，确保产品满足客户需求。
技术评审	尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。
机构支撑过程域	目的
配置管理	通过执行版本控制、变更控制等规程，以及使用配置管理软件来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。
质量保证	提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。
外包与采购管理	选择合适的承包商（外包）和供应商（采购），并依据合同进行有效的管理。
培训管理	根据机构（或项目）的需求来制定培训计划，并监督该计划的实施，确保培训取得预期效果。
服务与维护	是指产品销售之后的客户服务和产品维护，其宗旨是提高客户对产品以及对开发方的满意度。

表2-1  SPP过程域的目的

2.3 SPP与CMMI的关系

       CMMI是SPP的主要参考标准，但是SPP并不是对CMMI进行简化处理后的结果。两者都是用于指导软件过程改进的方法论，CMMI主要论述“应当做什么才能使软件过程能力达到CMMI某种级别”，而SPP则论述“应当怎样做才能使软件过程能力达到CMMI 3级水平”。

SPP过程域和CMMI 3级过程域的对应关系如表2-2所示。

SPP的19个过程域		CMMI 3级以内的18个过程域
项目 管理 过程	立项管理	CMMI 3级，Decision Analysis and Resolution
	结项管理
	项目规划	CMMI 2级，Project Planning
	项目监控	CMMI 2级，Project Monitoring and Control CMMI 2级，Measurement and Analysis
	风险管理	CMMI 3级，Risk Management
	需求管理	CMMI 2级，Requirements Management
项目 研发 过程	需求开发	CMMI 3级，Requirements Development
	技术预研 系统设计 实现与测试	CMMI 3级，Technical Solution CMMI 3级，Product Integration
	系统测试 Beta测试 用户验收 技术评审	CMMI 3级，Verification CMMI 3级，Validation
机构 支撑 过程	配置管理	CMMI 2级，Configuration Management
	质量保证	CMMI 2级，Process and Product Quality Assurance
	外包与采购管理	CMMI 2级，Supplier Agreement Management
	培训管理	CMMI 3级，Organizational Training
	服务与维护
SPP其它成果： ²  SPP综述文章 ²  SPP培训教材 ²  基于Web的项目管理工具		CMM 3级，Organization Process Focus CMM 3级，Organization Process Definition CMM 3级，Integrated Project Management

表2-2  SPP过程域和CMMI 3级过程域的对应关系

2.4 SPP文档结构与规范细分

       SPP的文档结构如图2-2所示，SPP包含19个过程域、40余个规程、近60个文档 。SPP的规范细分如表2-3所示。

图2-2  SPP文档结构

 

项目管理过程域	主要规程	文档模板
立项管理 SPP-PROC-PIM	立项建议 立项评审 项目筹备	《立项建议书》 《立项调查报告书》 《立项可行性分析报告》 《立项评审报告》
结项管理 SPP-PROC-PCM	结项管理	《结项申请书》 《结项评审报告》
项目规划 SPP-PROC-PP	项目估计 制定项目计划 审批项目计划 项目计划变更控制	《项目估计表》 《项目计划》 《项目计划变更控制报告》
项目监控 SPP-PROC-PMC	项目计划跟踪 偏差控制 项目进展总结	《项目监控数据表》 《项目偏差控制报告》 《项目进展报告》
风险管理 SPP-PROC-PM	风险管理	《风险检查表》 《风险管理报告》
需求管理 SPP-PROC-RM	需求确认 需求跟踪 需求变更控制	《需求跟踪报告》 《需求变更控制报告》
项目研发过程域	主要规程	文档模板
需求开发 SPP-PROC-RD	需求调查 需求分析 需求定义	《用户需求说明书》 《产品需求规格说明书》
技术预研 SPP-PROC-TPR	技术预研	《技术预研计划》 《技术预研报告》
系统设计 SPP-PROC-SD	体系结构设计 用户界面设计 数据库设计 模块设计	《体系结构设计报告》 《用户界面设计报告》 《数据库设计报告》 《模块设计报告》
实现与测试 SPP-PROC-IT	实现与测试	《实现与测试计划》 《编程文档》
系统测试 SPP-PROC-ST	系统测试	《系统测试计划》 《测试用例》 《测试报告》
Beta测试 SPP-PROC-BETA	Beta测试	《Beta测试协议》 《Beta测试报告》
客户验收 SPP-PROC-CA	客户验收	《客户验收计划》 《客户验收报告》
技术评审 SPP-PROC-TR	正式技术评审 非正式技术评审	《技术评审计划》 《技术评审报告》 《技术评审检查表》
机构支撑过程域	规程与关键活动	文档模板
质量保证 SPP-PROC-QA	制定质量保证计划 过程与产品质量检查 问题跟踪与质量改进	《质量保证计划》 《质量保证检查表》 《质量保证报告》 《质量问题跟踪表》
配置管理 SPP-PROC-CM	制定配置管理计划 配置库管理 版本控制 变更控制	《配置管理计划》 《配置库管理报告》 《配置项变更控制报告》
外包与采购管理 SPP-PROC-OPM	外包管理	《外包开发竞标邀请书》 《承包商评估报告》 《外包开发合同》 《外包开发过程监控报告》 《外包开发成果验收报告》
	采购管理	《采购竞标邀请书》 《供应商评估报告》 《采购合同》 《采购物品验收报告》
培训管理 SPP-PROC-TM	机构培训管理 项目培训管理	《培训计划》 《培训评估报告》
服务与维护 SPP-PROC-SM	客户服务	《客户服务计划》 《客户服务报告》
	产品维护	《产品维护计划》 《产品维护报告》

表2-3  SPP规范细分

2.5 SPP角色与职责表

       SPP的主要角色及其职责如表2-4所示（详见各个过程域对角色与职责的描述）。企业在应用SPP时，可以将SPP的各个角色映射到企业原有的岗位上，也可以依据SPP角色建立新的岗位。一个人可以被赋予多个角色，视具体情况而定。

常设角色		职责简述
机构过程改进角色	软件工程过程组 （SEPG）	（1）制定适合于本机构的过程规范。 （2）在机构范围内推广该规范（如培训、考核），评估机构过程能力等。
	质量保证小组 （QAG）	（1）监督规范的实施，确保所有项目以及相关部门准照规范开展工作。 （2）分析并解决机构内存在的共性质量问题，协组SEPG完善规范。
项目 管理 过程角色	机构领导	（1）是机构内所有项目的主管，对立项管理和结项管理有最终决策权。 （2）监督项目经理的工作，审批项目经理的各种申请。
	项目经理	（1）向机构领导汇报工作。 （2）是项目规划、项目监控、风险管理和需求管理过程域的负责人。 （3）监督项目成员的工作，审批项目成员的各种申请。
项目研发 过程 角色	需求分析员	调查、分析并定义需求，撰写相应的需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。
	系统设计师	根据需求文档设计软件系统的体系结构、用户界面、数据库、模块等，并撰写相应的设计文档。
	程序员	（1）根据系统设计文档，编写软件系统的代码。 （2）随时测试和检查自己的代码，及时消除代码中的缺陷。
	测试员	从事单元测试、集成测试和系统测试，主要工作包括制定测试计划、设计测试用例、执行测试和撰写测试报告。
机构 支撑 过程 角色	配置管理员	（1）为项目制定《配置管理计划》。 （2）创建并维护配置库，如分配权限、清除垃圾文件、备份配置库等。
	质量保证员 （即QAG成员）	（1）为项目制定《质量保证计划》。 （2）周期性的开展“过程与产品质量检查”。 （3）跟踪质量问题，给出质量改进措施。
	外包管理员	（1）挑选最合适的承包商，签订外包开发合同。 （2）监控外包开发过程，验收外包开发成果。
	采购管理员	（1）挑选最合适的供应商，签订采购合同。 （2）验收采购物品。
	培训管理员	制定机构（或项目）的《培训计划》，监督该计划的实施，撰写《培训评估报告》。
	客户服务人员	为客户提供与产品相关的服务（如技术咨询），快速响应客户的要求，给客户一个满意的解答。
	产品维护人员	（1）纠错性维护：及时解决用户遇到的技术故障和消除产品中的缺陷。 （2）完善性维护：在资源允许的情况下，不断改善产品功能与质量。
临时角色		职责说明
立项建议小组		（1）开展立项调查、产品构思和可行性分析，撰写相应文档。 （2）申请立项，并在立项评审会议上答辩。
立项评审委员会		由机构领导、各级经理、市场人员、技术专家、财务人员等组成，委员会按少数服从多数原则投票决定是否同意立项。
结项评审委员会		对项目的有形资产和无形资产进行清算，对项目进行综合评估，总结经验教训等。结项委员会的人员组成与立项评审委员会的类似。
技术评审委员会		对工作成果进行正式技术评审，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷。该委员会由项目内外的技术专家组成。
配置控制委员会		对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。

表2-4  SPP的角色与职责简表

2.6 机构软件过程改进的政策

2.6.1 目标

l 持续改进机构的软件过程能力，不断地提高产品质量、提高生产率并且降低开发成本。

l 在一年之内，初步建立适合于本机构的软件过程规范，并使机构内的所有项目和相关部门执行该规范。本年度机构内部对过程能力的评估成绩达到：合格率为100％，良好率为50％以上，优秀率为25％以上。

l 在两年之内，完善适合于本机构的软件过程规范，并使机构内的所有项目和相关部门执行改进后的规范。第二年度机构内部对过程能力的评估成绩达到：合格率为100％，良好率为75％以上，优秀率为50％以上。或者通过CMMI 3级评估。

补充说明：评估成绩在100～85之间为“优秀”，85～70之间为“良好”，70～60之间为“合格”，分数低于60为“不合格”。

2.6.2 机构领导的支持

l 机构领导批准用于软件过程改进的必要经费，例如支付咨询费，购买相关软件工具等。

l 机构领导组建SEPG和QAG，专门从事软件过程改进工作。SEPG的主要职责是建立适合于机构的过程规范，QAG的主要职责是监督该规范的实施。建议让SEPG和QAG的大部分人员重叠，这些人既是SEPG成员又是质量保证员，扮演两种角色。这样不仅节约人力资源，并且提高了工作效果（由制定规范的人去监督规范的实施最合适不过）。一般地，SEPG成员和质量保证员共占机构总人数的5%左右。

l 机构领导不仅要口头支持，还要亲自参与软件过程改进的实践。例如参加培训和考试，准照过程规范执行立项管理和结项管理等。

2.6.3 质量管理的政策

质量管理口号：“在开发过程之中内建质量而非修补质量”。

质量管理有种基本措施：“质量保证”、“技术评审”和“测试”。

一、质量保证

机构的质量保证员周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量以及产品质量”。

机构的质量保证员独立于任何项目，并赋予他一定的权利，对质量不合格的工作成果作出处理。

二、技术评审

在工作成果刚产生之际，对其进行技术评审（分正式或非正式两种），目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而提高产品的质量。

如果时间允许的话，应当尽可能多地对产品的重要工作成果进行技术评审。技术评审活动由项目开发团队组织。

三、测试

测试是指通过运行测试用例（test case）来找出软件中的缺陷。测试与技术评审的主要区别是前者要运行软件而后者不必运行软件。

一般地，产品开发过程中有四个测试阶段：单元测试、集成测试、系统测试和验收测试（或Beta测试）。其中单元测试和集成测试可以由项目开发团队组织。系统测试阶段必须有项目外的人员参与，以保证系统测试的客观性。验收测试（或Beta测试）由客户组织。如果有条件的话，建议机构成立专门的测试小组从事单元测试、集成测试和系统测试工作。

2.6.4 软件工程过程小组的政策

       机构领导任命一位熟悉软件工程、项目管理、CMM/CMMI并且有丰富工作经验的人担任SEPG的负责人。在机构领导的许可下，该负责人组建SEPG（成员可以是全职的也可以是兼职的）。

l  第一年度的任务与目标

²  SEPG约用2～3个月的时间，了解机构过程能力的现状，通过裁剪或扩充SPP，初步建立适合于本机构的过程规范。

²  SEPG约用1～2个月的时间，对机构全员进行培训和考试，确保全员了解本规范，并懂得如何应用。

²  之后SEPG协助QAG监督本规范在所有项目和相关部门的实施，并不断收集员工们反映的过程改进问题和建议，逐步改进过程规范（允许有小幅度的升级）。

²  本年度最后一个月，SEPG对机构的过程能力进行评估，并向领导和员工们通报“本年度过程改进工作报告”。

²  在SEPG、QAG和全体项目人员的共同努力下，争取使本年度过程能力的评估成绩达到：合格率为100％，良好率为50％以上，优秀率为25％以上。

l  第二年度的任务与目标

²  根据上年度的过程能力评估状况，以及员工们反映的问题和建议，SEPG查找机构过程能力的薄弱环节，研究出解决措施。SEPG用1~2个月的时间，建立比较完备的过程规范新版本（允许有大幅度的升级）。 或者通过CMMI 3级评估。

2.6.5 质量保证小组的政策

       机构领导任命一位熟悉过程规范并且有丰富的质量管理经验的人担任QAG的负责人（或称为质量经理）。在机构领导的许可下，该负责人组建QAG（成员可以是全职的也可以是兼职的）。

QAG在行政上独立于任何项目。这种独立性有助于质量保证员客观地检查和监控“过程以及产品的质量”。QAG准照SEPG制定的“质量保证规范”开展工作。

机构领导赋予QAG一定的权利，可以对质量不合格的工作成果做出处理。这种权利使得QAG的工作不会被轻视，并有助于加强全员的质量意识。对于QAG与项目之间出现的难以调和的争议，由机构领导处理。

2.6.7 项目团队的政策

项目中的任何管理人员、开发人员、测试人员等，必须学习与本职工作相关的过程规范，每个人都必须明白自己“应当在什么时候依据什么规范做什么事情”。项目经理应当树立榜样，并且督促项目成员们按规范做事。

       允许项目经理根据本项目的特征，在SEPG和QAG的指导下，适当地裁剪或扩充机构的过程规范，从而快速建立本项目的过程规范。这项工作应当在“项目规划过程域”中完成，并在《项目计划》中体现出来。

       如果项目对机构过程规范的裁剪幅度比较大，遭到QAG的反对，如果双方不能达成共识，则由机构领导处理该争议。

       SEPG对项目过程能力的评估成绩将作为评定项目人员工作业绩的重要因素，具体比重由机构领导决定，建议占30％以上的比重。

2.7 SPP裁剪与扩充的指导方针

l  不要迷信或者死搬硬套他人推崇的过程标准和规范（例如CMM/CMMI,ISO, RUP,SPP等等）。SEPG一定要根据机构的实际情况（如发展战略、研发实力等）来制定机构过程规范，要充分考虑过程改进的成本和效益。能够以比较低的代价有效地改进机构过程能力的规范才是好规范。

l  SEPG要有计划地、逐步地完善机构的过程规范，切忌盲目追求“大而全”，否则“欲速则不达”。软件过程改进不是一次性买卖，不能靠“革命”，只能靠持续地改良，不进则退。

l  SEPG应当具备一定的软件工程和项目管理知识，再通读CMMI和SPP（或接受培训），才能结合机构实际情况裁剪或扩充SPP，形成机构自己的过程规范。

l  SPP对其19个过程域的论述已经比较充分，一般而言，SEPG裁剪或扩充这19个过程域不会遇到太大的困难。如果机构的业务包括硬件开发，那么SEPG应当制定硬件开发过程规范（参考SPP的格式），并努力使软件、硬件开发过程保持一致性。

l  显然，SPP并没有覆盖机构的全部职能，它仅仅局限于软件项目的研发与管理领域。SEPG应当协助有关人员制定人力资源管理、财务管理、行政管理、市场管理、生产制造等领域的过程规范。上述每个领域的过程改进工作都是非常重要的。

l  SEPG要认真撰写规范，力求使规范中的文字和图表没有歧义，并且简单易懂。

 

² CMMI4

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

　CMMI4只有两个PA，就是：

　　组织过程性能(Organizational Process Performance ):OPP是对组织级的要求，组织需要统计出组织级的基线。

　　定量项目管理(Quantitative Project Management):PM是对项目的要求，项目要用组织级的基线来控制项目过程。

两个PA都很复杂，其中OPP的SP1.4建立性能基线，SP1.5建立性能模型，两者工作量就可以是2、3级几个PA的总和。

 

　　【1】定量项目管理(QuatitativeProject Management)

　　定量项目管理与一般的量化管理很不同，不是在项目管理过程中用到数据，就算是定量项目管理。定量项目管理要求过程是稳定的，过程要稳定，需要满足很多条件，企业的过程要做到稳定，要付出很多努力。

　　SG1 The project is quantitatively managed usingquality and process-performance objectives.

　　用质量和过程性能目标对项目进行量化管理。

　SP1.1Establish and maintain the project’s quality and process-performanceobjectives.

　　建立和维护项目质量及过程性能目标。

　　要建立项目的质量及过程性能两个方面的量化目标，如何制定量化的目标是关键，要做到这一步，需要有完整而有效的度量体系。要做好4级这个PA，做好2级的度量(MA)是关键之一。

　　一般来说，项目质量方面的量化目标有：缺陷发现率、问题发现率等，过程性能目标有：CPI、SPI、生产力效率、返工率等。

　　SP1.2Select the subprocesses that compose the project’s definedprocess based on historical stability and process performance will besatisfied,and identify corrective action as appropriate.

　　跟踪项目判断项目是否满足质量目标、过程性能目标，并在适当的时候采取修正行动，保证项目满足质量目标、过程性能目标。

　　SG2 Theperformance of selected subprocesses within the project’s definedprocess is statisically managed.

　　对项目的子过程进行统计管理，也就是要对项目子过程进行SPC。

　　SG1强调的是确定项目的量化管理目标，选择子过程组成项目定义过程，并根据量化目标进管理项目。SG2则对项目的子过程的管理提出了要求。项目的子过程可能是需求过程、设计过程、编码过程、测试过程等等，每个企业可以根据自己实际的需要，选择有重要价值的子过程进行统计过程and capability data.

　　根据历史的稳定的有能力的数据选择组成项目定义过程的子过程。

　　IPM要求根据裁剪库和裁剪指南，裁减出项目定义过程，而这个SP在IPM的要求上提高一级，要求利用组织稳定的有能力的数据，选择子过程组合成项目定义过程。

　　SP1.3Select the subprocessed of the project’s defined process that will bestatistically managed.

　　选择要进行统计管理的子过程，组成项目定义过程。

　　SP1.2的子过程和这里的子过程不太一样，两者可能是一样的，但SP1.3的子过程是指要进行统计过程控制的子过程，这个子过程必须是稳定的有能力的过程。

　　SP1.4Monitor the project to determine whether the project’s objectivesfor quality

下波动，波动有可能在上下限范围内，也有可能超出上下限。企业需要建立对这些波动的理解指南，帮助项目组理解这些数据波动的原因，并能采取适当的修正行动。

　　SP2.3Monitor the performance of the selected subprocesses to determine theircapability to satisfy their quality and process-performance objectives,andindentify corrective action as necessary.

　　跟踪选定的子过程，判断是否满足它们的质量及过程性能目标，并在必要的时候采取修正行动。

　　SP2.2是SP2.3的基础，首先我们要理解这些波动的原因，然后判断是否正常，判断是否超出了既定的目标，并根据具体的原因采取适当的修正措施。

　　SP2.4Record statistical and qumeasures that are to be included in the organization'sprocess performance analyses.

　　建立和维护用来进行组织过程性能分析的度量。

　　SP1.1选择了哪些子过程进行SPC，SP1.2就是更进一步，确定具体的度量办法。

　　SP1.3Establish and maintain quantitative objectives for quality and processperformance for the organization.

　　建立和维护质量和组织过程性能的量化管理目标。

　　定下用于项目管理的量化管理目标，这个目标应该包括质量方面以及组织过程性能方面。

　　SP1.4Establish and maintain the organization's process performance baselines

控制。

　　SP2.1Select the measures and analytic techniques to be used in statisically managingthe selected subprocesses.

　　选择要进行统计过程控制的子过程的度量及分析技术。

　　统计过程控制对度量、数据分析的要求很高，企业需制定一套完整的、有效的收集数据、分析数据、使用数据的方法、制度，用于需要进行统计过程控制的子过程。

　　SP2.2Establish and maintain an understandiing of the variation of the selectedsubprocesses using the selected measures and analytic techniques.

　　我们用上限和下限对进行SPC的过程进行管理，在这个过程中，我们会收集到很多数据点，这些数据点会在中值上

mance of the organization's set of standard processes are established andmaintained.

　　这个PA只有一个SG，要建立和维护基线和模型，这些基线和模型能体现组织过程性能。

　　SP1.1Select the processes or process elements in the organization's set of standardprocesses that are to be included in the organization's process performance analyses.

　　在组织标准过程库中选择过程或过程元素，用于分析组织过程性能。

　　简单的说，要选择哪些子过程进行SPC。

　　SP1.2Establish and maintain definitions of the

ality management data in the organization’s measurementrepository.

　　在组织的度量库中记录统计的有质量的管理数据。把定量项目管理中的有价值的度量数据，记录到组织的度量库中。这些数据可以用来分析，并用来计算新的基线，更新模型等等。

　　组织过程性能(Organizational Process Performance)

　　OPP是对组织级提出要求的，组织要根据公司的商业目标、企业的实际情况，选择要进行性能分析、量化管理的子过程，制定组织的质量和过程方面的量化的目标，建立基线和模型。这些量化的目标、基线、模型，要用于进行项目管理。具体内容见QPM。

　　OPP最核心的问题就是要进行SPC（统计过程控制），SPC不容易理解。

　　SG1Baselines and models that characterize the expected process perfor.

　　建立和维护组织过程性能基线。

　　SP1.5Establish and maintain the process performance models for the organization'sset of standard processes.

　　建立和维护过程性能模型。