Sesi 02 dari 16

Metrik & Pengukuran Keandalan Perangkat Lunak

Belajar "mengukur" keandalan software seperti dokter mengukur kesehatan pasien — dengan angka yang bermakna, bukan perasaan semata.

🔢 Teori + Hitungan
⏱️ 3 x 50 menit
🐍 Python Praktik
📊 MTTF · MTBF · MTTR
📐 Bagian 1 — Mengapa Kita Perlu Mengukur?

Keandalan Tanpa Metrik Adalah Perasaan

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?

💡 ANALOGI — Rekam Medis

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.

🔬 Bagian 2 — Taksonomi: Fault, Error, Failure

Beda Fault, Error, dan Failure

Tiga istilah ini sering digunakan bergantian tapi sebenarnya memiliki arti yang sangat berbeda. Memahami perbedaannya krusial untuk analisis keandalan.

🐛 FAULT

Cacat dalam kode (bug yang ditulis programmer)

⚡ ERROR

State sistem yang salah saat fault aktif

💥 FAILURE

Perilaku sistem yang menyimpang dari yang diharapkan pengguna

💡 ANALOGI — Resep Masakan

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".

🐛 Fault (Cacat)

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.

⚡ Error (Kesalahan)

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.

💥 Failure (Kegagalan)

Ketidakmampuan sistem atau komponen untuk melakukan fungsi yang diperlukan dalam persyaratan yang ditentukan. Failure terlihat dari luar — pengguna merasakan dampaknya langsung.

❓ Fault → Failure?

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.

📊 Bagian 3 — Metrik Keandalan Utama

Lima Metrik Wajib Software Reliability

MTTF
Mean Time To Failure
MTTF = Total Waktu Operasi / Jumlah Failure
Rata-rata waktu sistem bekerja sebelum mengalami kegagalan pertama. Digunakan untuk sistem yang tidak diperbaiki (disposable).
MTBF
Mean Time Between Failures
MTBF = MTTF + MTTR
Rata-rata waktu antara dua kegagalan berturut-turut. Digunakan untuk sistem yang dapat diperbaiki dan digunakan lagi.
MTTR
Mean Time To Repair
MTTR = Total Waktu Perbaikan / Jumlah Perbaikan
Rata-rata waktu yang dibutuhkan untuk memulihkan sistem setelah terjadi kegagalan. Mengukur efisiensi tim support/DevOps.
λ (lambda)
Failure Rate
λ = 1 / MTTF = Jumlah Failure / Waktu Total
Frekuensi kegagalan per satuan waktu. Semakin kecil λ, semakin andal sistem. Kebalikan dari MTTF.
A
Availability (Ketersediaan)
A = MTTF / (MTTF + MTTR) = MTTF / MTBF
Proporsi waktu sistem tersedia dan berfungsi. Dinyatakan sebagai persentase (misal: 99.9% = "three nines").
SLA
Service Level Agreement
Downtime = (1 - A) × Total Waktu
Komitmen availability kepada pelanggan. 99.9% berarti max 8.7 jam downtime/tahun. 99.99% max 52 menit/tahun.
💡 ANALOGI — Bengkel Motor

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).

🔢 CONTOH PERHITUNGAN 1 — Sistem Backend E-Commerce

Sebuah sistem backend e-commerce mengalami 5 kali kegagalan dalam 1 bulan (720 jam). Total waktu perbaikan seluruhnya adalah 10 jam.

1

Hitung Failure Rate (λ):
λ = 5 failures / 720 jam = 0.00694 failure/jam

2

Hitung MTTR:
MTTR = 10 jam (total repair) / 5 failures = 2 jam/failure

3

Hitung MTTF:
Waktu operasi efektif = 720 - 10 = 710 jam
MTTF = 710 jam / 5 failures = 142 jam/failure

4

Hitung MTBF:
MTBF = MTTF + MTTR = 142 + 2 = 144 jam

5

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.

📋 Tabel SLA — Berapa Batas Toleransi Downtime?

