近年來小弟在公司任職與學校兼課時，發現在學校很少跟學生說明軟體估算怎估算(Estimate)因此在公司的教育訓練與課堂授課時，都會將自己在公司的小型軟體估算經驗做分享【1】，來與系統分析師、程式工程師與學校學生作經驗分享。
我首先開始在涉獵估算是2005年公司導入CMMI dev v1.1【2】時我負責專案管理(PP)的流程規畫，在寫SP1.3中專案生命週期的標準流程時，當時CMMI顧問洪肇奎教授要求我要有專案的軟體開發生命週期，並為生命週期的工期與大小、規模就制定專案的大小規模，制定估算準則來符合ML2認證的直接證據。所以我就依照公司的專案資料與開發主管的討論制定相關的公司的估算公式【3】，就作一個給專案開發團隊專案經理依照工程師的程式撰寫所估算產生專案的工時。
後來我過幾年後的歷練後，為應付業務面對客戶報價需要快速需求(1-2天就要給工時)，我在請教洪肇奎老師與參考軟體工程相關資料【4】後修正之前方法，採用以需求用WBS(Work Breakdown Structure)的方式先作歸類後一項一項給出工時，這時因為已經有一些歷史資料庫與專案經驗制定每項WBS工作項目下的參考數據，舉例如下：
1.程式的撰寫方面下：如撰寫依照公司的系統架構的一個表單畫面為6hr標準
(前提是不複雜-15個欄位以下、採用公司的畫面風格、新增、刪除、查詢等共用的元件)
2.系統分析方面下：依照會議記錄產生的需求項目不到20個以下，那系統分析的規劃工時與文件就會在3工作天(前提是舊系統修改沒有新工程)
這邊我要說明我依照當時公司的撰寫專案程式的經驗(約3年 20多專案資料)去設計這高階的估算方式，其實還有很多方法論可以依照每個公司的需求做調整，我認為沒有絕對都是要看公司的文化與特性，在2018年的CMMI 2.0中的估算中EST2.3方法敘述裡說到，\將每次估算歷史資料納入估算模型中並維護他，在認證ML3中EST3.2細節更將有數據庫估算資料與過程都要納入考慮。
以前業務請系統分析師估算工時都是依照是專案類比對與經驗，估算出來的工時，若可以透過公司制定的高階估算方法論，至少可以有依據算出來，也許專案估算精準度不一定很高，但是還是提供給業務、專案經理對軟體開發的參考數據與理論，不會因為人因素產生重大誤差。(舉例剛好系統分析師失戀算出來工時特別高)
文獻參考與說明
【1】我曾任職的公司是200-10人以下類型的軟體公司，所經歷的大小專案眾多，經驗豐富是小型軟體專案所以我指分享小型專案的經驗分享(我對小型專案定義工期 1年以下、金額150萬以下)，大型專案的整合、類型、複雜度、風險太多,我雖有經歷但還是不敢托大來敢來說明大型專案估算。
【2】CMMI (Capability Maturity Model® Integration，能力成熟度模式整合) 起源於美國國防部與卡內基美隆大學（Carnegie-Mellon University）合作所設立的軟體工程學院（Software Engineering Institute，SEI）。
【3】這方法就當時CMMI顧問洪老師就取名字叫【工程師專家法】依照與資深工程師討論數據，制定公式來估算撰寫程式(codeing)為基準1個數字，推算系統分析(SA)+程式設計(SD)+程式測試(Test)+系統建置+專案風險=總工時方法，最初依照數據我們認為系統分析只要撰寫程式的1/2，後來我們發現要將程式品質做好系統分析時間是不可以太短，然後作修正，因當初我還是開發部門小主管所以還不懂軟體工程技術中Delphi 法、積算法，功能點數法等相關理論的運用。
【4】這時我就參考2篇文章分別是在說明CMMI Dev v1.3專案管理與Agile經驗與分享，CMMI Ver1.3 專案管理的GP1基本在說明專案估算與範圍，但到CMMI ver2.0就把這部分獨立一個估算(EST)實踐領域(PA)，各位有興趣都可以參考看看。
這2篇參考文章下：
Jos
iThome鐵人賽
看影片追技術