Metrik Objektif untuk Kualitas Perangkat Lunak [ditutup]

12

Ditutup . Pertanyaan ini perlu lebih fokus . Saat ini tidak menerima jawaban.

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga berfokus pada satu masalah hanya dengan mengedit posting ini .

Ditutup 4 tahun yang lalu .

Ada berbagai jenis kualitas yang dapat diukur dalam produk perangkat lunak, misalnya kesesuaian untuk tujuan (misalnya penggunaan akhir), rawatan, efisiensi. Beberapa di antaranya agak subyektif atau spesifik domain (misalnya prinsip-prinsip desain GUI yang baik mungkin berbeda lintas budaya atau tergantung pada konteks penggunaan, pikirkan penggunaan militer versus penggunaan konsumen).

Yang saya minati adalah bentuk kualitas yang lebih dalam terkait dengan jaringan (atau grafik) jenis dan keterkaitannya, yaitu jenis apa yang dirujuk oleh masing-masing jenis, apakah ada kelompok interkonektivitas yang teridentifikasi dengan jelas yang berkaitan dengan arsitektur berjenjang, atau sebaliknya apakah ada 'bola' besar referensi tipe (kode 'monolitik'). Juga ukuran masing-masing jenis dan / atau metode (misalnya diukur dalam jumlah kode byte Java atau .Net IL) harus memberikan beberapa indikasi di mana algoritma kompleks besar telah diterapkan sebagai blok kode monolitik alih-alih didekomposisi menjadi lebih mudah dikelola / dikelola. potongan.

Analisis yang didasarkan pada ide-ide semacam itu mungkin dapat menghitung metrik yang setidaknya merupakan proksi kualitas. Ambang batas / titik keputusan yang tepat antara kualitas tinggi dan rendah akan saya curigai bersifat subyektif, misalnya karena dengan pemeliharaan berarti pemeliharaan oleh programmer manusia dan karenanya dekomposisi fungsional harus kompatibel dengan cara kerja pikiran manusia. Karena itu saya bertanya-tanya apakah akan pernah ada definisi kualitas perangkat lunak yang secara matematis murni yang melampaui semua perangkat lunak yang mungkin dalam semua skenario yang mungkin.

Saya juga bertanya-tanya apakah ini ide yang berbahaya, bahwa jika proksi obyektif untuk kualitas menjadi populer maka tekanan bisnis akan menyebabkan pengembang mengejar metrik ini dengan mengorbankan kualitas keseluruhan (aspek kualitas yang tidak diukur oleh proksi).

Cara berpikir lain tentang kualitas adalah dari sudut pandang entropi. Entropi adalah kecenderungan sistem untuk kembali dari keadaan tertata menjadi tidak teratur. Siapa pun yang pernah bekerja di dunia nyata, proyek perangkat lunak skala menengah hingga besar akan menghargai sejauh mana kualitas basis kode cenderung menurun seiring waktu. Tekanan bisnis umumnya menghasilkan perubahan yang berfokus pada fungsionalitas baru (kecuali jika kualitas itu sendiri adalah titik penjualan utama, misalnya dalam perangkat lunak avionik), dan pengikisan kualitas melalui masalah regresi dan fungsi 'kemunculan sepatu' yang tidak cocok dengan perspektif kualitas dan pemeliharaan. Jadi, dapatkah kita mengukur entropi perangkat lunak? Dan jika demikian, bagaimana caranya?

quality metrics measurement

— redcalx
sumber

Saya setuju dengan S. Lott. Dalam kehidupan sering ada perbedaan antara 'bagaimana seharusnya' dan 'bagaimana itu'. Anak laki-laki apakah saya berharap lebih banyak orang di planet ini telah mengatasi pendekatan 'niat baik' mereka dan memandang keras 'bagaimana itu'. Selain insentif yang salah, akan ada rasa aman palsu yang berbahaya. Kombinasikan itu dengan orang yang mencoba permainan sistem (yang alami karena mereka SELALU mencoba untuk memperbaiki kondisi mereka (baik moneter atau lainnya)), dan Anda mendapatkan situasi yang buruk. Seharusnya tidak mengejutkan bahwa crash pasar 'sekali dalam satu milenium' terjadi setiap 2 dekade.