Availability LevelNamaDowntime/TahunDowntime/BulanContoh Penggunaan
99%Two nines3.65 hari7.2 jamAplikasi internal non-kritis
99.9%Three nines8.77 jam43.8 menitE-commerce, SaaS umum
99.99%Four nines52.6 menit4.38 menitPlatform fintech, cloud provider
99.999%Five nines5.26 menit26.3 detikSistem kritis: perbankan, kesehatan, 911
🔍 Bagian 4 — Metrik Kualitas Kode

Mengukur "Kesehatan" Kode Anda

DD
Defect Density
DD = Jumlah Defect / KLOC
Jumlah bug per 1000 baris kode (KLOC). Standar industri: < 1 defect/KLOC untuk software berkualitas tinggi.
CC
Code Coverage
CC = (Baris Diuji / Total Baris) × 100%
Persentase kode yang dieksekusi oleh test suite. Target umum: ≥80% untuk aplikasi kritis.
CC
Cyclomatic Complexity
CC = E - N + 2P
Jumlah jalur independen melalui kode (cabang keputusan). CC > 10 = kode kompleks, sulit diuji, rawan bug.
TD
Technical Debt
TD = Biaya Perbaikan "jalan pintas"
Biaya yang harus dibayar di masa depan akibat mengambil jalan pintas sekarang. Semakin besar TD, semakin lambat pengembangan.
💡 ANALOGI — Kesehatan Keuangan

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.

📐 Memahami Cyclomatic Complexity dengan Contoh

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:

Contoh SederhanaPython
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 🚨

⚙️ Bagian 5 — Metrik Proses QA

Mengukur Efektivitas Proses Pengujian

DDR
Defect Detection Rate
DDR = Defect Ditemukan / Total Defect
Persentase defect yang berhasil ditemukan oleh proses QA sebelum rilis. Target: setinggi mungkin (≥95% untuk sistem kritis).
DRE
Defect Removal Efficiency
DRE = D_pre / (D_pre + D_post) × 100%
Efisiensi penghapusan defect sebelum rilis. D_pre = defect ditemukan sebelum rilis, D_post = ditemukan setelah rilis oleh user.
EDR
Escaped Defect Ratio
EDR = D_post / (D_pre + D_post) × 100%
Persentase defect yang "lolos" ke tangan pengguna. Ini adalah kebalikan DRE. Semakin kecil, semakin bagus tim QA Anda.
🔢 CONTOH PERHITUNGAN 2 — DRE & Escaped Defect

Tim QA proyek aplikasi klinik menemukan 85 defect selama fase pengujian. Setelah rilis, pengguna melaporkan 15 defect tambahan dalam 3 bulan pertama.

1

D_pre (sebelum rilis) = 85 defect
D_post (setelah rilis) = 15 defect
Total defect = 85 + 15 = 100 defect

2

Defect Removal Efficiency (DRE):
DRE = 85 / (85 + 15) × 100% = 85/100 × 100% = 85%

3

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!

🐛 Bagian 6 — Bug Tracking System

Bagaimana Defect Dikelola

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.

📋 Contoh Dataset Defect dari Bug Tracker

IDDeskripsiSeverityDitemukan FaseDiperbaikiWaktu (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

🐍 Bagian 7 — Praktik Python: Menghitung Metrik

Dari Teori ke Kode Nyata

PRAKTIK: Menghitung Metrik Keandalan dari Data Defect Python 3.x
# ================================================================
# 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)

💡 Cara Menjalankan Kode Ini

Install dependensi terlebih dahulu:

Terminal / Command PromptBash
pip install pandas matplotlib numpy

# Simpan kode di atas sebagai metrik_andal.py, lalu jalankan:
python metrik_andal.py
✏️ Bagian 8 — Latihan Mandiri
📝 KUIS SESI 2

Uji Pemahaman Anda

Soal 1 — Hitungan

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%?

Soal 2 — Analisis

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?

Soal 3 — Pemahaman Konsep

Jelaskan perbedaan Fault, Error, dan Failure dengan menggunakan analogi sebuah aplikasi mobile banking. Berikan contoh konkret untuk masing-masing.

Soal 4 — Analisis Kasus

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?

Soal 5 — Python Challenge

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.

💡 Rangkuman Kunci Sesi 2

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