功能點估算法的核心是利用軟件信息域中的一些計數估算和軟件復雜性估計的經驗關系式而導出功能點FP。因此，它是一種在需求分析階段基于系統功能的一種規模估計方法。主要是通過研究初始應用需求來確定各種輸入、輸出、計算和數據庫需求的數量和特性。這種方法的計算公式是：功能點=信息處理規模X技術復雜度。其中，信息處理規模包括：各種輸入、輸出、查詢、內部邏輯文件數、外部接口文件數等;技術復雜度則包括：性能復雜度、配置項目復雜度、數據通信復雜度、分布式處理復雜度、在線更新復雜度等。
②LOC代碼行估算法
衡量軟件項目規模的常用方法還有代碼行LOC(Line of Code) 估算法。LOC是指所有的可執行的源代碼行數，包括可交付的工作控制語言語句、數據定義、數據類型聲明、等價聲明、輸入/輸出格式聲明等。這是一種從技術角度來估算的方法，是以代碼行(LOC)作為軟件工作量的估算單位。開發團隊可以根據對歷史項目的審計來核算開發團隊的單行代碼價值，一個代碼行的價值和人月均代碼行數可以體現一個軟件開發團隊的生產能力。LOC方法在早期的系統開發中較為廣泛使用。優點在于方便計算、容易監控、能反映程序員的思維能力;缺點在于代碼行數的含糊不清，不能正確反映一項工作的難易程度以及代碼的效率。因此，在傳統的LOC方法上有許多改進的方法。這些不斷演化的新方法有：PERT功能點估算法、類比估算法、系統分解法等。
除了以上介紹的兩種方法外，還有許多其它的估算方法。不同的方法適用于不同的具體環境，有些方法雖然很好但并不一定適合當前的任務。因此，建議至少使用兩種方法進行規模估算，不要依賴于任何一種方法。只有量體裁衣，具體問題具體分析，才能得到盡量合理的規模估算。
準確進行項目規模估算的步驟
(1)規模估算前先制定良好的規劃
一個成功的軟件項目首先要有一個好的起點，也是一個合理的規劃。同樣道理，一個好的規模估算也需要有一個好的規劃。例如，當我們的辦公室內堆滿了雜亂無章的文件時，恐怕是無法知道對于我們真正有用的文件在哪里。同樣道理，當我們從軟件項目中收集了各種需求、意見和問題時，我們也很難從中估算出整個項目的規模、工作量以及成本。因此，在估算之前首先要對眾多信息進行整理、歸類和分析，從而得到一個條理清晰的項目規劃。在這個規劃提供的框架內，才可能正確的估算。因為有了規劃才能成竹在胸，才能給規模估算指出正確的方向。
(2)確定軟件項目的范圍
確定軟件項目的范圍，是確定目標軟件的數據和控制、功能、性能、約束、接口以及可靠性的要求。這項工作和需求分析是很類似的，如果之前已經達成需求分析規約，那么可以直接從《需求分析說明書》中把有用的部分拿來使用。如果還沒有開始需求分析，必須要使用需求分析技術從客戶處得到一個具體的軟件范圍。因為確定軟件項目的范圍，能形成一個有界限的開發框架。雖然這個開發框架還不夠精確，但足以進行規模的估算工作。
(3)制訂各級別的估算表框架和模板
在開發框架明確后，我們下一步要做的是把公司內部有項目經驗、有估算經驗的工程們召集在一起，制定各級別的估算表框架和估算表模板，并寫上足夠清晰的指導。當項目組用這些模板的時候，相當于用了估算精英們的腦袋來思考本項目的估算了。然后，再根據項目的實際情況列出具體的活動，后是把這些活動進行細化估算。據我過往的經驗，很多時候規模估算沒有做好的緣故是因為沒有估算好非直接生產編程的活動的規模，例如管理類、支持類、維護類的活動，而根本的原因是沒有制定好估算表框架和有合適的模板可利用。
(4)根據合適的估算表模板進行由底而上的估算
后一步是項目組根據項目的特點利用合適的估算表模板繼續細化，例如進行詳細的WBS分解，列出要完成這個項目所需要的全部工作。然后，把這些工作通過由底而上的方式進行綜合，以估算出項目規模的大小。
后，分享這次項目失敗給我的教訓：要客觀的利用和看待過去的經驗。因為以往的估算經驗雖然是寶貴的財富，但是如果財富用錯了地方會變成垃圾。在使用歷史經驗時，要注意現在和參考經驗之間的差異。不要忘記，隨著時間的推移，軟件開發領域的技術和方法都在發生著巨大的改變。
