riset-teknologi-informasi/slide/slide-02-problem-formulation.md

marp	paginate	header	footer
true	true	RTI — Riset Teknologi Informasi | Universitas Putra Bangsa Kebumen	Helmi Bahar Alim, S.Kom., M.Kom. | 2026

Bab 2 — Problem Formulation & System Context

Merumuskan Masalah Riset dari Fenomena TI

Pertemuan 2 (M2)  |  Sub-CPMK 1.2  |  CPMK01  |  CPL03 + CPL06

Fase: Thinking (M1–M4)  ·  Bagian I: Foundation

Universitas Putra Bangsa  |  Fak. Sains & Teknologi  ·  Prodi Teknik Informatika

---

Agenda Pertemuan 2

1. Dari mana penelitian dimulai?
2. Problem Formation Model — proses transformasi masalah
3. Problem Quality Model — 5 kriteria masalah yang layak diteliti
4. Topic vs Problem vs Research Problem
5. Symptom vs Root Cause — menggali ke akar
6. System Thinking dalam konteks riset TI
7. Operasionalisasi: Problem → Variable → Metric
8. Cognitive Traps & Studi Kasus
9. Output Praktis: Problem Statement

---

Capaian Pembelajaran

Setelah pertemuan ini, mahasiswa mampu:

• Membedakan topik, masalah, dan masalah riset secara presisi
• Mengidentifikasi gejala vs akar masalah dalam fenomena TI
• Mendeskripsikan konteks sistem (Input-Process-Output-Outcome-Constraints-Stakeholders)
• Mentransformasi fenomena TI menjadi researchable problem yang terukur
• Memvalidasi problem statement dengan 5 kriteria kualitas

Sub-CPMK 1.2 → Merumuskan masalah riset dari fenomena TI (CPL03 + CPL06)

---

Pertanyaan Pemantik

Bab 1 membagun fondasi berpikir: Curious → Critical → Systematic.

Sekarang pertanyaannya: dari mana penelitian dimulai?

Bukan dari metode. Bukan dari dataset. Bukan dari tool atau teknologi yang ingin digunakan.

Penelitian dimulai dari MASALAH.

Tapi "masalah riset" bukan sekadar keluhan:

• "Website kampus lambat" → keluhan
• "Waktu respons meningkat 340% saat concurrent user > 500, belum ada studi tentang caching strategy X di arsitektur monolitik akademik" → masalah riset

Perbedaannya: presisi, konteks sistem, dan testability.

---

Problem Formation Model

Dari Realitas ke Variabel Terukur

Reality → Observed Issue → Diagnosed Problem → Researchable Problem → Measurable Variable

(Symptom)        (Root Cause)        (Scoped & Bounded)     (Operationalized)

Tahap	Fungsi	Pertanyaan yang Dijawab
Reality	Fenomena dunia nyata	Apa yang terjadi di lapangan?
Observed Issue	Pengamatan awal (gejala)	Apa yang terlihat "tidak beres"?
Diagnosed Problem	Akar masalah setelah investigasi	Mengapa itu terjadi?
Researchable Problem	Masalah + gap literatur + batasan	Apakah ini layak diteliti?
Measurable Variable	Variabel yang bisa diuji	Bagaimana mengukurnya?

Kesalahan paling umum: melompat langsung dari Reality ke Measurable Variable — melewati analisis akar masalah dan literatur gap.

---

Problem Quality Model — 5 Kriteria

Setiap masalah riset harus lulus 5 kriteria ini:

Kriteria	Pertanyaan Uji	Gagal jika...
Clarity	Bisa dipahami tanpa ambiguitas?	Tidak jelas siapa/apa/di mana/kapan
Measurability	Ada metrik yang bisa diukur?	Hanya bisa dinilai secara subjektif
Relevance	Ada gap di literatur?	Sudah terjawab penuh sebelumnya
Testability	Bisa dieksperimenkan?	Terlalu luas, tidak feasible
Impact	Ada kontribusi nyata?	Tidak ada yang peduli dengan jawabannya

