如何評估軟體開發的工作量以及如何評估軟體專案的工作量（人日）。

1。很少有需求被確定的情況，因為客戶的需求總是在變化，即使確定了，在驗收過程中也會提出新的問題，這取決於專案經理的溝通，使用者目前的問題在這個版本或下乙個合同中解決。 所以，在需求大致確定之後，將子系統---子系統的元件模組拆解出來，這是比較粗粒度的，然後就要考慮手頭團隊的細分模組的開發和實現能力，一般會知道工作量。

2。要評估成員的工作量，首先要了解團隊的組成，誰有明確的規劃流程，誰更擅長技術研究能力，誰適合測試，誰編碼快，誰精通資料庫，誰更擅長介面布局，誰更善於溝通，同時擁有技術。 因此，通常由組長更善於溝通，及時將流程清楚地告訴團隊成員，對每個團隊成員的工作進度進行反饋，配合團隊成員的進度，決定何時做技術問題，何時組織測試。

3。專案完成後，好好數一數，每個組的行數，實現的功能模組數量，其他組呼叫的模組，多少天，涉及多少個領域等等，其實這個統計不能說A組完成了40%的專案，B組60%所以， 比較合理的做法是在某個方面，每個小組的比例，然後再對小組的工作進行總結比較合適。據**統計，A組2w行佔40%，B組3w佔60%。

模組數：A組6個，佔60%，B組4個，佔40%，並附模組結構說明。 當然，每個公司的管理都不一樣，統計方法也不同，反正乙個原則就是盡量多對兄弟們說好話，因為乙個軟體就做了，每個環節都不能差，再好的車，如果沒有很普通的小鐵板當剎車踏板， 你敢開車嗎。

首先，我們需要知道軟體開發工作負載由什麼組成。 軟體專案的工作量是完成專案或系統開發所需的總工作量，包括開發人員的需求、設計、構建（包括編碼和整合）、測試、實施以及相關的專案管理和支援活動，從專案開始到專案完成和驗收。

對於評估工作量，我認為第一步是對專案進行風險評估，例如：需求變化、外部協作、時間或成本限制、人力資源、系統架構等。 下一步是評估軟體要實現的功能的可重用程度，列出可以重用的功能以及它們可以重用的程度。

然後，根據我們的經驗，我們確定影響工作量的主要因素並對其進行評估。 例如：軟體的規模、應用領域、對質量的要求、使用什麼技術、開發團隊的能力等。

最後，需要選擇合適的工作量評估方法。 常用的方法是類比、類比和方程。 如果你對這些方法不太了解，我建議你找一本關於它們的書。

例如，新的國家標準《軟體研發成本測算規範》與其內容沒有太大區別。 如果你覺得這看起來太系統化了，也可以直接閱讀第二版《軟體研發成本測算規範解讀》。 希望以上內容對您有所幫助。

1 人 8 小時的工作量是 1 人日。 100 人日等於 1 人做 100 天或 100 人做一天。

從根本上說，首先要弄清楚需求，如果需求在不斷變化，工作量無法準確評估，開發無法按計畫進行，為了使開發盡可能可控，減少後期維護的工作量，需要做到以下幾點：

1、需求方和設計師能有良好的溝通。

這其實是最難的，因為通常需求方可能是財務、採購、銷售、倉庫管理，這些都不是開發背景，而系統設計者一定不是財務、採購、銷售、倉庫管理，他們彼此不熟悉對方的工作內容和方法，每個人的思維方式可能完全不同。

2、設計師學習能力強。

在需求分析階段，設計者需要在短時間內了解需求的每乙個細節，也就是說，如果需求是財務，那麼設計師就會成為財務，如果需求是採購，設計師就會成為採購。 不是對工作的一般理解，而是要了解每乙個細節，這就要求設計師要有很強的學習能力，能夠快速理解自己從未接觸過的業務，這不是技術問題，也不是新開發者能做到的，需要足夠的經驗。

3、資料分析能力。

對應大學裡的課程，應該是學習資料結構和數學建模，把具體的業務轉化成純數學的東西，而且要盡可能簡單，這不是每個人都能做到的，如果設計不合適，會造成後期無法維護，整個系統可能要翻轉重啟， 當然，設計師必須是程式設計師，但一定不能只是乙個程式設計師，你需要有足夠的經驗。

4、找乙個對資訊化足夠重視的老闆。

如果自己做不了老闆，就得找乙個對資訊化足夠重視的老闆，否則可能把大部分精力都花在說服老闆實現資訊化上。

為了使開發盡可能可控，減少後期維護的工作量，需要做以下幾點：1需求方和設計師可以有很好的溝通 這其實是最困難的，因為通常需求方可能是財務、採購、銷售、倉庫管理......