— Pekerjaan

20

Ini ide yang berbahaya. Proxy "obyektif" untuk arahan berkualitas langsung ke penghargaan manajemen dan pengembang akan mengejar metrik ini dengan mengorbankan kualitas aktual.

Ini adalah hukum konsekuensi yang tidak diinginkan.

Kualitas - walaupun penting - hanya satu aspek kecil dari perangkat lunak. Fungsi dan nilai yang diciptakan oleh perangkat lunak jauh, jauh lebih penting daripada kualitas.

Semua metrik mengarah ke aktivitas untuk mengoptimalkan metrik. Itu, pada gilirannya, memiliki konsekuensi yang mungkin tidak Anda sukai.

Perangkat lunak sangat kompleks. Sulit untuk memahami betapa rumitnya itu.

Bahkan hal-hal "jelas" seperti cakupan kode uji unit dapat membuang waktu. Mendapatkan hingga 100% mungkin memerlukan membuat tes yang sebenarnya lebih kompleks daripada kode trivial yang sedang diuji. Mendapatkan cakupan 100% mungkin melibatkan biaya yang tidak dapat diterima. [Alternatif untuk kode yang sepele, kecil, dan jarang digunakan adalah pengujian demi pemeriksaan. Tapi itu tidak cocok dengan game metrik 100%.]

Contoh lain adalah Kompleksitas Siklomatik. Ini adalah salah satu ukuran kualitas kode terbaik. Tapi itu bisa dimainkan dengan membuat banyak fungsi kecil yang mungkin lebih sulit dibaca (dan lebih sulit untuk dipertahankan) daripada satu fungsi yang lebih besar. Anda berakhir dalam ulasan kode di mana Anda setuju bahwa itu mungkin tidak terlalu mudah dibaca tetapi memenuhi ambang kompleksitas.

— S.Lott
sumber

3

"Semua metrik mengarah ke aktivitas untuk mengoptimalkan metrik." Saya pikir itu terlalu sering benar. Namun, seharusnya tidak demikian. Metrik harus, seperti yang saya singgung di paragraf terakhir saya, manajemen panduan. Namun, terlalu sering, keputusan dibuat secara eksklusif karena dan untuk angka-angka, tanpa pemahaman tentang makna angka-angka dan risiko serta trade-off yang terkait dengan keputusan.

— Thomas Owens

3

"Namun, tidak seharusnya begitu." Jelaskan beberapa cara di mana orang dapat diberitahu untuk tidak mengoptimalkan imbalan mereka. Temukan satu contoh perilaku manusia di mana imbalan budaya (berdasarkan pada semua jenis struktur sosial yang gila) bukanlah yang utama, terpenting dan hal terpenting yang akan dikejar orang. Apa pun yang melibatkan "harus" atau "tidak boleh" harus diukur terhadap apa yang sebenarnya dilakukan orang. Mereka benar-benar mengoptimalkan hadiah mereka. Jika metrik adalah bagian dari hadiah, orang mengoptimalkan metrik. Tolong jangan gunakan "harus" untuk menggambarkan perilaku orang.

— S.Lott

2

@Thomas Owens: "Anda tidak punya imbalan untuk dioptimalkan berdasarkan metrik". Itu lucu. Bagaimana Anda akan merahasiakannya? Setelah saya mengetahui bahwa kode Anda diterima lebih cepat dari milik saya, saya ingin tahu bagaimana manajemen memutuskan bahwa modul Anda selesai dan milik saya belum selesai. Setelah saya menemukan metrik yang "memandu" keputusan itu, saya akan benar-benar mengukur metrik yang harus dilakukan sedini mungkin. Jika tidak ada metrik yang dapat saya mainkan, maka saya akan melihat bahwa keputusannya sewenang-wenang, manajemen menyukai Anda lebih baik dari saya, dan saya akan berhenti karena tidak ada standar kinerja yang dapat saya pahami.

