本篇文章給大家談談軟件開發工作量評估模板，以及軟件開發度量評估標準對應的知識點，希望對各位有所幫助，不要忘了收藏本站喔。

本文目錄一覽：

• 1、軟件開發工作量如何評估
• 2、一個軟件項目如何評估工作量和成本?
• 3、如何評估軟件項目的工作量（人/天）
• 4、做軟件開發的成本究竟如何估算
• 5、軟件開發成本估算方法有哪幾種
• 6、軟件評估方法

軟件開發工作量如何評估

用于軟件項目工作量估算的方法有以“估”為主的專家法和類推法，以“算”為主的類比法和方程法。在軟件估算的實踐中，類比法和類推法也是普遍使用的估算方法。

1、類比法

類比法是指將本項目的部分屬性與類似的一組基準數據進行比對，進而獲得待估算項目工作量、工期或成本估算值的方法。類比法是基于大量歷史項目樣本數據來確定目標項目的預測值，通常是以50百分位數為參考而非平均值。選擇類比法進行估算，應根據項目的主要屬性，在基準數據庫中選擇主要屬性相同的項目進行比對。

類比法適合評估那些與歷史項目在應用領域、系統規模、環境和復雜度方面相似的項目，通過新項目與歷史項目的比較得到估計數據。類比法估算結果的精確度取決于歷史項目數據的完整性和準確度。因此，用好類比法的前提條件之一是組織建立起較好的項目后評價與分析機制，對歷史項目的相關屬性建立基線數據。

適用范圍：

當需求極其模糊或不確定時，如果此時有與本項目類似屬性（如規模、應用類型、復雜度、開發團隊經驗等）的一組基準數據，則可直接采用類比法，充分利用基準數據來估算工作量。類比法可以在整個項目級上做基準比對，也可以在子系統級上進行。

估算過程：

1） 確定待估算項目所具有的屬性特點，如系統的規模、復雜度、應用類型、業務領域、開發人員的經驗和能力等。

2） 查詢歷史數據庫并篩選“最相似”的項目屬性數據。

3） 如果待估算項目屬性與歷史項目的主要屬性類似，則可依據歷史項目的基線數據直接得出待估算項目的工作量合理范圍。

4） 如果同時滿足待估算項目主要屬性的歷史項目太少，則可針對待估算項目的每個屬性與歷史項目相應屬性的基準數據分別比對，再分別計算得出P25/P50/P75的平均值作為估算值。

5） 一般情況下，取P50的工作量數據作為待估算項目工作量最可能的值。

2、類推法

類推法是指將本項目的部分屬性與高度類似的一個或幾個已完成項目的數據進行比對，適當調整后獲得待估算項目工作量、工期或成本估算值的方法。選擇類推法進行估算，通常只參照1~2個高度類似的項目，同時根據待估算項目與參照項目的差異，進行適當調整。

適用范圍：

1） 當需求極其模糊或不確定時，較難估算工作量，如果此時具有高度類似的歷史項目，則可直接采用類推法，充分利用歷史項目數據進行估算。

2） 適用評估一些與歷史項目在業務領域、應用類型、環境和復雜度等方面的相似項目，通過新項目與歷史項目的比較進行估計。

3） 該方法估算結果的精確度取決于已完成項目數據的完整性、準確度，以及兩個項目之間的相似度。如果沒有類似的項目，該方法就不能應用。

估算過程：

1） 識別出待估算項目的主要屬性。

2） 查找本組織曾經做過的類似的歷史項目。

3） 對比歷史項目，標記差異點，經過調整后計算出待估算項目的工作量。

3、方程法

采用方程法進行工作量估算時，應考慮根據開發組織實際情況進行回歸分析，建立回歸方程。可將所有影響因子都考慮在內建立多元方程，也可以先根據部分影響因子算出初步的結果，再對結果進行調整。

行業級模型示例如下：

行業級模型： AE=（S*PDR）*SWF*RDF

公式中：

AE：調整后工作量，單位為人時

S：規模，單位為功能點數

PDR：生產率，單位為人時每功能點

SWF：軟件因素調整因子

RDF：開發因素調整因子

能上回答望采納！如有疑問可私信！

一個軟件項目如何評估工作量和成本?

軟件開發成本估算過程可進一步細分為軟件規模估算、工作量估算、成本估算和確定軟件開發成本等四個過程。

其中成本估算需要對直接人力成本、間接人力成本、間接非人力成本及直接非人力成本分別進行估算。

國家標準《GB/T 36964-2018 軟件工程 軟件開發成本度量規范》中建議的軟件開發成本估算基本流程如下圖所示：

