軟體專案計劃-估算雜談

規模，工作量，資源和工期

軟體專案的複雜性就在於這幾個因素間基本都沒有簡單的線性關係可尋。在專案過程不成熟或積累的歷史資料不夠的時候，慎用直接估算規模的 方法，因此及時估算 了規模也不清楚團隊的實際生產率情況，無法根據規模推出具體的工作量。在這種情況下一般可以直接估算工作量，在專案進度跟蹤過程中再收集產出物的規模資料 以積累歷史資料，方便後期建立相關的預測模型。

功能點和程式碼行是可採用的規模資料，但採用程式碼行時候往往無法區分不同的程式碼型別本身往往具有不同的複雜度，對於邏輯層實現演算法的程式碼 和UI層實現簡單完 整性程式碼，雖然可能相同的程式碼行，但其複雜度不同將直接導致工作量的不同。對於任意一個功能點的開發基本都會涉及到DB,邏輯層和UI程式碼，因此可以給出 一個綜合的程式碼生產率資料，然後根據該資料到計算工作量。

當新專案的規模比歷史專案規模大幾倍的時候，往往工作量會成指數級增長，在這種情況下要謹慎採用原來的線性比率關係。可以借鑑 Cocomo模型來估算專案 的工作量和專案工期。當預計出專案工作量人月後，最好能夠根據歷史經驗和模型來預測在不考慮人力資源限制情況下專案可以完成的最短週期。雖然這個時候還沒 有考慮活動任務排序和資源約束，但基本可以得出一個經驗資料。

WBS分解和估算的關係

專案在做詳細估算的時候往往專案週期已經確定，因此為了可以滿足進度WBS的分解粒度和進度的安排就至關重要了。比如在開發階段現在有 四個人可以進行並行 開發，這個時候WBS最好能細化出四個可以並行的任務,當發現預排的進度無法滿足要求的時候，需要再投入4個人，這個時候就需要WBS進一步分解以滿足8 個人能夠同時進入並行開發。當WBS分解導致後期整合工作量超過並行節約的時間時候，基本就到了進度能夠壓縮的極限。所以WBS和估算沒有完全的先後關 系，分解後進行估算，在估算過程中又在調整和分解WBS。

當專案人力資源很固定的時候，WBS分解更需要按現有人力資源情況進行考慮和分解，這個時候分解的粒度最好和專案可用人力資源匹配。總體原則仍然是前緊後鬆，讓專案人力資源在專案一開始就能夠完全動起來，而不是要漫長的等待前續工件和任務。

當考慮了人力資源仍然無法滿足進度要求的時候，需要考慮我們採用的方法論，如是否可用增量迭代的方法替換瀑布模型，如果可以則需要完全根據增量迭代思路重新分解WBS，對於採用不同生命週期模型情況下WBS往往存在較大的差異。

當以上仍然無法滿足進度要求的時候，我們可以考慮對過程進行裁剪，重點保證對產品質量又重大影響的核心過程元素。當進行過程裁剪仍然無 法滿足的時候，你需 要考慮的是人的因素，去尋找開發生產率比一般人高5倍以上的開發高手，而不是在明知WBS無法細分的情況下繼續往專案裡面投人。

估算方法

在專案沒有太多積累情況下，依賴專家去估算往往是最有效的方法。專家估算是一種沒有紙面化的Bottom-Up估算方法，因此專家法估 算的準確度往往是比 簡單的類別估算準確度高的。採用三點法估算的計劃評審技術仍然是專家法的一種，這種方式的估算可以讓我們更加清楚專案進度的一個範圍值。

功能點法是一種經過實踐驗證的方法，但應用成本很高，估算的工作量投入也較大。功能點法最終結果是規模，仍然需要知道專案的生產率資料才能得出實際的工作量。另外功能點法估算的結果無法直接和WBS分解的工作包和具體的任務對應起來，這是一個較難解決的問題。

Cocomo估算是一種關於軟體成本估算的方法，但僅給出一個可行的模型，專案沒有足夠多的歷史資料根本無法確定出各調整因子和係數。但一旦專案建立起這種模型，則通過Cocomo模型得出的專案工作量和專案週期具有更高的準確度。

觀察歷史專案中工作量和專案規模的資料，通過迴歸擬合可以得出生產率，工作量，生產率三者間的引數模型，這個引數模型可以用來我們通過軟體專案的規模來預測實際的工作量。

估算的科學和藝術

估算模型是科學，專家經驗是藝術

估算過程是科學，靈活調整是藝術

引數模型是科學，個體影響是藝術

過程定義是科學，過程裁剪是藝術