SQL

Modul 3 · Rangkaian tes otomatis untuk aplikasi web dengan fitur LLM, berjalan di CI

Uji aplikasi contoh (disediakan; aplikasinya sengaja mengandung beberapa bug). Bangun rangkaian tes dan temukan sebanyak mungkin bug dengan bukti. Bila Anda memakai AI untuk menulis tes, catat tes mana yang Anda buang dan alasannya. Tahapan pengerjaan • Kerangka: Strategi tes, prioritas risiko, dan rencana cakupan. • Draf: Tes ujung ke ujung dan tes API untuk alur utama berjalan di CI. • Revisi: Set evaluasi untuk fitur LLM dan tes keamanan dasar; tes yang gagal acak diperbaiki; umpan balik reviewer ditindaklanjuti. • Final: Laporan bug beserta bukti, laporan kualitas, dan catatan penggunaan AI dalam menulis tes.

Yang diserahkan: Tautan repositori berisi tes dan konfigurasi CI, laporan bug (langkah reproduksi dan bukti), serta laporan kualitas maksimal 3 halaman.

• Strategi dan cakupan berbasis risikobobot 25% · skor 0–4

  Area berisiko tinggi teruji di level yang tepat; cakupan dibenarkan.

• Bug yang ditemukanbobot 25% · skor 0–4

  Bug yang disisipkan ditemukan dengan langkah reproduksi yang jelas.

• Pengujian fitur LLMbobot 25% · skor 0–4

  Set evaluasi menangani keluaran tidak deterministik dengan kriteria lulus yang masuk akal.

• Stabilitas dan kualitas tesbobot 15% · skor 0–4

  Tes stabil, mudah dibaca, dan tes buatan AI yang tidak bermakna sudah disaring.

• Pelaporanbobot 10% · skor 0–4

  Laporan kualitas bisa ditindaklanjuti oleh tim pengembang.

Modul 1 · Infrastruktur sebagai kode dan deployment Kubernetes untuk aplikasi AI tiga komponen

Deploy aplikasi AI tiga komponen (API, worker, basis data; aplikasi contoh disediakan) ke cloud pilihan Anda memakai Terraform dan Kubernetes. Reviewer akan membaca kode Anda untuk menilai apakah infrastruktur bisa dibangun ulang dari nol. Tetapkan anggaran bulanan dan buktikan infrastruktur Anda berada di bawahnya. Tahapan pengerjaan • Kerangka: Diagram arsitektur, pilihan layanan cloud beserta alasannya, dan estimasi biaya bulanan. • Draf: Terraform membuat klaster dan jaringan; aplikasi berjalan di Kubernetes. • Revisi: Rahasia dikelola dengan benar, autoscaling teruji dengan uji beban sederhana, dan umpan balik reviewer ditindaklanjuti. • Final: Bukti pemulihan dari kehilangan basis data, perbandingan biaya aktual dengan estimasi, dan prosedur pembongkaran infrastruktur.

Yang diserahkan: Tautan repositori berisi Terraform dan manifest Kubernetes, README untuk membangun ulang dari nol, hasil uji beban, dan laporan biaya.

• Reprodusibilitas infrastrukturbobot 30% · skor 0–4

  Infrastruktur bisa dibangun ulang dan dibongkar hanya dari kode; tidak ada langkah manual tersembunyi.

• Ketepatan deployment Kubernetesbobot 25% · skor 0–4

  Sumber daya, probe kesehatan, dan autoscaling dikonfigurasi dengan benar dan teruji.

• Keamanan dasarbobot 20% · skor 0–4

  Rahasia tidak ada di repositori, kontainer berjalan sebagai non-root, akses jaringan dibatasi.

• Kendali biayabobot 15% · skor 0–4

  Estimasi masuk akal dan biaya aktual dilaporkan jujur terhadap anggaran.

