項目的目標和范圍確定后，需要開始確定項目的過程，項目整個過程中采用何種生命周期模型？項目過程是否需要對組織級定義的標準過程進行裁剪等相關內容。項目過程定義是進行WBS分解前必須確定的一個環(huán)節(jié)，你采用瀑布模型和增量迭代模型對WBS分解和進度計劃安排顯然是完全不同的。

　　項目過程確認清楚后開始進行項目的WBS分解，WBS分解一般是項目組的核心成員參加，但項目經理應該是起主導和協(xié)調作用。WBS分解方法一般有基于過程和基于成功兩種方式，但兩種方式可以混合使用，比如在高層分解的時候先分解出子系統(tǒng)和工作包，在底層的時候再按照需求，設計，編碼和測試各個過程進行分解。WBS的最底層工作單元需要是可以獨立核實的產品，需要去下達計劃和任務，工作單元需要有明確的責任人，因此有時候在沒有做仔細的估算時候我們很難讓工作單元滿足這些要求，這樣就難免在進行估算過程中還要對WBS進行優(yōu)化和調整。

　　WBS分解完成后可以開始進行工作單元的估算，估算一般有專家法，三點法和功能點法估算，由于我們的項目采用專家法估算，因此更需要項目核心成員和有經驗的成員參加，估算一般會針對工作單元的單位和復雜度進行估算，最后估算出項目的總規(guī)模，再除以項目的生產率后得到項目的工作量數(shù)據(jù)。專家法估算一般會進行很多輪，直到所有指標都收斂（收斂標準是組織或項目事先確定清楚了，如偏差<30%就算收斂）。

　　對于一個軟件項目而言，我們用專家法估算其實很難估算出具體的各個功能編碼的代碼行數(shù)據(jù)和編碼的具體工作量，所以這里是需要使用項目的歷史經驗數(shù)據(jù)，即你在做歷史項目的時候需求：設計：編碼工作量的比例究竟是如何的？然后根據(jù)估算得到的需求階段工作量數(shù)據(jù)去推算出設計和開發(fā)的估算工作量。所以從這點上也可以看出為何軟件項目度量和分析很重要，因為你做的度量和分析數(shù)據(jù)都會作為你后續(xù)項目的重要依據(jù)。很多項目老說軟件估算很不準，原因就在于你沒有你自己項目的歷史經驗數(shù)據(jù)的積累。

　　在估算數(shù)據(jù)出來后，可以使用Project工具安排整個項目的進度計劃，在項目進度計劃安排中的兩個重要內容就是關鍵人力資源的確定和關鍵路徑的確定。在這兩個因素確認清楚后要排出整個項目的進度計劃就很簡單了。對于項目關鍵人力資源確定一般可以采用工作單元->人員的責任矩陣進行分析，對于關鍵路徑一般直接用運籌學中的關鍵路徑分析法確定ES，EF，LE和LF四個時間即可

　　在項目進度計劃基本排出來后就可以規(guī)劃和確定項目的里程碑和基線了，項目的里程碑和基線是項目重要的跟蹤控制檢查點，在里程碑項目還會做專門的里程碑報告，對項目的當前狀態(tài)，項目的進度，工作量，規(guī)模，缺陷等各項指標的偏離進行分析。

　　整個項目進度計劃基本出來后需要和項目組的所有項目成員確認，獲取項目的內部承諾，項目成員應該對整個進度計劃安排基本達成一致。項目計劃還有需要支持計劃需要制定，項目進度計劃出來后整個可以通知QA和配置管理員分別制定質量保證計劃和配置管理計劃，項目經理協(xié)助測試負責人制定項目的系統(tǒng)測試計劃。

建設工程教育網整理