國家準中的四個估算過程，層層遞進，逐步細化，最終達到科學、一致的成本估算。

一、軟件規模估算

通常情況下，規模估算是軟件成本估算過程的起點。

估算規模是后續計算軟件項目的工作量、成本和進度的主要輸入，是項目范圍管理的關鍵，因此，在條件允許的情況下，應首先進行規模估算。

在規模估算過程中，需要注意以下情況：

在規模估算開始前，應根據可行性研究報告或類似文檔明確項目需求及系統邊界。項目需求除包含最基本的業務需求外，還應進行初步的子系統/模塊劃分，并對每一子系統或模塊的基本用戶需求進行說明，以保證可以根據項目需求進行規模預估。

依據項目特點和需求詳細程度不同，通常估算人員在選擇估算方法時應采用納入國際標準的功能點方法進行功能規模估算，在適用IFPUG或NESMA方法時，可以根據需求的粒度和管理需要，選擇預估功能點方法、估算功能點方法或者詳細功能點方法。

若當前的項目需求極其模糊或不確定，可不進行規模估算，而直接采用類比法或類推法估算工作量和成本。

二、工作量估算

在完成規模估算后，應當開展工作量估算工作，若當前項目未開展規模估算，也可直接啟動工作量估算工作。

工作量估算時，可采用方程法、類比法、類推法、功能點法：

方程法：即基于基準數據建立參數模型，通過輸入各項參數，確定估算值。

類比法：即將待估算項目的部分屬性與類似的一組基準數據進行比對，進而確定估算值。

類推法：即將待估算項目的部分屬性與高度類似的一個或幾個已完成項目的數據進行比對，并進行適當調整后確定估算值。

功能點法：從用戶視角出發，通過量化系統功能來度量軟件的規模，這種度量主要基于系統的邏輯設計。功能點規模度量方法在國際上的應用已經比較廣泛，并且已經取代代碼行成為最主流的軟件規模度量方法。

在開展工作量估算的過程中，需要注意以下情況：

當需求極其模糊或不確定時，如果此時具有高度類似的歷史項目，則可直接采用類推法，充分利用歷史項目數據來粗略估算工作量。

當需求極其模糊或不確定時，如果此時具有與本項目部分屬性類似的一組基準數據，則可直接采用類比法，充分利用基準數據來粗略估算工作量。

對于規模估算已經開展的項目，可采用方程法，通過輸入各項參數，確定待估算項目的工作量。若客戶或高層對項目的工期有明確的要求時，在采用方程法估算工作量時，工期要求有可能是方程的參數之一。

為追求估算的準確性，建議在條件允許的情況下，可采用兩種估算方法，對估算結果進行交叉驗證，若估算結果差別不大，可直接使用兩種估算結果的平均值或以某種估算結果為準，若差別較大，需進行差異分析。

工作量的估算結果宜為一個范圍而不是單一的值。

三、成本估算

在獲得了工作量估算結果后，可采用科學的方法進行成本估算。

在成本估算過程中，應需要注意的情況：

類比法和類推法，同樣適用于需求極其模糊或不確定時的成本估算；

間接成本是否與工作量估算結果相關取決于間接成本分攤計算方式。在絕大多數組織，項目周期越長，項目組成員越多，其分攤的間接成本就越高，此時項目的間接成本與工作量估算結果直接相關；

直接非人力成本通常與工作量估算結果無關，宜單獨分項測算；

成本估算結果，也通常為一個范圍，而不是單一的值。

四、確定軟件開發成本

在《軟件工程 軟件開發成本度量規范》中，將軟件開發成本分為四類，主要是為便于對成本構成（即哪些成本屬于開發成本，哪些不屬于開發成本）進行清晰界定。

而在實際確定軟件開發成本時，通常并不是分別測定四類成本，加和后獲得總成本，而是通常采用以下兩種方式確定總成本：

根據人力成本費率及工作量估算直接人力成本和間接成本之和，再加上直接非人力成本，獲得總成本；

根據規模綜合單價和軟件規模，測算出直接人力成本和間接成本之和，再加上直接非人力成本，獲得總成本。

在進行軟件的規模、工作量、成本估算時應遵循以下原則：

在規模估算時,應根據項目特點和需求的詳細程度選擇合適的估算方法；

充分利用基準數據,采用方程法、類比法或類推法,對工作量和成本進行估算；

工作量和成本的估算結果宜為一個范圍值；

在進行成本估算時,如有明確的工期要求,應充分考慮工期對項目成本的影響,可以根據項目實際情況以及工期對項目的影響程度,對成本的估算結果進行調整；

