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級-優(yōu)化級

組織性能管理

原因分析和解決,

4級-定量管理級L

定量項目管理

CMMI的階段式表示法就是組組織過程性能

織成熟度方法(3級-定義級

需求開發(fā)

技術解決方案

驗證5優(yōu)化級⑵

確認4定量管理級⑵

產(chǎn)品集成3已定義級(14)

集成項目管理

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

配置管理組織過程焦點

初始級

過程和產(chǎn)品質(zhì)量保證組織過程定義1(0)

供應商合同管理組織培訓

項目監(jiān)控和控制風險管理

項目計劃決策分析和解決

需求管理

i度量和分析y

1級-初始級

CMMI模型（持續(xù)表示法）

級別'分類Engineering(6)ProjectProcessSupport(5)

Management(6)Management(5)

2級PP（項目計劃）CM（配置管理）

受管理級PMC（項目監(jiān)控）PPQA

ManagedSAM（分包合同管理）（過程和產(chǎn)品質(zhì)量保證）

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

3級RD（需求開發(fā)）IPM（集成項目管理）OPD（過程定義）DAR

已定義級TS（技術解決）RSKM（風險管理）OPF（過程聚焦）（決策分析與解決方案）

DefinedPI（產(chǎn)品集成）OT（培訓）

(11)VER（驗證）

VAL（確認）

4級QPM（定量項目管理）OPP（組織過程性能）

定量管理級

Quantitatively

Managed

(2)

5級OPM（組織性能管理）CAR

.續(xù)優(yōu)化級

（因果分析和解決方案）

Optimizing

(2)

項目管理類過程域

A項目管理類過程域主要包含如下PA：

A項目計劃PP;

?項目監(jiān)督和控制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不同之處

特

定目標，特定實踐沒有實質(zhì)性的變更

以

下

項本語的定義在詞匯表史進迂了修改：項目和

目點動。程序從詞匯表由刪瑋

在4

踐,增加了關于該過程域的特定實

^是否適應于其他的箱導

在介紹性說明中增加了關于PP如何應用于產(chǎn)品線

和敏捷環(huán)境的相關信息。

移除掉了關于IPPD的資料

在特定實踐SP2.3和SP2.4中增加了子實踐。對于

SP2.4和SP2.5增加了工作產(chǎn)品樣例。修改信息化

材料，使WBS的開發(fā)基于項目策略而不是產(chǎn)品的

架構

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開發(fā)項目計劃

A與項目相關人員適當?shù)慕涣?/p>

?得到對計劃的承諾

＞維護計劃

策劃工作從定義產(chǎn)品和項目的需求開始

術語“項目計劃”指的是控制項目的整體計劃

PP的要點-2

A策劃通過如下活動，迭代地建立項目計劃

A估計工作產(chǎn)品和任務的屬性

A確定需要的資源

＞商討承諾

＞產(chǎn)生進度安排

A標識和分析項目風險

項目計劃提供執(zhí)行和控制項目活動的基礎，以滿足項目

對客戶的承諾

當遇到需求和承諾變更、不正確的估計、糾正行動和項

目過程變更時，通常需要修改項目計劃

PP的SGs和SPs

特定目標SpecificGoal特定實踐SpecificPractice

SP1.1估算項目的范圍

建立工作產(chǎn)品和任務屬性的估算

SG1:建立估計：要建立和維護SP1.2

定義項目生命周期

項目計劃參數(shù)的估計數(shù)據(jù)SP1.3

SP1.4估算工作量和成本

SP2.1建立預算和進度

SG2:開發(fā)項目計劃：要建立SP2.2識別項目風險

和維護項目計劃，并作SP2.3計劃數(shù)據(jù)的管理

為管理項目的基礎

SP2.4計劃項目的資源

SP2.5計劃所需的知識和技能

SP2.6計戈U項目相關人員的參與

SP2.7建立項目計劃

SP3.1評審影響項目的計劃

SG3:獲得對計劃的承諾：要

