軟體專案的估算曆來是比較複雜的事，因為軟體本身的複雜性、歷史經驗的可重複性、估算工具的缺乏以及一些人為錯誤，都會導致軟體專案的估算往往和實際情況相差甚遠。據有關機構調查發現，約有60％的軟體專案的失敗是因為估算偏差引起的，而不是因為技術實力不夠。因此，估算偏差已被列為軟體專案失敗的四大原因之一。

從軟體工程學上，我們知道軟體需求和估算是軟體專案的基礎。因為只有準確的瞭解客戶的需求，以之為基礎，並使用科學的方法對目標軟體系統的規模、工作量和進度做出合理的估算，我們才能在預算內按時按質順利的完成專案。然而，軟體估算作為軟體專案的基礎領域卻常常被人們所忽視。我在近期的一個開發專案中就嚐到忽視軟體規模估算帶來的苦果，結果是專案進行到一半時就發現不但工期嚴重滯後於計劃，而且專案的各種資源也嚴重的不足和缺乏，專案被迫暫停下馬。

常見的專案規模估算失準原因

一直以來，軟體專案的規模估算（Size Estimation）是個爭論不休的問題。不論是對軟體開發團隊還是對軟體使用者，軟體規模估算的重要性都是不容置疑的。因為它能極大的影響著甲方對發包軟體的成本估算，乙方對自身開發成本的預測，以及乙方對開發過程的量化管理等諸多方面。而且，只有相對合理和相對準確地估算軟體規模，才能對專案的進度安排、資源分配等各個環節進行合理的部署。所以，軟體專案的規模估算是軟體專案中相當重要的一環。但是，以下的原因卻使到我在這次專案的實際操作中對專案規模估算失準了：

（1）對專案規模估算認識不足

專案規模估算一般分為兩種應用場景：一是招投標的時候用來估價、報價；二是用來安排進度計劃和指導專案具體工作的分配。因此，如果對規模估算認識不足的話，將可能會在這兩種應用場景中估算失準。例如，如果專案規模低估的話就會造成人力估算低估、成本預算低估、日程過短，最終人力資源耗盡，成本超出預算。最後為了完成專案不得不趕工，不但會影響到專案質量，甚至會導致專案失敗。而如果規模高估的話，就會因估價過高而降低了招投標時的競爭力，或在進度安排時提高了開發成本和浪費資源。由於對規模估算的認識不足，使到我在這次專案中就嚐到一個大苦果，就是低估專案規模導致專案需要多次的追加預算。我不但多次受到公司領導的批評，而且還受到客戶的多次投訴。

（2）個人經驗估演算法帶有一定的侷限性

一般來說，依靠歷史或個人經驗的規模估算方法都有一定的侷限性。原因是很難在專案分析和計劃階段就對軟體的規模進行相對準確的估算。因為估算是依靠評估人員的經驗，所以對評估人員的能力要求比較強，並且難以由第三方對評估人員的工作偏差作出修正。在這次專案的初期，我片面的只是根據個人經驗進行估算，結果是輕率的估算了專案規模。這是最後導致專案失利的原因之一。另外，不同軟體專案使用的技術不一樣，這一點也非常影響到軟體規模的估算。例如同一個功能,使用JAVA語言和使用Ruby語言所涉及的程式碼行相差數十行，甚至數百行。即使同為JAVA語言,使用不用的框架所需要編寫的程式碼行也不一樣。

（3）對專案估算時缺乏資料支援

因為在軟體開發初期時對規模估算都是很難準確量化的，所以到底需要多少資源、多長時間或者規模估算到什麼的程度才算是合理的是沒有一個標準的。但一個好的專案估算，是離不開一個準確的、可信的、客觀的資料作為基礎。如果在專案規模估算時只憑專案管理人員的經驗進行估算，而缺乏大量的資料支援，那麼估算最終就會變成常見的"三拍"現象："首先是專案經理拍腦袋估算，然後是專案經理估算失準時拍馬屁的補救，最後是專案失敗時拍屁股走人"。當然，這只是個玩笑。不過由此可見專案規模估算不能只依靠經驗來估算，而應該是要有大量的資料來支援。

什麼是軟體專案的規模估算？

軟體開發專案管理中的一項重要任務是開發專案的規模估算，這是極其重要但卻很容易被忽視的一項內容。因為沒有正確的規模估算，專案計劃就會失去成功的基礎。可惜大部分的開發團隊都很難做到對專案規模進行準確的估算。

（1）什麼是專案規模估算？

做好軟體專案管理的基礎是要做好專案的規劃工作，而做好專案規劃的前提是要做好軟體估算。也就是說，就是沒有好的軟體估算，專案的規劃、跟蹤和控制就根本無從談起。因此，軟體估算是專案計劃活動的基礎之一。

軟體估算一般是通過主觀經驗和客觀分析兩種方法進行，包括有四個重要方面：規模估算、工作量估算、進度估算和成本估算。其中，對規模進行估算是為了將專案範圍進行量化。規模估算是整個軟體估算中最核心、最基礎的環節，也是整個軟體估算的第一步。規模估算有兩個主要作用：一是通過規模估算建立專案基線；二是利用基線對專案生產率和狀態進行評價，並確定軟體過程的進度目標。也就是說，規模估算是一切估算的基礎，是能直接決定和影響到其它三個估算的決策。

（2）常用的軟體規模估算方法