成本估算過程中宜采用不同的方法分別估算并進行交叉驗證。如果不同方法的估算結果產生較大差異,可采用專家評審方法確定估算結果,也可使用較簡單的加權平均方法；

在軟件項目的不同場景下(如預算、招投標、項目計劃和變更管理等)采用國家標準時,相關要求見國家標準中附錄A。

除了上述主要原則外，我們還需注意在使用基準數據時：

對于委托方和第三方，建議使用或參考軟件行業基準數據進行估算。估算模型的調整因子的增減或取值有可能隨著行業基準數據的變化而變化。

對于開發方，在引入行業基準數據的基礎上，可逐步建立組織級基準數據庫，以提高估算精度。組織級基準數據定義應與行業基準數據定義保持一致，以便于與行業基準數據進行比對分析，并持續提升組織能力。

如何評估軟件項目的工作量（人/天）

一個工作或者是項目的工作量的評估，會牽涉到的因素確實比較多。根據經驗，羅列幾種因素，比如使用的方法或者工具、開發者的熟悉程度、以及(部門之間的)利益關系、對項目的理解評估人員的個性。基于各種因素考量最后出現的工作量評估會有比較大的區別。

1.使用的方法或者是工具

對于一個項目，A有些現成的模塊，B需要重新開始搭建，A和B對完成時間的評估自然不一樣。

或是對于開發一個網站，假設合理的工作量是，做前臺展示頁面需要1個月，后臺管理需要1個月。A會評估為1個月，等前臺上線之后，再同步開始做后臺管理。B可能會認為需要2個月，B認為前后臺都完成，才是工作完成。

2.開發者的熟悉程度

這個容易理解，如果是一般對語言或是技術掌握不熟悉的人，花費的時間和返工的時間、溝通的時間自然就要長一點

3.(部門之間的)利益關系

公司之間的外包項目，服務方就傾向于時間長一點，考慮的因素是假設用戶需求會有一部分變化或者希望從中多賺錢。公司的部門之間也是類似，營銷部門總是希望越快越好，但是開發部門總是認為營銷部門沒有更早提出需求等等。

4.對項目的理解或者評估人員的個性

同樣一個項目，類似微信，如果1000個用戶數和1千萬的用戶數，做法上會有非常大的區別。

做軟件開發的成本究竟如何估算

軟件成本評估的6個步驟：

1、軟件規模評估：

軟件規模評估是軟件成本評估的基礎，是為了保證軟件成本評估結果的客觀性和透明性，軟件規模信息必不可少。

在軟件規模評估過程中，如果能夠以軟件功能點方法作為主要的軟件規模評估方法，同時輔以其他的非標準評估方法，例如代碼行方法、用例數方法等，應用不同的軟件規模評估方法對規模評估結果進行真實性交叉檢驗，一方面可以提高軟件規模評估結果的可信度；另一方面，也可以對不同類型的項目干系人也會具有更強的說服力。

在實際的軟件規模評估過程中，軟件組織或者個人也可以根據自身的特點采用有別于上述評估方法的其他方法。但要注意的是，不管采用哪種軟件規模評估方法，都要盡可能的保證這個方法所評估結果的一致性和客觀性。

2、軟件工作量評估

如果說我們能夠算出開發軟件、維護軟件所投入的人員工作量，那么我們也就相當于得到了相應的軟件成本。在軟件行業中的絕大多數項目里面，影響軟件工作量的最主要因素還是軟件規模因素，當軟件規模越來越大時，也就意味著我們需要投入的工作量越多，這兩者之間是存在著正相關的關系。

在軟件工作量的評估中，還包含了五個小步驟，也就是收集歷史工作量數據、分析歷史工作量數據、建立工作量評估模型、評估工作量、工作量模型的標定和更新。通過這些步驟可以積累更多關于軟件組織開發工作量和維護工作量的數據，在此基礎之上，建立相應的工作量評估模型，從而為后續的工作量評估任務提供支持方法。

3、軟件階段工作量評估

在這個步驟中，軟件成本評估團隊應該充分考慮軟件項目的工期因素，對軟件項目總工作量安排和各個階段工作量安排進行優化分析，將軟件項目的總工作量以合理可行的方式分解為各個階段的工作量。

不僅如此，還要考慮軟件項目工期所面臨的各種工期約束條件，例如一些來自客戶的強制工期要求、市場競爭性、可用的人力資源、項目各階段人力資源分配的合理比例等約束條件，都在這個步驟中明確介紹了一系列階段工作量安排的改進和優化方法，包括階段工作量匯總法、資源平滑法、快速跟蹤法、趕工法以及軟件階段工作量的可行性評估方法等。

