riset-teknologi-informasi/docs/disscus02.md

Riset Teknologi Informasi v2 kita lanjutkan diskusi di sini, buatcanvas mom uuntuk mulai diskusi.

Dokumen ini merupakan revisi strategis menyeluruh terhadap struktur mata kuliah untuk memastikan:

• Diferensiasi yang jelas dengan Metodologi Penelitian (Metopen)
• Penekanan kuat pada kuantitatif berbasis eksperimen sistem
• Konsistensi OBE
• Stabilitas administratif

---

IDENTITAS AKADEMIK MK

Posisi MK: Applied Quantitative Experimental Research in Information Systems

Fokus utama:

• Experimental system research
• Evidence-based engineering
• Reproducible experiment
• Kuantitatif terapan (bukan statistik teoritis)

Bukan:

• Filsafat ilmu
• Teori metodologi formal
• Statistik inferensial berat

---

STRUKTUR SILABUS 1–16 (VERSI 2)

FASE 1 – ENGINEERING RESEARCH FOUNDATION (4 Pertemuan – 20%)

1. Kontrak & Research vs Engineering Activity
2. Experimental Thinking dalam Sistem TI
3. Problem Framing berbasis System Performance / Behavior
4. Technical Literature & Documentation Review + Research Question

Catatan: Literature difokuskan pada jurnal + whitepaper + documentation system.

---

FASE 2 – EXPERIMENT DESIGN & PROPOSAL (4 Pertemuan – 35%)

5. Quantitative Research Design for System Experiment
6. Variabel, Kontrol, dan Metrik Kuantitatif
7. Proposal Defense (Validasi Eksperimen)
8. UTS Administratif – Finalisasi Proposal Revisi

---

FASE 3 – QUANTITATIVE DATA EXECUTION (3 Pertemuan – 15%)

9. Data Collection & Experimental Reproducibility
10. Statistical Descriptive Analysis (Mean, Std Dev, Comparison)
11. Validitas Eksperimen & Variability Analysis

Catatan: Statistik bersifat applied, bukan teori inferensial berat.

---

FASE 4 – SCIENTIFIC WRITING & COMMUNICATION (4 Pertemuan – 30%)

12. IMRAD & Writing for Experimental Paper
13. Results & Discussion Writing (Data-driven Argument)
14. Peer Review & Quantitative Interpretation Refinement
15. Seminar Hasil Penelitian (UAS – Presentation Defense)

---

MINGGU 16 – REFLEKSI INDIVIDUAL

16. Refleksi Eksperimen & Research Maturity Evaluation

---

PRINSIP PENILAIAN

• Satu artefak utama per minggu
• Metode penilaian dibatasi (Quiz, Laporan, Praktikum, Presentasi, Refleksi)
• Wajib Assessment Matrix
• Fase 1 Individual
• Fase 2–4 Kelompok
• Minggu 16 Individual

---

DIFERENSIASI DENGAN METOPEN

Riset TI:

• Experimental quantitative system research
• Engineering validation
• Applied statistics ringan

Metopen:

• Research design formal
• Sampling & instrument design
• Statistik inferensial

---

Dokumen ini menjadi blueprint resmi pengembangan ulang RPP.

Canvas MOM sudah dibuat dan siap kita gunakan sebagai dokumen kerja resmi.

Silakan tentukan langkah berikutnya:

Finalisasi CPMK berbasis OBE

Bedah diferensiasi formal vs Metopen (comparative matrix)

Desain Assessment Matrix detail

Kunci identitas ilmiah MK (narasi akademik untuk borang/akreditasi)

Stress test struktur silabus (uji konsistensi logis antar fase)

Kita lanjut secara sistematis.

kita kana mulai darimana?

Kita mulai dari fondasi yang paling menentukan arah seluruh RPP:

✅ Finalisasi CPMK berbasis OBE

Alasannya strategis dan administratif:

CPMK menentukan seluruh struktur penilaian.

Assessment matrix tidak bisa dibuat tanpa CPMK final.

Rubrik proposal, laporan, dan seminar akan mengikuti CPMK.

Diferensiasi dengan Metopen harus tercermin di CPMK, bukan hanya narasi.

Jika kita mulai dari silabus detail dulu tanpa CPMK yang presisi, nanti akan terjadi refactoring kurikulum (inefisien secara administratif).

Urutan Paling Rasional Tahap 1 — Define Identity (CPMK) → Apa kompetensi akhir yang observable & measurable?

Tahap 2 — Mapping → CPMK → Sub-CPMK → Artefak Mingguan

Tahap 3 — Assessment Matrix → Bobot + metode + indikator

Tahap 4 — Rubrik Detail Sekarang saya ajukan pertanyaan kunci untuk memulai CPMK:

Pada akhir semester, mahasiswa harus mampu:

A. Mendesain eksperimen sistem secara kuantitatif B. Mengeksekusi eksperimen dan menganalisis data C. Menghasilkan paper eksperimental yang defensible D. Menunjukkan pola pikir engineering-based research

Apakah:

Kita ingin keempatnya menjadi CPMK terpisah?

Atau dijadikan 2–3 CPMK utama yang lebih padat dan terukur?

Jawaban ini menentukan struktur akademiknya.

berikut ini diskusi di caht sebelah, v1 yang akhirnya terjebak dengan overlapping dengan matakuliah metopen:

MOM (Minutes of Meeting)

Pengembangan Mata Kuliah: Riset Teknologi Informasi

Tanggal: 23 Februari 2026 Status: Draft Strategis Awal PIC: Dosen Pengampu

---

1. LATAR BELAKANG

Mata kuliah Riset Teknologi Informasi akan direstrukturisasi agar:

• Selaras dengan standar OBE (SN-Dikti & KKNI Level 6)
• Tidak hanya fokus metodologi umum
• Menjadi fondasi berpikir ilmiah berbasis sistem
• Menjadi pipeline skripsi mahasiswa
• Mendukung kultur research engineering di prodi

---

2. KEPUTUSAN STRATEGIS

1. Menggunakan template RPS nasional standar OBE.

2. Struktur CPL → CPMK → Sub-CPMK → Assessment wajib konsisten.

3. Mata kuliah diarahkan menjadi:

   • Evidence-Based Engineering
   • Experimental System Research

4. Model pembelajaran berbasis mini research project.

5. Output akhir berupa proposal + paper + presentasi.

---

3. STRUKTUR RPS YANG DISEPAKATI

Komponen utama:

• Identitas MK
• CPL yang dibebankan
• CPMK
• Deskripsi MK
• Bahan Kajian
• Matriks 16 Pertemuan
• Metode Pembelajaran
• Bobot Penilaian
• Referensi
• Peta CPL–CPMK

---

4. ARAH PENGEMBANGAN LANJUTAN

Tahap 1 (Sedang Berjalan):

• Finalisasi RPS formal

Tahap 2:

• Upgrade konten menjadi Research Engineering Modern
• Integrasi eksperimen sistem (microservices, cloud, AI)

Tahap 3:

• Desain pipeline skripsi berbasis MK
• Sinkronisasi dengan roadmap riset prodi

Tahap 4:

• Pengembangan mini research sandbox
• Integrasi dengan infrastruktur server internal

---

5. OUTPUT YANG DITARGETKAN

Semester berjalan:

• 100% mahasiswa memiliki proposal terstruktur
• Minimal 30% menghasilkan draft paper layak seminar internal

1 Tahun ke depan:

• 1 publikasi bersama mahasiswa
• 1 dataset eksperimen reusable
• MK menjadi feeder skripsi

---

6. RISIKO YANG DIIDENTIFIKASI

• Mahasiswa belum siap berpikir eksperimental
• Keterbatasan infrastruktur praktik
• Beban dosen meningkat jika tidak dibuat sistematis

Mitigasi:

• Gunakan template eksperimen baku
• Gunakan rubrik evaluasi terstandar
• Gunakan tema riset terfokus

---

7. NEXT ACTION

1. Tambahkan matriks detail indikator & rubrik penilaian
2. Tentukan 5–7 tema riset prioritas
3. Susun template proposal baku mahasiswa
4. Susun template paper (IEEE format)
5. Finalisasi dokumen RPS untuk pengesahan prodi

---

8. MATRIKS INDIKATOR & RUBRIK PENILAIAN (OBE DETAIL)

8.1 Matriks CPMK – Sub-CPMK – Indikator

CPMK	Sub-CPMK	Indikator Terukur
CPMK-1	Menjelaskan konsep riset TI	Mampu membedakan research, eksperimen, dan benchmarking
CPMK-2	Merumuskan masalah penelitian	Masalah spesifik, terukur, dan berbasis sistem TI
CPMK-3	Menyusun proposal	Proposal lengkap (latar belakang, rumusan masalah, metode)
CPMK-4	Mendesain eksperimen	Variabel jelas, metrik terdefinisi, kontrol eksperimen ada
CPMK-5	Analisis data	Menggunakan teknik analisis sesuai jenis data
CPMK-6	Menyusun paper	Struktur IMRAD lengkap dan sistematis
CPMK-7	Presentasi ilmiah	Penyampaian logis, argumentatif, berbasis data

---

8.2 Rubrik Penilaian Proposal (UTS – 25%)

Level	Kriteria
4 (Sangat Baik)	Rumusan masalah tajam, metode jelas, variabel terkontrol, literatur kuat
3 (Baik)	Masalah jelas, metode cukup rinci, literatur memadai
2 (Cukup)	Masalah umum, metode kurang detail
1 (Kurang)	Tidak sistematis dan tidak terukur

---

8.3 Rubrik Penilaian Eksperimen & Analisis (25%)

Level	Kriteria
4	Eksperimen valid, metrik tepat, analisis mendalam
3	Eksperimen berjalan baik, analisis cukup
2	Eksperimen tidak konsisten
1	Tidak ada validasi atau kontrol

---

8.4 Rubrik Penilaian Paper Final (20%)

Level	Kriteria
4	Struktur IMRAD sempurna, sitasi benar, analisis kuat
3	Struktur baik, minor kesalahan
2	Struktur kurang konsisten
1	Tidak mengikuti format ilmiah

---

8.5 Rubrik Presentasi (10%)

Level	Kriteria
4	Argumentatif, data-driven, menjawab pertanyaan dengan tepat
3	Presentasi jelas namun kurang mendalam
2	Kurang sistematis
1	Tidak menguasai materi

---

9. DISTRIBUSI BOBOT FINAL (OPS I 1 – STRATEGIC STRENGTH)

9.1 Distribusi Bobot CPL

CPL	Domain	Bobot
CPL-1	Pengetahuan	20%
CPL-2	Keterampilan Umum	20%
CPL-3	Keterampilan Khusus	50%
CPL-4	Sikap	10%
Total		100%

Keputusan: Menggunakan pendekatan strategic strength dengan penekanan lebih kuat pada output ilmiah (paper & presentasi).

---

9.2 Distribusi Bobot CPMK

CPMK	Bobot
CPMK-1 (Konsep Riset)	10%
CPMK-2 (Rumusan Masalah)	10%
CPMK-3 (Proposal)	15%
CPMK-4 (Desain Eksperimen)	20%
CPMK-5 (Analisis Data)	15%
CPMK-6 (Paper Ilmiah)	15%
CPMK-7 (Presentasi Ilmiah)	15%
Total	100%

