Ketika Software Gagal, Siapa yang Bertanggung Jawab? — Peran Software Quality Metrics dalam Menjamin Kualitas Perangkat Lunak

“You can’t control what you can’t measure” — Tom DeMarco

Kalimat sederhana dari Tom DeMarco itu menjadi motto bagi para ahli kualitas perangkat lunak di seluruh dunia. Bagaimana kita tahu sebuah software sudah berkualitas? Tidak cukup hanya dengan berkata “rasanya sudah benar” atau “tidak ada bug yang terlihat.” Kita butuh alat ukur yang objektif — dan itulah yang disebut Software Quality Metrics (SQM).

Apa Itu Software Quality Metrics?

Definisi Software Quality Metrics

IEEE mendefinisikan SQM dalam dua sisi yang saling melengkapi:

Pertama, dari sisi hasil: SQM adalah ukuran kuantitatif yang menunjukkan seberapa baik sebuah software memiliki atribut kualitas tertentu, ini hasilnya berupa angka yang bisa dibaca dan dibandingkan.

Kedua, dari sisi proses: SQM adalah sebuah fungsi yang menerima data software sebagai input, lalu menghasilkan satu nilai numerik yang bisa diinterpretasi sebagai derajat kualitas software tersebut.

Sederhananya, SQM adalah alat ukur kualitas software yang berbicara dalam bahasa angka, bukan opini.

Standar internasional ISO/IEC 25010 membagi kualitas yang diukur ke dalam dua dimensi besar:

• Product Quality: Seberapa baik software secara teknis: fungsionalitasnya, keandalannya, keamanannya, dan seberapa mudah ia dipelihara.
• Quality in Use: Seberapa baik software dari mata pengguna: apakah efektif digunakan, efisien, dan memuaskan.

Analogi: Bayangkan SQM seperti rapor kendaraan saat servis. Tidak cukup hanya bilang “mobil masih bisa jalan” — harus ada angka konkret: tekanan ban 32 PSI, kedalaman kampas rem 5mm, konsumsi BBM 12 km/liter. Angka-angka itulah yang membuat keputusan menjadi objektif, bukan sekadar perasaan.

Masalah Apa yang Bisa Diselesaikan SQM?

Masalah yang diselesaikan SQM

Tanpa SQM, tim pengembang sering terjebak dalam masalah-masalah berikut:

Masalah 1: Kualitas kode tidak terukur Ribuan baris kode ditulis tanpa ada gambaran seberapa kompleks dan rawan bug kode tersebut. Saat ada masalah, sulit menentukan di mana akar penyebabnya.

Solusi SQM: Process Quality Metrics seperti Error Density dan Error Severity Metrics membantu mengevaluasi kualitas kode secara terukur, dan mendeteksi tren yang memburuk sebelum menjadi krisis besar.

Masalah 2: Pengujian tidak menyeluruh Tidak mungkin menguji 100% kode secara manual dengan sumber daya terbatas. Tim perlu tahu bagian mana yang paling kritis dan berisiko tinggi untuk diuji terlebih dahulu.

Solusi SQM: Error Removal Efficiency Metrics mengukur seberapa efektif tim mendeteksi dan menghapus defect — menjadi kompas untuk memprioritaskan pengujian.

Masalah 3: Tidak ada bahasa yang sama antar tim Developer, QA, dan manajer proyek sering punya definisi “kualitas” yang berbeda-beda. Ini menyebabkan miskomunikasi dan ekspektasi yang tidak selaras.

Solusi SQM: Metrik memberikan bahasa yang terstandarisasi dan terukur — bisa dipahami dan disepakati oleh semua pihak, dari tim teknis hingga manajemen.

Intinya, SQM adalah alat fundamental manajemen yang menopang tiga hal sekaligus: kontrol proyek, dukungan pengambilan keputusan, dan inisiasi tindakan korektif ketika ada yang tidak berjalan sesuai rencana.

Apa Tujuan Penggunaan SQM?

Secara garis besar, ada tiga tujuan utama mengapa SQM digunakan:

Mendukung kontrol proyek dan maintenance. Metrik memberikan informasi konkret kepada manajemen — apakah software sudah memenuhi persyaratan fungsional, apakah jadwal dipatuhi, dan bagaimana kinerja tim dibandingkan dengan standar yang telah ditetapkan sebelumnya.

Mendukung pengambilan keputusan berbasis data. Analisis statistik dari data metrik bisa menunjukkan perubahan yang signifikan — baik secara deskriptif (tren) maupun analitis (uji hipotesis) — yang kemudian menjadi dasar keputusan yang lebih terinformasi.

Menginisiasi tindakan korektif. Ketika metrik menunjukkan sesuatu yang tidak beres, ada dua jalur tindakan:

• Direct actions — perubahan langsung oleh tim atau manajer proyek, seperti reorganisasi atau perubahan metode pengembangan.
• Indirect actions — diinisiasi oleh Corrective Action Board (CAB) berdasarkan pola dari berbagai proyek yang dianalisis secara menyeluruh.

Bagaimana Proses Penilaian Kualitas dengan SQM?

Proses implementasi SQM yang benar mencakup empat tahap yang saling berurutan:

Implementasi Proses SQM

Tahap 1: Tentukan atribut yang ingin diukur Sebelum mengukur apapun, tentukan dulu apa yang ingin diketahui — apakah kualitas kode, produktivitas tim, atau efektivitas layanan maintenance.

Tahap 2: Definisikan metrik yang tepat Tidak sembarang angka bisa disebut metrik yang baik. Ada standar yang harus dipenuhi:

• Valid: Benar-benar mengukur apa yang dimaksud.
• Reliabel: Menghasilkan hasil serupa dalam kondisi serupa.
• Komprehensif: Berlaku di berbagai situasi dan implementasi.
• Mudah diterapkan: Tidak rumit dan tidak memakan biaya berlebihan.
• Tepat waktu: Data tersedia saat dibutuhkan.

Tahap 3: Tetapkan nilai target (indikator) Ini adalah tahap yang paling sering dilewati — dan paling fatal jika diabaikan. Tanpa target yang jelas, metrik hanya jadi kumpulan angka tanpa makna. Nilai target bisa berasal dari standar industri, pencapaian proyek sebelumnya, atau rata-rata organisasi.

Tahap 4: Tentukan metode pelaporan dan pengumpulan data Definisikan bagaimana data dikumpulkan, oleh siapa, kapan, dan seperti apa format laporannya. Setelah data terkumpul, analisis dilakukan dengan dua pendekatan:

• Descriptive statistics — mean, median, histogram, control chart untuk melihat tren.
• Analytical statistics — uji hipotesis untuk membuktikan apakah suatu perubahan signifikan secara statistik.

Jenis-Jenis SQM dan Contoh Penggunaannya

SQM menggunakan sistem klasifikasi dua level. Level pertama membedakan berdasarkan fase siklus hidup software, level kedua berdasarkan subjek pengukurannya.

Klasifikasi Jenis SQM

A. Process Metrics — Fase Pengembangan Process Metrics mengukur apa yang terjadi selama software sedang dibangun. Ada empat sub-kategori:

1. Software Process Quality Metrics Mengukur kualitas proses pengembangan itu sendiri, dengan dua jenis utama:

• Error Density Metrics: Mengukur kepadatan error relatif terhadap ukuran software. Ada dua ukuran yang digunakan: KLOC (ribuan baris kode) atau Function Points. Yang membuat metrik ini powerful adalah kemampuannya menggunakan weighted error — setiap error diberi bobot sesuai tingkat keparahannya. Misalnya, CED (Code Error Density) menghitung jumlah error biasa per KLOC. Sedangkan WCED (Weighted Code Error Density) menggunakan jumlah error berbobot. Keputusan yang diambil dari keduanya bisa berbeda: dengan CED kualitas mungkin terlihat masih dalam batas wajar, tapi WCED bisa menunjukkan bahwa kualitas sebenarnya sudah membutuhkan intervensi manajemen.
• Error Severity Metrics: Yaitu dirancang untuk mendeteksi situasi berbahaya di mana jumlah error parah justru meningkat, meskipun total error secara keseluruhan turun. Ini sinyal yang lebih akurat tentang kondisi kualitas yang sebenarnya.

2. Software Process Timetable Metrics Mengukur kepatuhan terhadap jadwal proyek:

• TTO (Time Table Observance) — rasio milestone yang selesai tepat waktu terhadap total milestone.
• ADMC (Average Delay of Milestone Completion) — rata-rata keterlambatan penyelesaian milestone.

3. Error Removal Efficiency Metrics Mengukur seberapa efektif tim dalam mendeteksi dan menghapus error sebelum software dirilis ke pengguna. Metrik ini menjawab pertanyaan: dari semua bug yang ada, berapa persen yang berhasil ditemukan sebelum sampai ke tangan pengguna?

4. Software Process Productivity Metrics Mengukur produktivitas tim pengembang, baik secara langsung (output per jam kerja) maupun tidak langsung melalui tingkat code reuse. Termasuk juga benchmarking produktivitas untuk membandingkan kinerja antar tim atau bahkan antar industri software secara nasional.

B. Product Metrics — Fase Operasional Product Metrics mengukur apa yang terjadi setelah software sudah digunakan oleh pelanggan. Ada empat kelompok:

1. HD (Help Desk) Quality Metrics