建立和維護對項目計劃SP3.2協(xié)調(diào)工作和資源

的承諾SP3.3獲得計劃的承諾

SG1建立估算」

SG1建立估算：建立和維護項目計劃參數(shù)的估算

A項目計劃參數(shù)包括項目從事下列活動所需的『仆：

規(guī)劃、組織、用人、指導、協(xié)調(diào)、報告及預算。

＞計劃參數(shù)的估計值應有充分的根據(jù)，以：

任何以此估算值所做的計劃，能夠支持項目目標。

A有必要把估算的理由和支持性數(shù)據(jù)形成文件，以便在

項目相關人員評審和獲得對計劃的承諾以及在項目進

展過程中維護計劃.

SG1建立估算-2

在估算項目計劃參數(shù)時，通常要考慮以下因素：

?項口需求，包括產(chǎn)品需求、組織的需求、客戶的需求和其

它影響項目的需求

A項目的范圍

＞已識別的任務和工作產(chǎn)品

＞技術實現(xiàn)方法

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

＞工作產(chǎn)品和任務的屬性（如規(guī)?；驈碗s度）

?進度

A轉換工作產(chǎn)品和任務的屬性為工時和成本的模型或歷史數(shù)

據(jù)

A確定需要的材料、技能、工時和成本的方法（模型、數(shù)據(jù)

和算法）

SP1.1估算項目的范圍

建立頂層的工作分解結構(WBS)來估計項目的范

AWBS與項目一起進化，初期的最頂層WBS用于初期

估計。

>WBS的開發(fā)將整個項目分解成可管理的相互關聯(lián)的

構件集。WBS通常是產(chǎn)品導向的結構，它提供了一

種綱要結構，以識別與安排工作管理的邏輯單元，該

邏輯單元稱之為工作包。

AWBS為分配工作量、進度和職責提供了一個參考和

組織機制，并被用作為計劃、組織和控制有關項目要

做的工作的基本框架

WBS-WorkBreakdownStructure的定義

工作結構分解（WBS）是對項目范圍的一種逐級分

解的層次化結構編碼。

?依據(jù)PMBOK,分解指把主要可交付成果分成較小的，

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

以支持各項項目活動（計劃、實施、控制和收尾）的制訂。

AWBS是面向可交付成果的對項目元素的分組，它組織

并定義了整個項目范圍，未列入WBS的工作將排除在

項目范圍以外。它是項目團隊在項目期間要完成的最

終細目的等級樹，所有這些細目的完成構成了整個項

目的工作范圍。

準確界定項目的可交付成果和目標

項目目標是完成項目所必須達到的可計量指標；

盡量采用指標化和量化的項目目標，不可量化的

目標一般都存在范圍風險；

A不適合的項目目標的例子

》建造一座2層樓的辦公樓；

＞寫一份與客戶溝通產(chǎn)品功能的報告材料；

A正確的項目目標描述可以是

用200萬元，根據(jù)第二號設計方案和****標準，在6個月內(nèi)建

成一座辦公樓，包括土建、安裝和室內(nèi)裝修工程，不包括室外

裝修；

項目范圍的定義

項目范圍：將項目可交付成果分成幾個小的、更

易管理的單元；

＞為交付具有規(guī)定特征和功能的產(chǎn)品或服務所必須完成

的工作(whattodo)；

A項目范圍的完成是對照項目計劃進行衡量的；

A產(chǎn)品范圍

＞區(qū)別產(chǎn)品或服務的特征和功能(whattomake)

＞產(chǎn)品范圍的完成是對照產(chǎn)品要求進行衡量的；

WBS分解的基本原則

完全窮盡，彼此獨立，一個項目單元只能從屬于某一上層單元，不能

同時屬于兩個上層單元；

沒有包含在WBS中的工作不屬于項目的工作范圍；

項目組的核心技術和管理人員參與制定，每個交付成果有人負責；

最低層次的工作包的單元成本不宜過大、工期不要太長。工作包

(workpackage)一般應在40小時(小于5個工作日)內(nèi)完成；