估算是建立在客觀事實上對未來可能發生的事情的一種合理性預測。估算本身的不確定性，決定了它不可能是百分之百準確無誤的，但是依據某種方法進行合理估計顯然比瞎猜好得多。軟體估算方法有很多，大致分為基於技術分解模型和基於經驗模型兩大類。目前基於技術分解模型的方法有：功能點估演算法、LOC估演算法、MARK II等；基於經驗模型的方法有：IBM模型、普特南模型、COCOMO模型等。目前基於技術分解的常用方法是FP功能點估演算法和LOC程式碼行估演算法。本文重點介紹這兩種方法。

①FP功能點法

功能點分析法 (FPA：Function Point Analysis) 是一種相對抽象的方法，是一種人為設計的估算方式。它是從系統的複雜性和系統的特性這兩個角度來估算系統的規模，它的關注點在於程式的"功能性"和"實用性"，是對軟體和軟體開發過程的間接估算。最初是由 IBM 工程師艾倫艾爾布策提出的，隨後被IFPUG 方法繼承，是目前國際上主流的軟體規模估算方法。

功能點估演算法的核心是利用軟體資訊域中的一些計數估算和軟體複雜性估計的經驗關係式而匯出功能點FP。因此，它是一種在需求分析階段基於系統功能的一種規模估計方法。主要是通過研究初始應用需求來確定各種輸入、輸出、計算和資料庫需求的數量和特性。這種方法的計算公式是：功能點=資訊處理規模X技術複雜度。其中，資訊處理規模包括：各種輸入、輸出、查詢、內部邏輯檔案數、外部介面檔案數等；技術複雜度則包括：效能複雜度、配置專案複雜度、資料通訊複雜度、分散式處理複雜度、線上更新複雜度等。

②LOC程式碼行估演算法

衡量軟體專案規模的最常用方法還有程式碼行LOC(Line of Code) 估演算法。LOC是指所有的可執行的原始碼行數，包括可交付的工作控制語言語句、資料定義、資料型別宣告、等價宣告、輸入/輸出格式宣告等。這是一種從技術角度來估算的方法，是以程式碼行（LOC）作為軟體工作量的估算單位。開發團隊可以根據對歷史專案的審計來核算開發團隊的單行程式碼價值，一個程式碼行的價值和人月均程式碼行數可以體現一個軟體開發團隊的生產能力。LOC方法在早期的系統開發中較為廣泛使用。優點在於方便計算、容易監控、能反映程式設計師的思維能力；缺點在於程式碼行數的含糊不清，不能正確反映一項工作的難易程度以及程式碼的效率。因此，在傳統的LOC方法上有許多改進的方法。這些不斷演化的新方法有：PERT功能點估演算法、類比估演算法、系統分解法等。

除了以上介紹的兩種方法外，還有許多其它的估算方法。不同的方法適用於不同的具體環境，有些方法雖然很好但並不一定適合當前的任務。因此，建議至少使用兩種方法進行規模估算，不要依賴於任何一種方法。只有量體裁衣，具體問題具體分析，才能得到儘量合理的規模估算。

準確進行專案規模估算的步驟

（1）規模估算前先制定良好的規劃

一個成功的軟體專案首先要有一個好的起點，也就是一個合理的規劃。同樣道理，一個好的規模估算也需要有一個好的規劃。例如，當我們的辦公室內堆滿了雜亂無章的檔案時，恐怕是無法知道對於我們真正有用的檔案在哪裡。同樣道理，當我們從軟體專案中收集了各種需求、意見和問題時，我們也很難從中估算出整個專案的規模、工作量以及成本。因此，在估算之前首先要對眾多資訊進行整理、歸類和分析，從而得到一個條理清晰的專案規劃。在這個規劃提供的框架內，才可能正確的估算。因為有了規劃才能成竹在胸，才能給規模估算指出正確的方向。

（2）確定軟體專案的範圍

確定軟體專案的範圍，就是確定目標軟體的資料和控制、功能、效能、約束、介面以及可靠性的要求。這項工作和需求分析是很類似的，如果之前已經達成需求分析規約，那麼可以直接從《需求分析說明書》中把有用的部分拿來使用。如果還沒有開始需求分析，就必須要使用需求分析技術從客戶處得到一個具體的軟體範圍。因為確定軟體專案的範圍，就能形成一個有界限的開發框架。雖然這個開發框架還不夠精確，但足以進行規模的估算工作。

（3）制訂各級別的估算表框架和模板

在開發框架明確後，我們下一步要做的是把公司內部最有專案經驗、最有估算經驗的工程們召集在一起，制定各級別的估算表框架和估算表模板，並寫上足夠清晰的指導。當專案組用這些模板的時候，就相當於用了估算精英們的腦袋來思考本專案的估算了。然後，再根據專案的實際情況列出具體的活動，最後是把這些活動進行細化估算。據我過往的經驗，很多時候規模估算沒有做好的緣故是因為沒有估算好非直接生產程式設計的活動的規模，例如管理類、支援類、維護類的活動，而根本的原因是沒有制定好估算表框架和有合適的模板可利用。

（4）根據合適的估算表模板進行由底而上的估算

最後一步是專案組根據專案的特點利用合適的估算表模板繼續細化，例如進行詳細的WBS分解，列出要完成這個專案所需要的全部工作。然後，把這些工作通過由底而上的方式進行綜合，以估算出專案規模的大小。

最後，分享這次專案失敗給我的教訓：要客觀的利用和看待過去的經驗。因為以往的估算經驗雖然是寶貴的財富，但是如果財富用錯了地方就會變成垃圾。在使用歷史經驗時，要注意現在和參考經驗之間的差異。不要忘記，隨著時間的推移，軟體開發領域的技術和方法都在發生著巨大的改變。