Belajar "mengukur" keandalan software seperti dokter mengukur kesehatan pasien — dengan angka yang bermakna, bukan perasaan semata.
Jika seorang dokter hanya berkata "pasien Anda kelihatan sehat" tanpa mengukur tekanan darah, suhu tubuh, atau kadar gula darah — apakah Anda akan percaya? Tentu tidak. Kita butuh angka yang objektif.
Hal yang sama berlaku untuk software. Berkata "software kita andal" tanpa metrik adalah pernyataan kosong. Kita butuh angka: seberapa sering sistem gagal? Berapa lama untuk pulih? Berapa kepadatan bug per 1000 baris kode?
Metrik keandalan = Rekam medis software Anda.
Dokter tidak bisa merawat pasien tanpa data riwayat kesehatan. Tim engineering tidak bisa meningkatkan keandalan tanpa data metrik. MTTF, MTBF, dan MTTR adalah "tekanan darah, suhu tubuh, dan kadar gula" dari sistem software Anda.
Tiga istilah ini sering digunakan bergantian tapi sebenarnya memiliki arti yang sangat berbeda. Memahami perbedaannya krusial untuk analisis keandalan.
Cacat dalam kode (bug yang ditulis programmer)
State sistem yang salah saat fault aktif
Perilaku sistem yang menyimpang dari yang diharapkan pengguna
Fault = Kesalahan dalam buku resep: "Tambahkan 1 kg garam" (harusnya 1 sendok teh). Resep sudah salah dari sononya, tapi belum tentu langsung terasa.
Error = Kondisi ketika juru masak mengikuti resep salah itu: dia sudah menuang 1 kg garam ke dalam panci. Keadaan panci sekarang sudah salah.
Failure = Tamu mencicipi masakan dan langsung memuntahkannya karena terlalu asin. Inilah yang terasa oleh "pengguna".
Kondisi abnormal yang dapat menyebabkan elemen atau item gagal melakukan fungsinya yang diperlukan. Fault ada dalam kode sebelum sistem dijalankan. Contoh: kondisi off-by-one dalam loop, null pointer tidak ditangani.
Perbedaan antara nilai/kondisi yang dihitung, diamati, atau diukur, dengan nilai/kondisi yang benar secara teoritis. Error adalah internal — bisa jadi tidak terlihat dari luar sistem.
Ketidakmampuan sistem atau komponen untuk melakukan fungsi yang diperlukan dalam persyaratan yang ditentukan. Failure terlihat dari luar — pengguna merasakan dampaknya langsung.
Penting: Tidak semua fault menghasilkan failure! Fault yang tidak pernah dieksekusi (dead code) tidak akan pernah menjadi error. Fault yang menghasilkan error bisa jadi tidak menghasilkan failure jika ada mekanisme error handling yang baik.
MTTF = Rata-rata berapa km motor jalan sebelum mogok pertama kali. MTBF = Rata-rata jarak antar mogok (setelah diperbaiki dan jalan lagi). MTTR = Rata-rata berapa jam di bengkel sampai motor bisa jalan lagi. Availability = Berapa persen waktu motor bisa dipakai dibanding waktu total (termasuk saat di bengkel).
Sebuah sistem backend e-commerce mengalami 5 kali kegagalan dalam 1 bulan (720 jam). Total waktu perbaikan seluruhnya adalah 10 jam.
Hitung Failure Rate (λ):
λ = 5 failures / 720 jam = 0.00694 failure/jam
Hitung MTTR:
MTTR = 10 jam (total repair) / 5 failures = 2 jam/failure
Hitung MTTF:
Waktu operasi efektif = 720 - 10 = 710 jam
MTTF = 710 jam / 5 failures = 142 jam/failure
Hitung MTBF:
MTBF = MTTF + MTTR = 142 + 2 = 144 jam
Hitung Availability:
A = MTTF / MTBF = 142 / 144 = 0.9861 = 98.61%
✅ Kesimpulan: Sistem tersedia 98.61% dari waktu. Artinya downtime ~10 jam/bulan atau ~120 jam/tahun. Untuk e-commerce besar, ini masih belum memenuhi standar 99.9% (three nines) yang umumnya ditargetkan.
| Availability Level | Nama | Downtime/Tahun | Downtime/Bulan | Contoh Penggunaan |
|---|---|---|---|---|
| 99% | Two nines | 3.65 hari | 7.2 jam | Aplikasi internal non-kritis |
| 99.9% | Three nines | 8.77 jam | 43.8 menit | E-commerce, SaaS umum |
| 99.99% | Four nines | 52.6 menit | 4.38 menit | Platform fintech, cloud provider |
| 99.999% | Five nines | 5.26 menit | 26.3 detik | Sistem kritis: perbankan, kesehatan, 911 |
Defect Density = Persentase tagihan yang salah dari total tagihan yang diterbitkan. Code Coverage = Persentase produk yang sudah diaudit dari total produk yang ada. Cyclomatic Complexity = Tingkat kerumitan prosedur — semakin rumit, semakin besar kemungkinan ada celah. Technical Debt = Hutang yang Anda tumpuk sekarang dan harus bayar (dengan bunga) nanti.
Cyclomatic Complexity (CC) menghitung berapa banyak jalur berbeda yang bisa dilalui kode. Setiap percabangan (if, else, while, for, case) menambah satu jalur.
✅ CC Rendah (CC = 3) — Baik:
def nilai_huruf(nilai): if nilai >= 80: # +1 cabang return "A" elif nilai >= 65: # +1 cabang return "B" else: return "C" # CC = 1 + 2 = 3 ← Mudah diuji!
⚠️ CC Tinggi (CC = 12+) — Berbahaya:
Fungsi dengan banyak if-else bersarang, multiple try-catch, loop bersarang, dan banyak kondisi boolean (AND/OR) menciptakan kompleksitas tinggi.
Risiko: Butuh 12+ test case hanya untuk menguji satu fungsi ini. Sulit dipahami, sulit diubah, rawan bug.
Panduan umum: CC 1-10 = sederhana ✅ | CC 11-20 = menengah ⚠️ | CC 21-50 = kompleks ❌ | CC > 50 = tidak bisa diuji 🚨
Tim QA proyek aplikasi klinik menemukan 85 defect selama fase pengujian. Setelah rilis, pengguna melaporkan 15 defect tambahan dalam 3 bulan pertama.
D_pre (sebelum rilis) = 85 defect
D_post (setelah rilis) = 15 defect
Total defect = 85 + 15 = 100 defect
Defect Removal Efficiency (DRE):
DRE = 85 / (85 + 15) × 100% = 85/100 × 100% = 85%
Escaped Defect Ratio (EDR):
EDR = 15 / 100 × 100% = 15%
✅ Interpretasi: Tim QA berhasil "menangkap" 85% dari semua defect sebelum rilis. Masih ada 15% yang lolos ke pengguna. Industri software kritis menargetkan DRE ≥ 95%. Perlu peningkatan proses QA!
Data metrik tidak muncul dari langit — ia dikumpulkan melalui bug tracking system seperti Jira, GitLab Issues, GitHub Issues, atau Bugzilla. Setiap defect dicatat dengan terstruktur.
| ID | Deskripsi | Severity | Ditemukan Fase | Diperbaiki | Waktu (jam) |
|---|---|---|---|---|---|
| BUG-001 | Login gagal dengan karakter khusus di password | CRITICAL | Integration Test | Ya | 4 |
| BUG-002 | Laporan PDF tidak ter-generate saat data kosong | HIGH | System Test | Ya | 6 |
| BUG-003 | Tombol "Simpan" berwarna salah di dark mode | LOW | UAT | Ya | 1 |
| BUG-004 | Race condition saat dua user edit data sama | CRITICAL | Production | Ya | 12 |
| BUG-005 | Pesan error tidak informatif saat timeout | MEDIUM | System Test | Ya | 2 |
Dari tabel ini kita bisa menghitung: BUG-004 ditemukan di production = escaped defect. MTTR rata-rata = (4+6+1+12+2)/5 = 5 jam/bug
# ================================================================ # S11409 - Sesi 2: Menghitung Metrik Keandalan Software # Dosen: Riadi Marta Dinata, S.Ti., M.Kom. | ISTN Jakarta # ================================================================ import pandas as pd import matplotlib.pyplot as plt import numpy as np # ── DATA: Riwayat Kegagalan Sistem (jam operasi antar failure) ── data_kegagalan = { 'failure_ke': [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], 'waktu_operasi': [142, 98, 167, 203, 88, 175, 220, 145, 190, 160], # jam 'waktu_repair': [2, 3, 1, 4, 2, 1, 5, 2, 3, 2] # jam } df = pd.DataFrame(data_kegagalan) # ── MENGHITUNG METRIK ── total_operasi = df['waktu_operasi'].sum() total_repair = df['waktu_repair'].sum() jumlah_failure = len(df) mttf = total_operasi / jumlah_failure mttr = total_repair / jumlah_failure mtbf = mttf + mttr failure_rate = 1 / mttf availability = mttf / mtbf * 100 # ── TAMPILKAN HASIL ── print("="*50) print(" LAPORAN METRIK KEANDALAN SISTEM") print("="*50) print(f"Total waktu operasi : {total_operasi} jam") print(f"Total waktu perbaikan: {total_repair} jam") print(f"Jumlah kegagalan : {jumlah_failure} kali") print("-"*50) print(f"MTTF (jam/failure) : {mttf:.2f} jam") print(f"MTTR (jam/perbaikan) : {mttr:.2f} jam") print(f"MTBF (jam) : {mtbf:.2f} jam") print(f"Failure Rate (λ) : {failure_rate:.5f} per jam") print(f"Availability : {availability:.4f}%") # ── VISUALISASI ── fig, axes = plt.subplots(1, 2, figsize=(12, 5)) # Plot 1: Waktu operasi per failure axes[0].bar(df['failure_ke'], df['waktu_operasi'], color='#C8102E', alpha=0.8, label='Waktu Operasi') axes[0].axhline(y=mttf, color='#D4A017', linestyle='--', linewidth=2, label=f'MTTF = {mttf:.1f} jam') axes[0].set_xlabel('Ke-n Kegagalan') axes[0].set_ylabel('Jam Operasi') axes[0].set_title('Waktu Operasi Antar Kegagalan') axes[0].legend() # Plot 2: Perbandingan MTTF, MTTR, MTBF labels = ['MTTF', 'MTTR', 'MTBF'] values = [mttf, mttr, mtbf] colors = ['#C8102E', '#22C55E', '#38BDF8'] axes[1].bar(labels, values, color=colors, alpha=0.85) axes[1].set_ylabel('Jam') axes[1].set_title('Perbandingan Metrik Keandalan') for i, v in enumerate(values): axes[1].text(i, v+1, f'{v:.1f}', ha='center', fontweight='bold') plt.tight_layout() plt.savefig('metrik_keandalan.png', dpi=150, bbox_inches='tight') print("\nGrafik disimpan: metrik_keandalan.png") # ── MENGHITUNG DRE ── defect_pre_rilis = 85 # ditemukan saat QA defect_post_rilis = 15 # ditemukan pengguna setelah rilis DRE = defect_pre_rilis / (defect_pre_rilis + defect_post_rilis) * 100 print(f"\nDefect Removal Efficiency (DRE): {DRE:.1f}%") if DRE >= 95: print(" ✅ SANGAT BAIK - Proses QA sudah sangat efektif!") elif DRE >= 85: print(" ⚠️ CUKUP BAIK - Masih perlu ditingkatkan") else: print(" ❌ PERLU PERBAIKAN - Banyak defect lolos ke produksi!")
Output yang diharapkan: MTTF ≈ 158.8 jam, MTTR = 2.5 jam, MTBF ≈ 161.3 jam, Availability ≈ 98.45%, DRE = 85% (⚠️ Cukup Baik)
Install dependensi terlebih dahulu:
pip install pandas matplotlib numpy
# Simpan kode di atas sebagai metrik_andal.py, lalu jalankan:
python metrik_andal.py
Sebuah aplikasi mengalami 8 kegagalan dalam periode 30 hari (720 jam). Total waktu downtime adalah 16 jam. Hitunglah: (a) MTTF, (b) MTTR, (c) MTBF, (d) Availability, (e) Apakah memenuhi SLA 99.5%?
Sebuah modul Python terdiri dari 2.500 baris kode dan memiliki 12 bug yang ditemukan selama pengujian. Hitunglah Defect Density. Apakah termasuk kualitas "baik" menurut standar industri?
Jelaskan perbedaan Fault, Error, dan Failure dengan menggunakan analogi sebuah aplikasi mobile banking. Berikan contoh konkret untuk masing-masing.
Tim QA menemukan 120 defect sebelum rilis. Setelah 2 bulan di produksi, pengguna melaporkan 30 defect tambahan. Hitunglah DRE dan Escaped Defect Ratio. Apa rekomendasi Anda untuk meningkatkan DRE?
Modifikasi kode Python di atas untuk menambahkan: (a) perhitungan dan plotting Failure Rate (λ) per periode, (b) indikator warna pada grafik (merah jika tidak memenuhi target, hijau jika memenuhi), (c) export hasil ke file CSV.
Fault ≠ Error ≠ Failure — Cacat kode, state salah, dan kegagalan yang dirasakan user adalah tiga hal berbeda
MTTF, MTBF, MTTR, λ, Availability — Lima metrik keandalan wajib untuk setiap sistem
Defect Density < 1/KLOC adalah target kualitas kode untuk software berkualitas tinggi
DRE ≥ 95% adalah target DRE untuk sistem kritis — artinya hanya 5% bug yang boleh lolos ke user
Cyclomatic Complexity ≤ 10 untuk kode yang mudah diuji dan dipelihara
Bug tracker adalah sumber data metrik — tanpa pencatatan yang baik, tidak ada metrik yang akurat