WBS的不同的分解層數(shù)；

應在各層次上保證項目內(nèi)容的完整性，不能遺漏任何必要的組成部分。

項目單元應能區(qū)分不同的責任者和不同的工作內(nèi)容，應有較高的整體

性和獨立性。

能夠符合項目目標管理的要求，能方便的應用工期、質(zhì)量、成本、合

同、信息等手段。

WBS不要太多層次，以四至六層為宜。

WBS對項目計劃編制的作用

SP1.2建立工作產(chǎn)品和任務屬性的估計

>SP1.2建立和維護工作產(chǎn)品和任務屬性的估計

規(guī)模(size)是許多用于估計工作量、成本和進度的模

型的主要輸入。其次是關聯(lián)性(connectivity)、復雜

度(complexity)和結構之類的輸入

要進行規(guī)模估計的工作產(chǎn)品的例子包括：

-可交付和不可交付的工作產(chǎn)品

-文檔

-操作和支持軟件

估計應該與項目需求一致，以便確定該項目的工作量、

成本和進度。每個規(guī)模屬性應附上有關的難度和復雜

度。

規(guī)模度量的例子

A規(guī)模度量的例子包括:

A功能數(shù)

A功能點

＞源代碼行

?類和對象數(shù)

A需求數(shù)

?接口數(shù)

?頁數(shù)

?輸入和輸出數(shù)

估算

存在于估算中的常見問題

沒有考慮到其他重要項目因素

開發(fā)環(huán)境的可用性和穩(wěn)定性

團隊的能力和經(jīng)驗

團隊穩(wěn)定性

過程成熟度

可復用的軟件

對需要創(chuàng)建的可復用軟件的估算

同客戶/用戶之間可能的交流程度

在軟件開發(fā)和軟件維護中使用自動化工具的程度

項目相關人員和團隊的團結

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

在項目的進行中對估算的跟蹤不好

估算的漸進性

A隨著項目的進展，估算不斷細化

每一階段均需要進行詳細的估算

估算

Basicprocess

>Estimatethesizeoftheproduct

估算規(guī)模的意義在于

考慮每個任務的復雜度；

規(guī)模是計算生產(chǎn)率的重要參數(shù)；

規(guī)模大可能意味著資源的需求也很大；

>Estimatetheeffort(man-months)

>Estimatethecostandschedule

Unitofsize:代碼行(LOC)、功能點

Unitofeffort:人天、人月、人年等

Unitofcost：人民幣、美元

軟件估算的組成

進度估算

規(guī)模(Size)、工作量(effort)和成本(cost)

規(guī)模和工作量可以進行轉換：軟件生產(chǎn)率

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

算和成本估算是同時進行的，工作量確定了，就

基本可以確定項目的成本。

軟件生產(chǎn)率

軟件生產(chǎn)率是指人均每月所能生產(chǎn)的有效源代碼

行數(shù)。（生產(chǎn)率=規(guī)模/工作量）

影響軟件生產(chǎn)率的因素

A人的因素：開發(fā)機構的規(guī)模和經(jīng)驗

＞問題因素：問題的復雜性和設計約束或要求更改的次

?過程因素：使用的分析和設計技術、應用的語言及評

審的過程。

A生產(chǎn)因素：計算機系統(tǒng)的性能和可靠性

?資源因素：開發(fā)工具、硬件和軟件資源

軟件生產(chǎn)率

A根據(jù)軟件組織的歷史數(shù)據(jù)，按照以下步驟獲取

A軟件生產(chǎn)率數(shù)據(jù)：

?選擇一些最近完成的項目，這些項目在規(guī)模、語言、

應用類型、團隊開發(fā)經(jīng)驗等方面與待完成項目類似。

A獲取各個項目的規(guī)模數(shù)（功能點、對象點、LOC）

＞計算投入到每個項目中的人員數(shù)量

?計算各個項目的軟件生產(chǎn)率，即（功能點、對象點、

