Eksperimen yang menghubungkan metrik kode dengan kepadatan bug

Saya ingin tahu apakah seseorang telah melakukan beberapa percobaan yang menghubungkan metrik kode (SLOC, Cyclomatic Complexity, dll) dengan kepadatan bug dalam aplikasi Berorientasi Objek.

Saya tidak mencari eksperimen yang hanya membuktikan atau menyangkal korelasi, tetapi pada keduanya. Saya tidak berusaha menemukan peluru perak karena saya percaya bahwa kepadatan bug suatu proyek mungkin berkorelasi dengan satu atau lebih metrik untuk proyek atau tim tertentu dan korelasinya dapat berubah selama masa proyek / tim.

Tujuan saya adalah untuk

Ukur semua metrik menarik selama 2-3 bulan (kami sudah memiliki cukup banyak dari sonar).
Temukan satu metrik yang berkorelasi dengan jumlah bug baru.
Lakukan analisis akar-penyebab untuk memeriksa mengapa hal ini terjadi (mis. Apakah kita tidak memiliki keterampilan desain tertentu?).
Tingkatkan keterampilan dan ukur perubahan untuk beberapa itereations.
Bilas dan ulangi dari 2.

Jika Anda tidak memiliki pengalaman dalam hal ini, tetapi ingat melihat makalah / blog tentang hal ini, saya akan sangat menghargai jika Anda dapat membagikannya.

Sejauh ini saya telah menemukan tautan berikut dengan beberapa informasi tentang subjek ini

Apakah Bug Berada dalam Kode Kompleks? - hanya slide dari presentasi.
Perubahan dan Bug: Menambang dan Memprediksi Aktivitas Pembangunan - Hanya slide dari presentasi. Intinya semakin banyak ketergantungan, semakin tinggi kemungkinan bug (saya pikir ini adalah aturan umum).
Kegagalan adalah kata empat huruf - Paradinya tentang korelasi antara bug dan metrik.

code-quality code-metrics Augusto
sumber

Jika Anda ingin menghindari penutupan, Anda harus mengubah pertanyaan Anda. Situs Stack Exchange bukan mesin pencari dan pengguna bukan asisten penelitian pribadi . Alih-alih meminta tautan ke makalah, penekanannya harus pada menanyakan jenis metrik apa yang telah dikorelasikan dengan cacat dan kepadatan cacat.

Thomas Owens

Saya minta maaf karena pertanyaannya muncul sebagai permintaan untuk menjadi asisten pencarian pribadi saya , itu jelas bukan yang ingin saya lakukan, tetapi menemukan jenis kertas ini bukanlah sesuatu yang sangat umum. Saya telah mengubah judulnya sehingga orang lain tidak memiliki kesan yang sama.

Augusto

Jawaban:

Setiap kali saya mendengar upaya untuk mengaitkan beberapa jenis metrik berbasis kode dengan cacat perangkat lunak, hal pertama yang saya pikirkan adalah kompleksitas siklomatik McCabe . Berbagai penelitian telah menemukan bahwa ada korelasi antara kompleksitas siklomatik yang tinggi dan jumlah cacat. Namun, penelitian lain yang melihat modul dengan ukuran yang sama (dalam hal garis kode) menemukan bahwa mungkin tidak ada korelasi.

Bagi saya, baik jumlah baris dalam modul dan kompleksitas siklomatik dapat berfungsi sebagai indikator yang baik dari kemungkinan cacat, atau mungkin lebih besar kemungkinan cacat akan disuntikkan jika modifikasi dilakukan pada modul. Modul (terutama di tingkat kelas atau metode) dengan kompleksitas siklomatik yang tinggi lebih sulit untuk dipahami karena ada banyak jalur independen melalui kode. Modul (sekali lagi, terutama di tingkat kelas atau metode) dengan sejumlah besar garis juga sulit dipahami karena peningkatan garis berarti lebih banyak hal terjadi. Ada banyak alat analisis statis yang mendukung komputasi kedua baris kode sumber terhadap aturan yang ditentukan dan kompleksitas siklomatik, sepertinya menangkap mereka akan meraih buah yang menggantung rendah.

Langkah- langkah kompleksitas Halstead mungkin juga menarik. Sayangnya, validitas mereka tampaknya agak diperdebatkan, jadi saya tidak perlu bergantung pada mereka. Salah satu tindakan Halstead adalah perkiraan cacat berdasarkan pada usaha atau volume (hubungan antara panjang program dalam hal total operator dan operan dan kosakata program dalam hal operator dan operator yang berbeda).

