sg 1:
建立估計計畫：要建立和維護專案計畫引數的估計資料
sp1.1
估計專案的範圍
sp1.2
建立專案屬性的估計
sp1.3
定義專案生命週期
sp1.4
確定工作量和成本的估計
專案範圍的估計可以通過建立頂層
wbs分解，
wbs分解一般是面向產品結構，需要分解到工作包這個層次。由於
wbs面向產品結構，使我們容易遺忘在
wbs分解中包括風險緩解，配置管理，整合，培訓，非開發管理等任務。我們仍然強調的是
wbs加上工作包的描述是專案範圍的乙個全集。
規模是許多用於估計工作量、成本和進度的模型的主要輸入。
sp1.2
提到的專案屬性估計的重點就是先要有任務或工作產品的規模和複雜度的估計，這個是後續工作量，成本和進度估算的基礎。對應軟體產品衡量規模的單位常用的有功能點，**行，需求頁數，用例數，需求條目數等。
**的ipm
整合專案管理強調了專案的過程是從組織標準過程定義裁剪出來的，乙個重點大的裁剪就是選擇專案生命週期模型。
sp1.3
定義專案生命週期在二級的時候還沒有上公升到組織級。
專案生命週期模型的定義是確定工作量和成本的基礎，不同的生命週期工作量的分布往往是不同的，而且我們的專案歷史資料也是在一定的生命週期模型下得到的。在這裡把生命週期模型放到
sp1.3
，是否說明頂層
wbs分解更多的是專案產品結構，和採用的生命週期模型關係不大?
工作量和成本的估計一般基於使用模型或歷史資料分析規模、活動和其他計畫引數的結果。不可**的工作量是更危險的，需要更多研究來開發合理的估計基礎，並需要預留更多的管理工作。在軟體工程領域，已經開發許多引數化模型來輔助成本和進度。歷史資料報括來自先前已執行專案的成本、工作量和進度的資料，加上考慮不同規模和複雜度的調整資料。
再對
sg1進行總結，大致遵循的乙個步驟如下
:
sow
和使用者需求
->
頂層wbs
分解->
規模和複雜度估算
->
生命週期模型確定
->
估算引數確定
->
工作量和成本
sg 2:
開發專案計畫：要建立和維護專案計畫，並作為管理專案的基礎
sp2.1
建立預算和進度
sp2.2
標識專案風險
sp2.3
計畫資料的管理
sp2.4
計畫專案的資源
sp2.5
計畫所需的知識和技能
sp2.6
計畫專案相關人員的參與
sp2.7
建立專案計畫
在這裡我們要注意，
cmmi
裡面的pp
過程域和
pmbok
裡面的制定進度過程有些小的區別。
sg1的重點是專案範圍管理裡面內容，
sg2重點是專案時間管理內容，有乙個大的不同就是規模和工作量的估算是在
wbs一建立後就可以開始的工作，而不是要先進度活動定義和排序後再開始。
從sg2
內容可以看到
pp專案計畫強調的內容仍然是乙個專案綜合計畫的內容，
sp2.2
涉及到初步的風險管理計畫制定，
sp2.3
涉及到資料管理計畫；
sp2.4
涉及到人力資源計畫，
sp2.5
涉及到培訓計畫等。到了
ipm整合專案管理後更加強調了整合計畫，會再增加入質量保證計畫、配置管理計畫，測試計畫等。
sp2.1+sp2.4
基本就涵蓋了
pmbok
中時間管理過程組的所有內容。最終的目的仍然是要有乙個進度表出來，這個進度表考慮了活動間的依賴關係，每個活動的複雜度和持續時間，關鍵路徑，資源的分配和平衡等各個方面的內容。在這個過程中我們看到關於活動和任務的所有屬性基本上都得到了確定了完善，包括任務的依賴關係，開始和結束時間，分配的資源，輸入，產出定義。
sp2.1
還有個重要內容就是要確定專案的重要里程碑，里程碑的乙個重點是來保證度量的準確性，另外就是在里程碑點的時候我們要及時的檢查計畫和實際執行的偏差情況，當偏差超出了某乙個範圍的時候就要考慮是否採取相應的糾正措施。
在**有專門的
rskm
風險管理過程域，**的風險管理更加強調了組織級的風險管理流程和風險引數的定義，組織級的歷史風險庫等內容。在二級
pp裡面的風險管理一般做到能夠能夠識別風險，優先順序排序和文件化排序，並沒有對文件的分析方法，風險的應對和跟蹤過多的進行要求。
注意sp2.4
可能是在專案一開始的時候就確定的，也可能是我們更多強調的進度和質量要求，對於資源的投入沒有明確的要求。但是要注意的是能夠排進度計畫的時候資源和資源的分配都應該是基本確定的了。在
sp2.4
的子實踐中也強調了，專案的人員配置取決於為完成專案需求而將專案需求分解為在
wbs工作包內任務、角色、職責的分配。人員配置需求應該考慮每個已標識職位要求的知識和技能
(像在計畫需要的知識和技能特有實踐中定義的)。
在專案計畫中要計畫專案需要的知識和技能，評估當前專案成員是否具備這些技能，如果沒有達到則需要安排相應的培訓進行學習或者避免使用一些新技術。這也是乙個風險管理的過程。在二級這個工作主要是在專案層面進行的，在專案是可重複的，到了**後提公升到組織層面，有專門的
ot過程域進行對應。
我們都知道干係人分析和管理是專案管理的乙個重要內容，在專案計畫階段我們需要識別專案干係人，分析專案各個階段活動和干係人之間的關係，知道專案干係人對專案的影響以平衡干係人的期望。對於
sp2.6
可行的乙個方法是通過標識專案中人員和功能需要代表的型別來標識專案生命週期所有階段的專案相關人員，並描述他們的相關性和在特定專案活動的互動程度。用兩維矩陣來描述，乙個軸是專案相關人員，另乙個軸是專案活動，這是實現這種標識的方便的格式。
有了以上活動後，最終就是要形成乙個整體的專案計畫。專案計畫的意思就是到了專案執行階段後所有的活動都是事先有所計畫進行的，而不是太多的臨時任務。為專案產生的計畫確定了所有方面的工作：專案生命週期考慮；技術和管理任務；預算和進度；里程碑；資料管理；風險標識；資源和技能需求；專案相關人員的標識和互動。基礎設施的描述包括專案人員、管理和支援組織的職責和授權關係。
sg 3:
獲得對計畫的承諾：要建立和維護對專案計畫的承諾
sp3.1
評審專案的附屬計畫
sp3.2
協調工作和資源
sp3.3
獲得計畫的承諾 對應
sg3主要說明專案計畫指定完成後，必須得到專案識別的所有干係人對計畫的承諾。而要獲取計畫承諾的乙個重要方式就是對專案計畫進行評審，包括專案的附屬計畫。當出現了相關干係人利益衝突的時候，需要考慮平衡和對計畫進行調整。
相關的通用實踐和
pp過程域的關係
gp 2.2:
制訂活動的計畫
(做專案計畫前要先有計畫的計畫)
gp 2.3:
提供資源
(提供進行專案計畫活動的資源，你制定專案計畫需要哪些資源參與)
gp 2.4:
明確職責
gp 2.5:
培訓員工
(員工知道如何做計畫，估算的方法和原理，風險識別方法等)
gp 2.6:
管理配置
(計畫活動的內容是受控的)
gp 2.7:
識別和爭取相關干係人的參與(和
sp2.6
的區別?)
gp 2.8:
對活動進行監控
(對計畫活動進行監控)
**對pp
專案計畫的一些要求
根據組織標準過程進行過程定義和裁剪，首先要先選擇生命週期模型
在專案計畫中要有風險管理計畫，能定性分析風險，對關鍵風險有緩解措施的制定
專案的估算引數**於組織級的基線資料，但是專案可以根據需要進行調整
專案計畫是整合計畫，要考慮和質量保證計畫，配置管理計畫，測試計畫等配合和整合
專案計畫有了組織提供的標準規程和模板形成的最佳實踐，制定專案計畫時候要遵循
四級對pp專案計畫的一些要求
通過專案歷史資料已經分析了專案自身哪些過程或子過程是穩定的。
根據業務和客戶的目標在專案計畫中要確定專案的哪些子過程要進行量化管理。
確定要量化管理的子過程採取的方法，工具和技術。
通過組織提供的
ppm對專案的目標進行量化的預算，如工作量，週期和缺陷情況等。
對風險管理進行了量化，比如引入蒙特卡洛方法對風險分析進行了量化。
根據總的質量目標分析和定義了可量化的過程效能指標
(目標值，控制上下限)
CMMI過程域 PP專案計畫
sg 1 建立估計計畫 要建立和維護專案計畫引數的估計資料 專案範圍的估計可以通過建立頂層wbs分解，wbs分解一般是面向產品結構，需要分解到工作包這個層次。由於wbs面向產品結構，使我們容易遺忘在wbs分解中包括風險緩解，配置管理，整合，培訓，非開發管理等任務。我們仍然強調的是wbs加上工作包的描...
論 CMMI專案策劃方法 PP
一 建立專案策劃方針和過程 1.建立方針 在我們的組織過程方針中，對專案策劃方針進行了描述。二 策劃專案策劃的活動 5.明確人員職責 組織的團隊建設指南中，明確了專案參與人員角色的職責 專案主計畫中描述了專案參與人員 角色職責和任務。6.進行培訓 參加了組織過程的培訓，其中包含了專案策劃過程。三 執...
CMMI的級別和CMMI的過程域
cmmi全稱是capability maturity model integration，即軟體能力成熟度模型整合模型。分為如下5個級別 1 初始級 軟體過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，成功取決於個人努力。管理是反應式的。2 可重複級 建立了基本的專案管理過程來跟蹤費用 進度和功...