---
marp: true
paginate: true
class: bagian-ii
header: 'RTI — Riset Teknologi Informasi | Universitas Putra Bangsa Kebumen'
footer: 'Helmi Bahar Alim, S.Kom., M.Kom. | 2026'
---
# Bab 6 — System Design sebagai Experimental Artifact
## Sistem sebagai Alat Uji, Bukan Tujuan Akhir
*Pertemuan 6 (M6) | Sub-CPMK 2.2 | CPMK02 | CPL06*
Fase: **Designing** (M5–M7) · Bagian II: Measurement & Design
**Universitas Putra Bangsa** | Fak. Sains & Teknologi · Prodi Teknik Informatika
---
## Agenda Pertemuan 6
1. Perubahan paradigma: sistem sebagai alat uji hipotesis
2. System as Experiment Model
3. 4 Prinsip desain sistem riset: Traceability, Modularity, Controllability, Measurability
4. Mapping RQ → System Component
5. Pentingnya control & isolation variabel
6. Dokumentasi arsitektur sebagai bagian metodologi
7. Cognitive Traps & Studi Kasus
8. Output Praktis: Diagram arsitektur + mapping ke variabel
---
## Capaian Pembelajaran
Setelah pertemuan ini, mahasiswa mampu:
- Menjelaskan perbedaan antara **sistem engineered** dan **sistem sebagai artefak penelitian**
- Memetakan **RQ → System Component** secara eksplisit
- Merancang sistem yang memenuhi **4 prinsip**: Traceability, Modularity, Controllability, Measurability
- Menjelaskan pentingnya **variabel control** dan **isolation** dalam desain eksperimen
- Mendokumentasikan arsitektur sebagai bagian metodologi riset
> Sub-CPMK 2.2 → Merancang sistem sebagai artefak eksperimen (CPL06)
---
## Perubahan Paradigma Fundamental
| Pertanyaan | Engineering View | Research View |
|-----------|-----------------|--------------|
| **Untuk apa sistem ini dibangun?** | Agar pengguna bisa menggunakannya | Agar hipotesis bisa diuji |
| **Ukuran keberhasilan utama** | Sistem berjalan sesuai requirement | Hipotesis terjawab secara signifikan |
| **Yang diprioritaskan** | Fitur lengkap, UX bagus | Kontrol variabel, reproducibility |
| **Arsitektur dirancang berdasarkan** | Kebutuhan fungsional | RQ dan variabel eksperimen |
| **Dokumentasi terpenting** | User manual, API docs | Experimental setup, parameter log |
> "Dalam penelitian, sistem bukan dibangun untuk digunakan, tetapi untuk **membuktikan sesuatu secara ilmiah**."
---
## System as Experiment Model
*RQ menentukan arsitektur, bukan sebaliknya*
**Research Question** ↓ Variable (Independent & Dependent) ↓ System Component (apa yang perlu dibangun?) ↓ Experimental Setup (bagaimana dijalankan?) ↓ **Output / Measured Data**
Setiap komponen sistem harus bisa dijawab: **"Komponen ini mendukung variabel/hipotesis yang mana?"**
---
## 4 Prinsip Desain Sistem Riset
### 1. Traceability — setiap komponen bisa ditelusuri ke RQ
Setiap modul atau komponen sistem harus punya kaitan eksplisit ke variabel dalam RQ.
**RQ:** "Apakah attention mechanism meningkatkan F1-score NER?"
- Modul A: BiLSTM encoder (baseline)
- Modul B: Attention layer (variabel independen)
- Modul C: CRF decoder (output)
- Modul D: Evaluasi F1 per entity (variabel dependen)
Jika ada komponen yang tidak bisa ditelusuri ke RQ → pertanyakan apakah komponen itu diperlukan.
---
## 4 Prinsip Desain Sistem Riset (lanjutan)
### 2. Modularity — komponen yang diuji harus bisa diswap
Sistem harus dirancang sehingga variabel yang diuji bisa diubah secara independen.
**Monolith:** Semua logika dalam satu fungsi besar → tidak bisa isolasi perubahan
**Modular:** Setiap komponen terpisah, bisa diganti tanpa mengubah yang lain
### 3. Controllability — bisa mengontrol kondisi eksperimen
Harus bisa mengatur: seed random, hyperparameter, ukuran dataset, split ratio — secara konsisten dan reproducible.
### 4. Measurability — output bisa langsung diukur
Output sistem harus langsung menghasilkan data dalam format yang bisa dievaluasi dengan metrik yang sudah didefinisikan.
---
## Mapping RQ → System Component
*Template traceability matrix*
| RQ / Hipotesis | Variabel | Komponen Sistem | Cara MengukurNya |
|----------------|---------|----------------|-----------------|
| H1: attention meningkatkan F1 NER | IndepVar: ada/tidaknya attention layer | Modul attention (swappable) | F1 per entity type |
| | DepVar: F1-score NER | Evaluation module | Seqeval library |
| H2: batch size pengaruhi training speed | IndepVar: batch size (16/32/64/128) | Training config (YAML) | Training time per epoch |
| | DepVar: convergence speed | Logger | Loss curve per epoch |
> **Traceability matrix** ini adalah bagian wajib dari bab Metodologi dalam laporan riset.
---
## Control & Isolation Variabel
**Prinsip eksperimen ilmiah:** Ubah **satu variabel pada satu waktu**, kontrol semua yang lain.
**Variabel yang harus dikontrol (contoh ML):**
| Variabel Kontrol | Cara Mengontrol |
|-----------------|----------------|
| Dataset split | Fixed seed, stratified split |
| Hyperparameter | Config file yang di-version control |
| Hardware | Sama untuk semua eksperimen |
| Random seed | Set di semua library (numpy, torch, sklearn) |
| Data preprocessing | Pipeline identik untuk semua kondisi |
| Jumlah epoch/run | Fixed, sama untuk semua kondisi |
> Mengubah lebih dari satu variabel dalam satu eksperimen → tidak bisa mengidentifikasi variabel mana yang menyebabkan perubahan output.
---
# Cognitive Traps
## Bab 6 — System Design
---
## Cognitive Traps — Bab 6
**"Semakin kompleks sistem, semakin besar kontribusi"**
Kompleksitas bukan kontribusi. Sistem sederhana yang terkontrol dengan baik lebih kuat secara ilmiah daripada sistem kompleks yang tidak bisa diisolasi variabelnya. Reviewer menilai kontrol eksperimen, bukan jumlah fitur.
**"Arsitektur bisa ditentukan setelah RQ"**
Dalam engineering, RQ ≠ yang menentukan arsitektur. Dalam research, RQ **adalah** yang menentukan arsitektur. Desain tanpa traceability ke RQ akan sulit dipertahankan saat sidang.
**"Sistem monolith lebih mudah, jadi pakai itu saja"**
Monolith tidak bisa diisolasi. Jika Anda tidak bisa mematikan/menghidupkan satu komponen tanpa mengubah yang lain, Anda tidak bisa menguji pengaruh variabel secara independen.
---
## Studi Kasus 1 — Monolith vs Modular (Basic)
**Konteks:** Model ML untuk text classification. RQ: "Apakah pre-trained embedding meningkatkan F1?"
**Desain monolith:**
```python
def train_and_evaluate(data):
# 500 baris kode: preprocessing + embedding + model + training + eval
# semua dalam satu fungsi
```
Masalah: tidak bisa mengisolasi efek embedding. Preprocessing berubah → semua berubah.
**Desain modular:**
```python
preprocessor = TextPreprocessor(config) # modul terpisah
embedder = EmbeddingLayer(type="pretrained" | "random") # swappable
model = ClassificationModel(embedder) # depend on embedder interface
evaluator = F1Evaluator() # independent
```
*Sekarang bisa swap `type="pretrained"` ↔ `type="random"` tanpa mengubah yang lain.*
---
## Studi Kasus 2 — Multiple Feature Change (Advanced)
**Konteks:** Peneliti melaporkan: "Model baru 15% lebih baik dari baseline."
**Masalah — terlalu banyak perubahan sekaligus:**
- Menambahkan attention mechanism ✚
- Mengubah optimizer dari Adam ke AdamW ✚
- Menambahkan dropout layer ✚
- Mengubah learning rate schedule ✚
Pertanyaan reviewer: *"Peningkatan 15% berasal dari yang mana?"*
**Pendekatan yang benar: Ablation Study**
| Eksperimen | Attention | AdamW | Dropout | F1-score |
|-----------|-----------|-------|---------|----------|
| Baseline | – | – | – | 74.2% |
| + Attention | ✓ | – | – | 81.5% (+7.3%) |
| + AdamW | ✓ | ✓ | – | 82.1% (+0.6%) |
| + Dropout | ✓ | ✓ | ✓ | 85.7% (+3.6%) |
*Sekarang jelas: attention yang berkontribusi terbesar.*
---
## Research vs Engineering — System Design
| Aspek | Engineering | Research |
|-------|------------|---------|
| Tujuan rancangan | Sistem berfungsi | Hipotesis dapat diuji |
| Kompleksitas | Bisa kompleks jika diperlukan | Sesederhana mungkin agar terkontrol |
| Dokumentasi | User manual | Experimental setup (reproducibility) |
| Perubahan komponen | Untuk perbaikan fitur | Untuk ablation study |
| Evaluasi | Acceptance testing | Uji statistik vs baseline |
| Portability | Nice to have | Wajib (reproducibility) |
---
## Ringkasan Pertemuan 6
| Konsep | Inti |
|--------|------|
| Paradigma shift | Sistem **bukan** tujuan → alat uji hipotesis |
| System as Experiment | RQ → Variable → Component → Setup → Output |
| 4 Prinsip | Traceability · Modularity · Controllability · Measurability |
| Mapping RQ | Setiap komponen harus bisa ditelusuri ke variabel |
| Control | Ubah 1 variabel, kontrol semua → ablation study |
| Dokumentasi | Traceability matrix wajib dalam metodologi |
---
## Final Statement & Output Praktis
"Dalam penelitian, sistem bukan dibangun untuk digunakan, tetapi untuk membuktikan sesuatu secara ilmiah."
### Output Praktis M6
Buat **2 dokumen**:
1. **Diagram Arsitektur Sistem** (Mermaid/draw.io) — annotated dengan label variabel:
- Tandai: `[IndepVar]`, `[DepVar]`, `[Control]` pada setiap komponen
2. **Traceability Matrix** (tabel: RQ/Hipotesis → Variabel → Komponen → Cara Ukur)
*Dokumen ini menjadi bagian "System Design" dalam bab Metodologi.*
---
## Referensi Utama — Bab 6
- 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.
- Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research methodology for information systems research. *Journal of Management Information Systems, 24*(3), 45–77.