• Pemulihanbobot 10% · skor 0–4

  Pencadangan dan pemulihan basis data terbukti berjalan.

Modul 2 · Basis data PostgreSQL untuk katalog dengan pencarian teks, vektor, dan gabungan, beserta bukti kinerja

Rancang dan bangun basis data untuk katalog produk berukuran minimal 200.000 baris (generator dataset disediakan). Terapkan tiga jenis pencarian, ukur kualitas dan kecepatannya, lalu rekomendasikan mana yang dipakai untuk kasus apa. Tahapan pengerjaan • Kerangka: Model data, pola kueri utama, dan rencana indeks. • Draf: Skema dan data termuat, kueri transaksional teroptimasi dengan bukti rencana kueri. • Revisi: Pencarian teks penuh, vektor, dan gabungan berjalan dan diukur; umpan balik reviewer ditindaklanjuti. • Final: Row-Level Security, laporan kinerja, dan rekomendasi arsitektur.

Yang diserahkan: Tautan repositori berisi migrasi skema, skrip data, dan skrip pengukuran, serta laporan maksimal 5 halaman berisi tabel kinerja dan rekomendasi.

• Kualitas model databobot 25% · skor 0–4

  Skema ternormalisasi dengan tepat, tipe data benar, dan batasan integritas lengkap.

• Kinerja terbuktibobot 25% · skor 0–4

  Indeks dirancang dari pola kueri dan perbaikannya dibuktikan dengan rencana kueri dan pengukuran.

• Kualitas pencarianbobot 25% · skor 0–4

  Ketiga jenis pencarian berjalan; kualitas hasil diukur, bukan diasumsikan.

• Keamanan databobot 15% · skor 0–4

  Peran dan Row-Level Security membatasi akses dengan benar dan teruji.

• Rekomendasibobot 10% · skor 0–4

  Rekomendasi didukung angka dan jujur tentang batas PostgreSQL.

Modul 1 · Analisis penjualan toko daring dan rekomendasi bisnis yang didukung data

Pakai dataset transaksi e-commerce publik atau dataset yang disediakan instruktur. Rumuskan tiga pertanyaan bisnis yang penting bagi pemilik toko, jawab dengan spreadsheet dan SQL, lalu tulis rekomendasi yang bisa dijalankan. Tahapan pengerjaan • Kerangka: Tiga pertanyaan bisnis beserta alasannya, KPI yang dipakai, dan rencana analisis. • Draf: Kueri SQL dan tabel hasil untuk ketiga pertanyaan. • Revisi: Perbaikan logika kueri dan pembersihan data sesuai umpan balik reviewer, ditambah grafik pendukung. • Final: Rekomendasi bisnis dan berkas kerja yang bisa diulang orang lain.

Yang diserahkan: Dokumen rekomendasi 1–2 halaman, berkas kueri SQL, dan spreadsheet kerja yang menunjukkan langkah dari data mentah sampai angka akhir.

• Ketepatan analisis dan kueribobot 35% · skor 0–4

  Kueri menjawab pertanyaan yang benar dan angkanya bisa direproduksi.

• Relevansi pertanyaan bisnisbobot 20% · skor 0–4

  Pertanyaan memang penting bagi pemilik usaha dan KPI-nya tepat.

• Kejujuran membaca angkabobot 20% · skor 0–4

  Batasan data, pencilan, dan ketidakpastian disebutkan, bukan disembunyikan.

• Kejelasan rekomendasibobot 25% · skor 0–4

  Rekomendasi singkat, bisa dijalankan, dan setiap klaim didukung angka.

Modul 2 · Dashboard kinerja dan retensi pelanggan beserta memo keputusan untuk manajemen

