缺陷率跟蹤最適合什麼？每個KLOC的缺陷？

Question

我想創建一些內部指標來演示（確定？）TDD如何改善代碼中的缺陷率。

有沒有比缺陷/ KLOC更好的方法？一種語言的「功能密度」呢？

任何意見或建議將是有幫助的。

謝謝 - 喬納森

Answer 1

您也可以考慮映射缺陷發現率和缺陷解決率...要花多長時間才能發現錯誤，而且一旦他們發現，他們是否需要多長時間才能修復？據我所知，TDD應該在修復時間方面有所改進，因爲它會使得早期的缺陷被發現......對嗎？

Answer 2

任何措施是缺陷與代碼大小的任意比較;只要比較相似，它應該可以工作。例如，C中的缺陷/ kloc與C中的缺陷/ kloc。如果您更改了語言，則會影響度量標準，因爲使用其他語言編寫的相同程序可能不太容易出現缺陷。

Answer 3

我建議使用的時間之間的比：

1. 的時間花費修正錯誤
2. 的時間花費寫其他代碼

這種跨似乎有效語言...

---

它也適用，如果你只是粗略估計一些大的代碼庫。您仍然可以將其與您正在編寫的新代碼進行比較，以打動您的管理;-)

Answer 4

測量缺陷並非易事。人們想說明代碼的複雜性，但這是令人難以置信的混亂和不愉快。當測量代碼質量，我建議：

1. 測量電流狀態（你現在的不良率）
2. 進行更改（同行評審，培訓，準則的指導原則等）
3. 衡量新缺陷率（有事情好轉？）
4. 轉到2

如果你要比較程序員確保你比較編碼器做類似的工作，在相同的語言。不要將在最複雜的計算引擎的深層內部工作的編碼人員與編寫存儲數據庫中代碼的代碼的編碼人員進行比較。

我嘗試確保編碼員知道該過程正在被測量而不是編碼器。這有助於提高指標的質量。

Answer 5

我對所有與LOC相關的度量都持懷疑態度，不僅僅因爲語言的相對錶達能力不同，而且因爲各個程序員在代碼的表達能力上會有足夠的差異，使得這個度量最好是「模糊」的。

我會在項目管理中的利益衡量的事情是：

• 對項目開放缺陷的數量。沒有任何一個標量可以告訴你項目在哪裏，它與可釋放狀態有多接近，但這仍然是一個方便的數字，可以隨時隨地觀看。
• 缺陷的檢測率。這不是將新缺陷引入系統的速度，但它可能是您找到的最接近的代理。
• 缺陷解決率。如果這個數字低於檢測率，那麼你落後了 - 如果它更大，你就會領先。

如果將這些數字與嚴重性信息結合使用，所有這些數字都會更有用。具有20個小錯誤的產品可能比具有2個崩潰錯誤的產品更接近釋放。如果你正在清理小錯誤而不是嚴重錯誤，你必須讓開發人員重新關注它。

我會跟蹤每個項目和每個開發這些數字。每個項目的理由應該清楚。每個開發人員的數字當然不是個人貢獻者的技能或生產力的全貌，但可以指出可能需要培訓或補救的人員。

您可能還希望通過項目模塊標記在你的缺陷跟蹤系統中所有的門票，以及（特別是對於較大的項目），這樣，當關鍵模塊處於脆弱狀態，你可以告訴。

Answer 6

你爲什麼不考慮按使用情況下的缺陷？或每個要求的缺陷。我們在抵達KLOC時遇到了實際問題。