這些方法的主要目的就是在于將軟件工作總量以合理、可行的方式分配到軟件項目的各個階段，確保在不超出工作總量的前提下，盡可能降低人員成本、優化人力資源配置，為軟件預算、軟件開發計劃制定等管理活動提供充分的決策支持信息。

4、軟件人員成本評估

在這個步驟里面，我們將會詳細說明如何在軟件開發和維護所需的工作量轉換為對應的費用信息，以便為相關的項目外部干系人提供更直接的決策依據。在軟件人員成本評估中，也包含有單一人員成本評估法、分類人員成本評估法和行業人員成本評估法。

5、軟件風險評估

在軟件開發的過程中，許多軟件組織明確認識到軟件行業的開發人員已經默認和接受了無償加班這一行業事實，這樣一來，就算沒有識別相應的風險信息，但也沒有嚴重后果，也就是說，如果風險發生了，那就加班。

這個步驟中通過應用不同的風險評價方法，將軟件項目的風險信息轉換為項目的成本信息，從而建立軟件項目的風險預算。

6、軟件成本報告與更新

軟件項目在開發過程中時，經常容易發生各種軟件需求變更、人員變更、工期變更等多種類型的變更，這些變更無一例外地將對軟件成本產生明顯的影響。

在這個步驟中，可以分析軟件成本更新面臨的困難，有哪些典型的軟件成本更新的信息來源，從機制設計的角度確保盡可能全面獲取軟件成本變更信息。最后遵循軟件組織所建立的軟件成本更新過程，將軟件成本變更信息反映到更新后的軟件成本評估結果中。

軟件開發成本估算方法有哪幾種

開發一個軟件項目，成本如何估算？對此業內已經形成了較為通用的做法，估算步驟主要是這樣的：A.軟件項目需求溝通-》B.軟件項目需求拆分-》C.每個需求點的人天評估-》D.項目人天匯總-》E.商務報價定稿，下面我給大家逐一分解：

A節點主要是將客戶需要做什么弄清楚；

B節點則將需求按模塊拆分成需求點；

C節點則是根據企業開發實力和過往經驗判斷每個功能點多少人多少天完成（這個點需要較為資深的銷售經理或項目經理來評估）；

D節點則是把項目所有人天及價格進行匯總，這個匯總不是簡單的相加，因為前面步驟得出的人天僅僅是開發部分的工作量，但是軟件開發還包括需求調研、系統設計、系統測試、UAT、上線和運維等等，這部分一般通過一定系數進行測算得出；

E節點就是考慮商務層面而非技術層面的因素對最終價格進行修訂，比如甲方是一個大企業那么可能第一次合作吃虧也得進去先，比如說甲方不差錢那報價可以適度提升以防后續有需求變更等等；

為了讓大家有個清晰的認知，我把工作中接觸過的一個評估模板（只到D節點哈）復制上來給大家參考：

軟件開發成本估算模型

以上是我從知乎大神處借鑒來的軟件開發成本估算方法之一，也有一些其他辦法，比如拿著同一份需求找不同廠商報價，看報價分布區間就能知道大概成本，另外對于資深的項目經理或開發人員，他們憑借感覺也是能估算的出來的……其他的歡迎其他同仁積極發表意見，畢竟借助科學的評估流程、工具及經驗做好軟件項目成本估算，從而更好的保障項目盈利是非常有必要的。

軟件評估方法

軟件系統質量 記分辦法，可以按照月，季或者年進行記分合計，每分對應相應的價格進行獎懲。 上線前 ；95%需求覆蓋率，至少 ；5%問題遺留率，最高 BUG嚴重 ；10%比率，最高 試運行過程 內（一般以軟件交付給用戶后的三個月內為初期故障期）指軟件在初期故障期初期故障率： 可以用它來評價交付使用的軟件質小時的故障數為單位。100一般以每單位時間的故障數。量與預測什么時候軟件可靠性基本穩定。檢查項目初期故障率的大小取決于軟件設計水平、 數、軟件規模、軟件調試徹底與否等因素偶然故障率：指軟件在偶然故障期（一般以軟件交付給用戶后的四個月以后為偶然故障期） 小時的故障數為單位，它反映了軟件處于穩定狀態下1000內單位時間的故障數。一般以每 的質量 運維過程 ）MTBF平均失效間隔時間（ 通MTBF指軟件在相繼兩次失效之間正常工作的平均統計時間。在實際使用時， 次失效之間的平均統計時間。n+1次失效與第n很大時，系統第n常是指當 小時左右。

關于軟件開發工作量評估模板和軟件開發度量評估標準的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。