Ada juga sekelompok metrik yang dikenal sebagai Metrik CK. Definisi pertama dari rangkaian metrik ini tampaknya ada dalam makalah berjudul Suite Metrik untuk Desain Berorientasi Objek oleh Chidamber dan Kemerer. Mereka mendefinisikan Metode Tertimbang Per Kelas, Kedalaman Pohon Warisan, Jumlah Anak, Kopling Antar Kelas Objek, Respon untuk Kelas, dan Kurangnya Kohesi dalam Metode. Makalah mereka menyediakan metode komputasi serta deskripsi tentang bagaimana menganalisis masing-masing.

Dalam hal literatur akademik yang menganalisis metrik ini, Anda mungkin tertarik dengan Analisis Empiris Metrik CK untuk Kompleksitas Desain Berorientasi Objek: Implikasi untuk Cacat Perangkat Lunak, yang ditulis oleh Ramanath Subramanyam dan MS Krishna. Mereka menganalisis tiga dari enam metrik CK (metode tertimbang per kelas, kopling antara objek kelas, dan kedalaman pohon warisan). Melirik kertas, tampak bahwa mereka menemukan ini berpotensi metrik valid, tetapi harus ditafsirkan dengan hati-hati karena "meningkatkan" seseorang dapat menyebabkan perubahan lain yang juga mengarah pada kemungkinan cacat yang lebih besar.

Analisis empiris Metrik Desain Berorientasi Objek untuk Memprediksi Kesalahan Tinggi dan Rendahnya Keparahan, yang ditulis oleh Yuming Zhou dan Hareton Leung, juga memeriksa metrik CK. Pendekatan mereka adalah untuk menentukan apakah mereka dapat memprediksi cacat berdasarkan metrik ini. Mereka menemukan bahwa banyak metrik CK, kecuali untuk kedalaman pohon warisan dan jumlah anak) memiliki beberapa tingkat signifikansi statistik dalam memprediksi area di mana cacat dapat ditemukan.

Jika Anda memiliki keanggotaan IEEE, saya akan merekomendasikan mencari di Transaksi IEEE pada Rekayasa Perangkat Lunak untuk publikasi akademis lebih banyak dan Perangkat Lunak IEEE untuk beberapa laporan yang lebih nyata dan diterapkan. ACM mungkin juga memiliki publikasi yang relevan di perpustakaan digital mereka .

Thomas Owens
sumber

Metrik Halstead semuanya telah terbukti sangat berkorelasi dengan SLOC mentah (jumlah baris kode sumber). Pada titik itu, apa pun yang berkorelasi dengan metrik Halstead diketahui berkorelasi dengan SLOC mentah, dan lebih mudah untuk mengukur SLOC daripada metrik Halstead mana pun.

John R. Strohm

@ JohnR.Strohm Saya tidak setuju bahwa menghitung SLOC lebih mudah daripada menghitung metrik Halstead, ketika Anda menggunakan alat untuk melakukan perhitungan. Dengan asumsi bahwa metrik Halstead adalah valid (yang sebenarnya diperdebatkan, tetapi tidak ada masalah untuk metrik yang tidak valid), mengetahui jumlah waktu yang diperlukan untuk mengembangkan kode atau jumlah cacat yang diproyeksikan dalam sistem adalah nilai yang lebih berguna daripada mengetahui jumlah garis. Saya dapat membuat jadwal dengan data waktu, rencana kualitas dengan data cacat, atau mengalokasikan cukup waktu untuk peninjauan kode dengan kesulitan. Lebih sulit menggunakan SLOC mentah untuk hal-hal itu.

Thomas Owens

@ JohnR.Strohm Saya yakin bahwa program perhitungan metrik Halstead membutuhkan waktu sedikit lebih lama daripada program penghitungan SLOC. Tetapi dengan asumsi output yang valid menjadi input yang valid ke dalam pengambilan keputusan, saya lebih suka memiliki waktu, upaya, dan data cacat yang berarti daripada jumlah SLOC mentah. Nilai tambah dari metrik yang lebih kompleks sering sepadan dengan waktu perhitungan tambahan, sekali lagi dengan asumsi input yang valid dan output komputasi yang valid.

Thomas Owens

@ThomasOwens, pertanyaan apakah upaya perangkat lunak, dan karenanya biaya dan jadwal, dapat diperkirakan secara langsung dari perkiraan SLOC mentah telah dilakukan sampai mati. Setelah banyak penelitian pada data proyek nyata, pertanyaan itu diselesaikan, dalam persetujuan. Lihat "Ekonomi Rekayasa Perangkat Lunak", oleh Barry Boehm, 1981.

