《CMMI-DEVV1.3项目管理过程域.ppt》由会员分享，可在线阅读，更多相关《CMMI-DEVV1.3项目管理过程域.ppt（180页珍藏版）》请在金锄头文库上搜索。
1、CMMI-DEV V1.3Project Management PAs项目管理过程域项目管理过程域Continuous Representation: PAs by Category ProjectManagementProcess AreasCategoryRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationEngineeringConfiguration ManagementProcess and Product Quality AssuranceMeasurement and
2、 AnalysisDecision Analysis and Resolution Causal Analysis and ResolutionSupportProject PlanningProject Monitoring and ControlSupplier Agreement ManagementIntegrated Project ManagementRisk ManagementQuantitative Project ManagementRequirements ManagementOrganizational Process FocusOrganizational Proce
3、ss Definition Organizational TrainingOrganizational Process PerformanceOrganizational Performance ManagementProcessManagementStaged Representation: PAs by Maturity LevelOrganizational Performance ManagementCausal Analysis and Resolution5 Optimizing4 Quantitatively Managed3 Defined2 ManagedContinuous
4、Process ImprovementQuantitativeManagementProcessStandardizationBasicProjectManagementOrganizational Process PerformanceQuantitative Project Management Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process Definition Orga
5、nizational Training Integrated Project ManagementRisk ManagementDecision Analysis and ResolutionRequirements Management Project PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality AssuranceConfiguration Management RiskRework1 Initial
6、Process Areas Including IPPDLevelFocusCMMI模型(阶段表示法)CMMI的阶段式表示法就是组织成熟度方法5 5 优化级优化级(2)(2)4 4 定量管理级定量管理级(2)(2)3 3 已定义级已定义级(14)(14)2 2 已管理级已管理级(7)(7)1 1 初始级初始级(0)(0)1 1级级- -初始级初始级2 2 级级- -管理级管理级配置管理配置管理过程和产品质量保证过程和产品质量保证供应商合同管理供应商合同管理项目监控和控制项目监控和控制项目计划项目计划需求管理需求管理度量和分析度量和分析4 4 级级- -定量管理级定量管理级定量项目管理定量项目管
7、理组织过程性能组织过程性能3 3 级级- -定义级定义级需求开发需求开发技术解决方案技术解决方案验证验证确认确认产品集成产品集成集成项目管理集成项目管理组织过程焦点组织过程焦点组织过程定义组织过程定义组织培训组织培训风险管理风险管理决策分析和解决决策分析和解决5 5 级级- -优化级优化级组织性能管理组织性能管理原因分析和解决原因分析和解决CMMI模型(持续表示法) 级别级别分类分类Engineering (6) ProjectManagement (6)ProcessManagement(5) Support(5)2级 受管理受管理级Managed (7)PP(项目目计划划)PMC(项目目监
8、控控)SAM(分包合同管理分包合同管理)REQM (需求管理需求管理)CM(配置管理配置管理)PPQA(过程和程和产品品质量保量保证)MA(度量与分析度量与分析)3级 已定已定义级Defined (11)RD(需求开需求开发)TS(技技术解决解决)PI (产品集成品集成) VER(验证)VAL(确确认)IPM(集成集成项目管理目管理)RSKM(风险管理管理)OPD(过程定程定义)OPF(过程聚焦程聚焦) OT(培培训)DAR(决策分析与解决方案决策分析与解决方案)4级 定量管理定量管理级Quantitatively Managed (2)QPM(定量定量项目管理目管理 )OPP(组织过程性能程
9、性能)5级 持持续优化化级Optimizing (2)OPM(组织性能管理性能管理)CAR(因果分析和解决方案因果分析和解决方案)项目管理类过程域项目管理类过程域主要包含如下PA：项目计划PP;项目监督和控制PMC；风险管理RSKM;集成项目管理IPM；供应商合同管理SAM；需求管理REQM;Basic Project Management PAs 基础项目管理过程域基础项目管理过程域Advanced Project Management Pas高级项目管理过程域高级项目管理过程域项目计划 PPProject PlanningProject Planning目的: 制定和维护定义项目活动的计划
10、V1.3版的PP与V1.2版的PP不同之处特定目标，特定实践没有实质性的变更以下术语的定义在词汇表中进行了修改：项目和项目启动。程序从词汇表中删掉在介绍性说明中，增加了关于该过程域的特定实践除了项目之外是否适应于其他的指导在介绍性说明中增加了关于PP如何应用于产品线和敏捷环境的相关信息。移除掉了关于IPPD的资料在特定实践SP2.3和SP2.4中增加了子实践。对于SP2.4和SP2.5增加了工作产品样例。修改信息化材料，使WBS的开发基于项目策略而不是产品的架构Project Planning - ContextPlanningDataEstablishEstimatesObtainCommi
11、tmentto the PlanDevelop a Project PlanProject PlansPMCProject Planning - ContextDetermineEstimates of Effortand CostPlanningDataEstablish EstimatesEstimate the Scope of the ProjectEstablishEstimates of Work Product and TaskAttributesDefineProjectLife CycleProject Planning - ContextEstablish the Budg
12、etandSchedulePlanning DataDevelop a Project PlanPlan DataManagementPlanStakeholderInvolvementPlan forProjectResourcesProject PlansEstablishthe ProjectPlanIdentifyProject RisksPlan forNeededKnowledge and SkillsProject Planning - ContextObtain Commitment to the PlanReconcileWork andResourceLevelsProje
13、ctPlansReviewPlans that Affect the ProjectObtainPlanCommitmentPP的目的PP的目的就是制定和维护定义项目活动的计划PP的要点-1PP包括以下主要活动：开发项目计划与项目相关人员适当的交流得到对计划的承诺维护计划策划工作从定义产品和项目的需求开始术语“项目计划” 指的是控制项目的整体计划PP的要点-2策划通过如下活动，迭代地建立项目计划估计工作产品和任务的属性确定需要的资源商讨承诺产生进度安排标识和分析项目风险项目计划提供执行和控制项目活动的基础，以满足项目对客户的承诺当遇到需求和承诺变更、不正确的估计、纠正行动和项目过程变更时，通常
14、需要修改项目计划PP的的SGs和和SPsSG 1: 建立估计：要建立建立估计：要建立 和维护和维护项目计划参数的项目计划参数的 估计数据估计数据 SG 2: 开发项目计划：要建立开发项目计划：要建立和维护项目计划，并作和维护项目计划，并作为管理项目的基础为管理项目的基础 SG 3: 获得对计划的承诺：要获得对计划的承诺：要建立和维护对项目计划建立和维护对项目计划的承诺的承诺 SP1.1 估算项目的范围估算项目的范围SP1.2 建立工作产品和任务属性的估算建立工作产品和任务属性的估算 SP1.3 定义项目生命周期定义项目生命周期SP1.4 估算工作量和成本估算工作量和成本SP2.1 建立预算和进
15、度建立预算和进度 SP2.2 识别项目风险识别项目风险 SP2.3 计划数据的管理计划数据的管理 SP2.4 计划项目的资源计划项目的资源 SP2.5 计划所需的知识和技能计划所需的知识和技能SP2.6 计划项目相关人员的参与计划项目相关人员的参与SP2.7 建立项目计划建立项目计划SP3.1 评审影响项目的计划评审影响项目的计划 SP3.2 协调工作和资源协调工作和资源SP3.3 获得计划的承诺获得计划的承诺特定目标特定目标 Specific Goal特定实践特定实践 Specific PracticeSG 1 建立估算-1SG 1 建立估算: 建立和维护项目计划参数的估算项目计划参数包括项
16、目从事下列活动所需的所有信息：规划、组织、用人、指导、协调、报告及预算。计划参数的估计值应有充分的根据，以提高自信心：任何以此估算值所做的计划，能够支持项目目标。有必要把估算的理由和支持性数据形成文件，以便在项目相关人员评审和获得对计划的承诺以及在项目进展过程中维护计划.SG 1 建立估算-2在估算项目计划参数时，通常要考虑以下因素:项目需求，包括产品需求、组织的需求、客户的需求和其它影响项目的需求 项目的范围已识别的任务和工作产品技术实现方法选择的生命周期模型 (如瀑布、增量、螺旋等)工作产品和任务的属性 (如规模或复杂度)进度转换工作产品和任务的属性为工时和成本的模型或历史数据确定需要的材
17、料、技能、工时和成本的方法（模型、数据和算法）SP 1.1 估算项目的范围建立顶层的工作分解结构(WBS)来估计项目的范围WBS与项目一起进化，初期的最顶层WBS 用于初期估计。WBS的开发将整个项目分解成可管理的相互关联的构件集。 WBS 通常是产品导向的结构，它提供了一种纲要结构，以识别与安排工作管理的逻辑单元，该逻辑单元称之为工作包。WBS为分配工作量、进度和职责提供了一个参考和组织机制，并被用作为计划、组织和控制有关项目要做的工作的基本框架WBS-Work Breakdown Structure的定义 工作结构分解（WBS）是对项目范围的一种逐级分解的层次化结构编码。依据PMBOK，分
18、解指把主要可交付成果分成较小的，便于管理的组成部分，直到可交付成果定义明晰到足以支持各项项目活动(计划、实施、控制和收尾)的制订。WBS是面向可交付成果的对项目元素的分组，它组织并定义了整个项目范围，未列入WBS的工作将排除在项目范围以外。它是项目团队在项目期间要完成的最终细目的等级树，所有这些细目的完成构成了整个项目的工作范围。准确界定项目的可交付成果和目标项目目标是完成项目所必须达到的可计量指标；尽量采用指标化和量化的项目目标，不可量化的目标一般都存在范围风险；不适合的项目目标的例子建造一座2层楼的办公楼；写一份与客户沟通产品功能的报告材料；正确的项目目标描述可以是用200万元，根据第二号
19、设计方案和*标准，在6个月内建成一座办公楼，包括土建、安装和室内装修工程，不包括室外装修；项目范围的定义项目范围：将项目可交付成果分成几个小的、更易管理的单元；为交付具有规定特征和功能的产品或服务所必须完成的工作(what to do)；项目范围的完成是对照项目计划进行衡量的；产品范围区别产品或服务的特征和功能(what to make)产品范围的完成是对照产品要求进行衡量的；WBS分解的基本原则完全穷尽，彼此独立，一个项目单元只能从属于某一上层单元，不能同时属于两个上层单元；没有包含在WBS中的工作不属于项目的工作范围；项目组的核心技术和管理人员参与制定，每个交付成果有人负责；最低层次的工作
20、包的单元成本不宜过大、工期不要太长。工作包(work package)一般应在40小时(小于5个工作日)内完成；WBS的不同的分解层数；应在各层次上保证项目内容的完整性，不能遗漏任何必要的组成部分。项目单元应能区分不同的责任者和不同的工作内容，应有较高的整体性和独立性。能够符合项目目标管理的要求，能方便的应用工期、质量、成本、合同、信息等手段。WBS不要太多层次，以四至六层为宜。WBS对项目计划编制的作用启动WBS活动定义资源计划风险管理风险识别成本估算活动排序工作量估算进度计划编制成本预算风险定性和定量分析项目计划编制风险应对措施和计划SP 1.2 建立工作产品和任务属性的估计SP 1.2
21、建立和维护工作产品和任务属性的估计规模(size)是许多用于估计工作量、成本和进度的模型的主要输入。其次是关联性(connectivity)、复杂度(complexity)和结构之类的输入要进行规模估计的工作产品的例子包括：可交付和不可交付的工作产品文档操作和支持软件估计应该与项目需求一致，以便确定该项目的工作量、成本和进度。每个规模属性应附上有关的难度和复杂度。规模度量的例子规模度量的例子包括: 功能数功能点源代码行类和对象数需求数接口数页数输入和输出数估算存在于估算中的常见问题没有考虑到其他重要项目因素开发环境的可用性和稳定性团队的能力和经验团队稳定性过程成熟度可复用的软件对需要创建的可复
22、用软件的估算同客户/用户之间可能的交流程度在软件开发和软件维护中使用自动化工具的程度项目相关人员和团队的团结缺少用于估算的培训和技能在项目的进行中对估算的跟踪不好估算的渐进性估算的渐进性随着项目的进展，估算不断细化每一阶段均需要进行详细的估算估算估算Basic processEstimate the size of the product估算规模的意义在于考虑每个任务的复杂度；规模是计算生产率的重要参数；规模大可能意味着资源的需求也很大；Estimate the effort (man-months)Estimate the cost and scheduleUnit of size: 代码行
23、（LOC）、功能点Unit of effort: 人天、人月、人年等Unit of cost：人民币、美元软件估算的组成软件需求规格说明书规模估算工作量估算其他项目因素其他成本构成成本估算进度估算客户提出的进度规模规模(Size)、工作量工作量(effort)和成本和成本(cost)规模规模和工作量工作量可以进行转换：软件生产率工作量工作量是成本成本的主要因素，一般项目的工作量估算和成本估算是同时进行的，工作量确定了，就基本可以确定项目的成本。软件生产率软件生产率是指人均每月所能生产的有效源代码行数。（生产率规模/工作量）影响软件生产率的因素人的因素：开发机构的规模和经验问题因素：问题的复杂性
24、和设计约束或要求更改的次数过程因素：使用的分析和设计技术、应用的语言及评审的过程。生产因素：计算机系统的性能和可靠性资源因素：开发工具、硬件和软件资源软件生产率根据软件组织的历史数据，按照以下步骤获取软件生产率数据：选择一些最近完成的项目，这些项目在规模、语言、应用类型、团队开发经验等方面与待完成项目类似。获取各个项目的规模数(功能点、对象点、LOC)计算投入到每个项目中的人员数量计算各个项目的软件生产率，即（功能点、对象点、LOC）/PM（人月）,进而求出平均值作为类型项目的典型软件生产率。估算步骤确定软件项目范围估算完成软件开发所需的资源估算产品的规模估算工作量估算成本估算方法估算方法1-
25、PERT方法方法PERT方法Pert方法是一种基于统计原理的估计方法，是一种简单易用、实效性强的软件估计方法对于指定的估计单元(可能是规模、进度、工作量、费用等)，由直接负责人给出估计结果，估计结果由3个值构成：最乐观值、最悲观值、最可能值，通过下面的计算公式得到估计的结果。期望值=(最乐观值+ 4* 最可能值+ 最悲观值)/ 6标准偏差=(最乐观值- 最悲观值)/6建议：(最高-最低)/最可能 40由此，推算出来最有可能接近实际情况的值期望值- 标准偏差，期望值+ 标准偏差是一个可以接受的估计范围，如果你的最终实际值能够落到该范围内，则可以被认为你的估计是成功的。初期该范围可以较大，随着估计
26、的不断精确，该范围应该逐渐被有意识的减少以求得更准确的估计。估算方法估算方法2Delphi方法方法宽带Delphi方法SP 1.4 确定工作量和成本估计基于估计原理，估计工作产品和任务的工作量和成本 工作量和成本的估计一般基于使用模型或历史数据分析规模、活动和其他计划参数的结果估计的可信度取决于选择估计模型的基本理由和历史数据的性质。在某些情况下没有适用的历史数据，如工作量无先例或任务类型没有适用的模型如果从来就没有做过类似的产品或产品构件，工作量就是无先例的。如果开发组从来没有做过这类产品或产品构件，工作量也是无先例的工作量无先例，风险就更大，需要多做调查研究，以便打下切实可行的估计基础，同
27、时也需要比较多的管理储备。在使用这些估计模型时，为了确保在初始的策划阶段对所做的任何假设有共识，必须就该项目的唯一性形成文档工作量估算应考虑的因素任务的难度：新颖程度、复杂度；日历表、节假日等；对技能的要求；对经验和经历的要求对业务知识的要求；质量问题：所需的质量标准是什么？项目的重要性：对客户、对管理层、对最终用户；外部资源：可得性、可靠性、质量、价格造成工作量估算不准的原因缺少经验或历史数据的支持；在估算时缺乏适当的方法或技能；与用户之间缺乏沟通，不能准确捕获需求；来自客户、内部的压力，导致不现实的估算；疏漏；对相关问题的定义模糊或者不准确；人为虚报，以降低风险；对项目团队成员的技能了解不
28、够；SG 2 开发项目计划建立和维持一个项目计划作为管理项目的基础 项目计划是正式的已批准的文档，用于管理和控制项目的执行。它基于项目需求和已建立的估计。 项目计划应该考虑项目生命周期的所有阶段。项目计划应该确保所有影响项目的计划与整体项目计划一致。 SP 2.1 建立预算和进度预算的定义对于项目执行方来说，预算是完成工作计划投入的成本；建立和维护项目的预算和进度项目的预算和进度基于已开发的估计，并确保预算分配、任务复杂度和任务依赖得到合适的处理预算的三件事情确定项目的总预算；确定项目各项活动的预算；确定项目各项活动预算的投入时间；预算项目预算过程其实可以分成估算和预算两大部分。估算的目的是估
29、计项目的总成本，而预算则是将项目的总成本分配到各工作项中去；估算内容包括人工成本、差旅、设备、和外包成本等。通常，人工成本占相当大比例，可以根据各类人员的成本单价和投入工作量进行计算；成本预算是在确定总体成本后的分解过程。分解主要是做两个方面工作：一是按工作包分摊成本。这样可以对照检查每项工作的成本，出现偏差时可以确定是哪项工作出了问题；二是按工期时段分摊成本，将预算成本分摊到工期的各个时段，可以确定在未来某个时点累计应该花费的成本,这样做的好处是可以在任何时间检查偏差，并评价成本偏离情况综上所述，预算包括估算和预算两个步骤，预算的关键是要知道每个工作包成本和未来具体时点累计成本 如何制定进度
30、计划根据项目活动定义、排序、工期估算和所需资源的结果进行分析和进度计划的编制确定项目的起至时间；与范围、成本等方法综合考虑；活动的排序任务之间的依赖关系(逻辑关系)工作流程、相互关系文档化任务间的几种逻辑关系完成开始关系FS finish-start开始开始关系SS start-start结束结束关系FF finish-finish开始结束关系SF start-finishSP 2.3 计划数据管理 -1计划项目数据的管理这些数据是各种形式的文件,用以支持项目的所有方面（例如，事务管理、工程化、配置、财务、后勤、质量、安全、制造以及采购等）.这些数据的形式是各种各样的（例如，报告、手册、笔记本
31、、表格、图纸、规格说明书、文卷或信件等）数据的存储媒体也可能是各种各样的（例如，各种印刷材料、照片、电子媒体或多媒体）这些数据可能是可交付件（例如，业务计划的合同数据要求中规定的数据），也可能是不可交付件（例如，非正式资数据、趋势研究和分析、内部会议记录、内部设计评审文档、经验教训和行动安排等）这类数据的分发形式也很多，包括电子传输在内SP 2.3 计划数据管理 -2对于项目的数据要求，应该根据通用的或标准的数据需求从两个方面考虑：一个是要创建哪些数据，另一个是数据的内容和形式。对数据的统一的内容和形式要求，要考虑有利于理解数据内容，有助于数据资源的一致管理收集数据的原因应清楚。这项作业包括分
32、析和确认项目的可交付件和不可交付件、合同数据要求和非合同数据要求以及客户提供的数据。数据收集时，经常没有清楚的了解将如何使用该数据，收集数据的成本很高，应该只在需要时才收集。SP 2.4计划项目资源计划必要的资源来执行项目定义项目资源（人力资源、机器/设备资源、材料和方法）和基于初始估计定义执行项目活动需要的数量，并提供可应用的额外信息来扩展用于管理项目的WBS顶层WBS应作为估计手段早期开发。通常要通过分解这些顶层结构为可独立地分配、执行和跟踪的代表单个工作单元的工作包的方法来扩展。进行这种细化来分配管理职责，并提供更好的管理控制。在WBS中的每个工作包或工作产品应该赋唯一的标识符，以便允许
33、跟踪。一个WBS是基于需求、活动、工作产品的。要用一个字典来描述WBS中的每个工作包的工作。 SP 2.5 计划需要的知识和技能计划执行项目需要的知识和技能项目需要的知识包括项目人员需要的培训和从外部源获取知识人员配置需求取决于支持项目的执行可获得的知识和技能 SP 2.6 项目相关人员参与通过确定需要介入该项目的各类人员和职能，同时描述他们与具体活动的关系和相互作用的程度，确定项目生命周期所有各个阶段的相关人员。一般用二维矩阵来描述。 要让相关人员的参与发挥效用，必须慎选项目的相关人员。针对每个重大活动标识出受该活动影响的项目相关人员和拥有执行该活动所需技能的项目相关人员。项目相关人员名单可
34、能随项目推进而变。保证生命周期后面各个阶段的项目相关人员针对与之有关的需求和设计决策较早地提出意见，这一点很重要。 什么是干系人积极参与该项目工作的、或者由于项目的实施或成功其与失败利益会受到积极或消极影响的个体和组织；对项目有很大影响，解决分歧时应以利于客户为原则；主要干系人项目经理：管理项目；项目团队：实施项目任务；客户：使用项目产品或服务；发起人：为项目提供资金，承担最大风险；高层管理者分包商干系人计划确定项目干系人的信息和沟通需求，包括谁(receiver)在什么时候(when)需要什么信息(what)；谁(sender)通过什么方式(how)将信息传递给他们；根据计划实施的结果进行定
35、期检查，做必要的修整和补充，确定其适合性；SP 2.7 制定项目计划制定和维护整体项目计划的内容；项目计划必须文档化，以便与项目有关的个人、小组和组织达成共识、实现承诺以及执行或支持该计划；为项目产生的计划确定了所有方面的工作：项目生命周期考虑；技术和管理任务；预算和进度；里程碑；数据管理；风险标识；资源和技能需求；项目相关人员的标识和参与。基础设施的描述包括项目人员、管理和支持组织的职责和授权关系。SP 3.1 评审影响项目的计划为了理解项目承诺，评审影响项目的所有计划在其他过程域里开发的计划，通常包括与整体项目计划类似的信息。这些计划提供了更加详细的指导，而且应该与整体计划兼容并支持整体计
36、划来指示谁有职权、职责、责任和控制。所有影响项目的计划被评审，确保对项目取得成功需要的范围、目的、角色和关系的共同理解许多计划是由每个过程域中的“计划过程”共性实践描述的项目进度计划评审现实性项目的工期估算由来？有哪些假设条件，是否有案可查？项目任务之间的搭接度如何？是否准备了足够的风险储备(风险计划如何？)项目干系人是否介入了进度计划的制定？介入是否充分？范围是否明确？是否需要澄清？项目资源配置是否合理，是否还需要平衡？进度计划是否客观？是否需要进行评审？SP 3.2 协调工作和资源等级协调项目计划来反映可用和估计的资源 要获得项目相关人员的承诺，协调估计和可用资源之间的任何差异是重要的。协
37、调一般通过:降低或推迟技术性能需求磋商更多的资源找到增加生产率的方法外购调整人员技能搭配修订所有影响项目进度的计划来实现.SP 3.3 获得计划承诺从执行和支持计划执行的有关的项目相关人员处获得承诺获得的承诺包括项目内部和外部所有有关的项目相关人员之间交互的承诺。做出承诺的个人或小组应该对在成本、进度和性能约束内执行工作有信心。通常先做一个暂时性的承诺较为适当，以容许工作启动，并进行相关研究，当增加信心至适当程度， 需要得到充分的承诺。 Requirements Management (REQM)Purpose Manage requirements of the projects produ
38、cts and product components and to ensure alignment between those requirements and the projects plans and work products. V1.3版的REQM与V1.2版的不同之处特定目标和术语没有实质性的变更修改后的SP1.5更好的描述了该实践的内容，确保需求的一致性。通过积极主动的关注于计划和产品与需求的一致性，而不是找出不一致性问题在介绍性说明中增加信息描述REQM是如何应用于敏捷环境中的在SP1.4中进行了大量的澄清，更加清晰的讨论了什么是可追溯性在整个PA中，把“议定的需求”改为“批
39、准的需求”来更加清晰的描述什么样的需求是将要计划，采购，设计，服务和交付的该过程域从工程过程域的分类中划分到项目管理过程域类别中When Requirements Management Is Not Done Well Requirements are accepted by staff from any source they deem to be authoritative.The project experiences a high level of requirements changes.There are high levels of rework throughout the p
40、roject.There is an inability to prove that the product meets the approved requirements.Lack of requirements traceability often results in incomplete or incorrect testing of the product. Requirements Management GoalsSG 1: Manage RequirementsRequirements are managed and inconsistencies with project pl
41、ans and work products are identified.The process area also has generic goals to support institutionalization.Requirements Management ContextRequirementsUnderstandRequirementsObtainCommitmentto RequirementsTraceability Matrix MaintainBidirectional Traceability ofRequirements Ensure Alignment Between
42、ProjectWork and RequirementsManage RequirementsManage Requirements ChangesREQM (需求管理需求管理)目标目标Goals实践实践practicesSG1管理需求，管理需求，并确定项并确定项目需求与项目计划和工作目需求与项目计划和工作产品之间的不一致性产品之间的不一致性Manage Requirements SP1.1理解需求理解需求：与需求提供者一起理解需求的含义：与需求提供者一起理解需求的含义Understand Requirements :Develop an understanding with the requ
43、irements providers on the meaning of the requirements. SP1.2获得对需求的承诺获得对需求的承诺：取得项目成员对需求的承诺：取得项目成员对需求的承诺Obtain Commitment to Requirements. SP1.3管理需求变更管理需求变更：当项目需求在项目进行期间渐进演化时，管理需：当项目需求在项目进行期间渐进演化时，管理需求的变更求的变更Manage Requirements Changes SP1.4维护需求的双向可跟踪性：维护需求与工作产品之间的双向可跟维护需求的双向可跟踪性：维护需求与工作产品之间的双向可跟踪性踪性M
44、aintain Bi-directional Traceability of Requirements SP1.5确保项目工作与需求之间的不一致确保项目工作与需求之间的不一致Ensure Alignment Between Project Work and Requirements REQM (需求管理需求管理)RM主要目标是项目组要理解需求、管理需求的变更、主要目标是项目组要理解需求、管理需求的变更、在开发中对需求的实现进行跟踪。在开发中对需求的实现进行跟踪。现实中需求的变更很突出，现实中需求的变更很突出，”客户客户”早期对需求的不早期对需求的不确定性造成了需求的变更、需求的增加。以致对项目
45、确定性造成了需求的变更、需求的增加。以致对项目的成功、进度的保证、成本控制、质量的保证都有影的成功、进度的保证、成本控制、质量的保证都有影响。响。与RDREQM相关的PARDREQM提到了对需求的确认、理解、承诺，除了共利益者进行商讨、研究需求外，应该采用同行评审VER 。评审的效果要用发现的错误数/评审工作量表示。对需求的跟综、溯源，要采用跟综工具。对需求变更的管理，要用变更管理过程CM 。需求有变更就要对版本做标识的变更，基线的变更CM 。如果注意到今后规模的历史数据参考，统计出需求的功能点数和代码行数、工作量的关系需要做MA 。因此，RDREQM已涉及了VER、MA、PPQA、CM。RD
46、&RM 实例1.过程实例2.RTM实例RD&RM应形成的基本过程文档1.需求开发和管理过程2.需求变更控制过程项目监督与控制PMCProject Monitor and ControlProject Monitoring and Control Purpose: Provide understanding into the projects progress so that appropriate corrective actions can be taken when the projects performance deviates significantly from the plan.
47、V1.3版的PMC与V1.2版不同之处特定目标，特定实践没有实质性的变化修改了“项目”，“项目启动”的定义，删掉“程序”的定义。在信息化材料中增加了一些样例，做了一些小的变更。如：监控服务级别和客户满意度监控一个敏捷环境增加了关于”进度“和”里程碑“意义的讨论提供相关指导说明如何联合进度和里程碑评审可能做为一个单独的评审事件把解决过渡假设做为纠正行动的一部分Project Monitoring and Control- ContextProject PlansMonitorProjectRisksMonitorCommitmentsAnalyze IssuesTakeCorrectiveAct
48、ionsConductMilestoneReviewsMonitorDataManagementMonitorProjectPlanningParametersManageCorrective Actionsto ClosureMonitor the Project Against PlansConductprogressReviewsMonitorStakeholderInvolvementManageCorrectiveActions PP进度压缩的方法赶工(优先选择赶工费最少的活动)重点分析关键活动增加资源或提高生产率以缩短工期快速跟进技术分解长工期任务修改资源的任务分配进度最多压缩25
49、项目监督与控制PMC的目的提供对项目进展情况的了解当项目的性能与其计划严重偏离时，采取适当的纠正行动PMC的要点文档化的项目计划是监督活动、沟通状态和采取纠正行动的基础在预定的里程碑处或在项目进度或WBS的控制点处，项目的进展主要通过实际的工作产品和任务属性、工作量、成本和进度与计划相比较来确定的当项目严重偏离计划时，提供适当的可见性并及时地采取纠正行动。如果严重偏离不能解决，则应重新考虑其目的是否可行所有的实践中使用“项目计划”术语是指项目的整体计划以便控制这个项目当实际状态严重偏离期望值时，要采取适当的纠正行动。这些行动可能要求重计划，可能包括：修订原来的计划建立新的协议或包括在当前计划内
50、的额外的缓解活动PMC的SGs和SPsSG1: 对照项目计划，监督项目的实际性能和进展SG2: 当项目的性能和结果与计划有重大偏离时，要管理纠正行动直至解决SP1.1 监督项目的计划参数SP1.2 监督承诺SP1.3 监督风险SP1.4 监督数据管理SP1.5 监督项目相关人员的参与SP1.6 执行进展评审SP1.7 执行里程碑评审SP2.1 分析问题SP2.2 采取纠正行动SP2.3 管理纠正行动特定目标特定目标 Specific GoalSpecific Goal特定实践特定实践 Specific PracticeSpecific PracticeSG 1 按计划监督项目SG1: 对照计划
51、监督项目：对照项目计划，监督项目的实际性能和进展SP1.1 监督项目计划的参数SP1.2 监督承诺SP1.3 监督风险SP1.4 监督数据管理SP1.5 监督项目相关人员的参与SP1.6 执行进展评审SP1.7 执行里程碑评审SP 1.1监督项目计划参数SP1.1 监督项目计划参数：按照项目计划，监督项目计划参数的实际值 项目计划参数由项目进展和性能的典型指示器组成，包括工作产品和任务的属性、成本、工作量和进度工作产品和任务的属性包括规模、复杂度、权重等监督通常包括度量项目计划参数的实际值，比较实际值与计划中的估计值，标识严重偏离记录项目计划参数的实际值包括记录相关的上下文信息来帮助理解度量严
52、重偏离的影响分析确定要采取什么纠正行动，这在本过程域的第二个特定目标的特定实践中处理 SP 1.2 监督承诺SP1.2 监督承诺：按项目计划中标识的承诺关系监督承诺 子实践定期评审承诺 (包括内部承诺和外部承诺)标识不满足的承诺和具有高风险而很可能无法满足的承诺文档化对承诺评审的结果 SP 1.3 监督项目风险 SP1.3 监督项目风险：按项目计划中标识的风险监督风险子实践在项目的当前状态和环境中,定期评审风险的文档当额外的信息变得可用时，修订风险文档，并纳入变更与有关的项目相关人员沟通风险状态风险状态的例子包括：风险发生概率的变更风险优先级的变更SP 1.4 监督数据管理 SP1.4 监督数
53、据管理：按计划监督对项目数据的管理一旦制定了项目数据管理的计划，数据管理就应该得到监督，确保那些计划的完成SP 1.5 监督相关人员参与 SP1.5 监督项目相关人员的参与：按计划监督项目相关人员的参与要获得更多的关于标识有关的项目相关人员和计划他们的参与的信息，请参阅项目策划过程域的“计划项目相关人员的参与”特定实践一旦标识了项目相关人员并在项目计划中规定了他们参与项目的程度，就应该监督参与，确保适当地产生相互之间的交互SP 1.6 执行进展评审SP1.6 进行进展评审：定期评审项目的进展、性能和问题进展评审可以是正式评审，也可以是非正式评审，而且可能没在项目计划中标出由项目组成员评审由项目
54、工程师和支持人员评审由管理人员评审SP 1.7 进行里程碑评审SP1.7 进行里程碑评审：在选定的里程碑处，评审项目的成就和结果里程碑评审是项目策划期间计划的评审，而且通常是正式评审 SG2 管理纠正行动直至解决 管理纠正行动直至关闭：当项目性能和结果严重偏离计划时，管理纠正行动直至解决SP2.1 分析问题SP2.2 采取纠正行动SP2.3 管理纠正行动SP 2.1 分析问题 SP2.1 分析问题：收集和分析问题，并确定必要的纠正行动来解决问题 SP 2.2 采取纠正行动SP2.2采取纠正行动：采取与已标识的问题有关的纠正行动SP 2.3 管理纠正行动 SP2.3 管理纠正行动：管理纠正行动，
55、直至问题解决子实践监督纠正行动的完成分析纠正行动的结果，确定纠正行动的有效性确定和文档化适当的行动，来纠正与纠正行动计划的结果的偏离（注：采取纠正措旋结果的经验教训是计划和风险管理过程的输入）进度计划控制对影响进度变化的因素的控制(事前控制)确定是否发生了变化(警戒值控制，增加跟踪密度，采取纠正措施，进行风险管理)对已经发生和正在发生的变化实施管理(事中、事后控制)进度计划控制的核心数据数据采集的责任者数据收集的周期性偏差分析(警戒值)纠偏措施(压缩进度的方法/利用浮动时间，在关键路径上找工期，在非关键路径上找资源)趋势分析需要注意的几种情况强制性(客观)“硬”逻辑(mandatory dep
56、endencies)阶段评审、成果确认可以自由决定的关系“软”逻辑(preferred dependencies)取决于习惯、资源调度方式与限制；先急后缓、先重要后次要；外部约束(external dependencies)项目干系人问题、外部采购、客户强加的特殊的需求；项目的重要里程碑点项目监督和控制项目控制的主要任务是判断实际的执行情况是否与计划出现偏差，如果出现偏差，就可能需要采取纠正措施；项目最理性的情况是“多、快、好、省”，这四个指标之间是相互关联的，提高一个指标的同时会降低另一个指标；项目跟踪控制的范围主要包括干系人的监控和任务的跟踪；项目监督和控制的标准任何一个项目经理都会面临一
57、个同样的问题，计划与控制做到什么程度才算可以？项目监督和控制的标准建立项目监控偏差的接受准则，以确定跟踪控制的程度；警戒值：警戒信号出现后，应执行纠正措施；阈值：是一种预测，预测延迟的可能的时间；项目监督和控制的标准充分了解项目的当前的状态；根据所期望的状态、当前的状态和目标做出决策；进行项目监督和控制的基本步骤建立基准计划；观察项目的性能：建立项目监控和报告体系，确定为控制项目所必需的数据；度量和分析结果：将项目的实际结果与计划进行比较；采取必要措施：当实际的结果与计划有误差时，采取必要的纠正措施，必要时修改项目计划；控制反馈：如果修正计划；风险管理RSKMRisk ManagementRi
58、sk ManagementPurpose:Identify potential problems before they occur, so that risk handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.V1.3版的RSKM与V1.2版RSKM的不同之处特定目标和术语没有实质性的变更修改后的SP3.1明确的将风险缓解计划和风险管理策略联系
59、在一起，将”根据风险管理策略为项目中非常重要的风险制定风险缓解方案”改为“根据风险管理策略，开发风险缓解方案在介绍性说明中强调了风险是如何应用于敏捷环境中的信息化材料变更较小，增加了一些样例.在信息化材料中出现以下一些新的主题：运用行业标准帮助识别和阻止风险；风险与质量属性和产品架构相关；运用风险货币化来加强风险的标准处理运用一些技术如FEMA来改进风险参数的处理Risk Management - ContextIdentifyRisksEvaluate, Categorize, andPrioritizeRisksIdentify and Analyze RisksFrom Project
60、Planning and Project Monitoringand ControlDevelopRiskMitigationPlansImplementRiskMitigationPlansMitigate RisksDARRisk RepositoryDetermineRisk Sourcesand CategoriesDefineRiskParametersPrepare for Risk ManagementEstablish a Risk ManagementStrategyRSKM目的：识别潜在的问题，以便策划应对风险的活动和在必要时在整个产品或者项目生命周期中实施这些活动，缓解不
61、利的影响，实现目标 风险的概念风险就是造成项目可能无法达到预期目标的因素或事件；风险与问题的区别？风险管理过程风险管理计划风险识别风险定性分析风险应对概率影响规避转移减少接受风险监控与评价RSKM要点风险管理是一种持续的前瞻性的过程，它是业务和技术管理过程的重要组成部分风险管理需要处理可能危及关键目标的问题应该采用持续风险管理方法来确保有效地预测和缓解对项目有关键影响的风险有效的风险管理包括通过有关的相关人员的协作和参与来早期积极地识别风险（有关的相关人员在项目策划过程域中的相关人员参与计划中做了描述）RSKM要点为了建立起能够自由而开放地揭示和讨论风险的环境，有必要在所有受影响的各方之间形成
62、强有力的领导关系如果说技术问题是一个从项目的早期开始并且贯穿项目所有各个阶段的关注焦点，那么风险管理则必须从内部和外部两个方面考虑成本、进度和技术等风险来源早期积极地探测出风险很重要，因为了解越早，为对付风险而做出变更和采取纠正措施所带来的开销越低，干扰也越小 RSKM要点风险管理可分成三个部分：定义风险管理策略识别和分析风险处理识别出来的风险，包括在必要时实施风险缓解计划而“风险管理”过程域描述的是这些行为的更高阶段，即为了主动设法减小风险对项目的影响，而有系统地进行策划、预测和缓解风险虽然“风险管理”过程域主要强调项目的风险管理，但这种概念也适用于对整个组织的风险管理。风险缓解策略应着眼于
63、共同的产品成功前景，以确保其得以维护 特定目标和共性目标SG 1 准备风险管理进行风险管理准备SG 2 识别和分析风险识别和分析风险，以确定风险的重要性SG 3 缓解风险在适当时处理和缓解风险，以减小对实现目标的不利影响风险管理策略建立并维护用于识别、分析和缓解风险的策略风险管理策略一般编写成项目风险管理计划风险管理策略处理的是在运用和控制风险管理大纲时使用的具体措施、资源和管理方法风险管理策略包括对风险来源、风险分类方案及风险的评价、界定和控制参数等的策划SP 1.1 确定风险来源和类别SP 1.1 确定风险的来源和风险的类别了解风险来源，将为系统性地检查不断变化的情况打下基础，以便揭示那些
64、将对项目实现其目标的能力造成不利影响的环境风险来源存在于项目的内部和外部。随着项目的推进，还可能发现新的风险来源风险分类，实质上是提供一种机制，便于收集和归纳各种风险以及确保这些风险得到适当的推敲和引起管理者的关注这些风险是否将对项目目标的实现产生更严重的后果 项目风险分类按照项目管理的过程和要素分类高层战略风险；决策风险；项目策划风险；技术设计风险；实施与控制风险；按照项目的内部与外部分类内部风险技术因素风险(依行业而不同)；非技术风险(资源不足或员工熟练度问题、团队问题、项目范围模糊)；外部风险可预测风险(市场风险、环境和社会影响风险、政府风险)；不可预测风险(规章：不可预测的政府干预、自
65、然灾害)；SP 1.2 定义风险参数SP 1.2 对用于分析和归类风险的参数和用于控制风险管理工作的参数加以定义用于风险的评价、归类和排序的参数包括：风险可能性（likelihood），即风险发生的概率风险的后果，即风险发生的影响和严重程度触发风险管理活动的阈值（thresholds）风险参数用于为要管理的各种风险提供了公共的、一致的准则没有这些参数，很难衡量由风险引起的不期望变化的严重程度，也很难对风险管理策划所要求的必要行动排优先级SP 1.3 建立风险管理策略SP 1.3 建立和维护用于风险管理的策略综合性的风险管理策略涉及的内容（例如）有 ：用于风险识别、风险分析、风险缓解、风险监督和
66、沟通的方法和工具项目特有的风险来源对已标识的风险采取措施的参数（如可能性、后果和阈值）所要使用的风险缓解技术，例如原型、模拟、替代设计或渐进式开发用于监督风险状态的风险度量项的定义风险监督或重新评估的时间间隔风险管理策略应着眼于共同的成功愿景（Vision）。这个愿景应描述所希望的以交付的产品、产品成本和适用性等为标志的项目的未来成果风险管理策略往往在项目风险管理计划中反映，并且应该与有关的相关人员一起评审，以促进对风险策略的理解和承诺的实现 SG2 识别和分析风险风险的严重程度影响到为对付风险而进行的资源分配和确定何时需要相应的管理者关注；对风险进行分析也就是给源于内部和外部的风险加上标识，
67、然后评价每个风险，确定其发生的可能性和后果；根据已建立的风险分类办法和依据风险管理策略拟订的准则确定风险的类别，为处理风险提供所需的信息；可以把相关的风险分组，以便有效地应对风险和使用风险管理资源；SP 2.1 识别风险 对那些可能对工作或工作计划造成不利影响的潜在问题、危害、威胁、脆弱性等等的识别是风险管理的基础把风险形成简明扼要的文件，其中包括背景、条件和风险发生后的后果风险识别应遵循有组织的通盘考虑的思路，以便找出在实现目标的过程中的可能的或现实的风险为了有效进行风险识别，不应该不顾其重要性而试图处理每一个可能事件应定期评审风险一览表，以便重新检查可能的风险来源和调整条件，从而进一步发现
68、以前没有注意到的或者是在拟订风险管理策略时还不存在的风险来源和风险风险识别活动致力于风险的识别，而不是追究过失。管理者不应该把风险识别活动的结果用于评价个人的表现 风险识别方法风险识别的方法一般包括：检查项目工作分解结构(WBS)的每个元素，以发现风险运用风险分类学进行风险评估向相应的主题领域的专家征求意见评审类似的产品的风险管理工作查找有关的经验教训文件或数据库检查设计规范和协议需求 SP 2.2 对风险进行评价、分类和排序 SP 2.2 运用风险类别和参数对每个风险进行评价和分类，并确定其相对轻重缓急顺序有必要划分风险的等级，以便表明每个风险的相对重要性，进而用以确定要求相应的管理者在何时
69、予以关注。根据风险的内在关系把风险加以汇总并且就同一个汇集层考虑处理意见，往往总是很有用的。如果某个风险汇集是由较低层次的风险汇集而成的，必须注意保证那些重要的较低层次的风险不至于被忽略使用诸如可能性（概率）和后果（影响）之类参数对风险加以量化，同时也可以补充其他参数。一般采用这些参数的等级划分值的组合来确定风险处理的总的优先顺序 有时把风险评价、分类和排列轻重缓急顺序的活动笼统称为风险评估或风险分析SP 3.1 开发风险缓解计划 SP 3.1 按照风险管理策略的规定，针对那些对项目来说最重要的风险开发风险缓解计划 缓解风险处理风险的步骤包括提出风险处理意见、监督风险和在超出规定阈值时执行风险
70、处理活动针对所选择的风险拟订并实施缓解风险计划，主动降低风险发生时的潜在影响这包括应急计划，当所关注的风险万一发生时，可以按应急计划处理风险造成的影响用于触发风险处理活动的风险参数由风险管理策略规定 风险缓解计划-1风险缓解计划的关键是为每个关键风险推荐的一个行动方案每个风险的缓解计划都要包括用以规避、降低和控制该风险发生的可能性的技术和方法，和用以降低和控制该风险招致的危害程度的技术和方法(有时称为应急计划)一旦超过规定的阈值，就要实施缓解计划，以便使受到影响的工作回归到可接受的风险级别上如果风险不能被缓解，就要调用应急计划通常只为选择的风险生成风险缓解计划和应急计划。这类风险的后果被认为是
71、高的或不可接受的其他风险可以接受和简单地监督风险缓解计划-2处理风险的意见一般包括若干替代方案，例如:风险规避：在仍然满足用户需要的情况下修改或降低需求风险控制：采取主动行动尽量减少风险风险转移：重新分配设计需求，以降低风险风险监督：监视风险并且针对所分配的风险参数的变化情况定期对风险重新进行评价风险接受：承认风险，但是决定不采取任何措施通常，特别对“高”风险，应该有一种以上的风险处理方法风险缓解计划-3在许多情况下，对风险采取接受或监视方式。风险接受通常是在判断该风险属于不值得正式缓解的低风险或是找不到减小该风险的可行方法的情况下采用。如果某个风险被接受，那么，应该把这个决定的理由形成文件如
72、果有着客观规定的、经过验证和形成文件的性能、时间或风险暴露度（可能性和后果的组合值）的阈值，应该监视风险；必要时，这些阈值将启动风险缓解计划或应急计划应该把项目技术论证、模型、模拟和原型设计作为风险缓解策划的组成部分尽早充分考虑风险管理计划的内容风险管理计划需要对项目生命周期全过程中进行识别风险、风险定性分析、风险应对计划以及风险监控的方法做出结构化的说明。识别风险的方法；风险管理的预算；时间安排；风险分析的评价标准(scoring and interpretation)；不同干系人的风险承受程度和承受方式Threshold: the level of risk that is accepta
73、ble to the organization跟踪计划；SP 3.2 实施风险缓解计划 SP 3.2 定期监督每个风险的状态并且在适当时实施风险缓解方案为了在项目整个工作期间有效地控制和管理风险，需要遵循预先制订的计划定期监督风险和风险处理行动的状态和结果风险管理策略规定检查风险状态的时间间隔。这一行动可能发现新的风险或新的风险处理意见要求重新策划和评估无论哪种情况出现，都应该把该风险的可接受的阈值与之相比较，以便确定是否需要实施缓解计划风险分析方法风险概论与影响技术风险的参数风险概率：风险发生的可能性；风险影响：风险发生后将对实现项目目标的影响；风险优先级排序：概率*影响度风险应对措施规避风
74、险-stay outside the heatP*I=0放弃有风险的项目资源、设计和施工方案；选择熟悉的、有信誉的承包商；缩小范围；及时提交中间工作成果(工期越长，风险越高)；定义详细需求；避免使用没有把握的技术；增加预算和工期；风险化解：如对干系人之间的矛盾，通过沟通的方式化解；在关键点上进行独立审查和评价，检查遗漏问题；风险应对措施-转移风险-find someone to stand it for me通过这种方法只是将风险进行转移，风险并没有消除，而且还需要付出风险成本；签订外包合同；合作开发，风险共担；内部责任书；购买保险；风险应对措施缓解风险(降低P*I)-stay inside,
75、 but install an air-conditioner减少不确定性降低员工离职率；项目利益总体权衡，确保重点；采用原型方法；增加迭代次数；对供应商和项目组成员的工作进行定期检查；采用简单的作业流程；招聘熟练员工；风险应对措施接受风险-stay inside and stand the heat对于无法找到合适的风险应对措施，或者对项目目标影响比较小的风险，可能需要采取接受的策略积极的接受态度：制定应急计划以备风险发生之用；消极的接受态度：心甘情愿的接受较低的利润；风险监控风险监控过程就是跟踪已经识别的风险，监视残留风险；识别新出现的风险；确保管线管理计划和风险应对计划的执行；评价风险减
76、缓措施的有效性；跟踪风险的状态和变化已经识别但尚未发生的风险；已经识别已经发生的风险；没有识别出来但是已经发生的风险；已经避免、减缓或者转移的风险；在项目执行过程中又出现的风险；集成项目管理IPMIntegrated Project ManagementIntegrated Project ManagementPurpose:Establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is
77、 tailored from the organizations set of standard processes.V1.3的IPM与V1.2版的不同之处IPM的SG3以及相关特定实践都被删掉了，因此IPPD从IPM中删除掉了在SP1.5后面增加了一个子实践5，用于提醒用户，可采取因果分析来阻止问题再次发生从而做为提供项目或工作性能的一种行动在SP1.5后加了一个实践“SP1.6建立和维护团队”；之前的SP1.6改为SP1.7，内容由1.2版的“将工作产品，度量数据，文档，经验等贡献给组织过程资产库”改为“将与过程相关的经验贡献给组织过程资产库”以下术语有所修改：项目，项目启动，团队。程序从
78、术语中删掉Integrated Project Management - ContextManageStakeholderInvolvementManageDependenciesResolveCoordinationIssuesCoordinate with Relevant StakeholdersDocumentedTechnical IssuesDocumentedCritical DependenciesAgendas and Schedules for Collaborative ActivitiesUse the Projects Defined ProcessDefined P
79、rocess Based Project PlanProjects Defined ProcessUse Org Proc Assets for PlanningProjectActivitiesIntegratePlansOPDEstimates and MeasuresDocumentationLessons LearnedOther Project& Org FunctionsEstablishthe Projects Defined ProcessContributeto OrgProcessAssetsManageProject UsingIntegrated PlansEstabl
80、ish Teams集成项目管理集成项目管理保证项目各要素相互协调，在相互影响的项目目标和方案中做出权衡，以满足项目干系人的需求和期望；集成项目管理是要综合所有的计划，协调方方面面的情况，例如制定进度计划的同时需要考虑项目的测试、质量保证计划等；集成计划不是简单的堆砌，是需要不断的进行反馈，以使各个子计划不断修正以满足项目的总体目标；项目管理过程是一个集成的过程，项目的范围、规模、工作量、工期和成本等是相互关联的；IPM的目的目的：按照剪裁自本组织的标准过程集的集成的和已定义的过程（称项目已定义过程（PDP：Projects Defined Process）来建立和管理项目，并使有关的相关人员（
81、Relevant Stakeholder）介入项目IPM（Integrated Project Management)包括：通过裁剪本组织的标准过程集来建立PDP使用PDP管理项目使用并不断积累组织过程资产使有关的相关人员的意见得以识别和考虑，并在合适时在产品开发过程中得到落实确保有关的相关人员协同地和及时地执行他们的任务，以便：1）处理产品和产品构件方面的需求、计划、目的、问题及风险；2）实现他们的承诺；3）识别、跟踪和解决问题IPM要点-1结合项目定义过程的任务对项目的工作量、成本、进度、人员配备、风险以及其他因素进行管理。PDP的实施和管理一般是在项目计划中描述。某些活动可能在其他从属计
82、划中进行描述，例如，质量保证计划、风险管理策略以及配置管理计划等由于每个项目的PDP都是剪裁于本组织的标准过程集，因此项目之间差异得以减少，并且各个项目更容易共享过程资产、数据和经验教训IPM还处理包括下列活动在内的与项目相关的所有活动的协调：技术活动，例如需求开发、设计和验证等支持类活动，例如配置管理、文档、营销和培训等 IPM要点-2项目内部和外部的有关的相关人员之间的工作接口和交互要事先策划，并予以管理，以确保整个项目的质量和完整性适当时，有关的相关人员参加制订PDP和项目计划要定期与这些有关的相关人员对有关活动进行评审并交换意见，协调问题以得到适当的关注，并确保介入该项目的每一个人适当
83、地了解所有活动的状态、计划和活动。在制订PDP时，必要时要确定正式的接口，以确保适当的协调和合作特定目标和共性目标SG 1 使用项目已定义过程：运用剪裁自组织标准过程集的已定义过程来执行项目SG 2 与有关的相关人员协调和合作：与有关的相关人员进行项目的协调和合作特定目标与实践特定目标SG1: 使用项目已定义过程：使用剪裁自组织的标准过程集的已定义过程执行项目SG2: 与有关的相关人员协调和合作：与有关的相关人员进行项目的协调和合作特定实践SP1.1 建立项目已定义过程SP1.2 运用组织过程资产策划项目活动SP1.3建立项目工作环境SP1.4 集成计划SP1.5 运用集成计划管理项目SP1.
84、6 建立团队SP1.7 充实组织过程资产 SP2.1 管理相关人员的介入事宜 SP2.2 管理依赖关系SP2.3 解决协调问题SG1使用项目已定义过程SG1 使用剪裁自组织的标准过程集的已定义过程执行项目项目已定义过程必须包括组织级标准过程中那些所有涉及到与产品开发和维护所必须的过程并行地开发与产品相关生命周期过程，如制造和支持过程SP 1.1 建立项目已定义的过程SP 1.1 从项目开始，建立并维护项目已定义过程项目已定义过程由已定义的过程组成，这些已定义过程形成该项目的集成的、内在的生命周期项目已定义过程覆盖项目所需的所有过程，包括那些CMMI L2中的过程域中的过程项目已定义过程要满足合
85、同要求和运作需要、机会和限制条件。它用于为项目提供最佳的需要项目已定义过程的建立基于以下方面：干系人的需求承诺组织的过程需要和目的组织标准过程集及裁剪指南运作环境商业环境SP 1.2 运用组织过程资产策划项目活动 SP 1.2 运用组织过程资产和度量库进行估算和策划项目活动 如果可以，用以前的策划和执行活动的结果作为预测因子来估算相关范围和工作量风险SP 1.3 建立项目工作环境基于组织标准工作环境，建立和维护项目工作环境项目的合适的工作环境包括基础设施，工具，设备，这些是项目组人员为实现商业和项目的目标而有效执行他们的工作所需要的项目的工作环境可以包括产品集成，验证和确认的环境，也可以单独列
86、开SP 1.4 集成计划SP 1.4 集成项目计划和其他影响项目的从属计划，以描述项目已定义过程 这个特定实践涉及的活动比建立和维护项目计划的特定实践更广泛，以便处理附加的策划活动，例如，纳入项目已定义过程、与有关的相关人员协调、运用组织过程资产、纳入同行评审计划以及建立任务的客观的入口和出口准则在项目计划的开发中，说明组织、客户、供应商和最终用户的当前和计划的需要、目标和需求 集成的项目计划项目经理及干系人在开发集成的项目计划时，要创造一个开发的环境和氛围，充分利用项目干系人的才智和力量，使得项目的集成的计划更全面、更经济、更具有可操作性，尽量减少对计划的变更；由于计划的严肃性，开发集成的项
87、目计划时，也是各有关项目干系人对项目的承诺过程；集成的项目计划的作用计划的法律作用，也是一种承诺；全面指导项目的实施；度量项目的性能和控制项目的基准；促进项目相关干系人之间的沟通；确定主要的管理问题，如：范围、时间安排等；是统一和协调项目工作的指导文件，避免多头的、矛盾的指挥和命令，防止项目单组织和团队中不同群体的“各自为政”；集成的项目计划实施中的管理原则制度化原则建立统一过程，规范和标准，如项目组每周例会、日(周、月)报制度；透明度原则适度授权原则针对WBS的分解调度和授权(资源控制权，包括时间资源的控制)；系统原则考虑同时进行的各项工作及其关系；这些工作和尚未开展未来工作之间的关系；SP
88、 1.5 运用集成计划管理项目 SP 1.5 运用项目计划、影响项目的其他计划和项目已定义过程管理项目SP1.6建立团队建立并维护团队项目通过团队进行管理，团队的结构，形成，运作都反映了组织的规则和指南（参考“团队”的定义）项目的共同愿景应建立于团队形成之前，而团队是以WBS为基础的。对于一个小的组织来说，整个组织以及相关的外部干系人可以看作是一个团队。确保相关干系人之间的和谐互助最好的办法就是把他们纳入团队中在客户环境中，要求在多个产品或服务开发商中保持和谐，最重要的就是建立一个能影响最终成功的具有代表性的团队。这种代表可以有助于组织间的协作，包括问题的及时协调解决SP1.6建立团队工作产品
89、列举文档化的共同愿景每个团队分配的人员名单团队章程定期团队状态报告子实践建立和维护项目的共同愿景建立和维护团队的结构记录和维护每个团队定期评价团队的结构和构成SP 1.7充实组织过程资产 SP1.6 把过程相关经验充实到组织过程资产中 项目结项管理Lessons learnedProject is not completed until a lessons learned is completed;It is unforgivable to make the same mistake;What we have done, how can we do it better;技术方面/管理方面；最好
90、由整个项目团队完成，加入到组织的经验库；项目反刍式管理还有谁是应该知道的？EPG? SM?SP 2.1 管理相关人员的介入 SP 2.1 管理项目相关干系人的参与SP 2.2 管理依赖关系 SP 2.2 与有关的相关人员一起识别、磋商和跟踪关键的依赖关系关键路径关键路径：完成关键路径上所有任务时间的总和，就是项目开发所需要的最短时间 关键活动：浮动时间最少关键路径的变化；非关键路径上的活动一般存在浮动时间，可以挖掘资源潜力；SP 2.3 解决协调问题SP 2.3 与有关的相关人员一起解决问题协调问题的例子有：产品和产品构件需求和设计的缺陷推迟结束的关键依赖关系和承诺产品级的问题不可用关键的资源
91、或人员 供应商合同管理供应商合同管理SAMSupplier Agreement ManagementPurpose: Manage the acquisition of products from suppliersV1.2版的SAM与V1.3版的SAM的区别特定目标没有实质性的变更SP1.3的描述的一些词进行了修改，建立供应商协议把“正式”协议改为“供应商”协议SP2.2监控所选择的供应商过程和SP2.3评估所选择的供应商工作产品被降为新的SP2.1的子实践，SP2.1执行供应商协议修改SP2.3确保产品移交过程中的可应用性，保证产品或服务从供应商交付到客户或终端用户中是可用的在词汇表中增加
92、以下术语：收购商，合同要求，可交付，招标方案，供应商协议澄清SAM实践的应用范围增加“产品和过程对项目的重要价值”观点用以帮助确认需要监控和评估的内容Supplier Agreement Management ContextProductEstablishSupplierAgreementsDetermineAcquisitionTypeEnsure Transition of Products Accept theAcquiredProductSelectSuppliersSupplier RequirementsExecutethe SupplierAgreementEstablish S
93、upplier AgreementsSatisfy Supplier AgreementsSupplier AgreementPITS供应商协议管理的目的 管理来自于供应商的管理来自于供应商的产品的获取产品的获取SAM要点-1SAM过程域包含以下活动：确定产品的获取类型选择供应商建立供应商间的协议执行供应商协议监控选中的供应商的过程评价被选中的供应商的工作产品接收所获取的产品确保成功移交所获取的产品SAM要点-2本过程域应用范围需要交付给客户的产品和产品构件的获取为了尽量减少项目的风险，该过程域也用于强调那些并不需要交付给客户的，但是用于开发和维护产品或服务的产品或产品构件， (如，开发工具和
94、测试环境等)SAM要点-3根据业务的需要，供应商可以有许多方式存在，包括来自于组织内部供应商(如：项目之外的组织内部供应商)、具有生产制造能力的供应商和实验室、以及商业供应商供应商协议是组织(代表项目方)与该供应商间的任何书面协议。该协议可以是合同、特许版权(license)、服务级别协议（SLA）或备忘录(MOA)特定目标和共性目标SG 1 建立供应商协议 建立并维护与供应商间的协议SG 2 满足供应商协议 项目和供应商共同满足建立的协议SG及其特定实践SG1: SG1: 建立供应商协议：建立供应商协议：建立和维护与供应商间的协议建立和维护与供应商间的协议SG2: SG2: 满足供应商协议满
95、足供应商协议SP1.1 SP1.1 确定获取类型确定获取类型SP1.2 SP1.2 选择供应商选择供应商SP1.3 SP1.3 建立供应商协议建立供应商协议SP2.1 SP2.1 执行供应商合同执行供应商合同SP2.2 SP2.2 验收获取的产品验收获取的产品SP2.3 SP2.3 移交产品移交产品特定目标特定目标特定实践特定实践SP1.1 确定获取类型对需要获取的每个产品或产品构件确定获取类型对于项目使用的、待获取的产品和产品构件有许多不同的获取类型。例如：购买商用现货产品(COTS)通过合同协议获得产品 从内部供应商获得产品从客户方获得产品上述方式的组合 典型工作产品 包括所有需获取的产品
96、和产品构件的获取类型列表/清单 # 获取产品的清单获取产品的清单项目名称填写人项目编号填写日期以下信息的来源产品、产品构件名称取得方式现货获取产品或服务签订合同得到产品或服务顾客提供的产品联合开发的产品其他SP1.2 选择供应商根据已建立的准则和对供应商满足具体需求能力的评价，选择供应商需要建立准则来，来处理项目的重要要素。如：供应商的地理位置供应商在类似工作上的表现记录工程能力可用于执行工作的员工和设施同样应用程序上的历史经验客户对供应商交付的类似产品的满意度工作产品 样例市场调研候选供应商名单首选供应商名单贸易条约或其他的相关记录，如：评价标准，候选供应商的优缺点，选择某些供应商的理由邀标
97、材料与要求 # 供应商候选名单供应商候选名单项目名称 项目编号填写人填写日期供应商名称类型所需产品名称、规格主要优势主要劣势销售商生产商服务商SP1.3 建立供应商协议建立和维护与供应商的协议供应商协议是组织(代表项目方)与该供应商间的任何书面协议。该协议可以是合同、特许版权(license)、服务级别协议（SLA）或备忘录(MOA)SP2.1 执行供应商协议与供应商按照供应商协议中的定义执行活动子实践依据供应商协议监控供应商的进度和实施情况（如：进度，工作量，成本，技术实施）监控，分析被选中的供应商使用的过程选择评价供应商提供的产品依据供应商协议中定义的活动与供应商一起进行评审依据供应商协议
98、与供应商一起进行技术评审依据供应商协议与供应商一起进行管理评审SP2.4 接收获取的产品确保在接收获取的产品前满足供应商协议应该按照供应商协议中所定义的、在接收产品前完成接收评审、测试和配置审计典型工作产品接收测试规程接收测试结果差异报告或纠正行动计划 #供应商问题解决记录供应商问题解决记录 供应商名称产品名称 发现日期报告日期报告人主要问题陈述对质量的影响程度对进度的影响程度处理意见 （谁做、如何做、完成期限、谁验证）批准意见 批准人签字： 日期：问题解决结果跟踪、验证人意见 验证人签字; 日期：SP2.5 移交产品将从供应商处获得的产品移交到项目在将从供应商获得的产品移交到项目进行集成之前，应进行策划和评价确保平稳的移交 关于集成获取的产品的更多的信息，参见“产品集成”过程域问题与回答谢谢