LOC）/PM（人月），進而求出平均值作為類型項目的

典型軟件生產(chǎn)率。

估算步驟

?確定軟件項目范圍

A估算完成軟件開發(fā)所需的資源

A估算產(chǎn)品的規(guī)模

估算工作量

估算成本

估算方法1一PERT方法

PERT方法

＞Pert方法是一種基于統(tǒng)計原理的估計方法，是一種簡單易用、實效性強

的軟件估計方法對于指定的估計單元（可能是規(guī)模、進度、工作量、費用

等），由直接負責人給出估計結果，估計結果由3個值構成：最樂觀值、

最悲觀值、最可能值，通過下面的計算公式得到估計的結果。

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

＞標準偏差二（最樂觀值-最悲觀值）/6

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

＞由此，推算出來最有可能接近實際情況的值

＞［期望值-標準偏差，期望值+標準偏差］是一個可以接受的估計范圍，如

果你的最終實際值能夠落到該范圍內(nèi)，則可以被認為你的估計是成功的。

初期該范圍可以較大，隨著估計的不斷精確，該范圍應該逐漸被有意識

的減少以求得更準確的估計。

估算方法2—Delphi方法

A寬帶Delphi方法

SP1.4確定工作量和成本估計

＞基于估計原理，估計工作產(chǎn)品和任務的工作量和成本

工作量和成本的估計一般基于使用模型或歷史數(shù)據(jù)分析規(guī)模、

活動和其他計劃參數(shù)的結果

＞估計的可信度取決于選擇估計模型的基本理由和歷史數(shù)據(jù)的

在某些情況下沒有適用的歷史數(shù)據(jù)，如工作量無先例

或任務類型沒有適用的模型

如果從來就沒有做過類僅的產(chǎn)品或產(chǎn)品構件，工作量就是無

先例的。如果開發(fā)組從來沒有做過這類產(chǎn)品或產(chǎn)品構件，工

作量也是無先例的

工作量無先例，風險就更大，需要多做調(diào)查研究，以便打下

切實可行的估計基礎，同時也需要比較多的口儲洛O

在使用這些估計模型時，為了確保在初始的策劃階段對所做

的任何假設有共識，必須就該項目的唯一性形成文檔

工作量估算應考慮的因素

A任務的難度：新穎程度、復雜度；

日歷表、節(jié)假日等；

對技能的要求；

對經(jīng)驗和經(jīng)歷的要求

對業(yè)務知識的要求；

質(zhì)量問題：所需的質(zhì)量標準是什么？

項目的重要性：對客戶、對管理層、對最終用戶;

外部資源：可得性、可靠性、質(zhì)量、價格

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

＞缺少經(jīng)驗或歷史數(shù)據(jù)的支持；

＞在估算時缺乏適當?shù)姆椒ɑ蚣寄埽?/p>

A與用戶之間缺乏溝通，不能準確捕獲需求；

A來自客戶、內(nèi)部的壓力，導致不現(xiàn)實的估算;

A疏漏；

＞對相關問題的定義模糊或者不準確；

A人為虛報，以降低風險；

對項目團隊成員的技能了解不夠；

SG2開發(fā)項目計劃

建立和維持一個項目計劃作為管理項目的基礎

項目計劃是正式的已批準的文檔，用于管理和控

制項目的執(zhí)行。它基于項目需求和已建立的估計。

項目計劃應該考慮項目生命周期的所有階段。項

目計劃應該確保所有影響項目的計劃與整體項目

計劃一致。

SP2.1建立預算和進度

A預算的定義

?對于項目執(zhí)行方來說，預算是完成工作計劃投入的成

本；

＞建立和維護項目的預算和進度

A項目的預算和進度基于已開發(fā)的估計，并確保預

算分配、任務復雜度和任務依賴得到合適的處理

預算的三件事情

A確定項目的總預算；

A確定項目各項活動的預算；

確定項目各項活動預算的投入時間；

預算

項目預算過程其實可以分成估算和預算兩大部分。

