引言

      前兩天一個朋友給我打電話，問我如何估計項目開發時間。對此我很詫異，問他以前他們是怎么估計的，他說以前基本都是大家開個會，大約都說說自己意見，最后負責人一拍腦袋，給出一個時間。不過這次遇到一個非常認真的客戶，要求不但要估計出項目開發時間，還要明確說明具體的依據和估算方法，這下我這朋友有點犯難，才詢問我。后來我翻閱了一些數理統計和項目估算方面的資料，告訴了他利用一元線性回歸分析估計軟件項目開發時間的方法。想到這種估算需要在一些開發團隊很常見，所以在這里整理成文。

　　問題的定義及數學模型

      這里我們僅考慮比較簡單的一元回歸問題，即通過單一的Proxy預測項目開發時間。這里先說一下什么叫Proxy。Proxy叫做代理變量，簡單來說就是估計項目開發時間的數理依據。說白了，就是我們預測開發時間，總要有個根據，例如需求中用例個數、概要設計中的實體個數、數據庫中的表的數量等等。

　　設Proxy為x，項目開發時間為y，那么可以得到y=f(x)，學過初等數學的都可以看懂，就是說開發時間是Proxy的一個函數，如果我們既知道了新項目的x，又知道函數f，那么y就出來了。可惜天下哪有這么好的事，我們現在既不知道f，又不知道x，別說x的值了，甚至我們都不知道該用哪個Proxy做x。

      不過也不必悲觀，經過上面分析，我們至少明確了我們奮斗的方向：

• 找出候選的Proxy。
• 選擇最合適的Proxy作為x。
• 得到x的值。
• 確定函數f。
• 得出y。

      下面我們一步一步解決各個問題。

　　找出候選的Proxy

      雖然一個項目的特征量很多，不過可不是隨便一個特征量都可以當做Proxy的。要成為Proxy，至少要滿足如下四個條件。

      1）Proxy的值應該和工作量緊密相關。

      這個不用多解釋了吧，就是說Proxy的值和y的值要有相關性。關于“相關性”的概念這里先定性說一下，定量分析后續會講到。

      2）Proxy應該是能明確得出值的，沒有二義性。

      這是說Proxy應該對應一個明確數值，是一就是一，是二就是二，不能取“不錯”、“挺多”這種值。

      3）Proxy應該在項目開始階段可以得出或能較精確估計出。

      這個開始階段最晚不能晚于概要設計，因為估算都是一開始進行，所以Proxy一定要在起始階段就能得出，否則項目結束了誰還搞估算，實際值都出來了。

      4）Proxy對于不同的實施方案是敏感的。

      就是說當開發方法、開發過程等因素變化時，Proxy應該具有一定的敏感性。

      經過上述分析，我想選用什么作為Proxy大家心里都有點譜了。一般來說，在估算時常被作為Proxy的有需求分析中用例數量、需求分析中功能模塊數量、概要設計中實體數量和數據庫設計中表的數量。當然，各位也可以根據上述要求選擇自己的Proxy。在本文中，我們暫且選擇用例數量、實體數量和表數量三個Proxy作為候選。

　　選擇最合適的Proxy作為x

      這里所謂的“最合適”，在數學上的意義就是和開發時間y的相關性最強。那么什么是相關性呢，從直觀意義上，兩個變量的相關性是指兩個變量關聯的緊密程度，數學上可以用相關系數表示。相關系數計算公式如下：

      至于這個公式為什么能反映出兩個變量的相關性，可以去參考高等數理統計相關資料，本文不再贅述，只是順便說一下，r的范圍在-1~1之間，絕對值越大代表相關性越強，如果為正值則表示兩個變量正相關，否則為負相關。知道了這個，我們這一步驟的目的就是找出候選Proxy中與y相關系數最大的作為x。

      不過，這數據從哪里來呢？這就要從以前做過的項目中提取了。查閱朋友所在團隊最近做過的5個項目的數據資料（這里當然歷史項目越多越好，不過筆者這個朋友的團隊只有5個項目的記錄），得到如下數據：

      項目工期（y）：     424     267     90     331     160     （人時）

      用例數量（x1）：   37       20       6       18       12

      實體數量（x2）：   15       9         4       11       14

      數據表數量（x3）： 25      18       7       16       18

      下面就是計算各個相關系數了，計算相關系數是一項機械且乏味的活動，一般都會交由相應的工具去完成。不過您要是感興趣，也可以自己代入上述公式手算。下圖是我用Excel計算的結果：

      圖1

      一般來說，|r|大于0.7就有很好的相關性了，而從計算結果可以看出，用例數量x1和工期y的相關系數達到0.93，最為優秀，而數據表數量x3也達到0.83，唯有實體數量x2的相關系數僅為0.65，質量較差。因為|r(x2,y)|<0.7，所以這里首先排除掉。

      到了這里似乎我們可以順利成章選擇x1作為最終Proxy，但是還有一點要考慮，就是顯著性。所謂顯著性就是在偶然情況下得到此結果的概率，如果顯著性不足，說明這個結果不可靠。顯著性t值的計算公式如下：

      因為n=5，這里自由度為3，然后查詢t分布表，得到95%預測區間為3.182。因為一般顯著性<0.05則認為顯著性較好，所以如果t的值大于3.182，我們則可以接受。不過如果使用工具的話，一般可以用t檢測直接得出顯著性，這里我用Excel得到r(x1,y)的顯著性為0.006，r(x3,y)的顯著性為0.007（如圖2所示），都遠小于0.05，顯著性均非常好。所以根據擇優錄取原則，我們選擇x1：需求文檔中用例數量作為預測Proxy。