— S.Lott

2

@Thomas Owens: "Saya belum pernah melihat metrik mengarah pada hadiah". Insentif budaya ada dalam semua situasi di mana dua orang atau lebih bekerja bersama. "Individu diakui untuk kinerjanya". Metrik untuk kompleksitas siklomatik menjadi tujuan. Jika Anda memenuhi tujuan kompleksitas siklomatik Anda lebih cepat daripada saya, maka ada imbalan budaya: Anda lebih "produktif" daripada saya. Saya perlu memainkan metrik kompleksitas saya agar tampil "produktif" seperti Anda.

— S.Lott

2

@ Thomas Owens: "Ini masalah kebanggaan pribadi". Itu adalah contoh yang bagus dari sistem penghargaan budaya. Metrik dapat memelintir ini karena konsekuensi yang tidak diinginkan karena dapat membuat metrik yang terlihat bagus yang tidak cocok dengan kode yang baik. Anda telah memberikan contoh bagus imbalan budaya yang dapat diabaikan oleh metrik.

— S.Lott

4

Saya juga bertanya-tanya apakah ini ide yang berbahaya, bahwa jika proksi obyektif untuk kualitas menjadi populer maka tekanan bisnis akan menyebabkan pengembang mengejar metrik ini dengan mengorbankan kualitas keseluruhan (aspek kualitas yang tidak diukur oleh proksi).

Bingo, dan tidak ada "jika" tentang hal itu. Ini disebut "Disfungsi Pengukuran" dan telah diamati dan ditulis tentang Joel berkali-kali menulis artikel tentang itu pada tahun 2002 merujuk buku oleh Profesor Harvard.

Itu tidak berarti metrik seperti itu tidak berguna, hanya saja orang tidak boleh mendasarkan insentif atau kebijakan secara eksplisit pada pengukuran proxy tersebut. Jika Anda ingin meningkatkan kualitas, metrik proksi dengan nilai yang sangat buruk mungkin merupakan titik yang baik untuk memulai. Tetapi Anda tidak dapat menyimpulkan bahwa kualitas itu baik hanya karena semua metrik Anda memiliki nilai yang bagus.

— Michael Borgwardt
sumber

3

Yang saya minati adalah bentuk kualitas yang lebih dalam terkait dengan jaringan (atau grafik) jenis dan keterkaitannya, yaitu jenis apa yang dirujuk oleh masing-masing jenis, apakah ada kelompok interkonektivitas yang teridentifikasi dengan jelas yang berkaitan dengan arsitektur berjenjang, atau sebaliknya apakah ada 'bola' besar referensi tipe (kode 'monolitik').

Ini terdengar seperti fan-in dan fan-out. Fan-in menghitung jumlah modul yang memanggil modul yang diberikan dan fan-out menghitung jumlah modul yang dipanggil oleh modul yang diberikan. Tanda peringatan untuk digunakan adalah modul yang memiliki kipas besar dan kipas besar, karena ini mungkin menunjukkan desain yang buruk dan target utama untuk refactoring atau mendesain ulang.

Juga ukuran masing-masing jenis dan / atau metode (misalnya diukur dalam jumlah kode byte Java atau .Net IL) harus memberikan beberapa indikasi di mana algoritma kompleks besar telah diterapkan sebagai blok kode monolitik alih-alih didekomposisi menjadi lebih mudah dikelola / dikelola. potongan.

Pengukuran sederhana adalah baris kode. Anda dapat memecahnya menjadi garis total kode di seluruh proyek dan garis kode per modul (mungkin menggunakan modul ukuran yang berbeda). Anda dapat menggunakan ini sebagai indikator peringatan yang menunjukkan bahwa Anda harus meninjau modul tertentu. Sebuah buku tentang pengukuran dan metrik kualitas perangkat lunak membahas beberapa pekerjaan yang menunjukkan bahwa hubungan antara tingkat cacat dan ukuran modul adalah kurva, di mana cacat rata-rata per KSLOC dilengkapi dengan modul dengan ukuran antara 175 dan 350 SLOC.

