Metrik Kualitas Software

Metrik perangkat lunak dapat diklasifikasikan menjadi tiga kategori -

Product metrics - Menjelaskan karakteristik produk seperti ukuran, kompleksitas, fitur desain, performa, dan tingkat kualitas.
Process metrics - Karakteristik ini dapat digunakan untuk meningkatkan aktivitas pengembangan dan pemeliharaan perangkat lunak.
Project metrics- Metrik ini menggambarkan karakteristik dan pelaksanaan proyek. Contohnya termasuk jumlah pengembang perangkat lunak, pola kepegawaian selama siklus hidup perangkat lunak, biaya, jadwal, dan produktivitas.

Beberapa metrik termasuk dalam beberapa kategori. Misalnya, metrik kualitas dalam proses suatu proyek adalah metrik proses dan metrik proyek.

Software quality metricsadalah bagian dari metrik perangkat lunak yang berfokus pada aspek kualitas produk, proses, dan proyek. Ini lebih terkait erat dengan metrik proses dan produk daripada dengan metrik proyek.

Metrik kualitas perangkat lunak dapat dibagi lagi menjadi tiga kategori -

Metrik kualitas produk
Metrik kualitas dalam proses
Metrik kualitas pemeliharaan

Metrik Kualitas Produk

Metrik ini meliputi:

Waktu Berarti untuk Gagal
Kerapatan Cacat
Masalah Pelanggan
Kepuasan pelanggan

Waktu Berarti untuk Gagal

Ini adalah waktu antara kegagalan. Metrik ini banyak digunakan dengan sistem keamanan kritis seperti sistem kontrol lalu lintas maskapai penerbangan, avionik, dan senjata.

Kerapatan Cacat

Ini mengukur cacat relatif terhadap ukuran perangkat lunak yang dinyatakan sebagai baris kode atau titik fungsi, dll. Yaitu, mengukur kualitas kode per unit. Metrik ini digunakan di banyak sistem perangkat lunak komersial.

Masalah Pelanggan

Ini mengukur masalah yang dihadapi pelanggan saat menggunakan produk. Ini berisi perspektif pelanggan terhadap ruang masalah perangkat lunak, yang mencakup masalah berorientasi non-cacat bersama dengan masalah cacat.

Metrik masalah biasanya dinyatakan dalam Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Dimana,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM biasanya dihitung untuk setiap bulan setelah perangkat lunak dirilis ke pasar, dan juga untuk rata-rata bulanan menurut tahun.

Kepuasan pelanggan

Kepuasan pelanggan sering diukur dengan data survei pelanggan melalui skala lima poin -

Sangat Puas
Satisfied
Neutral
Dissatisfied
Sangat tidak puas

Kepuasan terhadap kualitas produk secara keseluruhan dan dimensi spesifiknya biasanya diperoleh melalui berbagai metode survei pelanggan. Berdasarkan data skala lima poin, beberapa metrik dengan sedikit variasi dapat dibangun dan digunakan, tergantung pada tujuan analisis. Misalnya -

Persentase pelanggan yang benar-benar puas
Persentase pelanggan yang puas
Persentase pelanggan yang tidak puas
Persentase pelanggan yang tidak puas

Biasanya, persentase kepuasan ini digunakan.

Metrik Kualitas Dalam Proses

Metrik kualitas dalam proses berhubungan dengan pelacakan kedatangan kerusakan selama pengujian mesin formal untuk beberapa organisasi. Metrik ini mencakup -

Kerapatan cacat selama pengujian mesin
Pola kedatangan yang rusak selama pengujian mesin
Pola penghapusan cacat berbasis fase
Efektivitas penghapusan cacat

Kerapatan cacat selama pengujian mesin

Tingkat kerusakan selama pengujian mesin formal (pengujian setelah kode diintegrasikan ke dalam perpustakaan sistem) berkorelasi dengan tingkat kerusakan di lapangan. Tingkat kerusakan yang lebih tinggi yang ditemukan selama pengujian merupakan indikator bahwa perangkat lunak telah mengalami injeksi kesalahan yang lebih tinggi selama proses pengembangannya, kecuali tingkat kerusakan pengujian yang lebih tinggi disebabkan oleh upaya pengujian yang luar biasa.

Metrik sederhana dari kerusakan per KLOC atau titik fungsi ini adalah indikator kualitas yang baik, sementara perangkat lunak masih diuji. Sangat berguna untuk memantau rilis produk berikutnya dalam organisasi pengembangan yang sama.

Pola kedatangan yang rusak selama pengujian mesin

Kerapatan cacat keseluruhan selama pengujian hanya akan memberikan ringkasan dari cacat tersebut. Pola kedatangan barang cacat memberikan informasi lebih lanjut tentang berbagai tingkat kualitas di lapangan. Ini termasuk yang berikut -