＞估算的目的是估計項目的總成本，而預算則是將項目的總成

術分配到各工作項中去；

A估算內(nèi)容包括人工成本、差旅、設備、和外包成本等。

A通常，人工成本占相當大比例，可以根據(jù)各類人員的成本單

價和投入工作量進行計算；

成本預算是在確定總體成本后的分解過程。

＞分解主要是做兩個方面工作：

二一是按工作包分攤成本。這樣可以對照檢查每項工作的成本，出現(xiàn)偏

差時可以確定是哪項工作出了問題；

“二是按工期時段分攤成本，將預算成本分攤到工期的各個時段，可以

確定在未來某個時點累計應該花費的成本，這樣做的好處是可以在任

何時間檢查偏差，并評價成本偏離情況

綜上所述，預算包括估算和預算兩個步驟，預算的關鍵

是要知道每個工作包成本和未來具體時點累計成本

如何制定進度計劃

根據(jù)項目活動定義、排序、工期估算和所需資源的結果

進行分析和進度計劃的編制

A確定項目的起至時間；

A與范圍、成本等方法綜合考慮；

活動的排序

＞任務之間的依賴關系（邏輯關系）

產(chǎn)工作流程、相互關系

＞文檔化

任務間的幾種邏輯關系

＞完成開始關系FSfinish-start

＞開始開始關系SSstart-start

＞結束結束關系FFfinish-finish

＞開始結束關系SFstart-finish

SP2.3計劃數(shù)據(jù)管理」

A計劃項目數(shù)據(jù)的管理

這些數(shù)據(jù)是各種形式的文件，用以支持項目的所方方面

（例如，事務管理、工程化、配置、財務、后勤、質(zhì)量、

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

這些數(shù)據(jù)的0是各種各樣的（例如，報告、手冊、筆

記本、表格、圖紙、規(guī)格說明書、文卷或信件等）

數(shù)據(jù)的i媒彳也可能是各種各樣的（例如，各種印刷

材料、照片、電子媒體或多媒體）

這些數(shù)據(jù)可能是可占件（例如，業(yè)務計劃的合同數(shù)據(jù)

要求中規(guī)定的數(shù)據(jù)），也可能是不可交付件（例如，非

正式資數(shù)據(jù)、趨勢研究和分析、內(nèi)部會議記錄、內(nèi)部設

計評審文檔、經(jīng)驗教訓和行動安排等）

這類數(shù)據(jù)的分發(fā)形式也很多，包括電子傳輸在內(nèi)

SP2.3計劃數(shù)據(jù)管理-2

對于項目的數(shù)據(jù)要求，應該根據(jù)通用的或標準的數(shù)據(jù)需

求從兩個方面考慮：一個是要創(chuàng)建哪些數(shù)據(jù)，另一個是

數(shù)據(jù)的9容和形工，對數(shù)據(jù)的統(tǒng)一的內(nèi)容和形式要求，

要考慮有利于理解數(shù)據(jù)內(nèi)容，有助于數(shù)據(jù)資源的一致管

理

收集數(shù)據(jù)的原因應清楚。這項作業(yè)包括分析和確認項目

的可交付件和不可交付件、合同數(shù)據(jù)要求和非合同數(shù)據(jù)

要求以及客戶提供的數(shù)據(jù)。數(shù)據(jù)收集時，經(jīng)常沒有清楚

的了解將如何使用該數(shù)據(jù)，

收集數(shù)據(jù)的成本很高，應該只在需要時才收集。

SP2.4計劃項目資源

＞計劃必要的資源來執(zhí)行項目

定義項目資源（人力資源、機器/設備資源、材料和方

法）和基于初始估計定義執(zhí)行項目活動需要的數(shù)量，并

提供可應用的額外信息來擴展用于管理項目的WBS

頂層WBS應作為估計手段早期開發(fā)。通常要通過分解

這些頂層結構為可獨立地分配、執(zhí)行和跟蹤的代表單個

工作單元的工作包的方法來擴展。進行這種細化來分配

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

