CMMI-DEV V13 项目管理过程域

CMMI-DEVV1.3

ProjectManagementPAs

项目管理过程域

ContinuousRepresentation:PAsbyCategory

CategoryProcessAreas

OrganizationalProcessFocus

OrganizationalProcessDefinition

ProcessOrganizationalTraining

ManagementOrganizationalProcessPerformance

OrganizationalPerformanceManagement

ProjectPlanning

ProjectMonitoringandControl

ProjectSupplierAgreementManagement

ManagementIntegratedProjectManagement

RiskManagement

QuantitativeProjectManagement

RequirementsManagement

RequirementsDevelopment

EngineeringTechnicalSolution

ProductIntegration

Verification

Validation

ConfigurationManagement

ProcessandProductQualityAssurance

SupportMeasurementandAnalysis

DecisionAnalysisandResolution

CausalAnalysisandResolution

StagedRepresentation:PAsbyMaturityLevel

LevelFocusProcessAreasIncludingIPPD

Continuous

ProcessOrganizationalPerformanceManagement

5OptimizingCausalAnalysisandResolution

Improvementt

4QuantitativelyQuantitativeOrganizationalProcessPerformance/

ManagedManagementQuantitativeProjectManagement

RequirementsDevelopment

TechnicalSolution

ProductIntegration

Verification

3DefinedProcessValidation

StandardizationOrganizationalProcessFocus

OrganizationalProcessDefinition

OrganizationalTraining

IntegratedProjectManagement

RiskManagement

DecisionAnalysisandResolution

/

RequirementsManagement

ProjectPlanning

BasicProjectMonitoringandControl

2ManagedProjectSupplierAgreementManagement

ManagementMeasurementandAnalysisJ

ProcessandProductQualityAssurance

ConfigurationManagement

Risk

Rework

1Initial

CMMI模型(阶段表示法)5级-优化级

组织性能管理

原因分析和解决,

4级-定量管理级L

定量项目管理

CMMI的阶段式表示法就是组组织过程性能

