riset-teknologi-informasi/slide/slide-06-system-design.md

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

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:

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.