軟件項目的復雜性就在于這幾個因素間基本都沒有簡單的線性關系可尋。在項目過程不成熟或積累的歷史數(shù)據(jù)不夠的時候，慎用直接估算規(guī)模的方法，因此及時估算了規(guī)模也不清楚團隊的實際生產率情況，無法根據(jù)規(guī)模推出具體的工作量。在這種情況下一般可以直接估算工作量，在項目進度跟蹤過程中再收集產出物的規(guī)模數(shù)據(jù)以積累歷史數(shù)據(jù)，方便后期建立相關的預測模型。
功能點和代碼行是可采用的規(guī)模數(shù)據(jù)，但采用代碼行時候往往無法區(qū)分不同的代碼類型本身往往具有不同的復雜度，對于邏輯層實現(xiàn)算法的代碼和UI層實現(xiàn)簡單完整性代碼，雖然可能相同的代碼行，但其復雜度不同將直接導致工作量的不同。對于任意一個功能點的開發(fā)基本都會涉及到DB，邏輯層和UI代碼，因此可以給出一個綜合的代碼生產率數(shù)據(jù)，然后根據(jù)該數(shù)據(jù)到計算工作量。
當新項目的規(guī)模比歷史項目規(guī)模大幾倍的時候，往往工作量會成指數(shù)級增長，在這種情況下要謹慎采用原來的線性比率關系?？梢越梃bCocomo模型來估算項目的工作量和項目工期。當預計出項目工作量人月后，最好能夠根據(jù)歷史經驗和模型來預測在不考慮人力資源限制情況下項目可以完成的最短周期。雖然這個時候還沒有考慮活動任務排序和資源約束，但基本可以得出一個經驗數(shù)據(jù)。
WBS分解和估算的關系
項目在做詳細估算的時候往往項目周期已經確定，因此為了可以滿足進度WBS的分解粒度和進度的安排就至關重要了。 比如在開發(fā)階段現(xiàn)在有四個人可以進行并行開發(fā)，這個時候WBS最好能細化出四個可以并行的任務，當發(fā)現(xiàn)預排的進度無法滿足要求的時候，需要再投入4個人，這個時候就需要WBS進一步分解以滿足8 個人能夠同時進入并行開發(fā)。當WBS分解導致后期集成工作量超過并行節(jié)約的時間時候，基本就到了進度能夠壓縮的極限。所以WBS和估算沒有完全的先后關系，分解后進行估算，在估算過程中又在調整和分解WBS。
當項目人力資源很固定的時候，WBS分解更需要按現(xiàn)有人力資源情況進行考慮和分解，這個時候分解的粒度最好和項目可用人力資源匹配。總體原則仍然是前緊后松，讓項目人力資源在項目一開始就能夠完全動起來，而不是要漫長的等待前續(xù)工件和任務。
當考慮了人力資源仍然無法滿足進度要求的時候，需要考慮我們采用的方法論，如是否可用增量迭代的方法替換瀑布模型，如果可以則需要完全根據(jù)增量迭代思路重新分解WBS，對于采用不同生命周期模型情況下WBS往往存在較大的差異。
當以上仍然無法滿足進度要求的時候，我們可以考慮對過程進行裁剪，重點保證對產品質量又重大影響的核心過程元素。當進行過程裁剪仍然無法滿足的時候，你需要考慮的是人的因素，去尋找開發(fā)生產率比一般人高5倍以上的開發(fā)高手，而不是在明知WBS無法細分的情況下繼續(xù)往項目里面投人。
估算方法
在項目沒有太多積累情況下，依賴專家去估算往往是最有效的方法。專家估算是一種沒有紙面化的Bottom-Up估算方法，因此專家法估算的準確度往往是比簡單的類別估算準確度高的。采用三點法估算的計劃評審技術仍然是專家法的一種，這種方式的估算可以讓我們更加清楚項目進度的一個范圍值。
功能點法是一種經過實踐驗證的方法，但應用成本很高，估算的工作量投入也較大。功能點法最終結果是規(guī)模，仍然需要知道項目的生產率數(shù)據(jù)才能得出實際的工作量。另外功能點法估算的結果無法直接和WBS分解的工作包和具體的任務對應起來，這是一個較難解決的問題。
Cocomo估算是一種關于軟件成本估算的方法，但僅給出一個可行的模型，項目沒有足夠多的歷史數(shù)據(jù)根本無法確定出各調整因子和系數(shù)。但一旦項目建立起這種模型，則通過Cocomo模型得出的項目工作量和
項目周期具有更高的準確度。
觀察歷史項目中工作量和項目規(guī)模的數(shù)據(jù)，通過回歸擬合可以得出生產率，工作量，生產率三者間的參數(shù)模型，這個參數(shù)模型可以用來我們通過軟件項目的規(guī)模來預測實際的工作量。
估算的科學和藝術
估算模型是科學，專家經驗是藝術
估算過程是科學，靈活調整是藝術
參數(shù)模型是科學，個體影響是藝術
過程定義是科學，過程裁剪是藝術