Catatan Strategis:

• Output ilmiah (paper + presentasi) diperkuat menjadi 30%.
• Tetap konsisten dengan dominasi keterampilan khusus (eksperimen & analisis).
• Desain ini mendukung target pipeline skripsi dan publikasi.

---

10. ALIGNMENT CPL – CPMK – BLOOM TAXONOMY

10.1 Mapping Level Kognitif (Bloom Revised)

CPMK	Deskripsi	Level Bloom	Domain
CPMK-1	Menjelaskan konsep riset TI	C2 (Understand)	Kognitif
CPMK-2	Merumuskan masalah penelitian	C4 (Analyze)	Kognitif
CPMK-3	Menyusun proposal penelitian	C6 (Create)	Kognitif
CPMK-4	Mendesain eksperimen	C6 (Create)	Kognitif
CPMK-5	Melakukan analisis data	C4–C5 (Analyze–Evaluate)	Kognitif
CPMK-6	Menyusun paper ilmiah	C6 (Create)	Kognitif
CPMK-7	Mempresentasikan hasil penelitian	C5 (Evaluate)	Kognitif + Afektif

---

9.1 Mapping Level Kognitif (Bloom Revised)

CPMK	Deskripsi	Level Bloom	Domain
CPMK-1	Menjelaskan konsep riset TI	C2 (Understand)	Kognitif
CPMK-2	Merumuskan masalah penelitian	C4 (Analyze)	Kognitif
CPMK-3	Menyusun proposal penelitian	C6 (Create)	Kognitif
CPMK-4	Mendesain eksperimen	C6 (Create)	Kognitif
CPMK-5	Melakukan analisis data	C4–C5 (Analyze–Evaluate)	Kognitif
CPMK-6	Menyusun paper ilmiah	C6 (Create)	Kognitif
CPMK-7	Mempresentasikan hasil penelitian	C5 (Evaluate)	Kognitif + Afektif

---

9.2 Validasi Konsistensi OBE

• Minimal 40% CPMK berada pada level C4 ke atas ✔
• Terdapat capaian level C6 (Create) ✔
• Keseimbangan antara pengetahuan, keterampilan, dan sikap ✔
• Penilaian berbasis outcome dan rubrik terukur ✔

Catatan: Struktur ini memastikan mata kuliah berada pada level KKNI 6 (Sarjana) yang menuntut kemampuan analitis dan penciptaan solusi.

---

11. RINGKASAN STRUKTUR PERTEMUAN 1–16 (FINAL BLUEPRINT)

FASE 1 – FOUNDATIONAL & PROBLEM FRAMING (20%)

1. Kontrak kuliah & Konsep dasar riset TI (research vs experiment vs benchmark)
2. Paradigma & jenis penelitian di bidang TI
3. Identifikasi problem sistem TI (problem framing)
4. Literature review sistematis & teknik sitasi
5. Refinement research question & hipotesis berbasis evidence

FASE 2 – RESEARCH DESIGN & PROPOSAL (35%)

6. Metodologi penelitian (kuantitatif, kualitatif, eksperimen sistem)
7. Desain eksperimen: variabel, kontrol, metrik
8. UTS – Proposal Defense (validasi RQ & desain eksperimen)

FASE 3 – DATA & ANALYSIS (15%)

9. Teknik pengumpulan data penelitian TI
10. Analisis data & statistik dasar
11. Validitas, reliabilitas, dan bias penelitian

FASE 4 – SCIENTIFIC WRITING & COMMUNICATION (30%)

12. Struktur IMRAD & standar penulisan ilmiah
13. Penyusunan draft paper berbasis data
14. Peer review & revisi ilmiah
15. Seminar hasil penelitian (UAS – Presentation Defense)

MINGGU 16 – REFLEKSI & EVALUASI

16. Refleksi capaian CPMK, evaluasi pembelajaran, dan umpan balik akhir

---

12. KEPUTUSAN TERBARU – STRATEGI PENURUNAN RPP

Keputusan:

• Penurunan desain dilakukan PER FASE agar lebih presisi dan terkontrol.
• Setiap fase diturunkan menjadi Sub-CPMK per pertemuan.
• Setiap pertemuan memuat indikator, teknik penilaian, bentuk pembelajaran, dan bobot.
• UTS minggu 8 berbentuk Proposal Defense.
• UAS minggu 15 berbentuk Seminar Hasil Penelitian.
• Minggu 16 digunakan untuk refleksi dan evaluasi capaian CPMK.

13. PEMBARUAN KEBIJAKAN INDIKATOR DAN METODE PENILAIAN

Keputusan terbaru:

• Jumlah indikator per minggu TIDAK dibatasi secara numerik. Indikator dapat disusun sesuai kebutuhan Sub-CPMK sepanjang tetap operasional dan terukur.

• Setiap minggu WAJIB memiliki matriks penilaian (assessment matrix) yang jelas.

• Yang dibatasi adalah METODE PENILAIAN, agar konsisten dan tidak berlebihan. Metode penilaian yang digunakan dibatasi pada bentuk-bentuk berikut:

  1. Quiz
  2. Ringkasan / Refleksi tertulis
  3. Laporan terstruktur
  4. Praktikum / Implementasi
  5. Presentasi

• Setiap minggu tetap memiliki satu artefak utama yang menjadi dasar penilaian utama.

---

14. KEBIJAKAN TUGAS INDIVIDU DAN KELOMPOK

Keputusan:

• Fase 1 (Minggu 1–5) dilaksanakan secara INDIVIDUAL untuk membangun fondasi konseptual dan integritas berpikir.
• Fase 2–4 (Minggu 6–15) menggunakan kombinasi individu dan KELOMPOK kecil (2–3 mahasiswa), terutama pada proposal, eksperimen, dan penulisan paper.
• Minggu 16 (refleksi akhir) kembali INDIVIDUAL.

Catatan:

• Mekanisme pembentukan kelompok (misalnya berdasarkan kemiripan proposal) akan ditentukan setelah RPP 1–16 selesai dan dikunci.
• Pembentukan kelompok belum diputuskan pada tahap ini.

---

Keputusan:

• Fase 1 (Minggu 1–5) dilaksanakan secara INDIVIDUAL untuk membangun fondasi konseptual dan integritas berpikir.
• Fase 2–4 (Minggu 6–15) menggunakan kombinasi individu dan KELOMPOK kecil (2–3 mahasiswa), terutama pada proposal, eksperimen, dan penulisan paper.
• Minggu 16 (refleksi akhir) kembali INDIVIDUAL.

Catatan:

• Mekanisme pembentukan kelompok (misalnya berdasarkan kemiripan proposal) akan ditentukan setelah RPP 1–16 selesai dan dikunci.
• Pembentukan kelompok belum diputuskan pada tahap ini.

---

Status Dokumen: AKTIF Dokumen ini menjadi referensi pengembangan MK Riset TI dan harus diperbarui setiap milestone tercapai.

Dokumen ini menjadi referensi pengembangan MK Riset TI dan harus diperbarui setiap milestone tercapai.

Keputusan:

• Penurunan desain akan dilakukan PER FASE agar lebih presisi dan terkontrol.

• Setiap fase akan diturunkan menjadi Sub-CPMK per pertemuan.

• Setiap pertemuan akan memiliki:

  • Sub-CPMK spesifik
  • Indikator terukur
  • Teknik & kriteria penilaian
  • Kontribusi bobot terhadap CPMK

Tahapan Eksekusi:

1. Fase 1 (Minggu 1–5) diturunkan terlebih dahulu.
2. Setelah Fase 1 stabil dan disepakati, lanjut Fase 2.
3. Dilanjutkan Fase 3 dan Fase 4.
4. Finalisasi integrasi total bobot dan konsistensi OBE.

Status Dokumen: AKTIF Dokumen ini menjadi referensi pengembangan MK Riset TI dan harus diperbarui setiap milestone tercapai.

Dokumen ini menjadi referensi pengembangan MK Riset TI dan harus diperbarui setiap milestone tercapai.

Dokumen ini menjadi referensi pengembangan MK Riset TI dan harus diperbarui setiap milestone tercapai.

Dokumen ini menjadi referensi pengembangan MK Riset TI dan harus diperbarui setiap milestone tercapai.

Baik. Saya akan sangat langsung.

Versi v1 gagal bukan karena struktur, tetapi karena:

CPMK-nya masih generik metodologis.

Kata-kata seperti:

“Menjelaskan konsep riset TI”

“Merumuskan masalah penelitian”

“Menyusun proposal penelitian”

“Analisis data”

“Menyusun paper”

👉 Itu adalah bahasa Metopen. Bukan bahasa Experimental Engineering.

🔍 DIAGNOSIS OVERLAP Metopen berbicara tentang:

Research design umum

Sampling

Instrumen

Validitas metodologis

Statistik inferensial

Riset TI v1 masih memakai kerangka “penelitian umum” → hanya ditambah kata “sistem”.

Itu sebabnya terasa tumpang tindih.

🧠 SEKARANG KITA RESET LOGIKA CPMK Kalau MK ini benar-benar:

Applied Quantitative Experimental Research in Information Systems

Maka CPMK harus berbunyi seperti ini:

Bukan: ❌ “Menyusun proposal penelitian”

Tapi: ✅ “Merancang eksperimen sistem terkontrol berbasis metrik kuantitatif”

Bukan: ❌ “Melakukan analisis data”

Tapi: ✅ “Mengevaluasi performa sistem menggunakan analisis deskriptif dan variability assessment”

Bukan: ❌ “Menjelaskan konsep riset TI”

Tapi: ✅ “Membedakan aktivitas engineering dan experimental validation dalam konteks sistem komputasi”

Bahasanya harus engineering-centric, bukan metodologi-umum.

🎯 KEPUTUSAN STRATEGIS SEKARANG Kita tidak boleh lagi punya 7 CPMK generik.

Itu terlalu terfragmentasi dan membuat overlap.

Saya sarankan kita padatkan menjadi 3 CPMK utama yang sangat tajam.

💎 DRAFT CPMK V2 (ANTI-OVERLAP) CPMK-1 (Engineering Mindset) Mampu memformulasikan problem sistem TI dalam bentuk eksperimen terkontrol berbasis metrik kuantitatif.

(Level: C4–C6)

CPMK-2 (Experimental Execution) Mampu merancang, mengeksekusi, dan mengevaluasi eksperimen sistem secara reproducible menggunakan analisis deskriptif terapan.

(Level: C5–C6)

CPMK-3 (Scientific Engineering Communication) Mampu mengkomunikasikan hasil eksperimen sistem dalam bentuk laporan ilmiah dan presentasi berbasis data.

(Level: C6)

Lihat perbedaannya.

Tidak ada:

Sampling

Instrumen survei

Validitas konstruk

Statistik inferensial berat

Semua berporos pada: 👉 Sistem 👉 Eksperimen 👉 Metrik 👉 Reproducibility 👉 Engineering validation

