Kamu tidak.
Kualitas perangkat lunak sangat sulit diukur secara objektif. Cukup sulit sehingga tidak ada solusi. Saya menahan diri dalam jawaban ini untuk mencoba-coba tentang pertanyaan apakah ada solusi sama sekali, tetapi cukup tunjukkan mengapa mendefinisikan seseorang akan sangat sulit.
Penalaran berdasarkan status quo
Seperti yang ditunjukkan Kilian Foth, jika ada ukuran sederhana untuk perangkat lunak "baik", kita semua akan menggunakannya dan semua orang akan menuntutnya.
Ada proyek di mana manajer memutuskan untuk menegakkan metrik tertentu. Terkadang berhasil, terkadang tidak. Saya tidak mengetahui adanya korelasi yang signifikan. Terutama perangkat lunak sistem kritis (pikirkan pesawat terbang, mobil, dll.) Memiliki banyak persyaratan metrik untuk "memastikan" kualitas SW - Saya tidak mengetahui adanya penelitian yang menunjukkan bahwa persyaratan ini benar-benar menghasilkan kualitas yang lebih tinggi, dan saya memiliki pengalaman pribadi dengan kebalikan.
Penalaran dengan kontra-intelijen
Juga diisyaratkan oleh Kilian, dan lebih umum diucapkan sebagai "setiap metrik dapat dan akan dimainkan".
Apa artinya memainkan metrik? Ini adalah permainan yang menyenangkan bagi pengembang: Anda memastikan nilai metrik terlihat sangat baik, sambil melakukan hal-hal yang sangat menyebalkan.
Katakanlah Anda mengukur cacat per LOC. Bagaimana saya memainkannya? Mudah - tambahkan saja kode! Buat kode bodoh yang menghasilkan no-operasi lebih dari 100 baris dan tiba-tiba Anda memiliki lebih sedikit cacat per LOC. Terbaik dari semua: Anda benar-benar menurunkan kualitas perangkat lunak seperti itu.
Kekurangan alat disalahgunakan, definisi ditingkatkan semaksimal mungkin, cara-cara yang benar-benar baru ditemukan .. pada dasarnya, pengembang adalah orang-orang yang sangat pintar dan seandainya Anda hanya memiliki satu pengembang di tim Anda yang bersenang-senang memainkan metrik, maka metrik Anda akan dipertanyakan.
Ini bukan untuk mengatakan bahwa metrik selalu buruk - tetapi sikap tim terhadap metrik ini sangat penting. Secara khusus, ini menyiratkan itu tidak akan berfungsi dengan baik untuk setiap hubungan subkontraktor / vendor pihak ke-3.
Penalaran dengan penargetan yang salah
Yang ingin Anda ukur adalah kualitas perangkat lunak. Apa yang Anda ukur adalah satu atau beberapa metrik.
Ada celah antara apa yang Anda ukur dan apa yang Anda yakini akan memberi tahu Anda. Kesenjangan ini agak besar bahkan.
Itu terjadi setiap saat di semua jenis bisnis di sekitar kita. Pernah melihat keputusan berdasarkan KPI (indikator kinerja utama)? Ini masalah yang sama - Anda ingin perusahaan bekerja dengan baik, tetapi Anda mengukur sesuatu yang lain.
Penalaran dengan kuantifikasi
Metrik dapat diukur. Yang merupakan satu-satunya alasan kami berurusan dengan mereka sama sekali. Kualitas perangkat lunak, bagaimanapun, jauh melampaui entitas terukur ini dan memiliki banyak hal yang sangat sulit untuk diukur: Seberapa mudah dibaca kode sumbernya? Seberapa diperluas desain Anda? Seberapa sulit bagi anggota tim baru untuk bergabung? dll. dll
Menilai kualitas perangkat lunak hanya dengan metrik dan menutup mata terhadap bagian kualitas yang tidak dapat Anda ukur tentu tidak akan berhasil dengan baik.
edit:
Ringkasan
Biarkan saya menunjukkan bahwa di atas adalah semua tentang menilai secara objektif apakah perangkat lunak baik atau buruk berdasarkan metrik. Ini berarti, ia tidak mengatakan apa pun tentang apakah dan kapan Anda harus menerapkan metrik.
Sebenarnya, ini adalah implikasi searah: metrik buruk menyiratkan kode buruk. Searah berarti bahwa kode yang buruk tidak menjamin metrik yang buruk, juga metrik yang baik tidak menjamin kode yang baik. Di sisi lain, ini dengan sendirinya berarti Anda dapat menerapkan metrik untuk menilai perangkat lunak - ketika Anda mengingat implikasi ini.
Anda mengukur perangkat lunak A, dan metriknya menjadi sangat buruk. Maka Anda dapat yakin bahwa kualitas kodenya buruk. Anda mengukur perangkat lunak B dan metriknya ok, maka Anda tidak memiliki petunjuk apa pun tentang kualitas kode. Jangan tertipu dengan berpikir "metrik baik = kode baik" ketika itu benar-benar hanya "kode baik => metrik baik".
Intinya, Anda dapat menggunakan metrik untuk menemukan masalah kualitas, tetapi bukan kualitas itu sendiri.