Sesuatu yang sedikit lebih kompleks adalah kompleksitas siklomatik, yang dirancang untuk menunjukkan kemampuan uji, kemampuan memahami, dan pemeliharaan sistem. Kompleksitas siklus menghitung jumlah jalur independen melalui aplikasi atau modul. Jumlah tes, dan oleh karena itu upaya yang diperlukan untuk menghasilkan dan melaksanakan tes, sangat terkait dengan kompleksitas siklomatik.

Ambang batas / titik keputusan yang tepat antara kualitas tinggi dan rendah akan saya curigai bersifat subyektif, misalnya karena dengan pemeliharaan berarti pemeliharaan oleh programmer manusia dan karenanya dekomposisi fungsional harus kompatibel dengan cara kerja pikiran manusia.

Saya tidak yakin itu masalahnya.

Sebagai contoh, ada penelitian yang menunjukkan bahwa memori kerja manusia hanya dapat menampung 7 plus / minus 2 objek . Ini mungkin menarik untuk mengukur fan-in dan fan-out - jika saya bekerja dalam sebuah modul, dan terhubung ke lebih dari ~ 7 modul lainnya, saya mungkin tidak akan dapat melacak dengan tepat apa yang modul lain ada di kepala saya.

Ada juga yang telah bekerja pada terkait cacat pada metrik seperti kompleksitas siklomatik. Karena Anda ingin meminimalkan cacat pada sistem Anda, Anda dapat mengidentifikasi titik-titik yang membutuhkan lebih banyak upaya pengujian atau refactoring, sebagaimana diidentifikasi oleh kompleksitas siklomatik yang tinggi.

Saya juga bertanya-tanya apakah ini ide yang berbahaya, bahwa jika proksi obyektif untuk kualitas menjadi populer maka tekanan bisnis akan menyebabkan pengembang mengejar metrik ini dengan mengorbankan kualitas keseluruhan (aspek kualitas yang tidak diukur oleh proksi).

Ini adalah kasus dengan pengukuran atau metrik apa pun. Mereka perlu digunakan untuk memahami sistem dan membuat keputusan yang tepat. Ungkapan "Anda tidak bisa mengatur apa yang tidak bisa Anda ukur" muncul di benak Anda. Jika Anda menginginkan perangkat lunak berkualitas tinggi, Anda perlu beberapa pengukuran dan metrik untuk menilai kualitas itu. Namun, ada sisi lain dari ini. Anda tidak dapat mengelola secara eksklusif dengan angka. Anda dapat menggunakan angka-angka untuk membuat keputusan berdasarkan informasi, tetapi Anda tidak dapat membuat keputusan hanya karena angka-angka mengatakan demikian.

— Thomas Owens
sumber

Masalahnya dengan fan-in / out adalah bahwa ia memberikan dua angka per modul / kelas (atau apa pun) dan karena itu mengabaikan beberapa struktur organisasi yang lebih dalam tentang bagaimana modul terhubung. Misalnya Anda bisa memiliki sekelompok kecil modul yang sangat terhubung yang terkait dengan tingkat logis, dan Anda akan mengharapkan koneksi antara tingkat menjadi minimal (dibandingkan), mewakili antarmuka / kontrak yang didefinisikan dengan baik antara tingkat. Saya pikir kami senang bahwa beberapa modul sangat terhubung (misalnya metode / kelas helper yang umum digunakan), tetapi tergantung pada 'struktur' konektivitas (itulah hipotesis saya).

— redcalx