John R. Strohm

@ThomasOwens: Selanjutnya, orang harus mengenali bahwa metrik Halstead secara inheren retrospektif. Anda tidak dapat mengukur metrik Halstead dari perangkat lunak yang belum Anda tulis. Di sisi lain, itu mungkin untuk memperkirakan SLOC mentah untuk tugas yang diberikan, dan, diberikan spesifikasi yang cukup rinci dan sedikit pengalaman, relatif mudah untuk mendekati perkiraan. Selain itu, SANGAT mudah untuk membandingkan perkiraan dengan yang sebenarnya, untuk menyempurnakan perkiraan heuristik seseorang, dan mengkalibrasi penduga biaya seseorang. General Dynamics / Fort Worth melakukan banyak hal dalam hal ini pada awal 1980-an.

John R. Strohm

Saya telah membahas kemungkinan korelasi di salah satu posting blog saya :

Korelasi antara Kompleksitas Siklomatik dan kepadatan Bug: Apakah ini Masalah sebenarnya?

Jawabannya adalah tidak. Menjaga ukurannya konstan, penelitian tidak menunjukkan korelasi antara CC dan kepadatan cacat. Namun, ada dua korelasi menarik lainnya untuk dipelajari:

Yang pertama adalah: Apakah CC sangat berkorelasi dengan durasi mendeteksi dan memperbaiki cacat? Dengan kata lain, jika CC lebih rendah, akankah kita menghabiskan lebih sedikit waktu untuk debug dan memperbaiki cacat?

Yang kedua adalah: Apakah CC sangat berkorelasi dengan Fault Feedback Ratio (FFR, jumlah rata-rata cacat yang dihasilkan dari menerapkan satu perubahan atau memperbaiki satu cacat)?

Perlu penyelidikan lebih lanjut untuk melihat apakah ada orang yang pernah mempelajari korelasi ini secara empiris. Tetapi, perasaan saya dan umpan balik yang saya dapatkan dari tim tempat saya bekerja adalah bahwa ada korelasi positif yang kuat antara kompleksitas siklomatik di satu sisi dan lamanya mendeteksi dan memperbaiki cacat atau dampak perubahan di sisi lain.

Ini adalah eksperimen yang bagus untuk dilakukan. Tetap waspada untuk hasilnya!

Amr Noaman
sumber

Tidak layak untuk downvote, tetapi itu harus "beberapa studi tidak menunjukkan korelasi", karena studi lain memang menunjukkan korelasi.

David Hammen

Dalam buku Code Complete, hal.457, Steve McConnell mengatakan bahwa "kompleksitas kendali-aliran itu penting karena telah dikorelasikan dengan keandalan yang rendah dan dan sering terjadi kesalahan". Dia kemudian menyebutkan beberapa referensi yang mendukung korelasi itu, termasuk McCabe sendiri (yang dipercaya telah mengembangkan metrik kompleksitas siklomatik). Sebagian besar dari ini menganjurkan penggunaan bahasa berorientasi objek secara luas, tetapi karena metrik ini berlaku untuk metode dalam bahasa tersebut, referensi mungkin adalah apa yang Anda cari.

Referensi tersebut adalah:

McCabe, Tom. 1976. "Ukuran Kompleksitas." Transaksi IEEE pada Rekayasa Perangkat Lunak, SE-2, no. 4 (Desember): 308-20
Shen, Vincent Y., dkk. 1985. "Mengidentifikasi Perangkat Lunak Rawan Kesalahan - Sebuah Studi Empiris." Transaksi IEEE pada Rekayasa Perangkat Lunak SE-11, no.4 (April): 317-24.
Ward, William T. 1989. "Pencegahan Cacat Perangkat Lunak Menggunakan Metrik Kompleksitas McCabe." Hewlett-Packard Journal, April, 64-68.

Dari pengalaman saya sendiri, metrik McCabe, karena dapat dihitung oleh program pada banyak bagian kode, berguna dalam menemukan metode dan fungsi yang terlalu rumit dan yang memiliki probabilitas tinggi mengandung kesalahan. Meskipun saya belum menghitung, distribusi kesalahan dalam fungsi kompleksitas siklomatik tinggi versus fungsi kompleksitas siklomatik rendah, menyelidiki fungsi-fungsi tersebut telah memungkinkan saya untuk menemukan kesalahan pemrograman yang diabaikan.

QuantumOmega
sumber