Dengan dataset e-commerce publik atau dataset dari instruktur, bangun dashboard untuk satu pemakai yang jelas (misalnya manajer pemasaran). Dashboard wajib memuat metrik inti, segmentasi RFM, dan analisis cohort, lalu ditutup memo yang mengusulkan keputusan. Tahapan pengerjaan • Kerangka: Siapa pemakai dashboard, keputusan apa yang didukung, kamus metrik, dan sketsa tata letak. • Draf: Dashboard berjalan dengan data nyata untuk metrik inti. • Revisi: Perbaikan sesuai umpan balik reviewer, ditambah segmentasi RFM dan analisis cohort. • Final: Dashboard final, memo keputusan, dan presentasi singkat.

Yang diserahkan: Tautan dashboard yang bisa dibuka reviewer, memo keputusan satu halaman, kamus metrik, dan video presentasi maksimal 5 menit.

• Kebenaran metrik dan databobot 30% · skor 0–4

  Definisi metrik konsisten dan angka di dashboard bisa ditelusuri ke data.

• Desain yang menjawab keputusanbobot 25% · skor 0–4

  Hierarki, filter, dan grafik membantu pemakai mengambil keputusan yang dituju.

• Kedalaman analisisbobot 25% · skor 0–4

  Segmentasi RFM dan cohort dikerjakan benar dan ditafsirkan dengan tepat.

• Storytelling dan rekomendasibobot 20% · skor 0–4

  Memo dan presentasi berujung pada keputusan yang jelas dan didukung data.

Modul 3 · Pipeline ELT tiga sumber dengan pemeriksaan kualitas data dan keluaran siap-AI

Bangun pipeline untuk satu kasus bisnis dengan minimal tiga sumber data (API, berkas, dan basis data). Muat ke gudang data berlapis, tegakkan aturan kualitas, dan hasilkan satu keluaran siap-AI. Dataset publik atau dataset sintetis yang realistis boleh dipakai; dataset contoh disediakan bagi yang belum punya. Tahapan pengerjaan • Kerangka: Kasus bisnis, daftar sumber beserta contoh datanya, diagram lapisan data, rancangan model dimensional, dan daftar aturan kualitas data. • Draf: Pipeline berjalan ujung ke ujung untuk dua sumber, transformasi utama selesai, dan jadwal berjalan. • Revisi: Ketiga sumber masuk, pemeriksaan kualitas otomatis aktif, pemuatan ulang terbukti idempoten, dan umpan balik reviewer ditindaklanjuti. • Final: Keluaran siap-AI, dokumentasi lineage data, dan demo satu insiden kualitas data yang tertangkap oleh pemeriksaan Anda.

Yang diserahkan: Tautan repositori Git (docker compose untuk menjalankan semuanya), diagram arsitektur dan lineage, laporan kualitas data, serta video demo maksimal 5 menit.

• Ketepatan pemodelan databobot 25% · skor 0–4

  Model gudang data menjawab kebutuhan bisnis yang ditetapkan; grain tabel jelas dan konsisten.

• Keandalan pipelinebobot 25% · skor 0–4

  Pipeline idempoten, bisa dijalankan ulang tanpa duplikasi, dan kegagalan terlihat (tidak diam-diam).

• Kualitas databobot 25% · skor 0–4

  Aturan kualitas bermakna, diuji otomatis, dan data buruk dikarantina alih-alih diloloskan.

• Kesiapan untuk AIbobot 15% · skor 0–4

  Keluaran untuk aplikasi AI bersih, berpotongan masuk akal, dan membawa metadata yang dibutuhkan.

• Dokumentasi dan reprodusibilitasbobot 10% · skor 0–4

  Orang lain bisa menjalankan pipeline dari README; lineage terdokumentasi.

Modul 2 · Aplikasi katalog React dengan pencarian, filter, formulir tervalidasi, dan tes