Kedatangan cacat atau cacat dilaporkan selama fase pengujian dengan interval waktu (misalnya, minggu). Di sini semua yang cacat tidak akan valid.
Pola kedatangan cacat yang valid ketika dilakukan penentuan masalah terhadap masalah yang dilaporkan. Ini adalah pola cacat yang sebenarnya.
Pola backlog cacat lembur. Metrik ini diperlukan karena organisasi pengembangan tidak dapat menyelidiki dan memperbaiki semua masalah yang dilaporkan dengan segera. Ini adalah pernyataan beban kerja serta pernyataan kualitas. Jika defect backlog besar di akhir siklus pengembangan dan banyak perbaikan yang belum diintegrasikan ke dalam sistem, stabilitas sistem (karena itu kualitasnya) akan terpengaruh. Pengujian ulang (uji regresi) diperlukan untuk memastikan bahwa tingkat kualitas produk yang ditargetkan tercapai.

Pola penghapusan cacat berbasis fase

Ini adalah perpanjangan dari metrik kepadatan cacat selama pengujian. Selain pengujian, ia melacak cacat di semua fase siklus pengembangan, termasuk tinjauan desain, inspeksi kode, dan verifikasi formal sebelum pengujian.

Karena sebagian besar cacat pemrograman terkait dengan masalah desain, melakukan tinjauan formal, atau verifikasi fungsional untuk meningkatkan kemampuan penghapusan cacat proses di ujung depan mengurangi kesalahan dalam perangkat lunak. Pola penghapusan cacat berbasis fase mencerminkan kemampuan menghilangkan cacat secara keseluruhan dari proses pengembangan.

Berkenaan dengan metrik untuk fase desain dan pengkodean, selain tingkat kerusakan, banyak organisasi pengembangan menggunakan metrik seperti cakupan inspeksi dan upaya inspeksi untuk manajemen kualitas dalam proses.

Efektivitas penghapusan cacat

Itu dapat didefinisikan sebagai berikut -

$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \times 100\%$$

Metrik ini dapat dihitung untuk seluruh proses pengembangan, untuk front-end sebelum integrasi kode dan untuk setiap fase. Itu disebutearly defect removal saat digunakan untuk front-end dan phase effectivenessuntuk fase tertentu. Semakin tinggi nilai metrik, semakin efektif proses pengembangan dan semakin sedikit cacat yang diteruskan ke fase atau lapangan berikutnya. Metrik ini adalah konsep kunci dari model penghapusan cacat untuk pengembangan perangkat lunak.

Metrik Kualitas Perawatan

Meskipun banyak yang tidak dapat dilakukan untuk mengubah kualitas produk selama fase ini, berikut adalah perbaikan yang dapat dilakukan untuk menghilangkan cacat sesegera mungkin dengan kualitas perbaikan yang sangat baik.

Perbaiki backlog dan indeks manajemen backlog
Perbaiki waktu respons dan perbaiki respons
Persen perbaikan tunggakan
Perbaiki kualitas

Perbaiki backlog dan indeks manajemen backlog

Fix backlog terkait dengan tingkat kedatangan cacat dan tingkat di mana perbaikan untuk masalah yang dilaporkan tersedia. Ini adalah hitungan sederhana dari masalah yang dilaporkan yang tetap ada di akhir setiap bulan atau setiap minggu. Dengan menggunakannya dalam format diagram tren, metrik ini dapat memberikan informasi yang berarti untuk mengelola proses pemeliharaan.

Backlog Management Index (BMI) digunakan untuk mengelola backlog masalah terbuka dan belum terselesaikan.

$$BMI = \frac{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$

Jika BMI lebih besar dari 100, berarti backlog berkurang. Jika BMI kurang dari 100, maka backlog meningkat.

Perbaiki waktu respons dan perbaiki respons

Metrik waktu respons perbaikan biasanya dihitung sebagai waktu rata-rata semua masalah dari buka hingga tutup. Waktu respons perbaikan yang singkat mengarah pada kepuasan pelanggan.

Elemen penting dari fix responsiveness adalah ekspektasi pelanggan, waktu perbaikan yang disepakati, dan kemampuan untuk memenuhi komitmen seseorang kepada pelanggan.

Persen perbaikan tunggakan

Ini dihitung sebagai berikut -

$Percent \:Delinquent\: Fixes =$

$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%$

Perbaiki Kualitas

Perbaiki kualitas atau jumlah perbaikan yang rusak adalah metrik kualitas penting lainnya untuk fase pemeliharaan. Perbaikan rusak jika tidak memperbaiki masalah yang dilaporkan, atau jika memperbaiki masalah asli tetapi menyuntikkan cacat baru. Untuk perangkat lunak yang sangat penting, perbaikan yang rusak merugikan kepuasan pelanggan. Metrik persen perbaikan rusak adalah persentase dari semua perbaikan dalam interval waktu yang rusak.

Perbaikan yang rusak dapat dicatat dengan dua cara: Catat pada bulan ditemukannya atau catat pada bulan perbaikan tersebut dikirim. Yang pertama adalah ukuran pelanggan; yang kedua adalah ukuran proses. Perbedaan antara kedua tanggal tersebut adalah periode laten dari perbaikan yang rusak.

Biasanya semakin lama latensi, semakin banyak pelanggan yang terpengaruh. Jika jumlah cacatnya besar, maka nilai persentase metrik yang kecil akan menunjukkan gambaran yang optimis. Sasaran kualitas untuk proses pemeliharaan, tentu saja, adalah nol perbaikan cacat tanpa tunggakan.