@locster Anda mungkin ingin mengembangkannya dan perhatikan, misalnya, paket mana yang Anda gunakan. Jangan hanya melihat angka-angka mentah, tetapi pilah menjadi beberapa hal seperti kelas X dalam paket saya, Y kelas di luar paket saya, atau kelas Z dalam paket khusus ini. Jika Anda melihat fan-out antara modul dalam model data Anda dan modul di UI Anda, itu bisa menjadi indikator masalah. Anda perlu menggali sedikit lebih dalam dari sekadar angka mentah.

— Thomas Owens

3

Ada metrik atau proksi untuk banyak kualitas yang Anda minati:

Baris-baris kode
Kipas angin, kipas angin
Tingkat kesalahan per 1000 baris kode
Kompleksitas siklus
Cakupan kode
Cakupan poin keputusan
Rasio kesalahan diperbaiki / diperkenalkan oleh kegiatan pemeliharaan
Analisis titik fungsi

Ada beberapa masalah dengan semua item ini:

Pekerjaan yang dilakukan untuk mengoptimalkan metrik - tren universal; diperburuk secara besar-besaran jika ada metrik yang digunakan sebagai dasar penilaian atau penghargaan untuk tim atau individu.
Saya tidak mengetahui adanya metrik yang bebas konteks. Ini menyiratkan bahwa tidak ada perbandingan yang dimungkinkan di seluruh toko - hanya di dalam toko, dari waktu ke waktu. Metrik yang timbul dari perbandingan semacam itu masih berharga - "apakah kami memproduksi kode dengan lebih benar sekarang dari setahun yang lalu".

Efek total dari masalah ini adalah bahwa metrik seperti ini cenderung hanya bernilai dalam budaya yang lebih luas - seperti TQM, jaminan kualitas (bukan kontrol), peningkatan berkelanjutan, kaizan, dll. Diperlukan untuk menentukan elemen dari kedua budaya tersebut , dan bagaimana itu perlu diubah. Jika Anda memiliki definisi ini, maka metrik seperti ini menjadi alat penting dalam membantu meningkatkan kualitas kode, praktik kerja, produktivitas, dll. Tanpa konteks yang lebih luas ini, metrik akan menghasilkan pekerjaan untuk mengoptimalkan metrik; akan menjadi alat beancounter untuk meningkatkan produktivitas, dan mengurangi biaya; dan akan menjadi kendala untuk dimainkan oleh staf pengembangan.

— Chris Walton
sumber

2

Anda bisa terobsesi dengan metrik, atau Anda bisa terobsesi dengan orang-orang terbaik, alat, praktik untuk teknik dan QA yang Anda mampu. Saya akan jauh lebih bahagia memiliki beberapa genius QA paranoid yang telah membaca 'Tertipu oleh Keacakan' dan yang suka mengotomatisasi daripada sekelompok laporan yang diformat dengan angka.

— Pekerjaan
sumber

+1 untuk referensi buku Nassim Taleb. Penalaran cacat / epistemologi berada pada rantai kausalitas untuk kualitas rendah.

— redcalx

@locster, komentar Anda membuat saya memikirkan operator pipa F # :). Anda mulai dengan 'referensi buku Nassim Taleb' tetapi diakhiri dengan 'rantai sebab-akibat untuk kualitas rendah' (alih-alih 'rantai sebab-akibat berkualitas rendah'). Sama seperti dalam bahasa Inggris kadang-kadang kita ingin memiliki dua cara untuk mengatakan sesuatu, kita mungkin lebih suka itu dalam bahasa pemrograman juga.

— Pekerjaan

1

Ada masalah mendasar ini dengan metrik.

Hampir semua metrik yang diusulkan telah ditunjukkan, di dunia nyata pada kode nyata, berkorelasi kuat atau sangat kuat dengan SLOC mentah (baris kode sumber).

Inilah yang membunuh metrik Halstead, di tahun 1970-an. (Suatu hari, kebetulan, sekitar 1978, saya duduk di sebuah ceramah oleh PhD baru tentang metrik Halstead, di mana ia menunjukkan hal ini.)

