---
marp: true
paginate: true
header: 'RTI — Riset Teknologi Informasi | Universitas Putra Bangsa Kebumen'
footer: '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.