㈠ 一個軟體項目如何評估工作量和成本
軟體開發成本估算過程可進一步細分為軟體規模估算、工作量估算、成本估算和確定軟體開發成本等四個過程。
其中成本估算需要對直接人力成本、間接人力成本、間接非人力成本及直接非人力成本分別進行估算。
國家標准《GB/T 36964-2018 軟體工程 軟體開發成本度量規范》中建議的軟體開發成本估算基本流程如下圖所示:
國家准中的四個估算過程,層層遞進,逐步細化,最終達到科學、一致的成本估算。
一、軟體規模估算
通常情況下,規模估算是軟體成本估算過程的起點。
估算規模是後續計算軟體項目的工作量、成本和進度的主要輸入,是項目范圍管理的關鍵,因此,在條件允許的情況下,應首先進行規模估算。
在規模估算過程中,需要注意以下情況:
在規模估算開始前,應根據可行性研究報告或類似文檔明確項目需求及系統邊界。項目需求除包含最基本的業務需求外,還應進行初步的子系統/模塊劃分,並對每一子系統或模塊的基本用戶需求進行說明,以保證可以根據項目需求進行規模預估。
依據項目特點和需求詳細程度不同,通常估算人員在選擇估算方法時應採用納入國際標準的功能點方法進行功能規模估算,在適用IFPUG或NESMA方法時,可以根據需求的粒度和管理需要,選擇預估功能點方法、估算功能點方法或者詳細功能點方法。
若當前的項目需求極其模糊或不確定,可不進行規模估算,而直接採用類比法或類推法估算工作量和成本。
二、工作量估算
在完成規模估算後,應當開展工作量估算工作,若當前項目未開展規模估算,也可直接啟動工作量估算工作。
工作量估算時,可採用方程法、類比法、類推法、功能點法:
方程法:即基於基準數據建立參數模型,通過輸入各項參數,確定估算值。
類比法:即將待估算項目的部分屬性與類似的一組基準數據進行比對,進而確定估算值。
類推法:即將待估算項目的部分屬性與高度類似的一個或幾個已完成項目的數據進行比對,並進行適當調整後確定估算值。
功能點法:從用戶視角出發,通過量化系統功能來度量軟體的規模,這種度量主要基於系統的邏輯設計。功能點規模度量方法在國際上的應用已經比較廣泛,並且已經取代代碼行成為最主流的軟體規模度量方法。
在開展工作量估算的過程中,需要注意以下情況:
當需求極其模糊或不確定時,如果此時具有高度類似的歷史項目,則可直接採用類推法,充分利用歷史項目數據來粗略估算工作量。
當需求極其模糊或不確定時,如果此時具有與本項目部分屬性類似的一組基準數據,則可直接採用類比法,充分利用基準數據來粗略估算工作量。
對於規模估算已經開展的項目,可採用方程法,通過輸入各項參數,確定待估算項目的工作量。若客戶或高層對項目的工期有明確的要求時,在採用方程法估算工作量時,工期要求有可能是方程的參數之一。
為追求估算的准確性,建議在條件允許的情況下,可採用兩種估算方法,對估算結果進行交叉驗證,若估算結果差別不大,可直接使用兩種估算結果的平均值或以某種估算結果為准,若差別較大,需進行差異分析。
工作量的估算結果宜為一個范圍而不是單一的值。
三、成本估算
在獲得了工作量估算結果後,可採用科學的方法進行成本估算。
在成本估算過程中,應需要注意的情況:
類比法和類推法,同樣適用於需求極其模糊或不確定時的成本估算;
間接成本是否與工作量估算結果相關取決於間接成本分攤計算方式。在絕大多數組織,項目周期越長,項目組成員越多,其分攤的間接成本就越高,此時項目的間接成本與工作量估算結果直接相關;
直接非人力成本通常與工作量估算結果無關,宜單獨分項測算;
成本估算結果,也通常為一個范圍,而不是單一的值。
四、確定軟體開發成本
在《軟體工程 軟體開發成本度量規范》中,將軟體開發成本分為四類,主要是為便於對成本構成(即哪些成本屬於開發成本,哪些不屬於開發成本)進行清晰界定。
而在實際確定軟體開發成本時,通常並不是分別測定四類成本,加和後獲得總成本,而是通常採用以下兩種方式確定總成本:
根據人力成本費率及工作量估算直接人力成本和間接成本之和,再加上直接非人力成本,獲得總成本;
根據規模綜合單價和軟體規模,測算出直接人力成本和間接成本之和,再加上直接非人力成本,獲得總成本。
在進行軟體的規模、工作量、成本估算時應遵循以下原則:
在規模估算時,應根據項目特點和需求的詳細程度選擇合適的估算方法;
充分利用基準數據,採用方程法、類比法或類推法,對工作量和成本進行估算;
工作量和成本的估算結果宜為一個范圍值;
在進行成本估算時,如有明確的工期要求,應充分考慮工期對項目成本的影響,可以根據項目實際情況以及工期對項目的影響程度,對成本的估算結果進行調整;
成本估算過程中宜採用不同的方法分別估算並進行交叉驗證。如果不同方法的估算結果產生較大差異,可採用專家評審方法確定估算結果,也可使用較簡單的加權平均方法;
在軟體項目的不同場景下(如預算、招投標、項目計劃和變更管理等)採用國家標准時,相關要求見國家標准中附錄A。
除了上述主要原則外,我們還需注意在使用基準數據時:
對於委託方和第三方,建議使用或參考軟體行業基準數據進行估算。估算模型的調整因子的增減或取值有可能隨著行業基準數據的變化而變化。
對於開發方,在引入行業基準數據的基礎上,可逐步建立組織級基準資料庫,以提高估算精度。組織級基準數據定義應與行業基準數據定義保持一致,以便於與行業基準數據進行比對分析,並持續提升組織能力。
㈡ 如何量化考核軟體開發人員績效
你好,
「目標管理」更適合軟體開發人員。
但些方法最好從上至下全員使用
1、目標項(即當月或是階段性的工作項目、或是要點)
2、目標項的達成准標(以量化標准作為結點,避免方向性的准標如「進一步提高等」)
3、目標在執行過程中所遇到的問題點
4、針對第3項問題點所採取的應對措施(目的進行檢驗,和糾偏)
5、提交成果主要的衡量標准
6、衡向配合部門
以上6項樓主可以進行一個列表,進行橫排~進行目標設定,階段性進行總結。
根據目標完成成度進行考核。
因為軟體開發人員的工作性質比較特殊,考核方案要與所擔當的項目結合起來才能很好的推動,如果太過形式化,執行力和效果都不會很好。
希望回答對您有幫助.
㈢ 如何對程序員績效考核
我認為績效考核對程序員或者對整個公司都是重中之重,但是對程序員怎麼績效考核?難道看敲得代碼數量嗎?績效考核的先決條件是工作可測量。
從這個角度講,有兩種方式可以綜合使用:
1.代碼量。
每天下班進行工作提交時,統計今日修改,新增的代碼行數,業界基本水平大約是200行。
如果你做到了上面這些, 好恭喜你,你們公司非常正規了,如果這個程序猿工作不努力,幹活不認真,產出效率低,那麼問題一定不是處在程序猿身上,而是HR工作有問題.
㈣ 如何量化衡量一個程序員的工作量和工作效率
1. 代碼數量
可以統計代碼行數,或者字元數量。
2. 代碼質量
顯然,代碼長不等於工作量很大。不光要考慮代碼的數量,還要考慮代碼的質量。那麼什麼樣的代碼是高質量的呢?什麼樣的代碼是「好」的呢?
「好代碼」的評判標准可能非常主觀。主流的價值觀中大概有以下標准:可讀性好(注釋不多不少,版面整潔,符合公司規則,變數名有意義等)bug 少(正確處理各種異常和錯誤)。優雅(設計優雅,實現優雅)
(4)程序員工作量如何量化的擴展閱讀:
程序員的日常工作
1.確認通過審查方案的目標,輸入數據,分析師,監事,和客戶的輸出要求的項目要求。
2.安排項目要求在編程序列分析要求;准備工作流程圖和使用計算機知識的能力,題材,編程語言和邏輯圖。
3.編碼工作流程的信息轉換成計算機語言的項目要求。
4.通過輸入編碼信息的計算機程序。
5.確認程序操作進行測試,修改程序序列和/或代碼。
6.准備寫操作指令供用戶參考。
7.保持歷史記錄,通過記錄方案的制定和修訂。
8.維護客戶的信息和保護保密的業務。
技能/資格:一般的編程技巧,分析信息,解決問題,軟體演算法設計,軟體性能優化,注重細節,軟體設計,軟體調試,軟體開發基礎,軟體文檔,軟體測試。程序員其實分為很多種,大家開發的語言可能不盡相同,但是都是有他們的共同點。
參考資料來源:網路-程序員