他們都不是開發背景，系統設計人員一定不是財務、採購、銷售、倉庫管理，而且彼此不熟悉工作內容和方法，每個人的思維方式可能完全不同2設計師有很強的學習能力 在需求分析階段，設計師需要在短時間內了解需求的每乙個細節，換句話說，如果需求是財務的，那麼設計師就會成為財務，如果需求是採購，設計師就會成為採購...... 不是對工作的一般理解，而是要了解每乙個細節，這就要求設計師要有很強的學習能力，能夠快速理解自己從未接觸過的業務，這不是技術問題，也不是新開發人員能做到的事情，需要足夠的經驗3

資料分析能力與大學課程相對應，我覺得應該是學習資料結構和數學建模，雖然我沒有正式學過這兩門課程，但似乎我在這方面還是很有天賦的，把具體的業務轉化成純粹的數學的東西，而且要盡可能簡單， 這不是每個人都能做到的，如果設計不合適，會造成後期無法維護，整個系統可能要被推翻，當然，這個設計者必須是程式設計師，但一定不能只是乙個程式設計師，需要足夠的經驗4找乙個對資訊化足夠重視的老闆 如果你做不到老闆，就得找乙個對資訊化足夠重視的老闆，否則可能要消耗你大部分的精力去說服老闆實現資訊化，即使你能說服對方，以上第乙個可能也很難實現， 如果這個老闆是技術背景出身，那你就很幸運了，溝通成本會降低很多，如果這個老闆是最普通的程式設計師，那麼你就中了大獎，不過，平時純技術背景的人需要沒有分心，不能顧全域性，這樣的人不適合當老闆。

需求者和設計師之間有良好的溝通。

設計師有很強的學習能力。

資料分析能力。

找乙個對資訊化足夠重視的老闆。

開發是指利用荒地、礦山、森林、水力等自然資源來達到利用目的; 利用; 發現或發掘人才、技術等以供利用。

在估算軟體工作量時，我認為您應該首先了解估算軟體專案工作量的主要方法是什麼。 常用的方法有三種：方程法、類比法和類比法。

通常，估計軟體專案工作負載是基於估計軟體大小作為輸入，然後使用方程法估計的結果。 但是，也有一些特殊情況，比如需求非常模糊，無法確定大小，軟體工作量可以直接通過類比或類比來估算。

根據我的個人經驗，在估算軟體專案的工作量時，如果你對上述三種方法的使用有足夠的了解，就很容易選擇合適的方法。 對於這3種方法的詳細介紹，我覺得你應該多學習一些，或者系統地了解一下軟體成本估算的知識，畢竟工作量估算只是軟體成本估算的一小部分。 我可以給大家推薦一本書，北京軟體成本評價技術創新聯盟出版、機械工業出版社出版的《軟體研發成本測算規範》第二版。

或者您也可以購買最近發布的國家標準《GB T 36964-2018 軟體工程軟體開發成本測算規範》，了解相關知識。

閱讀程式的能力 很多軟體開發工作不一定是從零開始的，這就要求開發人員具備良好的程式閱讀能力，在最短的時間內了解軟體的整體架構，了解軟體的初始開發思路，並快速有效地參與到專案開發中。 2.

編碼技能 這與開發人員對所用語言的熟練程度以及開發人員的程式設計風格有關。 開發者是否具備良好的程式設計習慣，能否遵循常用的程式設計規範，並做出好的批註，對開發者開發的**的可讀性和可維護性有很大的影響。 3.

除錯和測試能力 在現代軟體行業中，除錯和測試時間並不比編碼時間短，甚至超過，當然，很多除錯和測試工作不是由編碼人員完成的，但測試工作是許多軟體開發人員的唯一途徑。 4.

軟體維護 維護似乎不需要太多的能力，因為它需要開發人員更多的耐心。 我記得讀過這樣的話（大意是）：你的程式是你的孩子，在你生產出來之後，你仍然需要你的照顧才能成長和成熟 前面的討論是關於實際動手能力的，這是軟體開發人員的基本技能。

要評估開發人員的軟體開發能力，除了評估他的程式設計能力外，還應考慮其他重要能力，例如 1

需求分析能力 乙個專案需要在一開始就做一次需求分析，了解專案的目的、對系統的要求、對功能的要求，並對其進行分析，並做好專案計畫和描述 2

構建軟體框架的能力 構建乙個好的軟體框架是這個專案成功的保證，需要考慮整個軟體的一致性和完整性。

貫穿整個專案的管控能力 在專案開發過程中，難免會有新的要求、目標修正、或者人員變動等，有效的管控對開發者來說是乙個更高的要求 因為到現在為止，在軟體方面，我還只是在修改和修改別人的程式， 做加減功能、除錯和故障排除等，所以只能說這麼多，希望大家給意見，一起進步 0 從基本角度來說，應該涉及以下幾點：