Kod metriklerini hata yoğunluğuyla ilişkilendiren denemeler

Birisi Nesne Odaklı uygulamalarda hata yoğunluğu ile kod metrikleri (SLOC, Siklomatik Karmaşıklık, vb) ilişkilendiren bazı deneyler yaptığını merak ediyorum.

Sadece bir korelasyonu kanıtlayan veya çürüten deneyler aramıyorum, ama her ikisinde de. Ben bir projenin hata yoğunluğu inanıyoruz olarak Gümüş mermi bulmaya çalışıyorum değilim belki belirli bir proje veya takımın bir veya birkaç metrikleri ilişkilendirmek ve korelasyon proje / ekibin ömrü boyunca değişebilir.

Amacım

1. Tüm ilginç metrikleri 2-3 ay boyunca ölçün (zaten sonardan çok azımız var).
2. Yeni hataların sayısıyla ilişkili bir metrik bulun.
3. Bunun neden olduğunu kontrol etmek için bir temel neden analizi yapın (örneğin, belirli bir tasarım becerisine sahip değiliz mi?).
4. Beceriyi geliştirin ve birkaç tekrar için değişimi ölçün.
5. Durulayın ve 2'den tekrarlayın.

Bu konuda herhangi bir deneyiminiz yoksa, ancak bu konuda bir makale / blog görmeyi unutmayın, paylaşabiliyorsanız sevinirim.

Şimdiye kadar bu konu hakkında bazı bilgiler içeren aşağıdaki bağlantıları buldum

• Hatalar karmaşık kodda ikamet ediyor mu? - sadece sunumdaki slaytlar.
• Değişiklikler ve Hatalar: Madencilik ve Kalkınma Faaliyetlerini Tahmin Etme - Sadece bir sunumu kaydırın. Alt satırda daha fazla bağımlılık, hata şansı o kadar yüksek (bence bu oldukça genel bir kural).
• Başarısızlık dört harfli bir kelimedir - Hatalar ve metrikler arasındaki korelasyonla ilgili bir geçit töreni.

Kod tabanlı bir metriği yazılım kusurlarıyla ilişkilendirme girişimlerini her duyduğumda, ilk düşündüğüm McCabe'nin siklomatik karmaşıklığı . Çeşitli çalışmalar, yüksek siklomatik karmaşıklık ile hata sayısı arasında bir korelasyon olduğunu bulmuştur. Bununla birlikte, benzer büyüklükteki modüllere (kod satırları açısından) bakan diğer çalışmalar, bir korelasyon olmayabilir.

Bana göre, bir modüldeki hem satır sayısı hem de siklomatik karmaşıklık olası hataların iyi bir göstergesi olabilir veya belki de bir modülde değişiklikler yapılırsa hataların enjekte edilmesi olasılığı daha yüksektir. Kodda çok sayıda bağımsız yol olduğu için yüksek siklomatik karmaşıklığa sahip bir modülün (özellikle sınıf veya yöntem düzeyinde) anlaşılması daha zordur. Çok sayıda çizgiye sahip bir modülü (yine, özellikle sınıf veya yöntem düzeyinde) anlamak da zordur, çünkü çizgilerin artması daha fazla şey olduğu anlamına gelir. Her iki kaynak kod satırını belirtilen kurallara ve siklomatik karmaşıklığa karşı hesaplamayı destekleyen birçok statik analiz aracı vardır, bunları yakalamak düşük asılı meyveyi yakalar gibi görünüyor.

Halstead karmaşıklık ölçütleri de ilginç olabilir. Ne yazık ki, geçerlilikleri biraz tartışılmış gibi görünüyor, bu yüzden onlara güvenmem gerekmiyordu. Halstead'in önlemlerinden biri, çaba veya hacime (toplam operatörler ve işlenenler açısından program uzunluğu ile farklı operatörler ve operatörler açısından program kelime dağarcığı arasındaki ilişki) dayalı bir tahminlerdir.

CK Metrikleri olarak bilinen bir grup metrik de vardır. Bu metrik paketinin ilk tanımı Chidamber ve Kemerer tarafından Nesneye Yönelik Tasarım İçin Bir Metrikler Paketi adlı bir makalede yer alıyor. Sınıf Başına Ağırlıklı Yöntemler, Kalıtım Derinliği, Çocuk Sayısı, Nesne Sınıfları Arasındaki Bağlanma, Bir Sınıf İçin Yanıt ve Yöntemlerde Uyum Eksikliğini tanımlar. Makaleleri, hesaplama yöntemlerinin yanı sıra her birinin nasıl analiz edileceğinin açıklamasını da sağlar.

