從表一中可以看出，模塊的代碼行越長，開發(fā)周期越長，對同一開發(fā)工具而言基本是一個線形關(guān)系，但其中也要考慮代碼重用問題，比如一個模塊代碼很長，但是可能包含了很多公用函數(shù)，那么在估算時應適當減少代碼行數(shù)量，表中會議管理是個例子，這個模塊的代碼行超過一萬行，但其中公共函數(shù)很多，去除此因素，真正的代碼行在9000行左右。

　　表二是軟件項目的實際開發(fā)周期(不考慮系統(tǒng)實施)，從普通意義上說軟件項目中包含的功能模塊越多、越復雜，或者說軟件越大開發(fā)周期增長的越快，這個時間絕不是模塊開發(fā)時間的簡單疊加，因為模塊功能數(shù)量的增加直接帶來了軟模塊間相互關(guān)聯(lián)度、復雜度的成倍增加，這直接導致了在需求、設計等階段需要花費更多的時間，這比單獨考慮一個模塊復雜的多。在表二中隨著模塊數(shù)量增加，開發(fā)周期增加不是特別明顯，這是因為產(chǎn)品化程度高所引起的，由于相當數(shù)量的模塊可以完全重用，實際開發(fā)量大大減少，后一個例子完全重新開發(fā)，開發(fā)周期長的多。

　　在實際進行軟件開發(fā)周期估算的時候，軟件規(guī)�？隙ㄊ鞘紫瓤紤]的因素，根據(jù)我們上面所討論的情況，在考慮軟件規(guī)模時一定要去除可重用的部分，由于當今軟件在設計上很重視這點，所以這部分會占相當?shù)谋戎亍Ａ硗廛浖�功能之間的關(guān)聯(lián)所造成的復雜性必須足夠重視，這樣在估算上不會產(chǎn)生重大偏差。

3.2估算與項目風險

　　任何一個項目都或多或少存在風險，軟件項目開發(fā)過程中也避免不了這種情況而且有這類項目自己的特點，常見的風險有以下幾種：技術(shù)風險，項目技術(shù)難度很大，花費的時間超過原先的估計;客戶風險，客戶需求不定，增加需求，組織協(xié)調(diào)不暢;人員風險，開發(fā)人員突然更換、離職;管理風險，項目經(jīng)理管理不善、決策失誤。對于風險控制，在項目管理中通常是提前做風險分析和預測，制定風險應對措施，這樣在風險真的來臨時不至于措手不及，提高整個項目的可控性。

　　軟件項目的潛在風險對于開發(fā)周期的影響在很多情況下是非常大的，當然好的項目控制會大限度的減少這種影響，避免是不可能的，所以在開發(fā)周期估算時項目風險應該適當考慮，尤其是技術(shù)風險和客戶風險。

　　技術(shù)風險主要來自于軟件本身的技術(shù)難度，如果對于一套成熟的產(chǎn)品，定制開發(fā)的技術(shù)風險相對非常小，因為重要的技術(shù)已經(jīng)成型，客戶也很少有新的能帶來高難度技術(shù)問題的需求，這種風險可以不予考慮。但是對于完全重新開發(fā)的項目，或是研發(fā)類的項目，技術(shù)風險必須特別重視，其中應該考慮的細節(jié)主要包括下面幾個。

　　開發(fā)平臺，是否能適合本項目所涉及的軟件開發(fā)、能否滿足終的需求，平臺的錯誤選擇將導致龐大的開發(fā)工作量，即便滿足了用戶需求也可能造成系統(tǒng)效率低下，擴展性差的致命問題，軟件可能會很快被淘汰。功能實現(xiàn)難度，在切實了解需求的基礎上要仔細分析采用的開發(fā)工具能否實現(xiàn)其中的難點，是否會耗費大量時間。

　　在實際估算中，建議技術(shù)難度分為十級，每一級在初次估算的代碼行上增加10%，終估算代碼長度=初始估算代碼長度×(1+0.1×n)。假設模塊A的初次估計代碼行為15000行，但考慮技術(shù)難度高的風險，設定技術(shù)難度級別為二級，終代碼行的估算數(shù)量為15000X(1+20%)=18000。

　　由于技術(shù)風險的分析是一項技術(shù)性很強的工作，要求做技術(shù)風險分析的人必須是技術(shù)專家，在相關(guān)技術(shù)領域有著豐富的經(jīng)驗，對重大技術(shù)風險的分析結(jié)果必須要經(jīng)過評審，保證準確性。