Jika masalah tidak lulus semua 5 kriteria → ulangi proses formasi. Lebih baik 1 minggu perbaiki masalah daripada 1 semester meneliti masalah yang salah.

---

Topic vs Problem vs Research Problem

Level	Analogi	Contoh TI
Topik	"Ada masalah di kota ini"	"Keamanan IoT"
Masalah	"Jalan berlubang di KM 5"	"MQTT tidak terenkripsi pada IoT rumahan"
Masalah Riset	"Lubang di KM 5 disebabkan drainase gagal; belum ada studi material X untuk kondisi ini"	"Belum ada studi yang membandingkan overhead TLS 1.3 vs DTLS pada MQTT di perangkat resource-constrained (RAM < 64KB)"

Research Problem memiliki 3 elemen yang tidak dimiliki masalah biasa:

1. Gap — "belum ada studi yang..."
2. Variabel terukur — "overhead (ms, KB)"
3. Batasan konteks — "resource-constrained, RAM < 64KB"

---

Symptom vs Root Cause

Dalam riset TI, apa yang terlihat di permukaan bukan selalu masalah yang sebenarnya.

Yang Diamati (Gejala)	Akar Masalah (Dugaan)	Masalah Riset
"Pengguna mengeluh aplikasi lambat"	Query DB tidak terindeks → full table scan	Efektivitas composite index pada tabel 2M record PostgreSQL dalam skenario concurrent read
"Model ML performa menurun di produksi"	Training-serving skew (distribusi data berbeda)	Deteksi & mitigasi data drift pada pipeline ML streaming real-time
"Pengguna meninggalkan fitur baru"	Friction di onboarding flow	Korelasi antara kompleksitas UI dan user retention pada aplikasi mobile F&B

Teknik menggali akar masalah: 5 Whys, Fishbone Diagram, Root Cause Analysis — sebelum masuk ke literatur.

---

System Thinking dalam Riset TI

Masalah riset TI selalu terikat pada sistem. Tanpa memahami sistem, masalah jadi abstrak dan tidak bisa dieksperimenkan.

Input → [Process] → Output → Outcome
           |
      Constraints
           |
      Stakeholders

Komponen	Contoh (Studi Rekomendasi Film)
Input	Riwayat tontonan pengguna, rating, metadata konten
Process	Algoritma collaborative filtering
Output	Daftar 10 film yang direkomendasikan
Outcome	Pengguna puas, waktu tonton meningkat (atau tidak)
Constraints	Latency < 200ms, privasi data, cold-start problem
Stakeholders	Pengguna, platform, content provider

Akurasi tinggi (Output) ≠ pengguna puas (Outcome). Inilah mengapa masalah riset tidak bisa hanya fokus pada satu komponen sistem.

---

Transformasi: Problem → Variable → Metric

Operasionalisasi masalah ke variabel yang dapat diukur

Problem → Variable → Metric → Data Type → Analysis Method

Contoh:

Problem	Variable	Metric	Tipe Data
Rekomendasi tidak relevan	Relevansi rekomendasi	Precision@K, NDCG	Ratio
Fraud lolos deteksi	Kemampuan deteksi fraud	Recall, F2-score	Ratio
UI terlalu kompleks	Kemudahan penggunaan	Task completion time, SUS score	Ratio / Ordinal

Metrik harus dipilih sebelum eksperimen berjalan — bukan setelah melihat data dan memilih yang menghasilkan angka terbaik. (Wohlin et al., 2012)

---

Cognitive Traps

Bab 2 — Problem Formulation

---

Cognitive Traps — Bab 2

"Saya ingin menggunakan metode X, maka saya cari masalah yang cocok" Ini reverse engineering penelitian. Metode dipilih berdasarkan masalah — bukan sebaliknya. Jika mulai dari metode, bukan masalah yang diteliti, tapi metode yang didemonstrasikan.