Bu metrikleri analiz eden akademik literatür açısından, Nesne Odaklı Tasarım Karmaşıklığı için CK Metriklerinin Ampirik Analizi: Ramanath Subramanyam ve MS Krishna tarafından yazılan Yazılım Hataları için Çıkarımlar ilginizi çekebilir. Altı CK metriğinden üçünü analiz ettiler (sınıf başına ağırlıklı yöntemler, sınıflandırılan nesne arasındaki bağlantı ve kalıtım ağacının derinliği). Belgeye bakıldığında, bunların potansiyel olarak geçerli metrikler olduğunu gördükleri, ancak "iyileştirme" olarak daha fazla hata olasılığına yol açabilecek diğer değişikliklere yol açabileceği için dikkatle yorumlanması gerektiği anlaşılmaktadır.

Yuming Zhou ve Hareton Leung tarafından yazılan Yüksek ve Düşük Şiddetli Hataların Öngörülmesi için Nesneye Dayalı Tasarım Metriklerinin Ampirik Analizi de CK metriklerini inceler. Yaklaşımları, bu metriklere dayalı hataları tahmin edip edemeyeceklerini belirlemekti. Kalıtım ağacının derinliği ve çocuk sayısı hariç olmak üzere CK metriklerinin çoğunun, kusurların bulunabileceği alanların öngörülmesinde bir miktar istatistiksel anlamlılığa sahip olduğunu bulmuşlardır.

IEEE üyeliğiniz varsa, daha akademik yayınlar için IEEE Yazılım Mühendisliği İşlemlerini ve daha gerçek dünya ve uygulamalı raporlar için IEEE Yazılımını aramanızı tavsiye ederim . ACM'nin dijital kütüphanelerinde de ilgili yayınlar olabilir .

Blog gönderilerimden birinde olası korelasyonları tartıştım :

Siklomatik Karmaşıklık ile Hataların Yoğunluğu Arasındaki Korelasyon: Bu gerçek Konu mu?

Cevap hayır. Büyüklüğü sabit tutan çalışmalar , CC ile kusur yoğunluğu arasında bir korelasyon olmadığını göstermektedir. Bununla birlikte, çalışılacak iki ilginç korelasyon vardır:

Birincisi: CC, kusurları tespit etme ve düzeltme süresi ile güçlü bir şekilde ilişkili mi? Başka bir deyişle, eğer CC daha düşükse, hata ayıklamak ve hataları düzeltmek için daha az zaman harcar mıyız?

İkincisi: CC, Hata Geri Bildirim Oranı (FFR, bir değişikliğin uygulanmasından veya bir hatanın düzeltilmesinden kaynaklanan ortalama hata sayısı) ile güçlü bir şekilde ilişkili mi?

Birinin bu korelasyonu ampirik olarak incelemiş olup olmadığını görmek için daha fazla araştırmaya ihtiyaç vardır. Ancak, bağırsak hissim ve birlikte çalıştığım ekiplerden aldığım geri bildirimler, bir tarafta siklomatik karmaşıklık ile bir arızayı tespit etme ve düzeltme süresi veya başka bir taraftaki değişiklik etkisi arasında güçlü bir pozitif korelasyon olması.

Bu iyi bir deney. Sonuçlar için tetikte olun!

Code Complete, s.457 kitabında Steve McConnell, "düşük güvenilirlik ve sık hatalarla ilişkili olduğu için kontrol akışı karmaşıklığının önemli olduğunu" söylüyor. Daha sonra, McCabe'nin kendisi de dahil olmak üzere (siklomatik karmaşıklık metriğini geliştirdiği düşünülen) bu korelasyonu destekleyen birkaç referanstan bahseder. Bu tarihlerin çoğu nesne yönelimli dillerin yaygın olarak kullanılmasından önceki tarihlerdir, ancak bu metrik bu dillerdeki yöntemlere uygulandığından referanslar aradığınız şey olabilir.

Bu referanslar:

• McCabe, Tom. 1976. "Bir Karmaşıklık Ölçüsü." IEEE Yazılım Mühendisliği İşlemleri, SE-2, no. 4 (Aralık): 308-20
• Shen, Vincent Y., vd. 1985. "Hataya meyilli Yazılımları Belirleme - Ampirik Bir Çalışma." Yazılım Mühendisliğinde IEEE İşlemleri SE-11, no.4 (Nisan): 317-24.
• Ward, William T. 1989. "McCabe Karmaşıklık Metriğini Kullanarak Yazılım Hatalarını Önleme." Hewlett-Packard Journal, 64-68 Nisan.

Kendi tecrübelerime göre, McCabe metriği, birçok kod bölümündeki bir program tarafından hesaplanabileceğinden, aşırı karmaşık olan ve hata olasılığı yüksek olan yöntem ve işlevleri bulmakta yararlıdır. Her ne kadar hesaplamamış olsam da, yüksek-siklomatik karmaşıklık fonksiyonlarındaki hataların düşük-siklomatik karmaşıklık fonksiyonlarına karşı dağılımı, bu fonksiyonları araştırmak gözden kaçan programlama hatalarını keşfetmeme izin verdi.