Pilih satu API publik yang datanya menarik bagi Anda. Bangun aplikasi katalog dengan React dan TypeScript: daftar, pencarian, filter, halaman rincian, favorit yang tersimpan, dan satu formulir (misalnya ulasan atau permintaan) dengan validasi. Tulis minimal 8 tes. Tahapan pengerjaan • Kerangka: API yang dipilih beserta alasannya, peta halaman, dan rancangan pohon komponen. • Draf: Alur utama berjalan dengan data nyata dari API: daftar, pencarian, dan rincian. • Revisi: Keadaan loading, galat, dan kosong tertangani; aksesibilitas diperbaiki; tes ditambahkan sesuai umpan balik reviewer. • Final: Aplikasi terbit, README menjelaskan keputusan teknis, dan laporan Lighthouse terlampir.

Yang diserahkan: Tautan aplikasi yang sudah terbit, tautan repositori dengan README berisi keputusan teknis (struktur komponen, pengelolaan state, alasan library), hasil tes, dan laporan Lighthouse.

• Fungsi dan penanganan keadaanbobot 30% · skor 0–4

  Seluruh fitur berjalan, dan keadaan loading, galat, serta kosong ditangani dengan jelas bagi pengguna.

• Struktur komponen dan statebobot 25% · skor 0–4

  Komponen terpecah masuk akal, state berada di tempat yang tepat, dan tipe TypeScript dipakai dengan benar.

• Pengujianbobot 20% · skor 0–4

  Minimal 8 tes yang menguji perilaku penting, bukan sekadar menambah jumlah.

• Aksesibilitas dan responsifbobot 15% · skor 0–4

  Bisa dipakai dengan papan ketik, kontras cukup, dan tampilan layak di ponsel.

• Keputusan teknis tertulisbobot 10% · skor 0–4

  README menjelaskan pilihan dan trade-off dengan jujur.

Modul 1 · Aplikasi pencatat keuangan pribadi berbasis web yang terbit di internet

Bangun aplikasi web pencatat keuangan pribadi dengan HTML, CSS, dan JavaScript murni (tanpa framework). Pengguna bisa menambah dan menghapus transaksi, melihat ringkasan pengeluaran per jenis, dan datanya tetap ada setelah halaman dimuat ulang. Seluruh pekerjaan dicatat di Git. Tahapan pengerjaan • Kerangka: Sketsa setiap layar, daftar fitur, dan struktur HTML awal di repositori GitHub. • Draf: Fitur tambah, hapus, dan ringkasan berjalan, dengan minimal 10 commit yang pesannya menjelaskan perubahan. • Revisi: Perbaikan dari umpan balik reviewer, tampilan ponsel, dan validasi masukan (nominal kosong atau negatif ditolak). • Final: Aplikasi terbit di GitHub Pages, README lengkap, dan video demo yang menjelaskan satu fungsi yang Anda tulis sendiri.

Yang diserahkan: Tautan aplikasi di GitHub Pages, tautan repositori dengan README (fitur dan cara menjalankan), dan video maksimal 3 menit yang menelusuri satu fungsi JavaScript buatan Anda baris demi baris.

• Fungsi sesuai spesifikasibobot 30% · skor 0–4

  Tambah, hapus, ringkasan, dan penyimpanan berjalan benar, termasuk saat data kosong.

• Kualitas kodebobot 25% · skor 0–4

  Nama variabel dan fungsi jelas, fungsi kecil dan berfokus, tanpa duplikasi yang tidak perlu.

• Responsif dan aksesibilitas dasarbobot 20% · skor 0–4

  Tampilan layak di ponsel dan desktop, kontras cukup, dan formulir punya label.

• Riwayat Git dan READMEbobot 15% · skor 0–4

  Commit bertahap dengan pesan yang bermakna; README cukup untuk orang lain menjalankan aplikasi.

• Pemahaman sendiribobot 10% · skor 0–4

  Video membuktikan Anda memahami kode yang Anda serahkan, bukan sekadar menyalin.

Modul 3 · REST API pemesanan jadwal untuk usaha jasa, teruji dan siap dijalankan dengan Docker

