怎樣估算軟體專案週期-程式碼行估演算法

專案是指以一定的成本在一定時間內取得預期收益的系列活動。專案的“生命期”是管理專案的重要指標，而對專案週期的估算則是管理專案的重要一環。本期“專案管理”介紹對軟體專案週期進行估算的技巧。

　　估算是軟體開發中很重要的一個環節：專案週期估算過短會造成人力低估、成本預算低估、日程安排過短，最終人力資源耗盡，成本超出預算，為完成專案不得不趕工，影響專案質量，甚至導致專案失敗；專案週期估計過長表面看來影響不大，但是實際上也會帶來成本估計過高、充分效率低下的後果。週期估算如同蓋樓房中打地基，是後續工作的基礎，它的影響會貫穿整個專案。

　　但軟體開發是一項非常複雜的工程，不僅包含需求分析、設計、編碼、測試、實施、維護等不同的子過程，還涉及到開發工具、開發人員、專案管理、風險等眾多因素，不同因素對估算產生的影響不盡相同。在進行軟體估算時（包括利用工具輔助估算）必須考慮到這些方面，否則估算結果就會和實際結果有很大的偏差。下面，我們對幾個常見的因素做一些探討。

軟體規模是專案估算的基礎

　　軟體規模通常指的是軟體的大小，可以通過程式程式碼行的長度、功能函式的數量、資料庫中表的數量、資料庫的大小等要素來描述軟體規模。一般而言，軟體規模越大，所花費的開發週期就越長。但這並不是一個簡單的線性函式關係，也要考慮程式碼重用問題。比如一個模組程式碼很長，但是可能包含了很多公用函式，那麼在估算時就應適當減少程式碼行數量。

　　軟體專案中包含的功能模組越多、越複雜（或者說軟體越大），開發週期越長。這個時間絕不是模組開發時間的簡單疊加，因為模組功能數量的增加直接帶來了軟體模組間相互關聯度、複雜度的成倍增加，這導致了在需求、設計等階段需要花費更多的時間，比單獨考慮一個模組複雜得多。另一方面，對於產品化程度高的專案開發，隨著模組數量增加，開發週期的增加卻不是特別明顯。這是因為相當數量的模組可以完全重用，實際開發量大大減少。

　　所以，在實際進行軟體開發週期估算的時候，軟體規模肯定是首先考慮的因素。具體估算時，在考慮軟體規模時要去除可重用的部分。另外，軟體功能之間的關聯所造成的複雜性也必須足夠重視。

風險影響週期

　　任何一個專案都或多或少存在風險，軟體專案開發過程中也避免不了這種情況而且有自己的特點。最常見的風險來自於：技術、客戶、專案人員等方面。開發週期估算時專案風險應該適當考慮，尤其是技術風險和客戶風險——

技術風險 技術風險主要來自於軟體本身的技術難度。對於一套成熟的產品，定製開發的技術風險相對非常小，因為重要的技術已經成型，客戶也很少有新的、能帶來高難度技術問題的需求，這種風險較小。但是對於完全重新開發的專案，或是研發類的專案，技術風險必須特別重視。以開發平臺為例，開發平臺必須適合本專案所涉及的軟體開發、滿足最終的需求，平臺的錯誤選擇將導致龐大的開發工作量，即便滿足了使用者需求也可能造成系統效率低下、擴充套件性差的致命問題，軟體可能會很快被淘汰。

　　在實際估算中，建議將技術難度分為十級，每一級在初次估算的程式碼行上增加10%，

　　最終估算程式碼長度=初始估算程式碼長度×(1+0.1×n)

　　假設模組A的初次估計程式碼行為15000行，但考慮技術難度高的風險，設定技術難度級別為二級，最終程式碼行的估算數量為15000×(1+20%)=18000。

　　由於技術風險的分析是一項技術性很強的工作，要求做技術風險分析的人必須是技術專家，在相關技術領域有著豐富的經驗。對重大技術風險的分析結果必須要經過評審，保證準確性。

客戶風險 客戶風險存在於客戶化專案中，客戶行業特點不盡相同，技術、理解水平也相差甚遠。在我經歷開發的專案中，80%的專案延期是由於客戶方的原因，而且這種風險可控性很低，對專案影響超過技術風險。

　　在開發週期估算前，專案經理要仔細分析客戶的具體狀況，包括客戶方的計算機水平、管理水平、可溝通程度，在此基礎上結合以往的經驗綜合判斷是否會對開發帶來明顯的影響，可以按照上述的技術風險的方式將客戶分級，最終確定開發週期。在這個過程中，專案經理的經驗極其重要，對客戶的分析基本上要依賴經驗做判斷，要求管理人員有大量的客戶經驗和行業分析能力。

專案團隊影響速度

　　對於軟體開發專案來說，人力資源是核心力量。人力資源對估算的影響表現在技術水平、理解能力、溝通能力等幾個方面。專案技術人員程式設計水平、工作效率、團隊適應性、溝通能力等素質，都會對開發進度產生影響，其中技術水平是最關鍵的因素。評價程式設計師的技術水平可以從程式設計熟練程度、程式設計速度、解決技術問題的能力等幾個因素考慮：程式設計熟練程度指的是程式設計師使用程式設計工具實現軟體的功能的熟悉程度；程式設計速度指的是完成某個功能的速度；解決技術問題的能力可以反映程式設計師的技術功底—如果以100%作為總和，這三個因素分別佔的合適比例為70%、15%和15%。

　　軟體開發週期估算前，應對開發人員定級，建議按新手、初級程式設計師、中級程式設計師、高階程式設計師來劃分，每一級人員再評定上述三個因素。初次估算時可以假定開發人員為中級程式設計師，然後依據專案組實際人員的水平做修正，這樣結果的準確度能大大提高。

寶貴的經驗

　　依據歷史資料估算軟體開發週期是一種比較常見的方法，這種方法以歷史軟體開發週期為依據，在估算時把當前軟體專案的情況與歷史資料加以對比，從而得出最終結果。

　　按照歷史資料估算開發週期的準確度還是相當高的，但這種方法只適用於對某類軟體的開發，比如某個行業業務系統的開發。當要估算的軟體與歷史軟體相差太多，比如開發工具完全不同、或者專案型別完全不同，就不能再依賴這種方法，最起碼應該輔助使用其它估演算法。如果沒有歷史資料或是開發一種新領域軟體，可以使用程式碼行或功能點估演算法，在此基礎上再通過其它方法校正。

　　在實際使用歷史資料估演算法時，建議專案經理建立一個歷史專案資料庫。在庫中包含以前所有專案的開發週期、專案規模、開發人員狀況、客戶狀況等詳細資料。當估算時根據當前專案的狀況在庫中尋找最類似的歷史專案，然後再比較兩個專案之間在專案規模、專案風險、人力資源之間的區別，我們假定歷史專案開發週期為A，當前專案的週期可以依據下列公式得出：

　　估算專案週期 = A×(2×S+R+P+2×C)/6

　　S：代表軟體規模 R：代表風險 P：代表人力資源 C：代表客戶

　　（以上值均指當前專案與歷史專案的比率）

　　實際的比較因素應該不止這些，但軟體規模、風險、人力資源及客戶狀況是其中最重要的，對軟體開發的影響也最大，所以這個公式中只考慮了這些因素。其中軟體規模和客戶兩項佔的權重最大，這也是根據專案管理經驗得出的，在實際使用歷史資料估演算法時還可以靈活加入其它因素

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-621751/，如需轉載，請註明出處，否則將追究法律責任。