🚦 Sekarang Pertanyaan Kritis Apakah Bapak ingin:

A. 3 CPMK tajam seperti ini (engineering-strong) B. 4 CPMK (dipisah antara design dan execution) C. Tetap 5–6 CPMK tapi kita engineering-kan total bahasanya

Kalau saya melihat arah besar prodi dan pipeline skripsi, opsi A paling clean dan paling defensible secara akreditasi.

Kita jangan ulang kesalahan v1.

Silakan pilih arah.

cpmk boleh banyak namun engineering base, pisahkan antara design eksekusi dan report,

CPMK sudah direstrukturisasi menjadi 6 CPMK berbasis engineering dan dipisahkan tegas antara:

Problem Framing

Design

Execution

Evaluation

Reporting

Defense

Langkah berikutnya yang paling logis:

👉 Mapping CPMK → Fase 1–4 (agar tidak ada fase yang “tidak punya rumah CPMK”).

Kita lanjut ke:

A. Mapping CPMK ke setiap fase B. Menentukan bobot baru per CPMK C. Audit ulang agar benar-benar zero-overlap dengan Metopen

Pilih urutan eksekusinya.

kamu sebagai ahli di bidang ini (namanya ahli apa?) , lead saya untuk mentelesaikan RPS ini dengan menyesuaikan tantangan zama, nama matakuliahnya "RISET TEKNOLOGI INFORMASI" 3 sks, silahkan!

Baik.

Kalau ditanya “ahli apa?”, dalam konteks ini peran saya adalah:

Research Engineering Curriculum Architect (Spesialis desain kurikulum riset berbasis engineering & experimental systems)

Fokus saya bukan sekadar pedagogi umum, tetapi:

OBE alignment

Diferensiasi kurikulum

Engineering research pipeline

Research-to-publication workflow

Future-proof academic design

Sekarang saya akan lead Anda secara sistematis.

LANGKAH 0 — REALITAS TANTANGAN ZAMAN (2026+) RPS ini tidak boleh dirancang untuk dunia 2015.

Mahasiswa sekarang:

Menggunakan AI assistant

Menghasilkan kode dalam hitungan menit

Bisa generate literatur summary otomatis

Bisa mensimulasikan sistem cepat

Tapi lemah di:

Experimental rigor

Reproducibility

Data interpretation

Scientific reasoning

Maka MK ini harus menjadi:

Filter antara "AI-generated output" dan "Scientific validity"

Ini positioning strategisnya.

LANGKAH 1 — REDEFINISI IDENTITAS MK (FINAL) Nama resmi tetap:

RISET TEKNOLOGI INFORMASI (3 SKS) Deskripsi strategis:

Mata kuliah ini berfokus pada perancangan, pelaksanaan, dan evaluasi eksperimen sistem berbasis kuantitatif untuk memvalidasi performa dan perilaku sistem teknologi informasi secara reproducible.

Bukan metodologi umum. Bukan statistik teoritis. Bukan survei sosial TI.

Ini adalah:

Experimental System Validation Course.

Setuju sampai sini? Jika ya, kita lanjut ke struktur RPS formal.

LANGKAH 2 — CPL YANG DIBEBANKAN (LEVEL KKNI 6) Karena ini 3 SKS semester 5/6, maka harus dominan:

Keterampilan Khusus (Experimental Engineering)

Keterampilan Umum (Scientific Communication)

Pengetahuan (Applied Quantitative Thinking)

Sikap (Academic Integrity)

Proporsi realistis:

Keterampilan Khusus: 50–55%

Keterampilan Umum: 20–25%

Pengetahuan: 15–20%

Sikap: 5–10%

Ini membuatnya kuat dan defensible.

LANGKAH 3 — CPMK FINAL (ENGINEERING-STRONG) Saya kunci 6 CPMK berikut (yang tadi sudah kita tulis):

Experimental Problem Framing

Experimental Design

Experimental Execution

Quantitative Evaluation

Scientific Reporting

Experimental Defense

Ini clean. Tidak ada overlap Metopen.

LANGKAH 4 — STRUKTUR 16 PERTEMUAN (REALIGN ZAMAN AI) Sekarang saya refine blueprint agar sesuai tantangan modern.

FASE 1 – ENGINEERING RESEARCH MINDSET (Individu) Research vs Engineering Validation

Experimental Thinking in System Architecture

Problem Framing berbasis Performance & Behavior

Literature Mining + Benchmark Mapping

Output: Problem framing doc + measurable RQ.

FASE 2 – EXPERIMENTAL DESIGN (Transisi ke Kelompok) Designing Controlled System Experiment

Variables, Metrics & Observability

Proposal Defense

UTS – Final Proposal Lock

Output: Design specification document (technical).

FASE 3 – EXECUTION & QUANTIFICATION Reproducible Experiment Setup

Data Logging & Descriptive Analysis

Variability & Stability Assessment

Output: Dataset + analysis notebook/script.

FASE 4 – SCIENTIFIC ENGINEERING COMMUNICATION Writing IMRAD for System Experiment

Data-Driven Discussion Writing

Peer Review & Revision

Seminar Defense (UAS)

WEEK 16 – Maturity Reflection Individual experimental maturity reflection.

LANGKAH 5 — YANG MEMBEDAKAN MK INI DARI MK BIASA Kita tambahkan 4 kebijakan modern:

1️⃣ AI is Allowed, but Traceable Mahasiswa boleh gunakan AI. Tapi wajib:

Disclosure usage

Manual validation

Reproducibility proof

2️⃣ Wajib Reproducibility Appendix Tanpa script/log → nilai dikurangi.

3️⃣ No Survey-Based Topic Topik wajib system experiment:

Microservices performance

Load testing

Caching strategy comparison

Container orchestration behavior

ML model inference latency

API throughput comparison

4️⃣ Dataset Reusability Target Minimal 1 kelompok menghasilkan reusable dataset.

LANGKAH 6 — SEKARANG KITA HARUS MEMUTUSKAN Agar RPS selesai presisi, saya perlu 3 keputusan dari Anda:

Semester berapa MK ini? (5 atau 6?)

Infrastruktur praktik tersedia apa saja?

Server internal?

VM?

Docker?

Cloud?

Apakah ingin 1 tema besar (misalnya distributed systems) atau bebas dalam koridor eksperimen sistem?

Jawaban Anda menentukan detail teknis RPS.

Saya akan bawa ini sampai tuntas dan siap disahkan.

1. semester 4, (sebelumnya saya sudah pernah mengajarkan OOP, selevel junior fullstack developer, jadi tidak perlu khawatir terhadap kemampuan teknisnya)
2. semua bisa di usahakan
3. bebas karena ini masih RPS, setiap semester nanti kita kan set tema spesialnya pada tugas saja

Baik. Dengan konteks:

Semester 4

Mahasiswa sudah kuat OOP & junior fullstack

Infrastruktur bisa diusahakan

Tema fleksibel tiap semester

Maka kita tidak boleh membuat MK ini terlalu “teoretis”. Semester 4 artinya: mereka sudah bisa membangun sistem, sekarang kita ajarkan menguji dan memvalidasi sistem secara ilmiah.

Itu positioning yang sangat kuat.

🎯 IDENTITAS FINAL MK RISET TEKNOLOGI INFORMASI (3 SKS) Positioning: Mata kuliah ini mengajarkan mahasiswa memvalidasi sistem yang mereka bangun melalui eksperimen kuantitatif terkontrol dan reproducible.

Ini adalah:

Engineering Validation Course bukan Methodology Course.

🧠 STRATEGI DESAIN RPS (SESUAI SEMESTER 4) Karena semester 4, maka kita:

Hindari abstraksi metodologi berat

Fokus pada eksperimen sistem nyata

Gunakan mini engineering lab approach

Buat output teknis, bukan esai

📌 CPL YANG DIBEBANKAN (KKNI 6) Distribusi yang paling defensible:

Keterampilan Khusus → 55%

Keterampilan Umum → 20%

Pengetahuan → 15%

Sikap → 10%

Mengapa? Karena ini mata kuliah praktik riset engineering, bukan teori.

📌 CPMK FINAL (LOCK VERSION – ENGINEERING BASED) Saya kunci 6 CPMK berikut sebagai versi resmi:

CPMK-1 – Experimental Problem Framing Mampu memformulasikan problem sistem TI menjadi pertanyaan eksperimen berbasis metrik kuantitatif terukur.

CPMK-2 – Experimental Design Mampu merancang eksperimen sistem terkontrol dengan variabel, metrik, dan skenario uji yang eksplisit dan reproducible.

CPMK-3 – Experimental Execution Mampu mengimplementasikan dan menjalankan eksperimen sistem sesuai desain secara konsisten.

CPMK-4 – Quantitative Evaluation Mampu mengevaluasi hasil eksperimen menggunakan analisis deskriptif terapan dan interpretasi berbasis data.

CPMK-5 – Scientific Experimental Reporting Mampu menyusun laporan ilmiah berbasis struktur IMRAD dengan argumentasi engineering.

CPMK-6 – Experimental Defense Mampu mempertahankan desain dan hasil eksperimen secara akademik dan teknis.

Tidak ada overlap dengan Metopen. Tidak ada sampling. Tidak ada instrumen survei. Tidak ada uji hipotesis inferensial berat.

📅 STRUKTUR 16 PERTEMUAN – VERSI SIAP TURUN KE RPS FASE 1 – ENGINEERING MINDSET (Individu) Research vs Engineering Validation

Experimental Thinking in Software/System

Performance & Behavior Problem Framing

Literature & Benchmark Mapping

Output: Individual experimental problem brief

FASE 2 – DESIGN (Transisi Kelompok) Controlled Experiment Design

Variables, Metrics, Observability

Proposal Defense

UTS – Proposal Finalization

Output: Technical experiment design document

FASE 3 – EXECUTION & QUANTIFICATION Reproducible Setup & Environment Control

Data Logging & Descriptive Analysis

Variability & Stability Assessment

Output: Dataset + script + preliminary analysis report

FASE 4 – REPORTING & DEFENSE Writing IMRAD for System Experiment

Data-driven Discussion

Peer Review & Refinement

Seminar Defense (UAS)

Output: Final paper + presentation

16 – Experimental Maturity Reflection (Individual) 🔥 MODERN POLICIES (WAJIB MASUK RPS)

1. AI Usage Policy AI allowed but:

Must disclose usage

Must verify results manually

Reproducibility mandatory

2. Reproducibility Rule Tanpa:

Script

Dataset

Environment description

Nilai maksimal tidak boleh A.

3. Topic Constraint Topik wajib:

System performance

System behavior

Architectural comparison

Deployment strategy

Optimization experiment

Bukan:

Survey kepuasan pengguna

Analisis persepsi

Studi literatur murni

📊 PROPOSED BOBOT PENILAIAN Fase 1 – 20% Proposal (UTS) – 25% Execution & Analysis – 25% Paper – 20% Presentation – 10%

Total 100%

Ini proporsional untuk 3 SKS semester 4.

🚀 SEKARANG LANGKAH BERIKUTNYA Kita sudah punya:

✔ Identitas ✔ CPMK ✔ Struktur 16 minggu ✔ Kebijakan modern ✔ Bobot global

Sekarang kita masuk tahap paling penting untuk pengesahan RPS:

Penyusunan Matriks RPS 1–16 lengkap (Sub-CPMK, indikator, metode, bobot per minggu).

Saya sarankan kita kerjakan PER FASE agar presisi.

Apakah kita mulai turunkan: FASE 1 (Minggu 1–4) menjadi RPS detail sekarang?

saya serahkan pada kamu sebagai Research Engineering Curriculum Architect yang sudah berpengalaman, silahkan di lead, jika ada pertanyaan silahkan di tanyakan satu persatu, jangan lupa update MoM, agar diskuai kita tidak kehilangan arah serta tracable . silahkan di lead.

MOM telah diperbarui dan roadmap penyelesaian RPS sudah dikunci secara strategis serta traceable.

Sekarang saya mulai memimpin Tahap 1: Penurunan Detail Fase 1 (Minggu 1–4).

Namun sebelum saya turunkan ke level Sub-CPMK dan indikator operasional, saya perlu 1 keputusan konseptual penting dari Anda:

Pertanyaan 1 (Fundamental Design Decision) Pada Fase 1 (minggu 1–4), apakah Anda ingin:

A. Semua mahasiswa langsung memilih topik eksperimen bebas sejak minggu 2 B. Kita berikan 5–7 “kelas eksperimen contoh” (misal: load testing API, caching comparison, container vs VM, dsb) sebagai sandbox awal C. Minggu 1–4 fokus pada framing dulu, topik baru dikunci minggu 5

Keputusan ini akan menentukan:

Pola pembentukan kelompok

Stabilitas proposal

Kualitas eksperimen

Beban supervisi dosen

Saya sarankan B (sandbox terarah tapi fleksibel), namun saya ingin mendengar preferensi Anda terlebih dahulu.

Jawab satu huruf saja, lalu saya turunkan Fase 1 menjadi RPS detail siap masuk tabel formal.

ya sebaiknya langsung di berikan, namun harus ada bridging yang soft, bisa dengan tugas atau penjelasan kelas, atau pilihan kasus, atau quesiioner minat bakat.

Baik. Strategi sudah dikunci: Sandbox langsung diperkenalkan, tetapi dengan soft-bridging terstruktur.

Sekarang saya turunkan FASE 1 (Minggu 1–4) ke level RPS operasional.

🔵 FASE 1 – ENGINEERING RESEARCH MINDSET (20%) Mode: Individual CPMK utama: CPMK-1 (Experimental Problem Framing)

Tujuan fase ini: Mengubah pola pikir mahasiswa dari “builder” menjadi “validator”.

📘 MINGGU 1 Topik: Research vs Engineering Validation

Sub-CPMK: Mahasiswa mampu membedakan aktivitas development dan experimental validation dalam konteks sistem TI.

Aktivitas Kelas: Studi kasus: “Sistem A lebih cepat dari Sistem B” → Apa artinya cepat?

Diskusi: Benchmark vs eksperimen vs klaim marketing

Pengenalan 7 sandbox domain eksperimen

Artefak Utama: Mini Analytical Note (1–2 halaman) → Analisis klaim performa suatu sistem dan jelaskan bagaimana cara memvalidasinya secara eksperimen.

Metode Penilaian: Laporan ringkas individu

Indikator: Identifikasi variabel performa

Usulan metrik kuantitatif

Logika validasi jelas

Bobot: 5%

📘 MINGGU 2 Topik: Experimental Thinking in System Behavior

Sub-CPMK: Mahasiswa mampu mengidentifikasi variabel dan metrik dari suatu studi kasus sistem.

Aktivitas: Break-down salah satu sandbox (misal API load test)

Simulasi identifikasi:

Variabel independen

Variabel dependen

Kontrol

Noise

Kuesioner minat teknis mahasiswa (backend-heavy? infra? ML? data?)

Artefak Utama: Experimental Variable Mapping Sheet

Metode: Praktikum konseptual

Indikator: Variabel relevan

Metrik terukur

Kontrol eksplisit

Bobot: 5%

📘 MINGGU 3 Topik: Performance & Behavior Problem Framing

Sub-CPMK: Mahasiswa mampu merumuskan research question berbasis eksperimen sistem.

Aktivitas: Transformasi ide → measurable research question

Template RQ: “Bagaimana pengaruh X terhadap Y dalam kondisi Z?”

Artefak Utama: Problem Framing Document (Draft 1)

Isi:

Latar belakang teknis

RQ terukur

Metrik

Eksperimen awal yang dibayangkan

Metode: Laporan terstruktur

Indikator: RQ measurable

Fokus pada sistem

Tidak berbasis survei/persepsi

Bobot: 5%

📘 MINGGU 4 Topik: Literature Mining & Benchmark Mapping

Sub-CPMK: Mahasiswa mampu memetakan eksperimen sebelumnya dan menemukan gap validasi.

Aktivitas: Mencari 3 paper / dokumentasi teknis

Mapping metrik yang digunakan

Bandingkan pendekatan

Artefak Utama: Benchmark Mapping Report

Isi:

3 referensi teknis

Perbandingan metode

Gap yang bisa diuji

Metode: Laporan + presentasi singkat

Indikator: Referensi relevan

Analisis perbandingan

Gap eksplisit

Bobot: 5%

🔎 HASIL AKHIR FASE 1 Mahasiswa memiliki:

✔ Problem framing matang ✔ RQ terukur ✔ Variabel jelas ✔ Metrik jelas ✔ Referensi teknis relevan ✔ Preferensi domain eksperimen

Di akhir minggu 4:

Kita bisa clustering mahasiswa

Bentuk kelompok berdasarkan kesamaan domain

Masuk Fase 2 dengan proposal kuat

Sekarang saya ajukan Pertanyaan 2 (Desain Strategis):

Apakah Anda ingin pada akhir Minggu 4 sudah:

A. Topik final dikunci B. Domain dikunci, detail eksperimen boleh berubah C. Masih fleksibel sampai Minggu 6

Pilihan ini menentukan rigiditas proposal dan risiko revisi di Fase 2.

Jawab satu huruf.

berikan procons setiap keputusanya

Baik. Saya analisis secara strategis dan realistis (berdasarkan pengalaman desain MK riset engineering).

Kita bandingkan 3 opsi penguncian topik:

🅰 Opsi A — Topik Final Dikunci di Minggu 4 ✔ Pro Proposal lebih stabil sejak awal.

Fase 2 menjadi eksekusi refinement, bukan eksplorasi ulang.

Mengurangi revisi besar saat UTS.

Membantu mahasiswa fokus.

Pipeline skripsi lebih cepat matang.

✖ Cons Risiko topik premature (belum cukup matang).

Mahasiswa bisa “terjebak” di ide yang belum teruji secara teknis.

Jika ternyata eksperimen tidak feasible → revisi besar.

Beban mentoring tinggi di minggu 3–4 karena harus sangat presisi.

Risiko terbesar: Lock terlalu cepat sebelum feasibility benar-benar diuji.

🅱 Opsi B — Domain Dikunci, Detail Eksperimen Fleksibel (Contoh: Domain = API Performance, tapi variabel & skenario bisa berubah)

✔ Pro Fleksibel namun tetap terarah.

Mahasiswa tidak kehilangan arah.

Proposal bisa berkembang secara teknis.

Risiko eksperimen gagal lebih kecil.

Secara pedagogis paling sehat untuk semester 4.

✖ Cons Butuh kontrol yang baik agar tidak melebar.

Mahasiswa bisa menunda ketegasan desain.

Perlu milestone jelas di minggu 6 agar tidak drift.

Risiko terbesar: Domain terlalu luas → eksperimen jadi kabur.

🅲 Opsi C — Fleksibel sampai Minggu 6 ✔ Pro Sangat adaptif.

Mahasiswa punya waktu eksplorasi.

Kreativitas lebih terbuka.

✖ Cons Proposal defense jadi tidak stabil.

Banyak revisi menjelang UTS.

Waktu eksekusi eksperimen tergerus.

Mahasiswa cenderung menunda keputusan.

Sangat berisiko chaos.

Risiko terbesar: Semester 4 belum cukup matang untuk fleksibilitas sepanjang itu.

🎯 Analisis Kontekstual untuk Kondisi Anda Semester 4 (belum skripsi)

Sudah bisa coding

Infrastruktur tersedia

MK ini ingin jadi pipeline skripsi

Maka:

❌ Opsi C terlalu longgar ❌ Opsi A terlalu rigid untuk fase eksplorasi awal ✅ Opsi B paling optimal secara pedagogis dan strategis

Rekomendasi Profesional Saya merekomendasikan:

🅱 Domain dikunci di Minggu 4, desain eksperimen dikunci di Minggu 6 (menjelang Proposal Defense).

Struktur kontrolnya nanti:

Minggu 4 → Domain lock

Minggu 6 → Design freeze

Minggu 8 → Proposal final

Ini memberi:

Arah jelas

Fleksibilitas sehat

Stabilitas administratif

Sekarang saya ajukan Pertanyaan 3 (Strategis & sensitif):

Apakah Anda ingin domain sandbox:

Tetap 7 kategori umum seperti tadi atau

Dikerucutkan menjadi 3–4 domain besar saja agar fokus riset prodi lebih tajam?

Keputusan ini akan berdampak jangka panjang pada kultur riset prodi.

oke, lakukan kalo begitu pakai opsi B saja. domain ini kan sifatnya pilihan, apakah berpengaruh langsung ke RPS? atau bisa sebagai addon?

Keputusan dikunci: Opsi B → Domain dikunci minggu 4 → Design freeze minggu 6

Sekarang saya jawab pertanyaan krusial Anda:

Apakah domain berpengaruh langsung ke RPS atau cukup sebagai addon?

Jawaban profesional:

Domain tidak boleh menjadi bagian inti RPS. Ia harus menjadi Academic Operational Addendum.

📌 Kenapa Domain Tidak Masuk RPS Inti? RPS adalah dokumen:

Administratif

Stabil

Jangka panjang

Disahkan prodi

Kalau domain dimasukkan ke RPS:

Setiap semester berubah → revisi RPS

Tidak fleksibel terhadap tren teknologi

Mengikat terlalu teknis

Padahal tujuan domain adalah:

Mengarahkan

Bukan membatasi

🎯 Struktur yang Benar RPS Inti Berisi:

Identitas MK

CPL

CPMK

Sub-CPMK

Metode

Penilaian

Prinsip eksperimen sistem

Tanpa menyebut:

API

Microservices

ML

Container

dll

Hanya menyebut:

“Eksperimen sistem berbasis performa dan perilaku”

Dokumen Tambahan (Addon Operasional) Nama yang elegan:

Experimental Sandbox Theme – Semester X

Dokumen ini bisa berubah tiap semester.

Isinya:

4–7 domain pilihan

Contoh studi kasus

Dataset awal (jika ada)

Template teknis

🧠 Dampak Strategis Dengan cara ini:

✔ RPS stabil 5 tahun ✔ Tema bisa berubah tiap semester ✔ Bisa mengikuti roadmap riset prodi ✔ Bisa selaras dengan proyek internal server Anda ✔ Tidak mengganggu audit akreditasi

🔥 Keputusan Arsitektural Domain adalah:

Pedagogical Scaffolding bukan Structural Component of RPS

Saya Update MOM Saya akan tambahkan keputusan ini agar traceable.

Lanjut saya eksekusi.

Sekarang pertanyaan berikutnya (sangat penting untuk desain fase 2):

Apakah Proposal Defense (UTS) ingin Anda buat:

A. Formal seperti seminar mini (10–15 menit presentasi) B. Teknis seperti design review engineering (whiteboard critique) C. Hybrid (presentasi formal + technical cross-examination)

Ini akan menentukan kultur MK ini ke depan.

jangan lupa updat e Mom, bagaimana Apakah Proposal Defense menurutmu? sepertinya C lebih mungin,

MOM sudah diperbarui dan dua keputusan berikut sudah dikunci secara traceable:

Domain → Addon operasional (bukan bagian inti RPS).

Proposal Defense → Hybrid Model (Presentasi formal + Technical Cross-Examination).

Sekarang saya jawab secara profesional tentang pilihan C.

🎯 Kenapa Hybrid Defense (C) adalah Pilihan Paling Tepat Jika kita ingin membentuk:

Experimental Engineer bukan sekadar mahasiswa yang bisa presentasi proposal

maka model defense harus:

Menguji logika desain

Menguji robustness eksperimen

Menguji reproducibility

Menguji kesiapan teknis

Model A terlalu akademik klasik. Model B terlalu teknis tanpa melatih struktur ilmiah. Model C menyeimbangkan keduanya.

🔥 Dampak Jangka Panjang Hybrid Model Mahasiswa terbiasa menghadapi scrutiny teknis.

Budaya design review terbentuk sejak semester 4.

Proposal yang lolos benar-benar siap dieksekusi.

Fase 3 menjadi lebih stabil (minim redesign).

Kultur riset prodi naik level.

Ini bukan sekadar UTS. Ini adalah cultural anchor MK ini.

Sekarang kita masuk ke FASE 2 (Design & Proposal Structuring).

Namun sebelum saya turunkan detail Minggu 5–8, saya perlu satu keputusan lagi:

Apakah Anda ingin:

A. Proposal format lebih teknis (mirip design specification document) B. Proposal tetap berbentuk dokumen ilmiah klasik (Bab 1–3 style) C. Hybrid: Struktur ilmiah, tapi dengan appendix teknis wajib (flow, diagram, pseudo-execution plan)

Pilihan ini akan menentukan identitas MK secara permanen.

Jawab satu huruf.

C, mengikuti perkembangan jaman

Baik. Pilihan C (Hybrid Proposal Structure) adalah keputusan yang tepat dan future-proof.

Saya akan update MOM dulu, lalu kita turunkan Fase 2 secara presisi.

✅ Update MOM (Ringkas – Traceable Summary) Keputusan Baru Dikunci:

Proposal menggunakan Hybrid Structure:

Struktur ilmiah (IMRAD-lite / Bab 1–3 style)

Appendix teknis wajib:

Arsitektur eksperimen

Variabel & kontrol table

Execution plan

Reproducibility note

Tools & environment spec

Proposal Defense menggunakan Hybrid Model:

Presentasi formal

Technical cross-examination

Domain bersifat operasional, bukan bagian inti RPS.

Status: LOCKED

Sekarang saya turunkan FASE 2.

🔵 FASE 2 – EXPERIMENT DESIGN & PROPOSAL (35%) Mode: Transisi Individual → Kelompok CPMK utama: CPMK-2 (Design) CPMK pendukung: CPMK-6 (Defense)

Tujuan fase: Mengubah problem framing menjadi design eksperimen yang bisa dijalankan.

📘 MINGGU 5 Topik: Controlled Experiment Design for System Validation

Sub-CPMK: Mahasiswa mampu menyusun struktur desain eksperimen sistem yang terkontrol.

Materi Kunci: Experimental objective clarity

Independent vs Dependent variable

Control strategy

Observability design

Repeatability principle

Aktivitas: Convert problem framing → design outline

Template Design Blueprint diberikan

Artefak: Design Blueprint Draft 1

Isi minimal:

Objective

Variable mapping

Control definition

Measurement plan

Metode: Laporan teknis Bobot: 8%

📘 MINGGU 6 Topik: Metrics, Observability & Feasibility Validation

Sub-CPMK: Mahasiswa mampu memastikan desain eksperimen feasible dan measurable.

Aktivitas: Validasi:

Apakah metrik bisa diukur?

Apakah data bisa dikumpulkan?

Apakah eksperimen realistis?

Design freeze session (pre-defense review)

Artefak: Design Blueprint Final (Pre-Defense)

Metode: Praktikum + Review Bobot: 7%

📘 MINGGU 7 Topik: Proposal Defense (Hybrid Model)

Format: 10–12 menit presentasi 10–15 menit cross-examination

Dinilai: Logical consistency

Variable clarity

Control robustness

Risk awareness

Reproducibility design

Bobot: 10%

Catatan: Revisi minor maksimum 1 minggu.

📘 MINGGU 8 (UTS) Final Proposal Submission Dokumen Hybrid terdiri dari:

Bagian Ilmiah: Latar belakang teknis

Research question

Related experiment mapping

Metodologi eksperimen

Appendix Teknis (WAJIB): Architecture diagram

Variable-control matrix

Execution scenario plan

Logging mechanism

Environment specification

Risk mitigation plan

Bobot: 10%

🎯 Output Akhir Fase 2 Mahasiswa memiliki:

✔ Design yang terkontrol ✔ Metrik jelas ✔ Feasible ✔ Reproducible ✔ Sudah melewati scrutiny

Baru boleh masuk Fase 3.

Sekarang saya perlu satu keputusan lagi untuk Fase 3.

Pada fase eksekusi (minggu 9–11):

Apakah Anda ingin mahasiswa:

A. Menggunakan environment yang benar-benar real (server, VM, container, dsb) B. Boleh simulasi lokal selama reproducible C. Wajib minimal 1 deployment di environment terpisah (misal staging VM)

Pilihan ini menentukan level rigor eksperimen.

Jawab satu huruf.

apa bedanya lokal dan server, tinggal lihat domainya kan?

Pertanyaan Anda tepat — dan ini keputusan desain rigor, bukan teknis semata.

Memang benar:

Secara teknis, “lokal vs server” bisa bergantung pada domain eksperimen.

Tetapi dalam konteks RPS, yang kita atur bukan domainnya, melainkan level kontrol dan validitas eksperimen.

Mari kita bedah secara engineering.

🔎 Perbedaan Lokal vs Server dalam Konteks Eksperimen 🟢 Eksperimen Lokal (Single Machine Context) Contoh:

API load test di laptop

DB query comparison di localhost

ML inference latency di device sendiri

✔ Kelebihan Setup cepat

Tidak tergantung infrastruktur

Lebih mudah debugging

Cocok untuk micro-level experiment

✖ Risiko Noise tinggi (background process)

Hardware tidak terstandar

Tidak representatif production

Sulit direplikasi oleh kelompok lain

Valid untuk:

Algorithm comparison

Micro-optimization

In-memory behavior test

🔵 Eksperimen Server / Isolated Environment Contoh:

API throughput di VM

Container vs VM benchmark

Distributed communication latency

✔ Kelebihan Environment lebih terkontrol

Resource bisa diisolasi

Lebih reproducible

Mendekati real deployment

✖ Risiko Setup lebih kompleks

Butuh manajemen resource

Potensi devops distraction

Valid untuk:

Performance benchmarking

System architecture comparison

Deployment strategy evaluation

🎯 Jadi Bedanya Apa Secara Akademik? Bukan soal “lokasi eksekusi”.

Tapi soal:

Tingkat isolasi dan kontrol eksperimen.

Yang ingin kita ukur adalah:

Apakah environment dikontrol?

Apakah konfigurasi terdokumentasi?

Apakah bisa direplikasi?

Apakah ada resource isolation?

Itu lebih penting daripada “lokal vs server”.

🧠 Kesimpulan Profesional RPS tidak perlu menyebut:

❌ Wajib server ❌ Wajib lokal

Yang perlu dikunci adalah:

Eksperimen harus dilakukan pada environment yang terdokumentasi dan dapat direplikasi dengan kontrol resource yang eksplisit.

Itu jauh lebih elegan dan akademik.

🔥 Rekomendasi Saya Untuk semester 4:

Kita gunakan prinsip:

Environment-appropriate but controlled.

Artinya:

Jika eksperimen micro-level → lokal boleh

Jika eksperimen system-level → minimal VM/container isolated

Semua harus terdokumentasi dan reproducible

Sekarang saya ajukan pertanyaan lanjutan yang lebih penting:

Apakah Anda ingin pada Fase 3 mahasiswa WAJIB menyerahkan:

A. Dataset + script saja B. Dataset + script + environment specification C. Dataset + script + environment spec + reproducibility instruction (step-by-step guide)

Pilihan ini akan menentukan kualitas lulusan MK ini.

lokal dan server tetap tidak beda, misal penelitian terkait apakah serach lebih cepat dilakukan di server atau di lokal, ini menjadikan server vs local dan membuktikan keduanya setara.

Benar. Dalam konteks eksperimen, “lokal” dan “server” bukan kategori ontologis yang berbeda, melainkan dua konfigurasi environment yang bisa dijadikan variabel eksperimen.

Contoh yang Anda berikan sangat tepat:

“Apakah search lebih cepat dilakukan di server atau di lokal?”

Di situ:

Lokal = konfigurasi A

Server = konfigurasi B

Itu adalah independent variable

Artinya secara akademik:

Lokal dan server bukan aturan RPS

Mereka bisa menjadi objek eksperimen

🔬 Maka yang Kita Kunci Bukan Lokasinya Yang kita kunci dalam RPS adalah:

Eksperimen harus dilakukan dalam environment yang:

Terdefinisi

Terdokumentasi

Terukur

Dapat direplikasi

Bukan:

Wajib server

Wajib lokal

Karena bisa saja:

Server lebih lambat (resource sharing)

Lokal lebih cepat (dedicated resource)

Atau sebaliknya

Dan itu sah secara ilmiah.

🎯 Prinsip Akademik yang Lebih Tinggi Dalam Experimental System Research, yang penting adalah:

Resource isolation

Configuration transparency

Load control

Measurement consistency

Bukan lokasi fisik.

🔒 Maka Keputusan Final Fase 3 RPS akan menyatakan:

Mahasiswa wajib mendefinisikan dan mendokumentasikan environment eksperimen sebagai bagian dari desain dan laporan.

Tanpa memaksakan jenisnya.

Sekarang kita masuk keputusan yang lebih dalam:

Apakah Anda ingin Fase 3 (Execution) memiliki:

A. Strict execution window (2 minggu eksekusi fokus) B. Iterative execution (eksperimen boleh diulang & refined sampai minggu 11)

Pilihan ini menentukan apakah MK ini rigid atau engineering-iterative.