Bangun REST API pemesanan jadwal untuk satu jenis usaha jasa. Wajib ada: pendaftaran dan login, peran admin dan pelanggan, pengelolaan layanan dan jadwal oleh admin, pemesanan oleh pelanggan yang menolak jadwal bentrok, dokumentasi OpenAPI, tes otomatis, dan docker compose yang langsung jalan. Tahapan pengerjaan • Kerangka: Diagram model data (ERD), kontrak OpenAPI untuk seluruh endpoint, dan daftar aturan bisnis. • Draf: Endpoint inti berjalan dengan autentikasi dan migrasi basis data. • Revisi: Aturan jadwal bentrok, validasi masukan, tes integrasi, dan perbaikan keamanan sesuai umpan balik reviewer. • Final: Repositori lengkap, docker compose berjalan, koleksi uji, dan video demo.

Yang diserahkan: Tautan repositori dengan README (cara menjalankan, keputusan rancangan), berkas OpenAPI, koleksi uji (Postman atau sejenisnya), hasil tes, dan video demo maksimal 5 menit.

• Kebenaran aturan bisnisbobot 25% · skor 0–4

  Pemesanan bentrok ditolak, peran dihormati, dan kasus tepi diuji.

• Rancangan API dan databobot 25% · skor 0–4

  Endpoint, kode status, dan skema konsisten; kontrak OpenAPI sesuai implementasi.

• Keamananbobot 25% · skor 0–4

  Kata sandi di-hash, otorisasi diperiksa di setiap endpoint, masukan divalidasi, dan rahasia tidak ada di repositori.

• Pengujianbobot 15% · skor 0–4

  Tes mencakup aturan bisnis utama dan bisa dijalankan dengan satu perintah.

• Siap dijalankan orang lainbobot 10% · skor 0–4

  docker compose dan README cukup untuk menjalankan proyek tanpa bertanya.

Modul 5 · Aplikasi SaaS multi-tenant dengan fitur AI, isolasi tenant yang terbukti, dan kuota biaya AI

Bangun SaaS multi-tenant untuk satu kebutuhan bisnis yang Anda pilih. Minimal satu fitur AI harus menyelesaikan pekerjaan nyata pengguna, bukan sekadar kotak obrolan. Buktikan tenant A tidak bisa melihat data maupun pengetahuan AI tenant B, dan tunjukkan kuota AI per tenant ditegakkan. Tahapan pengerjaan • Kerangka: Masalah pengguna, model data, pilihan isolasi tenant beserta alternatif yang ditolak, desain API, dan wireframe. • Draf: Alur utama berjalan ujung ke ujung untuk dua tenant, termasuk autentikasi dan otorisasi. • Revisi: Fitur AI berjalan lewat antrean, tes isolasi tenant otomatis, CI/CD aktif, dan umpan balik reviewer ditindaklanjuti. • Final: Deploy yang bisa diakses reviewer, kuota biaya AI per tenant, dokumen keputusan arsitektur, dan video demo.

Yang diserahkan: Tautan aplikasi yang ter-deploy beserta akun uji untuk dua tenant, repositori, dokumen keputusan arsitektur maksimal 4 halaman, dan video demo maksimal 7 menit.

• Keputusan arsitekturbobot 25% · skor 0–4

  Pilihan isolasi tenant, pembagian sinkron dan asinkron, serta batas modul dibenarkan dan alternatifnya dibahas.

• Isolasi data tenantbobot 25% · skor 0–4

  Isolasi terbukti lewat tes otomatis, termasuk untuk pengetahuan AI; tidak ada jalur kebocoran yang ditemukan reviewer.

• Nilai fitur AIbobot 20% · skor 0–4

  Fitur AI menyelesaikan pekerjaan nyata, menangani kegagalan model dengan baik, dan biayanya terkendali.

• Kualitas rekayasabobot 20% · skor 0–4

  Kode rapi, tes bermakna, CI/CD berjalan, dan rahasia aman.