织成熟度方法(3级-定义级

需求开发

技术解决方案

验证5优化级⑵

确认4定量管理级⑵

产品集成3已定义级(14)

集成项目管理

G级-管理级2已管理级(7)

配置管理组织过程焦点

初始级

过程和产品质量保证组织过程定义1(0)

供应商合同管理组织培训

项目监控和控制风险管理

项目计划决策分析和解决

需求管理

i度量和分析y

1级-初始级

CMMI模型（持续表示法）

级别'分类Engineering(6)ProjectProcessSupport(5)

Management(6)Management(5)

2级PP（项目计划）CM（配置管理）

受管理级PMC（项目监控）PPQA

ManagedSAM（分包合同管理）（过程和产品质量保证）

⑺REQM（需求管理）MA（度量与分析）

3级RD（需求开发）IPM（集成项目管理）OPD（过程定义）DAR

已定义级TS（技术解决）RSKM（风险管理）OPF（过程聚焦）（决策分析与解决方案）

DefinedPI（产品集成）OT（培训）

(11)VER（验证）

VAL（确认）

4级QPM（定量项目管理）OPP（组织过程性能）

定量管理级

Quantitatively

Managed

(2)

5级OPM（组织性能管理）CAR

.续优化级

（因果分析和解决方案）

Optimizing

(2)

项目管理类过程域

A项目管理类过程域主要包含如下PA：

A项目计划PP;

»项目监督和控制PMC；

A风险管理RSKM;

»集成项目管理IPM；

»供应商合同管理SAM；

»需求管理REQM;

BasicProjectManagementPAs基础项目管理过程域

Status,issues,andresultsofprocessand

Correctiveactionproductevaluations;measuresandanalyses

PMC

Correctiveaction

Whatto

monitor

Productan

product

component

equirements

Whattobuild

WhattodQ_EngineeringandSupport

Status,issues,processareas

andresultsofCommitments»

reviewsand

monitoring

Plans

Measurement

SAMneeds

SupplierProductcomponentrequirements,technical

agreementissues,completedproductcomponents,and

acceptancereviewsandtests

Supplier

PMC=ProjectMonitoringandControl

PP=ProjectPlanning

REQM=RequirementsManagement

SAM=SupplierAgreementManagement

AdvancedProjectManagementPas高级项目管理过程域

Riskexposuredueto

unstableprocesses

Statisticalmanagementdata□PM

Quantitativeobjectives,

subprocessestostatisticall

manage,projectscomposed

anddefinedprocess

Organization'sstandardprocesseq

workenvironmentstandards!andRSKM

suDDortinaassets

IPM

ProcessManagementRisktaxonomies

processareasandparameters,

riskstatus,risk

Projectsdefinedmitigationplans,

processandworkandcorrective

environment

action

Coordination,

commitment^andissues

toresolve

Productarchitecture

forstructuringteamsTeamsforpertormingengineering

.ancLsuppoijprocesses

EngineeringandSupportBasicProiectManagement

-processareasprocessareas

IPM=IntegratedProjectManagement

QPM=QuantitativeProjectManagement

RSKM=RiskManagement

项目计划PP

ProjectPlanning

ProjectPlanning

目的：

制定和维护定义项目活动的计划

VI.3版的PP与VI.2版的PP不同之处

特

定目标，特定实践没有实质性的变更

以

下

项本语的定义在词汇表史进迂了修改：项目和

目点动。程序从词汇表由删玮

在4

践,增加了关于该过程域的特定实

^是否适应于其他的箱导

在介绍性说明中增加了关于PP如何应用于产品线

和敏捷环境的相关信息。

移除掉了关于IPPD的资料

在特定实践SP2.3和SP2.4中增加了子实践。对于

SP2.4和SP2.5增加了工作产品样例。修改信息化

材料，使WBS的开发基于项目策略而不是产品的

架构

ProjectPlanning-Context

；EstablishDevelopa

8EstimatesProjectPlan

I____________________

iObtain

Project

1Commitment

'tothePlanPlans

l________________

PMC

ProjectPlanning-Context

Planning

Data

ProjectPlanning-Context

PlanningData

DevelopaProjectPlan

ProjectPlans

ProjectPlanning-Context

PP的目的

>PP的目的

>就是制定和维护定义项目活动的计划

PP的要点J

pp包括以下主要活动：

A开发项目计划

A与项目相关人员适当的交流

»得到对计划的承诺

＞维护计划

策划工作从定义产品和项目的需求开始

术语“项目计划”指的是控制项目的整体计划

PP的要点-2

A策划通过如下活动，迭代地建立项目计划

A估计工作产品和任务的属性

A确定需要的资源

＞商讨承诺

＞产生进度安排

A标识和分析项目风险

项目计划提供执行和控制项目活动的基础，以满足项目

对客户的承诺

当遇到需求和承诺变更、不正确的估计、纠正行动和项

目过程变更时，通常需要修改项目计划

PP的SGs和SPs

特定目标SpecificGoal特定实践SpecificPractice

SP1.1估算项目的范围

建立工作产品和任务属性的估算

SG1:建立估计：要建立和维护SP1.2

定义项目生命周期

项目计划参数的估计数据SP1.3

SP1.4估算工作量和成本

SP2.1建立预算和进度

SG2:开发项目计划：要建立SP2.2识别项目风险

和维护项目计划，并作SP2.3计划数据的管理

为管理项目的基础

SP2.4计划项目的资源

SP2.5计划所需的知识和技能

SP2.6计戈U项目相关人员的参与

SP2.7建立项目计划

SP3.1评审影响项目的计划

SG3:获得对计划的承诺：要

建立和维护对项目计划SP3.2协调工作和资源

的承诺SP3.3获得计划的承诺

SG1建立估算」

SG1建立估算：建立和维护项目计划参数的估算

A项目计划参数包括项目从事下列活动所需的『仆：

规划、组织、用人、指导、协调、报告及预算。

＞计划参数的估计值应有充分的根据，以：

任何以此估算值所做的计划，能够支持项目目标。

A有必要把估算的理由和支持性数据形成文件，以便在

项目相关人员评审和获得对计划的承诺以及在项目进

展过程中维护计划.

SG1建立估算-2

在估算项目计划参数时，通常要考虑以下因素：

»项口需求，包括产品需求、组织的需求、客户的需求和其

它影响项目的需求

A项目的范围

＞已识别的任务和工作产品

＞技术实现方法

A选择的生命周期模型（如瀑布、增量、螺旋等）

＞工作产品和任务的属性（如规模或复杂度）

»进度

A转换工作产品和任务的属性为工时和成本的模型或历史数

据

A确定需要的材料、技能、工时和成本的方法（模型、数据

和算法）

SP1.1估算项目的范围

建立顶层的工作分解结构(WBS)来估计项目的范

AWBS与项目一起进化，初期的最顶层WBS用于初期

估计。

>WBS的开发将整个项目分解成可管理的相互关联的

构件集。WBS通常是产品导向的结构，它提供了一

种纲要结构，以识别与安排工作管理的逻辑单元，该

逻辑单元称之为工作包。

AWBS为分配工作量、进度和职责提供了一个参考和

组织机制，并被用作为计划、组织和控制有关项目要

做的工作的基本框架

WBS-WorkBreakdownStructure的定义

工作结构分解（WBS）是对项目范围的一种逐级分

解的层次化结构编码。

»依据PMBOK,分解指把主要可交付成果分成较小的，

便于管理的组成部分，直到可交付成果定义明晰到足

以支持各项项目活动（计划、实施、控制和收尾）的制订。

AWBS是面向可交付成果的对项目元素的分组，它组织

并定义了整个项目范围，未列入WBS的工作将排除在

项目范围以外。它是项目团队在项目期间要完成的最

终细目的等级树，所有这些细目的完成构成了整个项

目的工作范围。

准确界定项目的可交付成果和目标

项目目标是完成项目所必须达到的可计量指标；

尽量采用指标化和量化的项目目标，不可量化的

目标一般都存在范围风险；

A不适合的项目目标的例子

》建造一座2层楼的办公楼；

＞写一份与客户沟通产品功能的报告材料；

A正确的项目目标描述可以是

用200万元，根据第二号设计方案和****标准，在6个月内建

成一座办公楼，包括土建、安装和室内装修工程，不包括室外

装修；

项目范围的定义

项目范围：将项目可交付成果分成几个小的、更

易管理的单元；

＞为交付具有规定特征和功能的产品或服务所必须完成

的工作(whattodo)；

A项目范围的完成是对照项目计划进行衡量的；

A产品范围

＞区别产品或服务的特征和功能(whattomake)

＞产品范围的完成是对照产品要求进行衡量的；

WBS分解的基本原则

完全穷尽，彼此独立，一个项目单元只能从属于某一上层单元，不能

同时属于两个上层单元；

没有包含在WBS中的工作不属于项目的工作范围；

项目组的核心技术和管理人员参与制定，每个交付成果有人负责；

最低层次的工作包的单元成本不宜过大、工期不要太长。工作包

(workpackage)一般应在40小时(小于5个工作日)内完成；

WBS的不同的分解层数；

应在各层次上保证项目内容的完整性，不能遗漏任何必要的组成部分。

项目单元应能区分不同的责任者和不同的工作内容，应有较高的整体

性和独立性。

能够符合项目目标管理的要求，能方便的应用工期、质量、成本、合

同、信息等手段。

WBS不要太多层次，以四至六层为宜。

WBS对项目计划编制的作用

SP1.2建立工作产品和任务属性的估计

>SP1.2建立和维护工作产品和任务属性的估计

规模(size)是许多用于估计工作量、成本和进度的模

型的主要输入。其次是关联性(connectivity)、复杂

度(complexity)和结构之类的输入

要进行规模估计的工作产品的例子包括：

-可交付和不可交付的工作产品

-文档

-操作和支持软件

估计应该与项目需求一致，以便确定该项目的工作量、

成本和进度。每个规模属性应附上有关的难度和复杂

度。

规模度量的例子

A规模度量的例子包括:

A功能数

A功能点

＞源代码行

»类和对象数

A需求数

»接口数

»页数

»输入和输出数

估算

存在于估算中的常见问题

没有考虑到其他重要项目因素

开发环境的可用性和稳定性

团队的能力和经验

团队稳定性

过程成熟度

可复用的软件

对需要创建的可复用软件的估算

同客户/用户之间可能的交流程度

在软件开发和软件维护中使用自动化工具的程度

项目相关人员和团队的团结

缺少用于估算的培训和技能

在项目的进行中对估算的跟踪不好

估算的渐进性

A随着项目的进展，估算不断细化

每一阶段均需要进行详细的估算

估算

Basicprocess

>Estimatethesizeoftheproduct

估算规模的意义在于

考虑每个任务的复杂度；

规模是计算生产率的重要参数；

规模大可能意味着资源的需求也很大；

>Estimatetheeffort(man-months)

>Estimatethecostandschedule

Unitofsize:代码行(LOC)、功能点

Unitofeffort:人天、人月、人年等

Unitofcost：人民币、美元

软件估算的组成

进度估算

规模(Size)、工作量(effort)和成本(cost)

规模和工作量可以进行转换：软件生产率

工作量是成本的主要因素，一般项目的工作量估

算和成本估算是同时进行的，工作量确定了，就

基本可以确定项目的成本。

软件生产率

软件生产率是指人均每月所能生产的有效源代码

行数。（生产率=规模/工作量）

影响软件生产率的因素

A人的因素：开发机构的规模和经验

＞问题因素：问题的复杂性和设计约束或要求更改的次

»过程因素：使用的分析和设计技术、应用的语言及评

审的过程。

A生产因素：计算机系统的性能和可靠性

»资源因素：开发工具、硬件和软件资源

软件生产率

A根据软件组织的历史数据，按照以下步骤获取

A软件生产率数据：

»选择一些最近完成的项目，这些项目在规模、语言、

应用类型、团队开发经验等方面与待完成项目类似。

A获取各个项目的规模数（功能点、对象点、LOC）

＞计算投入到每个项目中的人员数量

»计算各个项目的软件生产率，即（功能点、对象点、

LOC）/PM（人月），进而求出平均值作为类型项目的

典型软件生产率。

估算步骤

»确定软件项目范围

A估算完成软件开发所需的资源

A估算产品的规模

估算工作量

估算成本

估算方法1一PERT方法

PERT方法

＞Pert方法是一种基于统计原理的估计方法，是一种简单易用、实效性强

的软件估计方法对于指定的估计单元（可能是规模、进度、工作量、费用

等），由直接负责人给出估计结果，估计结果由3个值构成：最乐观值、

最悲观值、最可能值，通过下面的计算公式得到估计的结果。

＞期望值=（最乐观值+4*最可能值+最悲观值）/6

＞标准偏差二（最乐观值-最悲观值）/6

＞建议：（最高-最低）/最可能v40%

＞由此，推算出来最有可能接近实际情况的值

＞［期望值-标准偏差，期望值+标准偏差］是一个可以接受的估计范围，如

果你的最终实际值能够落到该范围内，则可以被认为你的估计是成功的。

初期该范围可以较大，随着估计的不断精确，该范围应该逐渐被有意识

的减少以求得更准确的估计。

估算方法2—Delphi方法

A宽带Delphi方法

SP1.4确定工作量和成本估计

＞基于估计原理，估计工作产品和任务的工作量和成本

工作量和成本的估计一般基于使用模型或历史数据分析规模、

活动和其他计划参数的结果

＞估计的可信度取决于选择估计模型的基本理由和历史数据的

在某些情况下没有适用的历史数据，如工作量无先例

或任务类型没有适用的模型

如果从来就没有做过类仅的产品或产品构件，工作量就是无

先例的。如果开发组从来没有做过这类产品或产品构件，工

作量也是无先例的

工作量无先例，风险就更大，需要多做调查研究，以便打下

切实可行的估计基础，同时也需要比较多的口储洛O

在使用这些估计模型时，为了确保在初始的策划阶段对所做

的任何假设有共识，必须就该项目的唯一性形成文档

工作量估算应考虑的因素

A任务的难度：新颖程度、复杂度；

日历表、节假日等；

对技能的要求；

对经验和经历的要求

对业务知识的要求；

质量问题：所需的质量标准是什么？

项目的重要性：对客户、对管理层、对最终用户;

外部资源：可得性、可靠性、质量、价格

造成工作量估算不准的原因

＞缺少经验或历史数据的支持；

＞在估算时缺乏适当的方法或技能；

A与用户之间缺乏沟通，不能准确捕获需求；

A来自客户、内部的压力，导致不现实的估算;

A疏漏；

＞对相关问题的定义模糊或者不准确；

A人为虚报，以降低风险；

对项目团队成员的技能了解不够；

SG2开发项目计划

建立和维持一个项目计划作为管理项目的基础

项目计划是正式的已批准的文档，用于管理和控

制项目的执行。它基于项目需求和已建立的估计。

项目计划应该考虑项目生命周期的所有阶段。项

目计划应该确保所有影响项目的计划与整体项目

计划一致。

SP2.1建立预算和进度

A预算的定义

»对于项目执行方来说，预算是完成工作计划投入的成

本；

＞建立和维护项目的预算和进度

A项目的预算和进度基于已开发的估计，并确保预

算分配、任务复杂度和任务依赖得到合适的处理

预算的三件事情

A确定项目的总预算；

A确定项目各项活动的预算；

确定项目各项活动预算的投入时间；

预算

项目预算过程其实可以分成估算和预算两大部分。

＞估算的目的是估计项目的总成本，而预算则是将项目的总成

术分配到各工作项中去；

A估算内容包括人工成本、差旅、设备、和外包成本等。

A通常，人工成本占相当大比例，可以根据各类人员的成本单

价和投入工作量进行计算；

成本预算是在确定总体成本后的分解过程。

＞分解主要是做两个方面工作：

二一是按工作包分摊成本。这样可以对照检查每项工作的成本，出现偏

差时可以确定是哪项工作出了问题；

“二是按工期时段分摊成本，将预算成本分摊到工期的各个时段，可以

确定在未来某个时点累计应该花费的成本，这样做的好处是可以在任

何时间检查偏差，并评价成本偏离情况

综上所述，预算包括估算和预算两个步骤，预算的关键

是要知道每个工作包成本和未来具体时点累计成本

如何制定进度计划

根据项目活动定义、排序、工期估算和所需资源的结果

进行分析和进度计划的编制

A确定项目的起至时间；

A与范围、成本等方法综合考虑；

活动的排序

＞任务之间的依赖关系（逻辑关系）

产工作流程、相互关系

＞文档化

任务间的几种逻辑关系

＞完成开始关系FSfinish-start

＞开始开始关系SSstart-start

＞结束结束关系FFfinish-finish

＞开始结束关系SFstart-finish

SP2.3计划数据管理」

A计划项目数据的管理

这些数据是各种形式的文件，用以支持项目的所方方面

（例如，事务管理、工程化、配置、财务、后勤、质量、

安全、制造以及采购等）.

这些数据的0是各种各样的（例如，报告、手册、笔

记本、表格、图纸、规格说明书、文卷或信件等）

数据的i媒彳也可能是各种各样的（例如，各种印刷

材料、照片、电子媒体或多媒体）

这些数据可能是可占件（例如，业务计划的合同数据

要求中规定的数据），也可能是不可交付件（例如，非

正式资数据、趋势研究和分析、内部会议记录、内部设

计评审文档、经验教训和行动安排等）

这类数据的分发形式也很多，包括电子传输在内

SP2.3计划数据管理-2

对于项目的数据要求，应该根据通用的或标准的数据需

求从两个方面考虑：一个是要创建哪些数据，另一个是

数据的9容和形工，对数据的统一的内容和形式要求，

要考虑有利于理解数据内容，有助于数据资源的一致管

理

收集数据的原因应清楚。这项作业包括分析和确认项目

的可交付件和不可交付件、合同数据要求和非合同数据

要求以及客户提供的数据。数据收集时，经常没有清楚

的了解将如何使用该数据，

收集数据的成本很高，应该只在需要时才收集。

SP2.4计划项目资源

＞计划必要的资源来执行项目

定义项目资源（人力资源、机器/设备资源、材料和方

法）和基于初始估计定义执行项目活动需要的数量，并

提供可应用的额外信息来扩展用于管理项目的WBS

顶层WBS应作为估计手段早期开发。通常要通过分解

这些顶层结构为可独立地分配、执行和跟踪的代表单个

工作单元的工作包的方法来扩展。进行这种细化来分配

,并提供更好的管理控制。在WBS中的每个

工作包或工作产品应该赋唯一的标识符，以便允许跟踪。

一个WBS是基于需求、活动、工作产品的。要用一个

字典来描述WBS中的每个工作包的工作。

SP2.5计划需要的知识和技能

＞计划执行项目需要的知识和技能

A项目需要的知识包括项目人员需要的培训和从外

部源获取知识

人员配置需求取决于支持项目的执行可获得的知

识和技能

SP2.6项目相关人员参与

通过确定需要介入该项目的各类人员和职能，同时描

述他们与具体活动的关系和相互作用的程度，确定项

目生命周期所有各个阶段的相关人员。一般用：维矩

阵来描述。

要让相关人员的参与发挥效用，必须慎选项目的相关

人力。针对每个重大活动标识出受该活动影响的项目

相关人员和拥有执行该活动所需技能的项目相关人员。

项目相关人员名单可能随项目推进而变。保证生命周

期后面各个阶段的项目相关人员针对与之有关的需求

和设计决策较早地提出意见，这一点很重要。

什么是干系人

积极参与该项目工作的、或者由于项目的实施或成功其

与失败利益会受到积极或消极影响的个体和组织；

A对项目有很大影响，解决分歧时应以利于客户为原则；

＞主要干系人

A项目经理：管理项目；

A项目团队：实施项目任务；

A客户：使用项目产品或服务；

A发起人：为项目提供资金，承担最大风险；

＞高层管理者

＞分包商

干系人计划

确定项目干系人的信息和沟通需求，包括

A谁(receiver)在什么时候(when)需要什么信息(what)；

A谁(sender)通过什么方式(how)将信息传递给他们；

根据计划实施的结果进行定期检查，做必要的修

整和补充，确定其适合性；

SP2.7制定项目计划

＞制定和维护整体项目计划的内容；

项目计划必须文档化，以便与项目有关的个人、小组

和组织达成共识、实现承诺以及执行或支持该计划；

为项目产生的计划确定了所有方面的工作：项目生命

周期考虑；技术和管理任务；预算和进度；里程碑；

数据管理；风险标识；资源和技能需求；项目相关人

员的标识和参与。基础设施的描述包括项目人员、管

理和支持组织的职责和授权关系。

SP3.1评审影响项目的计划

A为了理解项目承诺，评审影响项目的所有计划

在其他过程域里开发的计划，通常包括与整体项目计划

类似的信息。这些计划提供了更加详细的指导，而且应

该与整体计划兼容并支持整体计划来指示谁有职权、职

责、责任和控制。

所有影响项"被评审，确保对项目取得成功需要

的范围、目的、角色和关系的共同理解

许多计划是由每个过程域中的“计划过程”共性实践描

述的

项目进度计划评审一现实性

A项目的工期估算由来？

A有哪些假设条件，是否有案可查？

＞项目任务之间的搭接度如何？

＞是否准备了足够的风险储备（风险计划如何？）

A项目干系人是否介入了进度计划的制定？介入是否充分?

＞范围是否明确？是否需要澄清？

A项目资源配置是否合理，是否还需要平衡？

进度计划是否客观？是否需要进行评审？

SP3.2协调工作和资源等级

＞协调项目计划来反映可用和估计的资源

要获得项目相关人员的承诺，协调估计和可用资源之

间的任何差1是重要的。协调一般通过：

＞降低或推迟技术性能需求

A磋商更多的资源

＞找到增加生产率的方法

＞外购

＞调整人员技能搭配

＞修订所有影响项目进度的计划

来实现.

SP3.3获得计划承诺

从执行和支持计划执行的有关的项目相关人员处

获得承诺

＞获得的承诺包括项目内部和外部所有有关的项目

相关人员之间交互的承诺。做出承诺的个人或小

组应该对在成本、进度和性能约束内执行工作有

信心。通常先做一个性的承i较为适当,以

容许工作启动，并进行相关研究，当增加信心至

适当程度，需要得到充分的承诺。

RequirementsManagement(REQM)

Purpose

Managerequirementsoftheproject's

productsandproductcomponentsandto

ensurealignmentbetweenthose

requirementsandtheproject'splansand

workproducts.

VL3版的REQM与V1.2版的不同之处

特定目标和术语没有实质性的变更

修改后的SP1.5更好的描述了该实践的内容，确保需求的

一致性。通过积极主动的关注于计划和产品与需求的一致

性，而不是找出不一致性问题

在介绍性说明中增加信息描述REQM是如何应用于敏捷环

境申语

在SP1.4中进行了大量的澄清，更加清晰的讨论了什么是

可追溯性

在整个PA中，把“议定的需求”改为“批准的需求”来

更加清晰的描述什么样的需求是将要计划，采购，设计，

服务和父付的

该过程域从工程过程域的分类中划分到项目管理过程域类

别中

WhenRequirementsManagementIsNot

DoneWell...

Requirementsareacceptedbystafffromanysource

theydeemtobeauthoritative.

Theprojectexperiencesahighlevelofrequirements

changes.

Therearehighlevelsofreworkthroughoutthe

project.

Thereisaninabilitytoprovethattheproductmeets

theapprovedrequirements.

Lackofrequirementstraceabilityoftenresultsin

incompleteorincorrecttestingoftheproduct.

RequirementsManagementGoals

SG1:ManageRequirements

Requirementsaremanagedand

inconsistencieswithprojectplansandwork

productsareidentified,

Theprocessareaalsohasgenericgoalsto

supportinstitutionalization.

RequirementsManagementContext

REQM（需求管理）

目标Goals实践practices

SP1.1理解需求：与需求提供者一起理解需求的含义

UnderstandRequirements:Developanunderstandingwiththe

requirementsprovidersonthemeaningoftherequirements.

SP1.2获得对需求的承诺：取得项目成员对需求的承诺

ObtainCommitmenttoRequirements.

SG1管理需求，并确定项

SP1.3管理需求变更：当项目需求在项目进行期间渐进演化时，管理需

目需求与项目计划和工作

求的变更

产品之间的不一致性

ManageRequirementsChanges

ManageRequirements

SP1.4维护需求的双向可跟踪性：维护需求与工作产品之间的双向可跟

踪性MaintainBi-directionalTraceabilityofRequirements

SP1.5确保项目工作与需求之间的不•致

EnsureAlignmentBetweenProjectWorkandRequirements

REQM（需求管理）

RM主要目标是项H组要理解需求、管理需求的变更、

在开发中对需求的实现进行跟踪。

现实中需求的变更很突出，"客户”早期对需求的不

确定性造成了需求的变更、需求的增加。以致对项目

的成功、进度的保证、成本控制、质量的保证都有影

响。

与RD&REQM相关的PA

RD&REQM提到了对需求的确认、理解、承诺，除了共利益

者进行商讨、研究需求外，应该采用同行评审VER。

评审的效果要用发现的错误数/评审工作量表示。

对需求的跟综、溯源，要采用跟综工具。

对需求变更的管理，要用变更管理过程CMo

需求有变更就要对版本做标识的变更，基线的变更CMo

如果注意到今后规模的历史数据参考，统计出需求的功能点数

和代码行数、工作量的关系需要做MAo

因此，RD&REQM已涉及了VER、MA、PPQA、CM。

RD&RM实例

1.过程实例

RTM实例

RD&RM应形成的基本过程文档

需求开发和管理过程

需求变更控制过程

项目监督与控制PMC

ProjectMonitorandControl

ProjectMonitoringandControl

Purpose:

Provideunderstandingintothe

projectsprogresssothat

appropriatecorrectiveactions

canbetakenwhentheprojects

performancedeviates

significantlyfromtheplan.

V1.3版的PMC与V1.2版不同之处

A特定目标，特定实践没有实质性的变化

修改了“项目”，“项目启动”的定义，删掉“程序”的

定义。在信息化材料中增加了一些样例，做了一些小的变

更。如：

A监控服务级别和客户满意度

＞监控一个敏捷环境

A增加了关于“进度“和”里程碑“意义的讨论

＞提供相关指导说明如何联合进度和里程碑评审可能做

为一个单独的评审事件

＞把解决过渡假设做为纠正行动的一部分

ProjectMonitoringandControl-Context

进度压缩的方法

赶工（优先选择赶工费最少的活动）

»重点分析关键活动

＞增加资源或提高生产率以缩短工期

快速跟进技术

分解长工期任务

修改资源的任务分配

进度最多压缩25%

项目监督与控制PMC的目的

提供对项目进展情况的了解

当项目的性能与其计划严币时，采取适当的

纠正行动

PMC的要点

A文档化的项目计划是监督活动、沟通状态和采取纠正行动的基

石出

在预定的里程碑处或在项目进度或WBS的控制点处，项目的

进展主要通过实际的工作产品和任务属性、工作量、成本和进

度）计划相比较来确定的

当项目计划时，提供适当的可见性并及时地采取纠正

行动。如果严重偏离不能解决，则应重新考虑其目的是否可行

所有的实践中使用“项目计划”术语是指项目的鲨体计息以便

控制这个项目

当实际状态严重偏离期望值时，要采取适当的纠正行动。这些

行动可能要求重计划，可能包括：

＞修订原来的计划

＞建立新的协议

＞或包括在当前计划内的额外的缓解活动

PMC的SGs和SPs

特定目标SpecificGoal特定实践SpecificPractice

SGI:对照项目计划，监督项»SP1.1监督项目的计划参数

目的实际性能和进展SP1.2监督承诺

SP1.3监督风险

SP1.4监督数据管理

SP1.5监督项目相关人员的

参与

SP1.6执行进展评审

SP1.7执行里程碑评审

SG2:当项目的性能和结果与SP2.1分析问题

计划有重大偏离时，要管理

SP2.2采取纠正行动

纠正行动直至解决

SP2.3管理纠正行动

SG1按计划监督项目

SG1:对照计划任督项目：对照项目计划，监督

项目的实际性能和进展

>SP1.1监督项目计划的参数

>SP1.2监督承诺

>SP1.3监督风险

ASPL4监督数据管理

>SP1.5监督项目相关人员的参与

>SP1.6执行进展评审

>SP1.7执行里程碑评审

SP1.1监督项目计划参数

SP1.1监督项目计划参数：按照项目计划，监督项目

计划参数的实际值

项目计划参数由项目进展和性能的典型指示器组成，

包括

»工作产品和任务的属性、成本、工作量和进度

»工作产品和任务的属性包括规模、复杂度、权重等

监督通常包括度量项目计划参数的实际值，比较实际

值与计划中的估计值，标识严重偏离

＞记录项目计划参数的实际值包括记录相关的卜文来

帮助理解度量

»严重偏离的影响分析确定要采取什么纠正行动，这在本过

程域的第二个特定目标的特定实践中处理

SP1.2监督承诺

SP1.2监督承诺：按项目计划中标识的承诺关系

监督承诺

»子实践

A定期评审承诺（包括内部承诺和外部承诺）

＞标识不满足的承诺和具有高风险而很可能无法满足的

承诺

A文档化对承诺评审的结果

SP1.3监督项目风险

SP1.3监督项目风险：按项目计划中标识的风险

监督风险

A子实践

＞在项目的当前状态和环境中，定期评审风险的文档

»当额外的信息变得可用时，修订风险文档，并纳入变

更

＞与有关的项目相关人员沟通风险状态

A风险状态的例子包括：

＞风险发生概率的变更

风险优先级的变更

SP1.4监督