Baru-baru ini, kompleksitas siklomatik McCabe telah terbukti sangat berkorelasi dengan SLOC mentah, sampai-sampai orang yang melakukan penelitian itu bertanya-tanya dengan lantang jika metrik McCabe memberi tahu kami apa pun yang berguna sama sekali.

Kami sudah tahu selama beberapa dekade bahwa program besar lebih cenderung memiliki masalah daripada yang kecil. Kami sudah tahu selama beberapa dekade bahwa subrutin besar lebih mungkin memiliki bug daripada yang kecil. Mengapa kita perlu metrik misterius untuk memberi tahu kita ini, ketika melihat empat halaman printer yang tersebar di atas meja harus cukup meyakinkan?

— John R. Strohm
sumber

Agar dapat dipelihara, kita memerlukan kode untuk berada di bongkahan manusia, maka metrik SLOC terlihat cukup baik dari perspektif itu. Namun, untuk ukuran tertentu Anda dapat memiliki jumlah jalur unik yang berbeda-beda (sesuai kompleksitas siklomatik) dan saya berpendapat bahwa lebih banyak jalur merupakan proksi untuk kurang mudah dimengerti. Oleh karena itu saya berpendapat bahwa CC mungkin menambah / beberapa / nilai tambahan untuk SLOC, selama Anda mengizinkan beberapa fleksibilitas, pengecualian pada aturan, dll. Yaitu, jangan secara ketat menegakkan CC.limits / tujuan.

— redcalx

1

@locster: Diberikan dua modul SLOC 100, satu dengan CC dari 47 kemungkinan memiliki lebih banyak masalah daripada satu dengan CC dari 3. NAMUN, untuk kode dunia nyata, dalam jumlah besar, orang menemukan bahwa modul pendek cenderung memiliki rendah Modul CC dan modul panjang cenderung memiliki CC tinggi, sampai pada titik mengetahui SLOC memberi Anda tebakan yang sangat baik di CC, dan sebaliknya. Inilah yang dimaksud dengan "berkorelasi sangat kuat." SEPERTI TERSEBUT, pada kode nyata, setiap manfaat yang Anda dapatkan dari memperhatikan CC = 47 adalah LEBIH MUDAH diperoleh dari memperhatikan SLOC = 1500. (Angka ditarik secara acak, prinsipnya sama.)

— John R. Strohm

Ya, saya setuju bahwa mereka akan cenderung berkorelasi kuat, meskipun hubungannya umumnya tidak linear. mis. Skor CC kira-kira LOC dinaikkan ke beberapa kekuatan. Jadi dari sudut pandang psikologis, skor CC dapat dilihat menjadi sangat besar sangat cepat, sedangkan skor SLOC yang terkait sepertinya 'hanya sedikit lebih tinggi'. Ya saya tahu saya mencengkeram sedotan di sini :)

— redcalx

@locster: Saya sudah melakukan ini selama lebih dari 30 tahun. Hari-hari ini, saya secara rutin melihat rutinitas run-on aliran kesadaran, yang berlangsung terus-menerus selama beberapa ratus SLOC, tanpa alasan. Selama bertahun-tahun, saya telah melihat persis satu (1) rutin yang benar-benar PERLU menjadi lebih dari satu halaman kode printer (sekitar 60 baris). Semua sisanya bisa saja diperhitungkan untung turun, dan keterbacaan dan reliabilitas meningkat secara signifikan. (Itu tidak termasuk mesin negara besar. Mereka bisa menjadi masalah di daerah ini, tetapi mereka RARE.)

— John R. Strohm

-2

Mengingat semua jawaban lain di sini, saya merasa konyol dengan yang kecil ini. Lihatlah Crap4j , yang mencoba untuk memberi peringkat metode di java dengan berapa banyak mereka bau. (Proyek ini terlihat ditinggalkan.)

Ini menggunakan kombinasi kompleksitas cyclomatic dan cakupan tes. Seperti setiap metrik lainnya, ini bisa dimainkan.

— Sean McMillan
sumber