2009-06-29 46 views
7

我想知道是否有人有衡量軟件質量的指標。我知道有代碼複雜性度量標準,但是我想知道是否有一種特定的方法來衡量它在生命週期中實際執行的效果。我不是指運行時間性能,而是衡量質量。任何建議的工具,這將有助於收集這些也是受歡迎的。軟件質量指標

有測量來回答這些問題:

  • 有多容易改變/增強軟件,健壯性
  • 如果是普通/一般足夠的軟件,如何可重複使用的是
  • 有多少缺陷的代碼
  • 先後此需要重新設計相關/重新編碼
  • 已這段代碼被周圍
  • 多久10
  • 開發者喜歡代碼是如何設計和實現的

看起來像大多數這將需要與CM和錯誤報告工具密切聯繫。

+2

社區維基... – 2009-06-29 21:07:03

回答

0

老軟件Joel在Software Discussion groups上有一個很好的thread

0

我知道一些SVN stat程序提供了對每次提交更改行的概述。如果您有錯誤跟蹤系統,並且修復錯誤的人員在修正錯誤時指出他們的提交編號,則可以計算每個錯誤/新功能請求影響的線數。這可以給你一個可變性的度量。

接下來的事情是簡單地計算找到的錯誤數量,並將它們與代碼行數量的比率進行設置。有一些價值觀看高質量軟件每個代碼行應該有多少錯誤。

0

你可以在一些經濟的方式程序員的方式

如果使用經濟的方式,您可以減少代碼改進,修復錯誤,增加新功能等等。如果您選擇第二種方式,您可能需要測量員工在程序中的工作量,以及查找和修復人爲小時的平均錯誤的容易程度。當然,它們並非完美無瑕,因爲成本取決於市場情況,人的時間取決於實際的人員和技能,所以最好將兩種方法結合起來。

這樣你就可以得到一些儀器來保證你的代碼的質量。當然,你應該考慮到你的項目的規模和其他因素,但我希望主要想法很明確。

1

如果按照您所說的術語來衡量代碼質量將是一件非常簡單的工作,且指標準確無誤,那麼可能不再需要項目經理了。更重要的是,好的和差的管理者之間的區別是非常小的。因爲它不是,這只是表明獲得關於軟件質量的準確概念並非易事。

您的問題涉及到多個量化不同的領域或對量化非常主觀的領域,因此您應將這些問題歸入與常見目標相對應的類別。然後,您可以爲每個類別分配一個「重要性」因素,並從中得出一些指標。

例如,您可以使用static code analysis tools來測量代碼的語法質量,並從中得出一些指標。

您還可以使用與版本控制系統集成的缺陷跟蹤工具從缺陷/代碼行中得出度量標準。

爲了測量編碼過程的穩健性,重用性和效率,您可以評估每個功能開發的設計模式的使用情況(當然這是有意義的)。沒有任何工具可以幫助你實現這個目標,但是如果你監視你的軟件變得越來越大,並且把數字放在這些數據上,它可以給你一個關於你的項目如何發展以及它是否朝着正確的方向的好主意。引入代碼審查程序可以幫助您更輕鬆地跟蹤這些過程,並可能在開發過程的早期解決它們。可以使用適當設計模式實現的功能的百分比。

雖然指標可能相當抽象且主觀,但如果您花時間去嘗試改善它們,它可以爲您提供有用的信息。

有幾件事情需要注意的軟件過程,雖然指標:

  1. 除非你做的好,指標可能被證明是弊大於利。
  2. 指標很難做好。
  3. 您應該謹慎使用指標評估個人表現或提供獎金計劃。一旦你這樣做,每個人都會試圖欺騙系統,你的指標將被證明毫無價值。
1

如果你使用Ruby,也有一些工具來幫助您與指標從交通線/方法與方法/類Saikuros圈複雜度。

我的老闆實際持有的軟件度量的演示,我們在去年紅寶石會議使用,these are the slides.

一個有趣的工具,爲您帶來了很多指標一次是metric_fu。它會檢查代碼的很多有趣的方面。那些高度相似的東西,變化很大,有很多分支。所有的跡象你的代碼可能會更好:)

我想有很多其他語言也是這樣的工具。

0

更關注客戶的度量標準是軟件供應商修復錯誤和實現新功能所需的平均時間。

根據您創建的錯誤跟蹤軟件的日期和已關閉的信息,它很容易計算。

如果您的平均錯誤修復/功能實施時間非常高,這也可能是軟件質量不佳的指標。

0

您可能需要檢查以下內容page描述軟件質量的各個不同方面,包括樣本圖。您需要測量的一些質量特性可以使用Sonar等工具推導出來。弄清楚如何建立以下幾個方面的模型非常重要:

  1. 可維護性:您確實提到了更改/測試代碼或重用代碼有多容易。這些與可維護性的可測試性和可重用性方面有關,這被認爲是關鍵的軟件質量特性。因此,您可以將可維護性作爲可測試性(單元測試覆蓋率)和可重用性(代碼的粘性指數)的函數進行度量。
  2. 缺陷:缺陷本身可能不是一個好主意來衡量。但是,如果您可以對缺陷密度進行建模,則可以爲您提供良好的圖像。