如何評估項目大小？如何確定項目的大小（代碼行，功能點等）
A部分：在開始一個項目之前。
B部分：對於一個完整的項目。
我有興趣比較無關項目。這裏有一些選項：
1）代碼行。
2）功能點。
有沒有人有另一種解決方案？所花費的時間似乎可能是一個有用的指標，但不完全是。如果我問你什麼是「更大的計劃」，並給你兩個計劃，你會如何處理這個問題？
我已經看到了關於stackover流的幾個討論，但大多數討論如何衡量程序員的生產力。我對項目規模更感興趣。
我們使用「人日」來確定項目的成本。 單個普通男士將在多少天內完成該項目。 （好吧，有時候多少年）
代碼行不是最好的，但不是最差的單位，但排除'庫'。
一項研究估計，一個開發者可以寫10行/日，仍然在最後的程序。 （但他也會做概念，文檔，管理項目等...）
例如，檢查Ohloh project哪些分析一些開源項目，他們估計成本與COCOMO算法（online calculator）。 基地是代碼行。
你從哪裏得到10行/每天？我會對閱讀那篇文章感興趣。 – sixtyfootersdude 2010-06-01 09:55:29
在IT課程期間，回到學校，抱歉我沒有在線資源。 但我猜測它是低估的，因爲該主題是爲了強調大型項目中缺陷檢測階段的成本。 我再說一遍：這是整個項目每個工作日的最終貢獻。不是程序員的生產/日子。 我會對別人的答案感興趣。 – Syprien 2010-06-01 10:15:23
A部分 開始之前很難完全測量一個項目。如果你曾經參與過任何相當大的軟件項目（聽起來像你一樣），這些要求事實上會隨着時間而改變。但是，如果您在敏捷的環境中工作，我認爲故事點是衡量軟件大小的好方法。在項目開始時，你不會有所有的細節，但你應該有足夠的估計。不明朗因素http://www.construx.com/Page.aspx?hid=1648的圓錐給出了一個很好的可視化，你可能會有多精確/精確。
B部分 您也可以在這裏使用故事點。項目完成後，您應該知道您完成了多少個故事點。你也可以測量你的團隊的速度（故事點數除以某個時間段）。
這裏的關鍵之一是您的團隊正在使用類似的故事點數量，因此一個團隊需要2個故事點的任務等同於其他團隊的2點故事。
A部分：
恕我直言，敏捷方法爲評估項目範圍的先驗的最佳途徑。你必須擁有一個已知速度的團隊，在發佈積壓時首先進行裁減，並以同樣的方式對團隊建立速度的項目進行大小分類。如果您有興趣，可以在http://www.rallydev.com/learn_agile/agile_planning/release_planning/有一個很好的幻燈片。
Agilists會指出你實際上選擇了改變範圍與日期/質量。所以從技術上講，你並沒有估計項目的規模。相反，您會優先考慮您的積壓以適應固定的時間段。儘管如此，一支經驗豐富，經驗豐富的團隊可以給你一個合理的想法，告訴他們什麼時候可以交付。
部分B：
我覺得你的問題的關鍵部分是「無關」。國際海事組織這些指標僅適用於比較類似項目的情況 - 就團隊，專業知識，開發環境，應用領域等而言。項目越「不相關」，比較項目規模就越困難。 KLOC和功能點指標似乎是應用最廣泛的。
有一家名爲QSM Associates（http://www.qsma.com/tools.html）的公司，擁有大型比較項目數據庫。你可能想看看他們的網站的資源。
我不確定這是否可以作爲答案，但我的聲譽太低，無法評論。
你的問題非常非常廣泛。有很多書籍試圖用不同的運氣來回答你的擔憂。
試圖在幾行中恢復整個字段（至少）是誤導性的。
我建議從這裏開始：http://www.itmpi.org/這是一個很好的網站，充滿了鏈接和適當的書目。
OP如何衡量項目規模？我的意思是，OP會使用哪些測量單位？在你的回答中，要小心建議測量項目大小而不是（計算機）程序大小。
在回答A部分時，我會花費時間和精力。以天爲單位的時間（如果是足夠小的項目，則以小時爲單位），以人爲度量。這然後給出成本=時間×人的成本。在項目規劃中，對任何措施的估計值（例如200萬美元（+/- 0.2百萬美元））都伴隨着這些估計值的變化估計也是至關重要的。
我可能會使用計算機程序大小的度量，例如LOC或函數點來估計項目的編程部分。但我不會使用這種估計值和乘數（比如說）來估計一個項目的成本和持續時間。我的意思是，我不會使用100天編程的估計值加上2.5的係數來獲得250天的項目大小。
當然，當你所擁有的只是項目的兩行描述時，你將得到的是一個模糊的估計，其誤差範圍很大。在您完善計劃並確定子任務時，您可以更準確地進行估算。
一旦項目完成，我會希望我的統計數據與我的原始估計數據相同，以便進行比較，省時省力。我不確定我是否會使用LOC作爲衡量生產力的指標，即使是回顧性的，我會更傾向於使用某種度量的功能，儘管標準方法（如功能點分析）並不可行以及目前我正在工作的領域，複雜的科學和技術規範。
編輯：我對時間，精力和成本的建議，部分基於我作爲項目經理處理客戶，經理等非IT利益相關者的經驗。項目管理是一項業務活動，以及向總會計師或銷售和營銷團隊說LOC和功能點，這是不正確的。
我可以推薦一本關於Steve McConnell的主題 - Rapid Development的真正優秀的書。這是寫了Code Complete的同一個人，是恕我直言的一本遠遠更好更重要的書。它會告訴你一切你需要了解項目估算和測量。
代碼行是專門使用的危險措施。考慮2位開發人員，他們在3行中寫入一些功能，另一位在50行中實現相同功能。誰更有成效？我已經在大型系統上看到了這一點。這就是爲什麼我傾向於避開LOC。
我很喜歡使用功能點的功能大小。他們需要一點學習，但一旦你已經學會了如何計數和如何的規則，他們就會帶來確定性，否則就會產生主觀性。已發佈的基於功能點的度量標準可以揭示您對軟件和軟件項目的深入洞察，而這些不會從LOC中獲得。
所以相信它們的用處的，我寫了一個應用程序供大家使用，使得它更容易和更快的計算功能點：projectsizer.com
一天計數300 FP是很實現的。 MI系統的美國平均每個成本費用約爲1500美元，因此一天可以算出300個。
如果您有Visual Studio，則可以運行代碼分析。它給了你圓複雜性，繼承深度，LOC和各種其他工具，告訴你它變得太複雜了...... – Carlos 2010-06-01 08:52:33
我能問你爲什麼想知道你想要達到什麼嗎？這可能會影響最適當的措施。基本上，你的意思是什麼？ – 2010-06-01 14:42:47