各位好,

目前敝公司正在準備搜集IR/KLOC值,我知道KLOC的計算各家算法不同,不知是否有人願意談談看KLOC的計算有那些算法.

目前我是用寫程式批次去計算,去除空白 & 註解行後,且只計算程式指令的部分(即不包含變數定義區),不過我想針對某些迴圈運算子或者是判斷運算子給予不同的權數,只是這個權數不知是否有參考值?

建議您不必太在意這些，從頭到尾只要是使用同一標準計算就可以了
多一點時間開發產品比較實際一點

Damnit的看法是...
要看您的目標是什麼啦

如果你考慮到維護的問題，那麼程式的註解當然也該算進去，因為寫註解也是要花時間的，如果不算的話，工程師為什麼要寫程式註解呢？

建議您只要是花effort去寫出來的東西，就該被列計吧。

如果你要算實際寫程式所花費的effort，那麼，最好要把reuse，但沒有做任何修改的程式碼排除掉。修改後reuse的部分，只計算修改的程式碼行數。

使用別人家的元件，那麼要把別人家的元件可能的程式碼行數排除。
呼叫開發環境提供的元件或函式，這些也應該被去掉的。

還有在計算程式的品質時，會用到Defect Density Value，以程式規模為分母，Defect數目為分子，因此，為使整個計算有意義，而且不失真，應該最真實地反映出專案人員花費effort所產生的程式規模。

謝謝eyeball的回應,不過之所以要計算KLOC,是為了累積quality的標準值,也就是CMMI要我們做的measurement->metric的功夫.

Damnint,你說到了我問這個問題的root cause,的確是為了計算Defect Density Value,而倒不是為了預估effort用,不過現在問題是出在分母的部分,所謂的<程式規模>,到底是用KLOC 或者是專案"預計effort" ,又或者是最後反應出來的"實際投入effort"呢?

Liangh 您好：

這個問題應該分兩個部分來說：
其一：為建立程式碼審查(Code Review)離去準則(Exit Criteria)而律定：
在專案前期階段，基於成本、品質與工作規劃三者求取平衡點時考慮。因為專案的預算多半是固定的，配置給V&V的預算不會無限制地擴張(當然如果是「非以軟體開發為營利目的」之組織，其內部自己的團隊在開發軟體，狀況可能又不一樣)，而審查的工作卻都是要算成本的，那麼那些程式碼要做審查？要做多少次的審查？找到多少那一類缺陷，達到多少的缺陷密度臨限(threshold)(簡單說，就是可以容忍的DDV)時，就可以將審查結束，而同時可以兼顧到軟體的品質？這時候，由於沒有實際的軟體規模數據(KLOC)，所以這個時候，是採用預估的KLOC(或EKLOC)，此時的主要目的是要得到DDV，作為程式碼審查工作的離去準則。當然，這個時候最好是能以過去的經驗值來估算，而此時此刻的估算也可以作為以後估算的參考。

其二：在實際進行程式碼審查時：
這個時候，接受審查之程式規模，當然是以實際的KLOC來計算了。

附帶一提：不論是CMMI也好、ISO/IEC 12207、ISO/IEC 15504、ISO 9001......，在這些不論是組織導向(CMMI, ISO/IEC 15504, ISO 9001, CNS 12681, CNS 14785)的軟體品質管理制度框架，或者是軟體本身導向(ISO/IEC 12207, CNS 14837)的軟體品質管理制度框架，所要求的目標，常常是數個項目可以透過一個活動而達到的。所以在工作設計或表單設計上就必須要有技巧，要巧妙地把很多個項目在同一個活動中涵蓋，以免增加人員的負擔。
就以一個程式碼審查來說，可以看到程式碼的缺陷狀況、程式碼的可維護性、可分析性、適用性、正確性的問題，程式碼審查也可以看到生產力的問題、程式設計人員技術水準的問題、審查所花費的Effort、成本效益的問題、......端看組織的需求、對於工程管理的能力及數據解讀的能力了。

----------------
引文:

(1)KLOC本身並未於相關標準文件中敘述，但如果討論範圍考慮為Source Line of Code，目前一般都接受SEI報告CMU/SEI-92-TR-20 Figure 2-2的計算法：就是不計算Comments以及Nonexecutable部分；
(2)KLOC本身可應用於COCOMO以及COSYSMO的計算，前者可將KLOC轉換為整個計畫所需MAN-MONTH，後者可將KLOC轉換為計畫執行的最小TIME PERIOD，但COCOMO與COSYSMO的計算隨language、domain、CASE tool、project size、project risk factor、team maturality、....而有極大差異因此必須調整眾多factors，我以前參與的專案計算出來的數字是“3 SLOC/per staff/per day”，當時美國國安局公佈的美方標準值是“50 SLOC/per staff/per month”；
(3)以下這一份報告可以提供與KLOC蠻有趣的統計資料，它包括的軍用與商用的眾多doamin的資訊
http://www.softwaretechnews.com/stn7-2/reifer.html
(4)前述KLOC的計算如果專案有使用RE-USE components，必須依據報告之參考文獻[2]與[3]計算出ESLOC (EQUIVALENT SOURCE LINE OF CODE)