工作包或工作產(chǎn)品應該賦唯一的標識符，以便允許跟蹤。

一個WBS是基于需求、活動、工作產(chǎn)品的。要用一個

字典來描述WBS中的每個工作包的工作。

SP2.5計劃需要的知識和技能

＞計劃執(zhí)行項目需要的知識和技能

A項目需要的知識包括項目人員需要的培訓和從外

部源獲取知識

人員配置需求取決于支持項目的執(zhí)行可獲得的知

識和技能

SP2.6項目相關人員參與

通過確定需要介入該項目的各類人員和職能，同時描

述他們與具體活動的關系和相互作用的程度，確定項

目生命周期所有各個階段的相關人員。一般用：維矩

陣來描述。

要讓相關人員的參與發(fā)揮效用，必須慎選項目的相關

人力。針對每個重大活動標識出受該活動影響的項目

相關人員和擁有執(zhí)行該活動所需技能的項目相關人員。

項目相關人員名單可能隨項目推進而變。保證生命周

期后面各個階段的項目相關人員針對與之有關的需求

和設計決策較早地提出意見，這一點很重要。

什么是干系人

積極參與該項目工作的、或者由于項目的實施或成功其

與失敗利益會受到積極或消極影響的個體和組織；

A對項目有很大影響，解決分歧時應以利于客戶為原則；

＞主要干系人

A項目經(jīng)理：管理項目；

A項目團隊：實施項目任務；

A客戶：使用項目產(chǎn)品或服務；

A發(fā)起人：為項目提供資金，承擔最大風險；

＞高層管理者

＞分包商

干系人計劃

確定項目干系人的信息和溝通需求，包括

A誰(receiver)在什么時候(when)需要什么信息(what)；

A誰(sender)通過什么方式(how)將信息傳遞給他們；

根據(jù)計劃實施的結果進行定期檢查，做必要的修

整和補充，確定其適合性；

SP2.7制定項目計劃

＞制定和維護整體項目計劃的內(nèi)容；

項目計劃必須文檔化，以便與項目有關的個人、小組

和組織達成共識、實現(xiàn)承諾以及執(zhí)行或支持該計劃；

為項目產(chǎn)生的計劃確定了所有方面的工作：項目生命

周期考慮；技術和管理任務；預算和進度；里程碑；

數(shù)據(jù)管理；風險標識；資源和技能需求；項目相關人

員的標識和參與?；A設施的描述包括項目人員、管

理和支持組織的職責和授權關系。

SP3.1評審影響項目的計劃

A為了理解項目承諾，評審影響項目的所有計劃

在其他過程域里開發(fā)的計劃，通常包括與整體項目計劃

類似的信息。這些計劃提供了更加詳細的指導，而且應

該與整體計劃兼容并支持整體計劃來指示誰有職權、職

責、責任和控制。

所有影響項"被評審，確保對項目取得成功需要

的范圍、目的、角色和關系的共同理解

許多計劃是由每個過程域中的“計劃過程”共性實踐描

述的

項目進度計劃評審一現(xiàn)實性

A項目的工期估算由來？

A有哪些假設條件，是否有案可查？

＞項目任務之間的搭接度如何？

＞是否準備了足夠的風險儲備（風險計劃如何？）

A項目干系人是否介入了進度計劃的制定？介入是否充分?

＞范圍是否明確？是否需要澄清？

A項目資源配置是否合理，是否還需要平衡？

進度計劃是否客觀？是否需要進行評審？

SP3.2協(xié)調(diào)工作和資源等級

＞協(xié)調(diào)項目計劃來反映可用和估計的資源

要獲得項目相關人員的承諾，協(xié)調(diào)估計和可用資源之

間的任何差1是重要的。協(xié)調(diào)一般通過：

＞降低或推遲技術性能需求

A磋商更多的資源

＞找到增加生產(chǎn)率的方法

＞外購

＞調(diào)整人員技能搭配

＞修訂所有影響項目進度的計劃

來實現(xiàn).

