顧名思義軟體評估就是對軟體專案的規模進度做出乙個合適評估以判斷軟體專案的預算以及專案計畫。
軟體評估是軟體工程的乙個最底層基礎，也是在軟體專案實施時必經非常核心的乙個步驟。對於乙個軟體專案，只有對其大致的評估後，才能掌握大致的軟體成本，人力資源配備，同時也是做專案計畫的基礎。
軟體評估，評估的是軟體規模，基本的使用單位是**行數。但是**行為單位有其自身的一些變數和問題，比如不同的程式語言，即便是實現相同的功能其大小也是不統一的。另外，這個單位無論是作為成本預算還是作為專案計畫，都是非常不方便的。所以，現在普遍使用的軟體規模單位是人天，比如
3人天，就是乙個功能需要
1個人做
3天或者
3個人做一天的規模。這個單位用於計算成本和規模進度都非常方便。而人天和**行之間的折算關係就涉及到另外乙個參量叫做生產率，就是乙個人平均一天寫多少行**（注意這個生產率是從專案開始到專案結束，包括需求分析，設計，編碼，測試所有活動總生產率，而不是僅僅是中間編碼活動中一天能寫多少行**）
軟體規模的評估方法通常是用專家評估法。專家評估法依據的是對被評估專案都是領域的專家情況下。首先要先將專案拆分成多個小的功能模組，注意功能模組拆分是有規定的，不能太大，每個模組不能超過
500行**，即不能超過
10人天左右工作量（太多則會產生較大誤差），專家（至少
3位以上）對每個功能模組進行評估各自進行評估。評估完後，彙總每個功能模組每個專家的評估值，每個功能模組專家的評估的平均偏差少於
20%的這個功能評估算是成功接受，取其平均值作為評估值，如果這個模組的功能估計偏差超過
20%那麼，針對這個功能的評估，對應的專家要進行講解，說明和澄清自己為何做次評估，在一次討論後。將所有未被接受的功能，如上進行第二次評估。同樣再次計算其中未能通過的功能模組，再進行第三輪評估。如果第三輪評估仍然有不通過的，則專案經理參考每個專家的評估值，自行決定這個功能模組的最後評估取值。這樣，將所有功能的規模彙總，就組成了最後的專案規模結果。
專家評估法，有點是非常準確，缺點是非常耗時耗資源，評估乙個中等規模的專案往往要
3個人以上花將近大半天時間完成，所以通常只有大公司耗得起，即便是大公司由於評估方式非常麻煩，所以經常也不用。
現在大多的軟體評估方法通常也是這個原理，但是採取了簡化版本的方法進行評估。即多個人對乙個完整專案進行評估，最後平均每個人的規模估計，作為最後結果。
軟體規模評估出來後，通常有兩個作用，首先是評估出軟體專案的研發成本。比如乙個
125人天規模的軟體專案要進行開發，假設每個人每天的成本是
2000
，那麼這個軟體研發成本大致就是
500000
。這是乙個很重要的參考依據。由此基本頁可以決策這個軟體是否值得做。
評估出來後的另外乙個作用就是製作軟體研發計畫，還是比如
125人天的專案，這個專案要多長時間開發完，顯然跟研發投入相關，理論上研發投入越高，進度越快，
125人天如果給定乙個專案組是
5人，那麼就是要
25天，也就是大致為乙個多月的時間（計算工作日平均
23天為乙個月的有效正常工作日），當然，專案組規模也不是完全是說如果有
125人就能一天完成，因為人多了就會產生大量的管理成本，同時任務之間也不全能切分和並行，所以這個不能是《人月神話》。但大致給定乙個合理的人數就可以計算出大致的專案合理進度。有了合理進度，下一步就可以根據一些常用經驗指定大致的專案計畫，比如從專案工作量來講需求大致花費
15%的工作量，設計佔
25%編碼佔
40%測試佔
20%而且，每個階段能夠投入的人也不盡相同，顯然需求能投入的人基本很少，因為總需要乙個人全域性的掌握所有需求，所以儘管需求比重不大，但總是很耗時，而編碼投入的人最多，所以總體耗時是差不多的。根據這些資訊，基本就可以制定出總體的專案計畫。而專案計畫，是軟體專案的管理基礎，有了計畫參考才能匯出後面一系列的專案管理活動，資料度量等情況。所以，軟體專案評估真的是非常核心和重要的事情。
以上是通用的軟體研發模式，其實很多軟體外包其成本和進度，也是由此進行評估參考的。
但以上評估可以看出，前提是基於專家，這對於一些傳統企業，顯然是乙個奢侈品，而當前網上，能夠進行規模評估的服務非常少，常用的是估估（
）。其他一些眾包平台，也有成本預算，但是那些是根據模組**進行大致統計的，和以上的規模評估差距就甚遠了。
軟體專案規模估計方法介紹
軟體專案的規模估算歷來是比較複雜的事，因為軟體本身的複雜性 歷史經驗的缺乏 估算工具缺乏以及一些人為錯誤，導致軟體專案的規模估算往往和實際情況相差甚遠。因此，估算錯誤已被列入軟體專案失敗的四大原因之一。軟體工程師經常會被問到，編乙個什麼什麼樣的軟體需要多長時間 多少錢。面對這個問題，有不少人很犯難，...
說說軟體專案工作量評估
今天剛剛進行了乙個小軟體的工作量評估，總是覺得評估的不夠準確，而且難以明確，把心中的困擾跟實際所使用的做法簡單說說，工作量評估中，困擾我的問題主要有以下幾個 1 需求不清晰，並且會有變化 2 工作量評估在需求規格說明編寫的同時就需要進行，一般來說，沒有立項，就還不會做詳細的需求調研，但這時候就要出工...
軟體專案技術路線 軟體工程 專案規模估算技術
估計軟體大小是軟體專案管理的重要組成部分。它有助於專案經理進一步 構建專案所需的工作量和時間。在專案規模估算中使用各種措施。其中一些是 顧名思義，loc計算專案中源 的總行數。loc的單位是 好處 缺點 er模型提供專案的靜態檢視。它描述了實體及其關係。er模型中的實體數量可用於衡量專案規模的估算。...