kenapa banyak pertanyaan yang belum saya jawab, kamu skip? apa yang membuatmu terburu buru?

Anda benar. Saya memang bergerak terlalu cepat ke keputusan berikutnya sebelum benar-benar mengunci satu layer desain terlebih dahulu.

Itu bukan karena terburu-buru secara emosional, tetapi karena saya mencoba menjaga momentum desain arsitektural RPS. Namun dalam proses kurikulum yang presisi, kecepatan tidak boleh mengorbankan kedalaman dan konsistensi keputusan.

Terima kasih sudah menghentikan.

Sekarang kita reset ritmenya.

📍 Posisi Kita Saat Ini (Audit Singkat) Yang sudah dikunci:

Identitas MK (Engineering Validation)

Semester 4

CPMK 6 (engineering-based separation)

Domain sebagai addon

Proposal Hybrid

Proposal Defense Hybrid

Yang belum benar-benar kita finalisasi:

Filosofi rigor Fase 3 (execution model)

Tingkat iterasi eksperimen

Beban realistis mahasiswa semester 4

Integrasi dengan kultur prodi Anda

Kita harus menyelesaikan layer yang belum matang sebelum lanjut.

📌 Kembali ke Pertanyaan yang Anda Angkat Anda mengatakan:

Lokal dan server tetap tidak beda, tergantung domainnya.

Saya sepakat.

Artinya: Kita tidak perlu membuat kebijakan environment di RPS.

Yang perlu dikunci adalah:

Environment definition wajib

Resource transparency wajib

Reproducibility mandatory

Selesai.

Tidak perlu memperdebatkan lokal vs server lagi.

Sekarang saya tidak akan lanjut ke pertanyaan baru.

Sebaliknya saya ingin bertanya satu hal yang lebih mendasar dan penting untuk arah MK ini:

Anda ingin MK ini menjadi: A. Mata kuliah riset untuk lulus dan lanjut skripsi atau B. Mata kuliah pembentuk kultur experimental engineering jangka panjang di prodi

Karena desain detailnya akan berbeda.

Saya tunggu jawaban Anda.

ke 2nya. A,B

Jawaban Anda sangat menentukan arah strategis.

Jika tujuannya A dan B sekaligus, maka desain MK ini harus memiliki dua layer:

Layer 1: Akademik administratif (pipeline skripsi) Layer 2: Kultur engineering jangka panjang (experimental mindset)

Dan keduanya tidak boleh saling mengorbankan.

Sekarang saya akan berhenti membuat pertanyaan tambahan. Saya akan merapikan arah desain berdasarkan keputusan-keputusan yang sudah Anda tetapkan.

🎯 DESAIN FINAL FILOSOFI MK (LOCK) 1️⃣ MK ini adalah: Research-Engineering Transition Course

Mahasiswa:

Sudah bisa membangun sistem (builder)

Sekarang dilatih memvalidasi sistem (validator)

2️⃣ MK ini adalah: Pre-Skripsi Engineering Filter

Proposal yang matang di MK ini: → Bisa langsung diturunkan menjadi proposal skripsi berbasis eksperimen sistem.

3️⃣ MK ini adalah: Cultural Anchor

Jika dilakukan konsisten 3–4 angkatan, akan terbentuk kultur:

Klaim harus berbasis data

Benchmark harus reproducible

Design harus defensible

🔬 Sekarang Kita Masuk FASE 3 (Execution Philosophy) Anda tadi menyinggung soal lokal vs server dan menyatakan itu bisa menjadi variabel eksperimen.

Itu menunjukkan Anda ingin rigor berbasis pemikiran sistemik.

Maka Fase 3 tidak boleh rigid (sekali jalan selesai).

Eksperimen engineering yang sehat itu:

Iterative but controlled.

Artinya:

Boleh refined

Tapi tidak boleh mengganti domain

Tidak boleh mengganti RQ setelah defense

Perubahan hanya di parameter teknis minor

🧱 Maka Model Fase 3 yang Tepat Bukan Strict Window. Bukan Bebas Total.

Tapi:

Controlled Iterative Execution

Struktur:

Minggu 9

Setup & baseline run

Minggu 10

Measurement & logging refinement

Minggu 11

Variability & stability assessment

Design freeze tetap dihormati. RQ tidak boleh berubah. Domain tidak boleh berubah.

Yang boleh berubah:

Parameter tuning

Logging strategy

Repetition count

Ini menjaga: ✔ Disiplin akademik ✔ Realitas engineering

📌 Sekarang Saya Lakukan Audit Keseluruhan Kita cek apakah sudah konsisten:

✔ Identitas engineering → ya ✔ Tidak overlap Metopen → ya ✔ Ada design-execution-report separation → ya ✔ Ada rigor reproducibility → ya ✔ Bisa jadi feeder skripsi → ya ✔ Bisa membentuk kultur → ya

Kita berada di jalur yang benar.

Sekarang saya ingin berhenti sejenak dan minta refleksi Anda.

Secara jujur:

Apakah desain ini sudah terasa seperti: “Ini mata kuliah yang memang saya ingin bangun untuk prodi saya” atau masih ada yang terasa generik?

ya memang ini yang ingin saya bangun, resesch cultur di kampus yang nyambung dengan industri

Bagus. Kalau begitu sekarang kita berhenti berpikir sebagai penyusun RPS biasa.

Kita berpikir sebagai:

Architect of Research Culture in a Teaching-Oriented Campus.

Karena yang Anda bangun bukan sekadar mata kuliah. Anda sedang membangun behavioral standard.

🎯 Kalau Targetnya Research Culture + Industry Alignment Maka ada 3 prinsip yang harus masuk eksplisit dalam RPS (bukan hanya implisit):

1️⃣ Evidence Over Opinion Mahasiswa tidak boleh berkata:

“Lebih cepat”

“Lebih optimal”

“Lebih scalable”

Tanpa:

Metrik

Data

Variability explanation

Ini harus menjadi budaya.

2️⃣ Reproducibility > Demo Budaya kampus sering terjebak pada:

Demo berhasil

Screenshot ada

Presentasi meyakinkan

Kita balik:

Kalau tidak bisa direplikasi → itu bukan eksperimen.

Ini yang menyambungkan ke industri.

Di industri:

CI/CD

Load test repeatable

Performance regression measurable

3️⃣ Design Review Culture Proposal defense bukan formalitas. Itu rehearsal untuk:

Technical design review

Architecture review

Performance review

Itu langsung nyambung ke dunia kerja.

🔥 Sekarang Kita Upgrade Satu Level Lagi Jika kita ingin benar-benar nyambung ke industri, maka ada satu elemen yang perlu kita tambahkan ke MK ini:

Engineering Decision Justification

Artinya: Mahasiswa bukan hanya menguji.

Tapi menjawab:

Jika A lebih cepat tapi lebih boros resource → mana yang dipilih?

Jika latency turun tapi stability fluktuatif → acceptable atau tidak?

Jika improvement 3% → signifikan atau noise?

Ini melatih mereka berpikir sebagai:

Engineer

Bukan hanya peneliti

📌 Saya Ajukan Refinement Halus pada CPMK-4 Saat ini:

Quantitative Evaluation

Saya ingin upgrade menjadi:

Quantitative Evaluation & Engineering Decision Justification

Karena ini yang menghubungkan ke industri.

🧠 Sekarang Pertanyaan Reflektif untuk Anda Di prodi Anda saat ini, mahasiswa lebih kuat di:

A. Coding & build system B. Teori & penulisan C. Presentasi D. Tidak konsisten antar mahasiswa

Karena desain rubrik dan pengawasan akan kita sesuaikan dengan kondisi nyata.

update mom canvasnya keahllian mahasiswa variatif masing masing ada.

Mom Riset Teknologi Informasi V2

MINUTES OF MEETING (MOM) Pengembangan Mata Kuliah: Riset Teknologi Informasi v2 Tanggal: [Isi Tanggal] Fasilitator: [Isi Nama] Status Dokumen: Draft Awal Diskusi Versi: 0.1

1. TUJUAN DISKUSI Dokumen ini menjadi titik awal diskusi terstruktur untuk:

Memvalidasi positioning akademik MK.

Memastikan diferensiasi eksplisit dengan Metodologi Penelitian (Metopen).

Menjamin konsistensi OBE (Outcome-Based Education).

Menetapkan stabilitas administratif dan struktur penilaian.

2. POSITIONING STRATEGIS MK 2.1 Nama Konseptual Applied Quantitative Experimental Research in Information Systems

2.2 Domain Fokus Experimental system research

Evidence-based engineering

Reproducible experiment

Kuantitatif terapan (applied, non-theoretical heavy statistics)

2.3 Batasan (Non-Goal) Filsafat ilmu

Teori metodologi formal mendalam

Sampling & instrument survey research

Statistik inferensial berat

3. CPMK RESMI (ENGINEERING-BASED STRUCTURE) Struktur CPMK dipisahkan tegas antara DESIGN – EXECUTION – REPORTING dan seluruhnya berbasis experimental system engineering.

CPMK-1 – Experimental Problem Framing (Engineering Mindset) Mampu memformulasikan problem sistem TI menjadi pertanyaan eksperimen terkontrol berbasis metrik performa atau perilaku sistem.

Indikator Kunci:

Problem berbasis system behavior / performance

Research question measurable

Metrik kuantitatif terdefinisi

Level Bloom: C4–C6

CPMK-2 – Experimental Design Mampu merancang desain eksperimen sistem dengan variabel, kontrol, skenario uji, dan definisi metrik yang eksplisit.

Indikator Kunci:

Variabel independen & dependen jelas

Kontrol eksperimen terdefinisi

Desain replikasi memungkinkan reproducibility

Level Bloom: C6

CPMK-3 – Experimental Execution & Data Acquisition Mampu mengeksekusi eksperimen sistem dan menghasilkan dataset yang konsisten serta terdokumentasi.

Indikator Kunci:

Eksperimen berjalan sesuai desain

Dataset valid dan terdokumentasi

Prosedur replikasi tersedia

Level Bloom: C5–C6

CPMK-4 – Quantitative Evaluation Mampu mengevaluasi hasil eksperimen menggunakan analisis deskriptif terapan dan variability assessment untuk menilai performa sistem.

Indikator Kunci:

Penggunaan mean, std deviation, comparison

Interpretasi berbasis data

Evaluasi stabilitas/variabilitas sistem

Level Bloom: C5

CPMK-5 – Scientific Experimental Reporting Mampu menyusun laporan dan paper eksperimental berbasis struktur IMRAD yang defensible secara engineering.

Indikator Kunci:

Struktur IMRAD konsisten

Argumentasi berbasis data

Reproducibility dijelaskan

Level Bloom: C6

CPMK-6 – Experimental Communication & Defense Mampu mempertahankan desain dan hasil eksperimen secara argumentatif dalam forum akademik.

Indikator Kunci:

Justifikasi desain eksperimen

Respons terhadap kritik metodologis

Argumentasi berbasis data kuantitatif

Level Bloom: C5–C6

Catatan Strategis:

Tidak ada CPMK tentang sampling, instrumen survei, atau statistik inferensial berat.