SP3.3獲得計劃承諾

從執(zhí)行和支持計劃執(zhí)行的有關的項目相關人員處

獲得承諾

＞獲得的承諾包括項目內(nèi)部和外部所有有關的項目

相關人員之間交互的承諾。做出承諾的個人或小

組應該對在成本、進度和性能約束內(nèi)執(zhí)行工作有

信心。通常先做一個性的承i較為適當,以

容許工作啟動，并進行相關研究，當增加信心至

適當程度，需要得到充分的承諾。

RequirementsManagement(REQM)

Purpose

Managerequirementsoftheproject's

productsandproductcomponentsandto

ensurealignmentbetweenthose

requirementsandtheproject'splansand

workproducts.

VL3版的REQM與V1.2版的不同之處

特定目標和術語沒有實質(zhì)性的變更

修改后的SP1.5更好的描述了該實踐的內(nèi)容，確保需求的

一致性。通過積極主動的關注于計劃和產(chǎn)品與需求的一致

性，而不是找出不一致性問題

在介紹性說明中增加信息描述REQM是如何應用于敏捷環(huán)

境申語

在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管理需求變更：當項目需求在項目進行期間漸進演化時，管理需

目需求與項目計劃和工作

求的變更

產(chǎn)品之間的不一致性

ManageRequirementsChanges

ManageRequirements

SP1.4維護需求的雙向可跟蹤性：維護需求與工作產(chǎn)品之間的雙向可跟

蹤性MaintainBi-directionalTraceabilityofRequirements

SP1.5確保項目工作與需求之間的不?致

EnsureAlignmentBetweenProjectWorkandRequirements

REQM（需求管理）

RM主要目標是項H組要理解需求、管理需求的變更、

在開發(fā)中對需求的實現(xiàn)進行跟蹤。

現(xiàn)實中需求的變更很突出，"客戶”早期對需求的不

確定性造成了需求的變更、需求的增加。以致對項目

的成功、進度的保證、成本控制、質(zhì)量的保證都有影

響。

與RD&REQM相關的PA

RD&REQM提到了對需求的確認、理解、承諾，除了共利益

者進行商討、研究需求外，應該采用同行評審VER。

評審的效果要用發(fā)現(xiàn)的錯誤數(shù)/評審工作量表示。

對需求的跟綜、溯源，要采用跟綜工具。

對需求變更的管理，要用變更管理過程CMo

需求有變更就要對版本做標識的變更，基線的變更CMo

如果注意到今后規(guī)模的歷史數(shù)據(jù)參考，統(tǒng)計出需求的功能點數(shù)

和代碼行數(shù)、工作量的關系需要做MAo

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

RD&RM實例

1.過程實例

RTM實例

RD&RM應形成的基本過程文檔

需求開發(fā)和管理過程

需求變更控制過程

項目監(jiān)督與控制PMC

ProjectMonitorandControl

ProjectMonitoringandControl

Purpose:

Provideunderstandingintothe

projectsprogresssothat

appropriatecorrectiveactions

canbetakenwhentheprojects

performancedeviates

significantlyfromtheplan.

V1.3版的PMC與V1.2版不同之處

A特定目標，特定實踐沒有實質(zhì)性的變化

修改了“項目”，“項目啟動”的定義，刪掉“程序”的

定義。在信息化材料中增加了一些樣例，做了一些小的變

更。如：

A監(jiān)控服務級別和客戶滿意度

＞監(jiān)控一個敏捷環(huán)境

A增加了關于“進度“和”里程碑“意義的討論

＞提供相關指導說明如何聯(lián)合進度和里程碑評審可能做

為一個單獨的評審事件

＞把解決過渡假設做為糾正行動的一部分

ProjectMonitoringandControl-Context

進度壓縮的方法

趕工（優(yōu)先選擇趕工費最少的活動）

?重點分析關鍵活動

＞增加資源或提高生產(chǎn)率以縮短工期

快速跟進技術

分解長工期任務

修改資源的任務分配

進度最多壓縮25%

