Menemukan bug itu mudah — yang sulit adalah memahami mengapa bug itu bisa ada, dan mencegah kategori yang sama tidak muncul lagi di masa depan.
Tanpa RCA: Setiap kali hujan, Anda meletakkan ember untuk menampung air yang bocor. Masalah "teratasi" — tapi besok hujan, ember lagi.
Dengan RCA: Anda naik ke atap, menemukan bahwa genteng retak bukan karena usia, tapi karena tukang pasang baut terlalu kencang. Anda memperbaiki genteng DAN mengubah SOP pemasangan — sehingga kebocoran serupa tidak terjadi lagi di rumah lain.
RCA dalam software: Bukan hanya memperbaiki bug yang ditemukan, tapi memahami akar penyebabnya agar kelas bug yang sama tidak muncul lagi di modul lain atau di sprint berikutnya.
Baru dilaporkan, belum diperiksa
Sudah di-assign ke developer
Sedang diperbaiki
Developer klaim sudah diperbaiki
QA verifikasi — bug benar-benar selesai
Fix tidak berhasil, dikembalikan ke developer
Diputuskan tidak perlu diperbaiki (low risk, high cost)
Bug yang sama sudah dilaporkan sebelumnya
Severity (keparahan medis) = Seberapa parah kondisi pasien secara klinis. Patah tulang = berat, luka kecil = ringan. Ini ditentukan dokter berdasarkan kondisi fisik.
Priority (prioritas penanganan) = Urutan siapa yang ditangani lebih dulu. Pasien VIP dengan flu mungkin ditangani lebih cepat dari pasien biasa dengan luka kecil — meskipun secara medis luka kecil lebih "urgent". Priority dipengaruhi faktor bisnis dan konteks.
Dalam software: Bug di fitur demo besok (severity rendah) bisa punya priority tinggi. Bug di fitur yang jarang dipakai (severity tinggi) bisa punya priority rendah untuk sementara.
ODC adalah taksonomi defect yang dikembangkan IBM untuk mengklasifikasikan bug secara sistematis, sehingga pola bisa diidentifikasi dan proses pengembangan bisa diperbaiki secara targeted.
| Tipe Defect | Deskripsi | Contoh Nyata |
|---|---|---|
| Function | Kesalahan dalam logika bisnis atau algoritma utama | Rumus perhitungan bunga pinjaman salah |
| Assignment | Inisialisasi variabel salah atau struktur data tidak tepat | Array dimulai dari index 1 bukan 0 |
| Interface | Masalah pada antarmuka antar komponen (API, parameter) | Format tanggal yang berbeda antara frontend-backend |
| Checking | Validasi input tidak memadai atau error handling kurang | Tidak ada validasi untuk field kosong di form login |
| Timing/Serialization | Race condition, deadlock, masalah sinkronisasi | Dua user mengedit data sama secara bersamaan |
| Build/Package | Masalah dalam proses build, deployment, atau konfigurasi | Library versi lama tidak di-update di server production |
| Documentation | Dokumentasi tidak akurat atau tidak lengkap | API docs mengatakan endpoint /users tapi sebenarnya /user |
Manfaat ODC: Jika 40% bug bertipe "Checking", artinya tim perlu meningkatkan code review dan validasi input. Data ODC memberi arah perbaikan proses yang spesifik!
Teknik sederhana tapi powerful: tanyakan "mengapa?" setidaknya 5 kali sampai menemukan akar masalah yang sebenarnya. Dikembangkan oleh Sakichi Toyoda di Toyota Production System.
Mesin pabrik tiba-tiba berhenti. Mengapa? Sekring putus. Mengapa? Arus berlebihan. Mengapa? Bearing tidak dilumasi. Mengapa? Pompa oli tidak bekerja. Mengapa? Filter oli tersumbat dan tidak pernah diganti. Solusi bukan ganti sekring, tapi buat jadwal penggantian filter oli!
Kasus: Sistem e-commerce down selama 2 jam saat Harbolnas
Solusi dari akar masalah: Buat prosedur analisis historis traffic sebelum setiap event besar → definisikan skenario load test → konfigurasi auto-scaling → bukan sekadar "tambah server" saat sudah down!
Cocok untuk masalah yang memiliki banyak faktor penyebab potensial. Diagram berbentuk tulang ikan, dengan "kepala" adalah masalah, dan "tulang" adalah kategori penyebab.
Kategori penyebab yang dianalisis:
Setelah fishbone dibuat: Tim voting untuk menentukan faktor yang paling berkontribusi, lalu fokus pada 2-3 akar masalah utama untuk diperbaiki di sprint berikutnya.
FTA memvisualisasikan bagaimana kombinasi kejadian (fault) dapat menyebabkan sebuah kegagalan (top event). Menggunakan logika boolean (AND gate, OR gate) — sangat berguna untuk sistem safety-critical.
Kebakaran terjadi jika ada tiga hal bersamaan (AND gate): bahan bakar + oksigen + panas. Jika salah satu tidak ada → tidak ada kebakaran. Sebaliknya, sistem alarm berbunyi jika ada salah satu dari (OR gate): asap ATAU panas berlebih ATAU api terdeteksi.
FTA dalam software: "Sistem payment gagal" ← bisa dari [API bank timeout] OR [validasi gagal] OR [database tidak tersedia]. Masing-masing bisa dipecah lebih lanjut.
Vilfredo Pareto menemukan bahwa di Italia, 20% penduduk memiliki 80% tanah. Prinsip ini ternyata berlaku hampir universal. Dalam software: 20% modul atau tipe defect menyebabkan 80% bug yang ditemukan. Fokus perbaiki yang 20% itu, dan Anda sudah menyelesaikan 80% masalah!
Total: 120 defect. Tiga kategori teratas menyebabkan 79% dari semua bug!
Keputusan berbasis data: Fokuskan improvement sprint berikutnya pada "Validasi Input" dan "Error Handling". Solusi: wajibkan checklist validasi di setiap PR, dan adakan workshop error handling untuk seluruh tim developer.
Masalah: Firefox crash ketika membuka halaman web dengan gambar berukuran sangat besar (>2GB). Ini adalah bug yang bisa dieksploitasi untuk crash browser pengguna.
5 Whys Analysis:
Solusi yang diterapkan: Ganti int32 → int64 untuk kalkulasi ukuran. Tambahkan batas maksimum gambar yang eksplisit. Buat kebijakan audit asumsi hardware setiap 2 tahun.
Pelajaran untuk SI: Saat membangun sistem informasi yang akan berkembang, selalu dokumentasikan asumsi (misal: "maksimum 10.000 pengguna", "ukuran file max 50MB") dan jadwalkan review asumsi tersebut secara berkala!
# ================================================================ # S11409 - Sesi 6: Analisis Defect & Visualisasi Pareto # Dosen: Riadi Marta Dinata, S.Ti., M.Kom. | ISTN Jakarta # ================================================================ import pandas as pd import matplotlib.pyplot as plt import matplotlib.ticker as mticker import numpy as np from collections import Counter # ── DATASET SIMULASI DEFECT ── data_defect = { 'id': [f'BUG-{i:03d}' for i in range(1, 121)], 'sprint': np.random.choice(['S1','S2','S3','S4','S5','S6'], 120, p=[0.10,0.15,0.22,0.20,0.18,0.15]), 'kategori': np.random.choice([ 'Validasi Input', 'Error Handling', 'Race Condition', 'UI Tampilan', 'Logika Bisnis', 'Lain-lain' ], 120, p=[0.38,0.25,0.16,0.11,0.07,0.03]), 'severity': np.random.choice(['Critical','High','Medium','Low'], 120, p=[0.10,0.25,0.40,0.25]), 'waktu_fix': np.random.exponential(scale=3, size=120).round(1) # jam } df = pd.DataFrame(data_defect) # ── ANALISIS DASAR ── print("="*55) print(" LAPORAN ANALISIS DEFECT — PROYEK SIAKAD") print("="*55) print(f"Total defect : {len(df)}") print(f"Rata-rata waktu fix : {df['waktu_fix'].mean():.1f} jam") print(f"Defect Critical : {(df['severity']=='Critical').sum()}") print() # ── PARETO ANALYSIS ── kategori_count = df['kategori'].value_counts().sort_values(ascending=False) total = kategori_count.sum() persen = (kategori_count / total * 100).round(1) kumulatif = persen.cumsum() print("--- Pareto Analysis ---") for kat, cnt in kategori_count.items(): print(f" {kat:<22} : {cnt:3d} ({cnt/total*100:5.1f}%)") print() # ── DEFECT ARRIVAL/CLOSURE CURVE ── arrival_by_sprint = df.groupby('sprint').size() # Simulasi closure (biasanya lebih lambat dari arrival) closure_by_sprint = (arrival_by_sprint * np.array([0.7,0.8,0.85,0.9,0.95,1.0])).astype(int) # ── VISUALISASI (3 plot) ── fig = plt.figure(figsize=(16, 5)) fig.patch.set_facecolor('#0A0608') # Plot 1: Pareto Chart ax1 = fig.add_subplot(1, 3, 1) ax1.set_facecolor('#160C0E') colors = ['#C8102E','#F97316','#FCD34D','#22C55E','#38BDF8','#9B7A80'] bars = ax1.bar(kategori_count.index, kategori_count.values, color=colors[:len(kategori_count)], alpha=0.85) ax1.set_title('Pareto Defect by Kategori', color='white', pad=10) ax1.tick_params(axis='x', rotation=45, colors='#9B7A80', labelsize=8) ax1.tick_params(axis='y', colors='#9B7A80') ax2_twin = ax1.twinx() ax2_twin.plot(range(len(kumulatif)), kumulatif.values, color='#D4A017', marker='o', linewidth=2, markersize=5) ax2_twin.axhline(80, color='#D4A017', linestyle='--', alpha=0.5) ax2_twin.set_ylabel('Kumulatif %', color='#D4A017') ax2_twin.tick_params(colors='#D4A017') ax2_twin.yaxis.set_major_formatter(mticker.PercentFormatter()) # Plot 2: Defect per Sprint (Arrival vs Closure) ax3 = fig.add_subplot(1, 3, 2) ax3.set_facecolor('#160C0E') x = np.arange(len(arrival_by_sprint)) ax3.plot(x, arrival_by_sprint.values, color='#C8102E', marker='o', lw=2, label='Defect Masuk') ax3.plot(x, closure_by_sprint.values, color='#22C55E', marker='s', lw=2, linestyle='--', label='Defect Ditutup') ax3.fill_between(x, arrival_by_sprint.values, closure_by_sprint.values, alpha=0.15, color='#C8102E', label='Backlog') ax3.set_xticks(x); ax3.set_xticklabels(arrival_by_sprint.index) ax3.set_title('Defect Arrival vs Closure Curve', color='white', pad=10) ax3.legend(fontsize=8); ax3.grid(alpha=0.15) ax3.tick_params(colors='#9B7A80') # Plot 3: Severity Distribution ax4 = fig.add_subplot(1, 3, 3) ax4.set_facecolor('#160C0E') sev_count = df['severity'].value_counts() sev_colors = ['#F87171','#F97316','#FCD34D','#22C55E'] wedges, texts, autotexts = ax4.pie(sev_count.values, labels=sev_count.index, colors=sev_colors, autopct='%1.1f%%', startangle=90, pctdistance=0.85) for t in texts: t.set_color('#9B7A80'); t.set_fontsize(9) for at in autotexts: at.set_color('white'); at.set_fontsize(9) ax4.set_title('Distribusi Severity Defect', color='white', pad=10) plt.tight_layout() plt.savefig('analisis_defect.png', dpi=150, facecolor='#0A0608', bbox_inches='tight') print("✅ Grafik tersimpan: analisis_defect.png") print("\n💡 Rekomendasi perbaikan berdasarkan Pareto:") top3 = kategori_count.head(3) for kat, cnt in top3.items(): print(f" → Fokus pada '{kat}' ({cnt} bug, {cnt/total*100:.0f}%)")
Sebuah bug dilaporkan pengguna (status: NEW), lalu developer mengatakan "sudah diperbaiki" (RESOLVED), tapi QA menemukan bug masih ada. Jelaskan langkah-langkah yang harus diambil tim QA. Apa status yang tepat dan siapa yang harus melakukan apa?
Berikan contoh nyata (dalam konteks aplikasi kampus SIAKAD) untuk: (a) Severity tinggi, Priority rendah, (b) Severity rendah, Priority tinggi. Jelaskan mengapa bisa terjadi situasi seperti ini.
Aplikasi presensi mahasiswa menunjukkan data presensi yang salah — mahasiswa yang hadir tercatat absen. Lakukan analisis 5 Whys untuk menemukan akar masalahnya. Tentukan minimal 2 kemungkinan root cause yang berbeda.
Buat fishbone diagram untuk masalah "Waktu respons aplikasi sangat lambat (>5 detik)" pada sistem informasi akademik. Identifikasi minimal 3 penyebab untuk setiap kategori: People, Process, Technology, dan Environment.
Modifikasi kode Python di atas untuk: (a) menghitung mean waktu perbaikan (MTTR) per severity level, (b) mengidentifikasi sprint dengan defect backlog tertinggi, (c) membuat rekomendasi otomatis berdasarkan Pareto (kategori mana yang harus diprioritaskan).
RCA mencari akar masalah, bukan sekadar memperbaiki bug yang terlihat — 5 Whys adalah alat paling praktis
Severity ≠ Priority — keparahan teknis dan urgensi bisnis bisa berbeda, keduanya harus dipertimbangkan
ODC mengklasifikasikan bug berdasarkan tipe — data ini mengarahkan perbaikan proses yang spesifik
Fishbone ideal untuk masalah dengan banyak faktor; FTA untuk sistem safety-critical dengan logika AND/OR
Pareto 80/20 — fokus perbaiki 20% penyebab yang menyumbang 80% bug, jangan buang waktu untuk hal minor
Arrival vs Closure curve menunjukkan apakah tim bisa "mengimbangi" bug baru — jika arrival > closure terus, ada masalah serius