Mengukur kualitas layanan help desk. Yang menarik, frekuensi panggilan HD yang tinggi bukan hanya masalah layanan purna jual — ini bisa menjadi sinyal bahwa software memang sulit digunakan, atau dokumentasinya buruk. Contoh: ASHC (Average Severity of HD Calls) mengukur rata-rata tingkat keparahan panggilan help desk dalam setahun. Jika angka ini terus naik dari kuartal ke kuartal, itu sinyal serius tentang memburuknya pengalaman pengguna.

2. HD Productivity & Effectiveness Metrics Mengukur seberapa efisien tim support dalam merespons panggilan. Contoh: HDE (HD Effectiveness) = total jam kerja HD dibagi jumlah panggilan pelanggan dalam setahun.

3. Corrective Maintenance Quality Metrics Mengukur kualitas perbaikan bug selama masa operasional, dengan dua jenis:

Failure Density Metrics — mengukur kepadatan kegagalan sistem relatif terhadap ukuran software yang di-maintain.

Availability Metrics — mengukur gangguan yang dialami pengguna:

• FA (Full Availability) — persentase waktu semua fungsi beroperasi normal.
• VitA (Vital Availability) — persentase waktu fungsi vital beroperasi normal.
• TUA (Total Unavailability) — persentase waktu sistem benar-benar tidak bisa digunakan.

Contoh: Aplikasi perkantoran yang beroperasi 50 jam/minggu selama 52 minggu = 2.600 jam/tahun. Jika ada 130 jam gangguan, FA = (2.600–130) / 2.600 = 95%. Untuk sistem real-time yang harus aktif 24 jam sehari, standarnya jauh lebih ketat karena total jam operasional mencapai 8.760 jam/tahun.

4. Corrective Maintenance Productivity & Effectiveness Metrics Mengukur produktivitas dan efektivitas tim maintenance — seberapa cepat, seberapa tuntas, dan seberapa sedikit perbaikan yang harus diulang.

Keterbatasan SQM yang Perlu Dipahami

SQM bukan tanpa cela. Ada keterbatasan inheren yang perlu disadari, terutama pada ukuran dasar yang menjadi komponen pembentuk metrik.

Ambil contoh KLOC — ukuran yang paling banyak dipakai. Angkanya sangat mudah dipengaruhi oleh hal-hal di luar kualitas kode itu sendiri: gaya pemrograman seseorang, seberapa banyak komentar yang dituliskan, atau seberapa kompleks modul yang dikerjakan. Dua programmer yang mengerjakan tugas yang sama bisa menghasilkan KLOC yang sangat berbeda — padahal kualitas outputnya setara.

Akibatnya, metrik berbasis KLOC rentan distorsi dan sering memiliki validitas yang rendah.

Itulah mengapa Function Points dikembangkan sebagai alternatif yang lebih kuat. Function Points didasarkan pada spesifikasi fungsionalitas software, bukan jumlah baris kode — sehingga tidak bergantung pada bahasa pemrograman maupun gaya programmer. Hasilnya lebih valid dan lebih bisa dibandingkan lintas proyek.

Kesimpulan

Software Quality Metrics bukan sekadar kumpulan angka di spreadsheet. Ia adalah fondasi dari pengembangan software yang profesional — cara kita memastikan bahwa kualitas bukan hasil keberuntungan, melainkan hasil dari pengukuran yang konsisten dan perbaikan yang terarah.

Beberapa poin kunci yang perlu diingat:

✅ SQM mengubah penilaian subjektif menjadi data yang bisa dianalisis dan ditindaklanjuti — persis seperti semangat Tom DeMarco: “you can’t control what you can’t measure.”

✅ Ada dua klasifikasi besar: Process Metrics untuk fase pengembangan, dan Product Metrics untuk fase operasional. Keduanya saling melengkapi untuk memberikan gambaran kualitas yang menyeluruh.

✅ Proses implementasi yang benar butuh empat tahap — dan tahap ketiga (penetapan target/indikator) adalah yang paling sering diabaikan, padahal paling krusial.

✅ Setiap metrik punya keterbatasan. Pahami batasannya sebelum menggunakannya sebagai dasar keputusan besar.

Pada akhirnya, software yang gagal bukan hanya tanggung jawab satu orang atau satu tim. Ia adalah cerminan dari sistem pengukuran kualitas yang lemah — atau bahkan tidak ada sama sekali. Dan SQM hadir untuk menutup celah itu.

Referensi

• Galin, D. (2003). Software Quality Assurance: From Theory to Implementation, Chapter 21. Pearson Education / Addison-Wesley.
• IEEE Std 610.12–1990 — IEEE Standard Glossary of Software Engineering Terminology.
• ISO/IEC 25010:2023 — Systems and Software Quality Requirements and Evaluation (SQuaRE).
• NanoGlobals (2026). Software Quality Metrics Explained With Examples. https://nanoglobals.com/glossary/software-quality-metrics/
• Milestone (2025). What Are the Common Types of Software Quality Metrics? https://mstone.ai/question/common-types-software-quality-metrics/