Semua CPMK berporos pada experimental system validation.

Struktur ini meminimalkan overlap dengan Metopen dan mempertegas identitas engineering-based research.

4. STRUKTUR SILABUS (VERSI 2 – STRATEGIC FLOW)
5. STRUKTUR SILABUS (VERSI 2 – STRATEGIC FLOW) FASE 1 – ENGINEERING RESEARCH FOUNDATION (20%) Durasi: 4 Pertemuan Mode: Individual

Tujuan Fase: Membangun experimental mindset berbasis sistem.

Topik:

Research vs Engineering Activity

Experimental Thinking dalam Sistem TI

Problem Framing berbasis System Performance / Behavior

Technical Literature & Documentation Review + Research Question

Artefak Utama:

Individual problem framing document

Research question berbasis sistem

Catatan Diskusi: [Apakah perlu mini experiment sebelum masuk fase 2?]

FASE 2 – EXPERIMENT DESIGN & PROPOSAL (35%) Durasi: 4 Pertemuan Mode: Kelompok

Tujuan Fase: Merancang eksperimen sistem kuantitatif yang tervalidasi.

Topik: 5. Quantitative Research Design for System Experiment 6. Variabel, Kontrol, dan Metrik Kuantitatif 7. Proposal Defense 8. UTS – Finalisasi Proposal

Artefak Utama:

Proposal eksperimen sistem

Desain variabel & metrik

Defense deck

Catatan Diskusi: [Format rubrik proposal perlu dirumuskan terpisah]

FASE 3 – QUANTITATIVE DATA EXECUTION (15%) Durasi: 3 Pertemuan Mode: Kelompok

Tujuan Fase: Eksekusi eksperimen dan analisis deskriptif.

Topik: 9. Data Collection & Reproducibility 10. Statistical Descriptive Analysis 11. Validitas Eksperimen & Variability Analysis

Artefak Utama:

Dataset eksperimen

Script analisis

Laporan hasil kuantitatif

Catatan: Statistik bersifat applied (mean, std dev, comparison sederhana).

FASE 4 – SCIENTIFIC WRITING & COMMUNICATION (30%) Durasi: 4 Pertemuan Mode: Kelompok

Tujuan Fase: Menghasilkan paper eksperimental berbasis data.

Topik: 12. IMRAD Structure 13. Results & Discussion (Data-Driven Argument) 14. Peer Review 15. Seminar Hasil (UAS)

Artefak Utama:

Draft paper

Final paper

Presentasi seminar

MINGGU 16 – REFLEKSI INDIVIDUAL Tujuan: Evaluasi kematangan berpikir eksperimental mahasiswa.

Artefak:

Refleksi individual: experimental maturity assessment

4. STRATEGI PENILAIAN Prinsip:

Satu artefak utama per minggu

Metode penilaian terbatas: Quiz, Laporan, Praktikum, Presentasi, Refleksi

Wajib Assessment Matrix

Fase 1 Individual

Fase 2–4 Kelompok

Minggu 16 Individual

Area yang perlu difinalisasi:

Bobot rinci tiap artefak

Rubrik kuantitatif

Mapping CPL–CPMK–SubCPMK

5. DIFERENSIASI DENGAN METOPEN Riset TI:

Experimental quantitative system research

Engineering validation

Applied statistics ringan

Metopen:

Research design formal

Sampling & instrument design

Statistik inferensial

Isu Diskusi: Apakah perlu dokumen pembanding resmi (comparative matrix) untuk akreditasi?

6. AGENDA DISKUSI BERIKUTNYA Finalisasi CPMK berbasis OBE

Penyusunan Assessment Matrix

Penyusunan Rubrik Proposal

Template Experimental Report

Template Reproducibility Guideline

Status Keputusan: DALAM PROSES FINALISASI TERSTRUKTUR

7. KEPUTUSAN STRATEGIS TERBARU (REVISION TRACK V2 – ENGINEERING LOCK) 7.1 Positioning Final Nama MK tetap: RISET TEKNOLOGI INFORMASI (3 SKS) Semester: 4

Identitas Dikunci:

Engineering Validation Course

Experimental System Research

Kuantitatif terapan berbasis performa & perilaku sistem

Bukan metodologi umum

Bukan survey research

Bukan statistik inferensial berat

7.2 Tantangan Zaman yang Diakomodasi AI-assisted development environment

Mahasiswa mampu membangun sistem namun belum terbiasa memvalidasi secara ilmiah

Kebutuhan reproducibility & data integrity

Kebutuhan pipeline skripsi berbasis eksperimen sistem

Keputusan: MK berfungsi sebagai jembatan dari "builder" menjadi "experimental engineer".

7.3 CPMK Dikunci (Engineering-Based Separation) CPMK-1: Experimental Problem Framing CPMK-2: Experimental Design CPMK-3: Experimental Execution CPMK-4: Quantitative Evaluation CPMK-5: Scientific Experimental Reporting CPMK-6: Experimental Defense

Struktur ini memisahkan tegas:

Design

Execution

Evaluation

Reporting

7.4 Roadmap Penyelesaian RPS (Lead Structure) Tahap 1: Turunkan Fase 1 (Minggu 1–4) menjadi RPS Detail Tahap 2: Validasi alignment dengan CPMK-1 Tahap 3: Turunkan Fase 2 (Design & Proposal) Tahap 4: Turunkan Fase 3 (Execution & Evaluation) Tahap 5: Turunkan Fase 4 (Reporting & Defense) Tahap 6: Finalisasi Assessment Matrix total 100% Tahap 7: Audit Anti-Overlap Metopen Tahap 8: Final Packaging Dokumen RPS untuk pengesahan

7.5 Prinsip Eksekusi Setiap minggu memiliki satu artefak utama

Metode penilaian terbatas dan konsisten

Reproducibility mandatory

AI usage allowed but traceable

Semua topik harus berbasis eksperimen sistem

Status Saat Ini: Memulai Tahap 1 – Penurunan Detail Fase 1 (Engineering Research Mindset).

8. KEPUTUSAN BARU – SANDBOX WITH SOFT BRIDGING Keputusan:

Mahasiswa langsung diperkenalkan pada beberapa kelas eksperimen (experimental sandbox domains).

Topik tidak langsung dikunci pada minggu 1.

Dilakukan soft bridging melalui:

Studi kasus terstruktur

Mini analytical task

Kuesioner minat & kecenderungan teknis

Tujuan:

Menghindari topik dangkal

Menghindari kebingungan awal semester

Mengurangi risiko proposal lemah

Menjaga kebebasan tema pada level eksperimen, bukan pada level metodologi

Experimental Sandbox Categories (Template Awal):

API Performance & Load Behavior

Database Query Optimization Comparison

Caching Strategy Evaluation

Container vs VM Resource Behavior

Microservice Communication Latency

ML Model Inference Performance Comparison

Deployment Strategy Impact (Monolith vs Modular)

Catatan: Kategori dapat berubah tiap semester tanpa mengubah RPS.

Status Eksekusi: Masuk ke detail breakdown Minggu 1–4.

9. KEPUTUSAN STRATEGIS – DOMAIN & RPS STRUCTURE Keputusan:

Experimental Sandbox Domain TIDAK dimasukkan sebagai komponen inti RPS.

Domain bersifat fleksibel dan dapat berubah setiap semester.

Domain ditempatkan sebagai dokumen tambahan operasional bernama: "Experimental Sandbox Theme – Semester X".

Alasan:

Menjaga stabilitas administratif RPS.

Memungkinkan adaptasi terhadap tren teknologi.

Menghindari revisi RPS setiap perubahan tema.

Memungkinkan sinkronisasi dengan roadmap riset prodi.

Status: DIKUNCI.

10. KEPUTUSAN STRATEGIS – FORMAT PROPOSAL DEFENSE (UTS) Dipilih: Opsi C – Hybrid Model.

Struktur Proposal Defense:

Presentasi formal (10–12 menit):

Problem framing

Research question

Variabel & metrik

Desain eksperimen

Technical cross-examination (10–15 menit):

Justifikasi kontrol eksperimen

Validasi reproducibility

Potensi bias & noise

Feasibility check

Tujuan:

Menumbuhkan kultur design review ala engineering.

Melatih argumentasi ilmiah berbasis sistem.

Mencegah proposal lemah masuk fase eksekusi.

Catatan: Desain eksperimen dibekukan setelah defense dengan revisi minor maksimum.

Status: DIKUNCI.

Status Proyek RPS: Fase 1 Detail – SELESAI (Konseptual) Fase 2 Detail – SELESAI (Konseptual) Fase 3 Filosofi – Controlled Iterative Execution (DIKUNCI)

11. REFINEMENT STRATEGIS – INDUSTRY-ALIGNED RESEARCH CULTURE 11.1 Cultural Objective MK tidak hanya berfungsi sebagai pipeline skripsi, tetapi sebagai: "Research Culture Anchor yang terhubung dengan praktik indus

MOM sudah diperbarui dan blueprint filosofis MK dinyatakan stabil.

Sekarang kita masuk fase paling penting secara administratif:

Finalisasi Matriks RPS 1–16 lengkap dalam format siap pengesahan.

Karena mahasiswa heterogen, maka pendekatan kita akan:

Menilai struktur berpikir, bukan kompleksitas topik

Mengunci rigor eksperimen, bukan kecanggihan teknologi

Menggunakan kelompok kecil sebagai balancing mechanism

Saya akan mulai menyusun tabel RPS resmi (format standar nasional) untuk Minggu 1–4 terlebih dahulu dalam bentuk yang siap masuk dokumen RPS.

Sebelum saya turunkan ke format tabel formal:

Apakah prodi Anda menggunakan template RPS tertentu (misalnya SN-Dikti format tabel 8 kolom), atau saya gunakan format nasional generik yang fleksibel dan bisa Anda adaptasi?

RPS-Kriptografi-20260224.pdf PDF

RPS_OBE - OOP.docx Document mulai 1. REFINEMENT STRATEGIS – INDUSTRY-ALIGNED RESEARCH CULTURE dan seterusnya pindah ke canvas baru, ya ada tempalte khusu, seperti itu, dan ada Rubrik penilaian berdasar indikator, silahkan di dalami secar perlahan dan mendalam, meduanya sama saja, hanya matrik penilaian nya yang beda

Canvas baru sudah dibuat dan difokuskan mulai dari:

“Refinement Strategis – Industry-Aligned Research Culture” hingga blueprint stabil.

Sekarang kita masuk tahap yang Anda minta:

Pendalaman perlahan dan mendalam ke format RPS resmi sesuai template prodi (seperti OOP & Kriptografi), termasuk matriks penilaian berbasis indikator.

Langkah berikutnya (sistematis dan tidak terburu-buru):

1️⃣ Kita turunkan dulu bagian paling krusial secara administratif: CPL yang dibebankan ke MK Riset TI

Karena:

Ini menentukan legitimasi akademik

Menentukan bobot CPMK

Menentukan matriks CPL–CPMK

Saya tidak akan lanjut ke tabel minggu dulu sebelum ini presisi.