圖2

　　得到x的值

      在上文中，我們通過相關性和顯著性分析，最終決定使用需求文檔中的用例數量作為x。下面就是要確定x的值，這個不必多說，直接從需求文檔中得到相應的數量即可。

　　確定相關函數f

      知道了x的值，下面就是要確定相關函數了。這一步是最艱難也是最有技術性的，因為相關函數不但和數理因素相關，還與開發團隊、團隊中的人以及管理方法有關。如果人員變動很大或管理方法做了很大的調整，歷史數據可能就不具備參考價值了。不過如果團隊的開發水平和管理方法沒有重大變動，這個函數還是相對穩定的。

      在函數選型上，一般會選擇線性函數，當然我個人對此是十分懷疑的，但是這里為了簡單起見，我們姑且照例使用線性函數作為預測模型。這樣可以建立一元線性回歸模型如下：

      這個函數并不是簡單的線性函數，而是包含了一個隨機變量ε，這是一個服從正態分布的隨機變量。上述模型的直觀意義可以如下描述：a代表與x即用例數量無關的起始時間，b代表每一個用例所耗費的平均時間，而ε代表開發中的不確定性。在不同的團隊中或不同的管理方法下，a,b和ε都是不一樣的，但是當團隊和管理方法相對穩定，可以認為a,b和ε是可通過歷史數據估計的。而因為ε的期望為0，所以只要給出a和b的合理估計，就可以得到y的一個無偏估計。

      下面我們估計a和b的值。估計方法有很多，如曲線擬合法或最小二乘法。這里我們采用最小二乘法進行估計。

      最小二乘法估計的基本原理如下：

      求極值可以使用微積分中的求極值方法，首先令Q(a,b)對a和b分別求偏導，并令偏導為零，得如下方程組：

      經過一系列計算和推導，最終可得到:

      將以前的歷史數據代入上述方程，就可以得到a和b的最小二乘估計。同樣，這種機械而乏味的計算一般交由工具去完成。我用Excel得到a和b的估計分別為56.251和10.653。Excel分析結果如圖3所示：

圖3

      根據估計結果，我們可以得出相關函數為y=56.251+10.653。我們還可以證明，這個估計是一致最小方差無偏估計，證明過程從略。

      現在我們不但得到了相關函數，還得到了如下有用的數據結果：這個團隊在目前的管理模式下，開發一個項目平均準備時間為56.251人時，而平均每個用例開發耗時為10.653人時。

　　得出y

      有了上面的結果，我們可以很輕易得出新項目的計劃工時。例如新項目有50個用例，代入可以得到y=56.251+10.653*50=588.901，約為589個人時，再假設團隊中有3個開發人員，平均每周工作五天，每天工作8小時，就可以得到項目大約需要開發24.54個人日，開發周期約為5周。

　　后面的話

      至此我們已經完成了利用一元線性回歸模型對軟件工期的估計。但是不得不承認，這個估計方法存在很多缺陷，如估計變量單一以及估計模型過于簡單等等。實驗證明，這種一元線性模型對中小型項目相對有效，如果團隊比較大并且項目十分復雜，估計效果就不理想了。

　　不過這篇文章給出了一種思路，就是如何利用數理統計模型以及歷史經驗數據來估計新項目的工期。對于文中的具體方法則可以進行諸多擴展，例如使用多個估計代理進行多元回歸分析、細化估計方法等等。

　　例如PSP中就給出一種非常精細的PROBE估計法，有興趣的朋友可以參考。另外，除了求得估計值，還可以給出估值置信區間，甚至使用蒙特卡洛模擬技術進行更復雜的分析，都可以得到更理想的估值。但是其核心思想與本文是相通的。

　　聯系作者