"Semakin kompleks sistemnya, semakin bagus penelitiannya" Kompleksitas bukan kontribusi. Masalah spesifik yang sederhana namun belum terjawab lebih bermakna daripada sistem kompleks dengan masalah yang sudah umum diketahui.

"Problem tidak perlu diukur, yang penting jelas" "Respon sistem lambat" bukan masalah riset — tidak ada yang bisa dieksperimenkan. Research problem harus memiliki variabel yang terukur secara kuantitatif.

"Semua problem bisa diteliti" Tidak semua masalah memenuhi 5 kriteria kualitas. Sebagian masalah lebih tepat diselesaikan melalui engineering atau desain, bukan riset ilmiah.

---

Studi Kasus 1 — Rekomendasi Film (Basic)

Konteks: Peneliti membangun sistem rekomendasi film dengan collaborative filtering. Akurasi: 91%.

Masalah: Peneliti menggunakan accuracy (hit rate) sebagai satu-satunya metrik. Pengguna memperoleh rekomendasi yang "akurat" secara teknis, tapi tidak puas karena semua rekomendasi mirip (filter bubble) dan selalu item populer (popularity bias).

Masalah riset yang sebenarnya: "Bagaimana trade-off antara Precision@10 dan Diversity dalam sistem rekomendasi collaborative filtering pada dataset cold-start?"

Solusi: Definisikan masalah dari perspektif sistem lengkap (output + outcome + constraints). Gunakan multi-metric: Precision@K + Serendipity + Diversity + Coverage.

---

Studi Kasus 2 — Fraud Detection (Advanced)

Konteks: Model fraud detection — akurasi 98%, tapi fraud tetap lolos ke produksi.

Root Cause Analysis:

• Dataset imbalance: 99.5% transaksi normal, 0.5% fraud
• Dengan akurasi 98% sederhana: model bisa memprediksi "semua normal" dan tetap mendapat akurasi 98%
• Metrik yang salah menghasilkan false sense of security

Metrik	Nilai	Makna Sebenarnya
Accuracy	98.2%	Tidak bermakna untuk imbalanced data
Recall (fraud)	12%	Model melewatkan 88% kasus fraud!
F2-score	0.31	Rendah — recall lebih dipentingkan dari precision

Masalah riset yang tepat: "Efektivitas teknik resampling [SMOTE vs ADASYN] terhadap Recall dan F2-score pada deteksi fraud transaksi perbankan dengan rasio imbalance 1:200."

---

Ringkasan Pertemuan 2

Konsep	Inti
Problem Formation	Reality → Observed Issue → Diagnosed → Researchable → Measurable
Problem Quality	Clarity + Measurability + Relevance + Testability + Impact
Hierarki	Topik (wilayah) < Masalah (celah) < Research Problem (celah + gap + batas)
Symptom vs Root Cause	Gali lebih dalam sebelum ke literatur
System Thinking	Input-Process-Output-Outcome + Constraints + Stakeholders
Operasionalisasi	Problem → Variable → Metric → Data Type → Analysis

---

Final Statement & Output Praktis

"Penelitian tidak dimulai dari solusi, tetapi dari masalah yang dipahami secara mendalam dan dapat diuji secara ilmiah."

Output Praktis M2

Buat Problem Statement yang mencakup:

1. Konteks sistem — deskripsikan Input, Process, Output, Outcome, Constraints
2. Gejala yang diamati — data/fakta yang membuktikan masalah nyata
3. Akar masalah — hasil 5-Whys/RCA
4. Gap literatur — apa yang belum dijawab di penelitian sebelumnya
5. Variabel & metrik yang akan diukur

Validasi terhadap 5 kriteria Problem Quality Model sebelum dikumpulkan.

---

Referensi Utama — Bab 2

• Creswell, J. W., & Creswell, J. D. (2018). Research design: Qualitative, quantitative, and mixed methods approaches (5th ed.). SAGE Publications.

• Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28(1), 75–105.

• Wieringa, R. J. (2014). Design science methodology for information systems and software engineering. Springer.

• Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). Experimentation in software engineering. Springer.