項目監(jiān)督與控制PMC的目的

提供對項目進展情況的了解

當項目的性能與其計劃嚴幣時，采取適當?shù)?/p>

糾正行動

PMC的要點

A文檔化的項目計劃是監(jiān)督活動、溝通狀態(tài)和采取糾正行動的基

石出

在預定的里程碑處或在項目進度或WBS的控制點處，項目的

進展主要通過實際的工作產(chǎn)品和任務屬性、工作量、成本和進

度）計劃相比較來確定的

當項目計劃時，提供適當?shù)目梢娦圆⒓皶r地采取糾正

行動。如果嚴重偏離不能解決，則應重新考慮其目的是否可行

所有的實踐中使用“項目計劃”術語是指項目的鯊體計息以便

控制這個項目

當實際狀態(tài)嚴重偏離期望值時，要采取適當?shù)募m正行動。這些

行動可能要求重計劃，可能包括：

＞修訂原來的計劃

＞建立新的協(xié)議

＞或包括在當前計劃內(nèi)的額外的緩解活動

PMC的SGs和SPs

特定目標SpecificGoal特定實踐SpecificPractice

SGI:對照項目計劃，監(jiān)督項?SP1.1監(jiān)督項目的計劃參數(shù)

目的實際性能和進展SP1.2監(jiān)督承諾

SP1.3監(jiān)督風險

SP1.4監(jiān)督數(shù)據(jù)管理

SP1.5監(jiān)督項目相關人員的

參與

SP1.6執(zhí)行進展評審

SP1.7執(zhí)行里程碑評審

SG2:當項目的性能和結果與SP2.1分析問題

計劃有重大偏離時，要管理

SP2.2采取糾正行動

糾正行動直至解決

SP2.3管理糾正行動

SG1按計劃監(jiān)督項目

SG1:對照計劃任督項目：對照項目計劃，監(jiān)督

項目的實際性能和進展

>SP1.1監(jiān)督項目計劃的參數(shù)

>SP1.2監(jiān)督承諾

>SP1.3監(jiān)督風險

ASPL4監(jiān)督數(shù)據(jù)管理

>SP1.5監(jiān)督項目相關人員的參與

>SP1.6執(zhí)行進展評審

>SP1.7執(zhí)行里程碑評審

SP1.1監(jiān)督項目計劃參數(shù)

SP1.1監(jiān)督項目計劃參數(shù)：按照項目計劃，監(jiān)督項目

計劃參數(shù)的實際值

項目計劃參數(shù)由項目進展和性能的典型指示器組成，

包括

?工作產(chǎn)品和任務的屬性、成本、工作量和進度

?工作產(chǎn)品和任務的屬性包括規(guī)模、復雜度、權重等

監(jiān)督通常包括度量項目計劃參數(shù)的實際值，比較實際

值與計劃中的估計值，標識嚴重偏離

＞記錄項目計劃參數(shù)的實際值包括記錄相關的卜文來

幫助理解度量

?嚴重偏離的影響分析確定要采取什么糾正行動，這在本過

程域的第二個特定目標的特定實踐中處理

SP1.2監(jiān)督承諾

SP1.2監(jiān)督承諾：按項目計劃中標識的承諾關系

監(jiān)督承諾

?子實踐

A定期評審承諾（包括內(nèi)部承諾和外部承諾）

＞標識不滿足的承諾和具有高風險而很可能無法滿足的

承諾

A文檔化對承諾評審的結果

SP1.3監(jiān)督項目風險

SP1.3監(jiān)督項目風險：按項目計劃中標識的風險

監(jiān)督風險

A子實踐

＞在項目的當前狀態(tài)和環(huán)境中，定期評審風險的文檔

?當額外的信息變得可用時，修訂風險文檔，并納入變

更

＞與有關的項目相關人員溝通風險狀態(tài)

A風險狀態(tài)的例子包括：

＞風險發(fā)生概率的變更

風險優(yōu)先級的變更

SP1.4監(jiān)督