　　客戶風險存在于客戶化項目中，不同行業(yè)的客戶特點不盡相同，技術(shù)、理解水平也相差甚遠，在我經(jīng)歷開發(fā)的項目中，80%的項目延期屬于客戶方的原因，而且這種風險可控性很低，對項目影響超過技術(shù)風險。在開發(fā)周期估算前，項目經(jīng)理要仔細分析客戶的具體狀況，包括客戶的計算機水平、管理水平、可溝通程度，在此基礎上結(jié)合以往的經(jīng)驗綜合判斷是否會對開發(fā)帶來明顯的影響，可以按照上述的技術(shù)風險的方式將客戶分級，終確定開發(fā)周期。在這個過程中，項目經(jīng)理的經(jīng)驗極其重要，對客戶的分析基本上要依賴經(jīng)驗做判斷，要求管理人員有大量的客戶經(jīng)驗和行業(yè)分析能力。

3.3估算與人力資源

　　對于軟件開發(fā)項目來說，人力資源是核心力量，因為軟件開發(fā)不同于其它類型的項目，除了電腦它不需要利用其它工具，終結(jié)果的產(chǎn)生完全取決于人腦中的知識，這也是知識經(jīng)濟的大特點。

　　人力資源對估算的影響表現(xiàn)在技術(shù)水平、理解能力、溝通能力等幾個方面，編程水平的高低、速度的快慢、能否適應團隊、能否與各成員保持良好的溝通都會對開發(fā)進度產(chǎn)生影響，其中技術(shù)水平是關(guān)鍵的因素。評價程序員的技術(shù)水平可以從編程熟練程度、編程速度、解決技術(shù)問題的能力幾個因素考慮，編程熟練程度指的是程序員能否很順暢的使用編程工具實現(xiàn)軟件的功能，編程速度指的是完成某個功能的時間，解決技術(shù)問題的能力可以反映程序員在遇到技術(shù)難點時表現(xiàn)出的技術(shù)功底，如果以作為總和，這三個因素分別占70%、15%和15%這樣的比例。

　　軟件開發(fā)周期估算前，應對開發(fā)人員定級，建議按新手、初級程序員、中級程序員、高級程序員來劃分，每一級人員再評定上述三個因素，初次估算時可以假定開發(fā)人員為中級程序員，然后依據(jù)項目組實際人員的水平做修正，這樣結(jié)果的精確度能大大提高。

4. 歷史數(shù)據(jù)估算法的運用

　　依據(jù)歷史數(shù)據(jù)估算軟件開發(fā)周期是一種比較常見的方法，這種方法以歷史軟件開發(fā)周期為依據(jù)，在估算時把當前軟件項目的情況與歷史數(shù)據(jù)加以對比，從而得出終結(jié)果。按照歷史數(shù)據(jù)估算開發(fā)周期準確度還是相當高的，但這種方法只適用于對某類軟件的開發(fā)，比如某個行業(yè)業(yè)務系統(tǒng)的開發(fā)，當要估算的軟件與歷史軟件相差太多，比如開發(fā)工具完全不同，或者類型完全不同，不能再依賴這種方法，起碼應該輔助使用其它估算法。如果沒有歷史數(shù)據(jù)或是開發(fā)一種新領域軟件，可以使用代碼行或功能點估算法，在此基礎上再通過其它方法校正。

　　事實上目前項目管理人員對開發(fā)周期的估算大部分屬于人力時間估算法，憑借的是自己的經(jīng)驗，經(jīng)驗越多估算的結(jié)果越精確，但是大部分項目管理人員對以前很有價值的歷史數(shù)據(jù)缺乏歸納整理，估算的時候憑借感覺的成分多一些，所以精確度相對要低很多，所以要求我們的項目管理人員不僅要有大量軟件開發(fā)的經(jīng)驗還要不斷總結(jié)積累，歷史項目數(shù)據(jù)對于以后軟件開發(fā)周期的估算是非常有價值的。

　　在實際使用歷史數(shù)據(jù)估算法時，建議項目經(jīng)理建立一個歷史項目數(shù)據(jù)庫，在庫中包含以前所有項目的開發(fā)周期、項目規(guī)模、開發(fā)人員狀況、客戶狀況等詳細數(shù)據(jù)，當估算時根據(jù)當前項目的狀況在庫中尋找類似的歷史項目，然后再比較兩個項目之間在項目規(guī)模、項目風險、人力資源之間的區(qū)別，我們假定歷史項目開發(fā)周期為A當前項目的周期可以依據(jù)下列公式得出

B=A×(2×S+R+P+2×C)/6

S：代表軟件規(guī)模 R：代表風險 P：代表人力資源 C：代表客戶

以上值均指當前項目與歷史項目的比率。

　　實際的比較因素應該不止這些，但軟件規(guī)模、風險、人力資源及客戶狀況是其中重要的，對軟件開發(fā)的影響也大，所以這個公式中只考慮了這些因素。其中軟件規(guī)模和客戶兩項占的權(quán)重大，這也是根據(jù)項目管理經(jīng)驗得出的，在實際使用歷史數(shù)據(jù)估算法時還可以靈活加入其它因素。