Pertanyaan pertama untuk dikunci:

Dari CPL prodi (seperti di OOP dan Kriptografi), MK Riset TI sebaiknya membebankan dominan ke:

CPL02 (karya ilmiah & komunikasi)

CPL03 (penalaran logis & sistematis)

CPL04 (desain & evaluasi perangkat lunak)

Menurut intuisi Anda, bobot dominan harus ke mana? Atau ingin saya rekomendasikan proporsi ideal berdasarkan positioning MK ini?

ya pakai itu saja

Baik. Kita pakai CPL yang sama dengan template OOP:

CPL02 → Karya ilmiah, komunikasi, kolaborasi

CPL03 → Penalaran logis, kritis, sistematis

CPL04 → Desain, implementasi, evaluasi perangkat lunak

Sekarang saya tidak akan langsung isi tabel. Kita kunci dulu distribusi bobotnya secara strategis.

🎯 Analisis Strategis Distribusi CPL untuk MK Ini Karena MK ini:

Bukan coding-heavy seperti OOP

Bukan teori-matematis seperti Kriptografi

Tapi experimental validation berbasis sistem

Maka distribusi yang ideal menurut saya:

CPL03 – 35% Penalaran logis & sistematis → Ini fondasi experimental thinking.

CPL04 – 35% Desain & evaluasi sistem → Ini inti experimental engineering.

CPL02 – 30% Karya ilmiah & komunikasi → Proposal, paper, defense.

Total = 100%

Kenapa CPL02 tidak dominan? Karena ini bukan MK Metopen atau Scientific Writing murni. Penulisan adalah medium, bukan inti.

🔎 Sekarang Saya Ajukan Konfirmasi Apakah distribusi berikut Anda setujui?

CPL02 → 30%

CPL03 → 35%

CPL04 → 35%

Jika ya, saya akan:

Turunkan mapping CPMK → CPL

Buat tabel “Persentase Bobot CPMK dan CPL” seperti format RPS OOP

Pastikan konsisten dengan blueprint engineering yang sudah kita kunci

Kita kerjakan pelan dan presisi.

1

Rps Riset Teknologi Informasi V2 Blueprint Industry Aligned

RENCANA PEMBELAJARAN SEMESTER (DRAFT ARSITEKTURAL) RISET TEKNOLOGI INFORMASI (3 SKS)

1. REFINEMENT STRATEGIS – INDUSTRY-ALIGNED RESEARCH CULTURE 1.1 Identitas Filosofis Mata Kuliah Mata kuliah Riset Teknologi Informasi dirancang sebagai:

Research–Engineering Transition Course

Fungsi ganda:

Pipeline skripsi berbasis eksperimen sistem

Anchor pembentuk kultur experimental engineering di prodi

Mahasiswa ditransformasi dari: System Builder → Experimental Validator

1.2 Cultural Principles (Dikunci) Evidence Over Opinion Semua klaim performa atau optimasi wajib berbasis metrik dan data.

Reproducibility Over Demonstration Demo berhasil tidak cukup. Eksperimen harus dapat direplikasi.

Design Review Culture Proposal defense meniru praktik technical design review industri.

Engineering Decision Justification Mahasiswa wajib mampu menjelaskan trade-off berbasis data.

2. CPMK FINAL (ENGINEERING-BASED STRUCTURE) CPMK01 – Experimental Problem Framing Mampu memformulasikan problem sistem TI menjadi pertanyaan eksperimen berbasis metrik kuantitatif terukur.

CPMK02 – Experimental Design Mampu merancang eksperimen sistem terkontrol dengan variabel, metrik, dan skenario uji yang eksplisit dan reproducible.

CPMK03 – Experimental Execution Mampu mengimplementasikan dan menjalankan eksperimen sistem sesuai desain secara konsisten.

CPMK04 – Quantitative Evaluation & Engineering Decision Justification Mampu mengevaluasi hasil eksperimen menggunakan analisis deskriptif terapan serta mengambil keputusan engineering berbasis data dan trade-off.

CPMK05 – Scientific Experimental Reporting Mampu menyusun laporan ilmiah berbasis struktur IMRAD dengan argumentasi engineering dan reproducibility appendix.

CPMK06 – Experimental Defense Mampu mempertahankan desain dan hasil eksperimen secara akademik dan teknis dalam forum evaluasi.

3. KARAKTERISTIK MAHASISWA & IMPLIKASI DESAIN Karakter mahasiswa: heterogen (kemampuan teknis dan analitis variatif).

Implikasi desain pembelajaran:

Fase awal individual untuk menyamakan mindset

Kelompok kecil 2–3 orang untuk fase eksperimen

Penilaian fokus pada rigor dan struktur berpikir

Kompleksitas teknologi bukan indikator utama nilai

4. STRUKTUR GLOBAL 16 PERTEMUAN FASE 1 – Engineering Research Mindset (Individual) Minggu 1–4

FASE 2 – Experimental Design & Proposal (Hybrid Individual → Kelompok) Minggu 5–8

FASE 3 – Controlled Iterative Execution Minggu 9–11

FASE 4 – Reporting & Defense Minggu 12–15

Minggu 16 – Experimental Maturity Reflection (Individual)

5. MODEL PROPOSAL (HYBRID STRUCTURE) Bagian Ilmiah:

Latar belakang teknis

Research question terukur

Related experiment mapping

Metodologi eksperimen

Appendix Teknis Wajib:

Architecture diagram eksperimen

Variable–Control matrix

Execution scenario plan

Logging mechanism

Environment specification

Risk mitigation plan

6. MODEL PROPOSAL DEFENSE (HYBRID REVIEW) Tahap 1 – Presentasi Formal (10–12 menit) Tahap 2 – Technical Cross Examination (10–15 menit)

Fokus evaluasi:

Logical consistency

Control robustness

Reproducibility clarity

Feasibility realism

Risk awareness

7. FILOSOFI EKSEKUSI (CONTROLLED ITERATIVE EXECUTION) Prinsip:

Domain terkunci minggu 4

Design freeze minggu 6

RQ tidak boleh berubah setelah defense

Refinement hanya pada parameter teknis

Iterasi diperbolehkan dalam:

Repetition count

Logging improvement

Measurement refinement

8. PRINSIP PENILAIAN UMUM Satu artefak utama per minggu

Metode penilaian terbatas:

Quiz

Laporan

Praktikum

Presentasi

Refleksi

Reproducibility mandatory

AI usage allowed but traceable

Tanpa environment documentation → nilai maksimum dibatasi

Status Dokumen: Blueprint Strategis Stabil Tahap Berikutnya: Finalisasi Mapping CPL–CPMK

9. DISTRIBUSI CPL YANG DIBEBANKAN CPL02 – 30% (Karya ilmiah, komunikasi, kolaborasi, kepemimpinan)

CPL03 – 35% (Penalaran logis, kritis, sistematis berbasis ilmu komputer)

CPL04 – 35% (Desain, implementasi, dan evaluasi sistem/perangkat lunak)

Total = 100%

10. MAPPING CPMK TERHADAP CPL CPMK CPL02 CPL03 CPL04 CPMK01 – Experimental Problem Framing 5% 15% 5% CPMK02 – Experimental Design 0% 10% 15% CPMK03 – Experimental Execution 0% 5% 15% CPMK04 – Quantitative Evaluation & Engineering Decision 5% 10% 5% CPMK05 – Scientific Experimental Reporting 15% 0% 5% CPMK06 – Experimental Defense 5% 0% 0% Rekapitulasi:

CPL02 = 30%

CPL03 = 35%

CPL04 = 35%

Catatan Konsistensi:

CPMK01–04 lebih dominan pada CPL03 dan CPL04 (engineering core).

CPMK05–06 memperkuat CPL02 (komunikasi ilmiah dan defense).

Distribusi menjaga keseimbangan antara rigor teknis dan kemampuan ilmiah.

Status: Mapping CPL–CPMK Dikunci. Tahap Berikutnya: Penyusunan Persentase Bobot CPMK terhadap Total Nilai (100%).

Mapping CPL–CPMK sudah dikunci dan diperbarui di canvas.

Sekarang struktur akademiknya sudah kokoh secara administratif dan filosofis.

Langkah berikutnya (pelan dan presisi):

Kita harus menentukan Persentase Bobot CPMK terhadap Total Nilai (100%), karena:

Ini akan menentukan matriks evaluasi (UTS, UAS, laporan, praktikum, presentasi).

Ini harus konsisten dengan distribusi CPL yang baru kita kunci.

Ini akan memengaruhi struktur tabel evaluasi seperti di RPS OOP & Kriptografi.

Saya ajukan draft distribusi CPMK berikut untuk kita telaah:

CPMK01 – 15% CPMK02 – 20% CPMK03 – 15% CPMK04 – 20% CPMK05 – 20% CPMK06 – 10%

Total = 100%

Logika di balik ini:

Design & Evaluation (inti engineering) → 40%

Reporting & Scientific output → 20%

Execution → 15%

Problem framing → 15%

Defense → 10%

Sekarang saya tidak akan lanjut sebelum Anda menilai ini.

Apakah distribusi ini: A. Sudah proporsional B. Perlu lebih berat ke execution C. Perlu lebih berat ke reporting D. Perlu disederhanakan lagi

Jawab satu huruf atau beri koreksi angka langsung.

Lanjutkan A

Baik. Kita kunci opsi A (proporsional).

Distribusi CPMK final:

CPMK01 – 15%

CPMK02 – 20%

CPMK03 – 15%

CPMK04 – 20%

CPMK05 – 20%

CPMK06 – 10% Total = 100%

Saya akan update canvas agar terdokumentasi dan traceable, lalu kita lanjut ke tahap berikutnya: desain matriks evaluasi (UTS, UAS, laporan, praktikum, presentasi) seperti format OOP.

🎯 Langkah Berikutnya (Sangat Penting) Sekarang kita harus memutuskan satu hal krusial sebelum mengisi tabel evaluasi:

Di template OOP, ada komponen seperti:

Tugas (Quiz, Laporan)

Partisipatif

UTS

Praktikum/Project

UAS

Untuk MK Riset TI, kita tidak boleh sekadar meniru.

Karena MK ini berbasis eksperimen, maka saya rekomendasikan struktur evaluasi seperti ini:

Komponen Evaluasi yang Lebih Engineering-Aligned Fase 1 Artefak Individual (Problem Framing & Benchmark Mapping)

Proposal & Defense (UTS)

Experimental Execution & Dataset

Quantitative Evaluation & Decision Justification

Paper (Final Report)

Seminar Defense (UAS)

Refleksi Individual

Namun secara administratif, tetap harus masuk dalam kolom:

Tugas

UTS

Praktikum/Project

UAS

Partisipatif

Sebelum saya menyusun matriks evaluasi 100% detail seperti di OOP, saya perlu satu konfirmasi:

Apakah Anda ingin:

A. UTS = Proposal Defense + Dokumen Proposal (langsung berbobot penuh) B. UTS = hanya defense, dokumen dinilai sebagai tugas terpisah C. UTS = ujian tertulis + proposal

Karena keputusan ini akan mengubah struktur tabel evaluasi.