• Pengalaman penggunabobot 10% · skor 0–4

  Alur utama jelas dan status pekerjaan AI (sedang diproses, gagal) terkomunikasikan.

Modul 4 · Refactor terukur atas satu modul kode warisan open source dengan bantuan AI

Pilih satu modul dari proyek open source yang punya kode sulit dirawat (fungsi panjang, duplikasi, tanpa tes). Kunci perilakunya dengan tes, lalu refactor bertahap dengan bantuan asisten coding AI. Setiap usulan AI yang Anda terima, ubah, atau tolak harus tercatat beserta alasannya. Tahapan pengerjaan • Kerangka: Modul yang dipilih, peta masalahnya (dengan metrik sederhana seperti panjang fungsi atau duplikasi), dan rencana langkah refactor. • Draf: Tes karakterisasi yang lulus terhadap kode asli, ditambah separuh langkah refactor dalam commit-commit kecil. • Revisi: Refactor selesai dengan perbaikan dari umpan balik reviewer. Log keputusan AI: minimal 10 usulan beserta keputusan Anda. • Final: Metrik sebelum dan sesudah, catatan bug yang Anda temukan dari usulan AI, dan pedoman penggunaan AI satu halaman untuk tim.

Yang diserahkan: Tautan fork repositori dengan riwayat commit, log keputusan AI (tabel usulan, keputusan, alasan), dan dokumen ringkas maksimal 3 halaman berisi metrik sebelum dan sesudah serta pedoman tim.

• Perilaku tetap terjagabobot 30% · skor 0–4

  Tes karakterisasi mencakup jalur penting dan tetap lulus setelah refactor; tidak ada perubahan perilaku yang tidak disengaja.

• Kualitas refactorbobot 25% · skor 0–4

  Struktur kode benar-benar lebih mudah dirawat dan metriknya membaik; commit kecil dan bisa di-review.

• Review kritis terhadap usulan AIbobot 30% · skor 0–4

  Usulan yang salah atau berisiko dikenali dan ditolak dengan alasan teknis yang tepat.

• Pedoman timbobot 15% · skor 0–4

  Pedoman penggunaan AI praktis, spesifik, dan bisa langsung diterapkan.

Analisis penjualan toko daring dan rekomendasi bisnis yang didukung data

Pakai dataset transaksi e-commerce publik atau dataset yang disediakan instruktur. Rumuskan tiga pertanyaan bisnis yang penting bagi pemilik toko, jawab dengan spreadsheet dan SQL, lalu tulis rekomendasi yang bisa dijalankan. Tahapan pengerjaan • Kerangka: Tiga pertanyaan bisnis beserta alasannya, KPI yang dipakai, dan rencana analisis. • Draf: Kueri SQL dan tabel hasil untuk ketiga pertanyaan. • Revisi: Perbaikan logika kueri dan pembersihan data sesuai umpan balik reviewer, ditambah grafik pendukung. • Final: Rekomendasi bisnis dan berkas kerja yang bisa diulang orang lain.

Yang diserahkan: Dokumen rekomendasi 1–2 halaman, berkas kueri SQL, dan spreadsheet kerja yang menunjukkan langkah dari data mentah sampai angka akhir.

• Ketepatan analisis dan kueribobot 35% · skor 0–4

  Kueri menjawab pertanyaan yang benar dan angkanya bisa direproduksi.

• Relevansi pertanyaan bisnisbobot 20% · skor 0–4

  Pertanyaan memang penting bagi pemilik usaha dan KPI-nya tepat.

• Kejujuran membaca angkabobot 20% · skor 0–4

  Batasan data, pencilan, dan ketidakpastian disebutkan, bukan disembunyikan.

• Kejelasan rekomendasibobot 25% · skor 0–4

  Rekomendasi singkat, bisa dijalankan, dan setiap klaim didukung angka.