Program Studi Bisnis Digital • FEB

Laboratorium Pemrograman

Pertemuan 13 — Evaluasi, Debugging, dan Penyusunan Laporan Proyek Akhir Secara Sistematis

Aplikasi Anda sudah tersambung front-end ke back-end di pertemuan lalu — sekarang saatnya menguji, membenahi bug yang tersisa, dan mendokumentasikannya jadi laporan yang layak dinilai.

RPS MINGGU 14 • 2×50 MENIT

Selamat datang di pertemuan ketiga belas. Pada pertemuan sebelumnya Anda sudah menyatukan komponen front-end dan back-end aplikasi proyek akhir menjadi satu sistem yang berjalan — mirip seperti saat tim developer Tokopedia atau Bukalapak menggabungkan modul katalog dengan modul pembayaran sebelum peluncuran. Masalahnya, sistem yang "berjalan" belum tentu sistem yang "benar" — bisa saja tombol checkout tampak berfungsi, padahal datanya tidak pernah benar-benar tersimpan ke database. Hari ini kita akan belajar mengevaluasi aplikasi Anda secara sistematis, mencari dan membenahi bug dengan metode yang terstruktur bukan asal coba-coba, lalu menyusun laporan proyek yang menjelaskan apa yang sudah dibangun dan apa yang masih perlu diperbaiki. Pertemuan ini adalah jembatan langsung menuju presentasi akhir minggu depan, jadi apa yang Anda kerjakan hari ini akan langsung menentukan kesiapan proyek Anda untuk dinilai.

Bagian 1 dari 3

Evaluasi & Debugging Sistematis

Berhenti menebak-nebak — kenali jenis bug, ikuti alur debugging terstruktur, dan pakai tool yang tepat untuk tiap lapisan aplikasi.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu mengevaluasi, men-debug, dan mendokumentasikan proyek aplikasi secara sistematis. Secara rinci:

CAPAIAN 1

KLASIFIKASI

Membedakan jenis bug (sintaks, logika, runtime) dan sumber kesalahan pada aplikasi full-stack.

CAPAIAN 2

DEBUGGING

Menerapkan alur debugging sistematis (reproduksi → isolasi → perbaikan → verifikasi).

CAPAIAN 3

EVALUASI

Menghitung skor evaluasi proyek berbasis rubrik berbobot dan densitas bug.

CAPAIAN 4

LAPORAN

Menyusun laporan proyek akhir yang sistematis, jujur, dan siap dipresentasikan.

Mengapa Evaluasi Sistematis Ini Penting?

Bayangkan tim Anda sudah menyatukan aplikasi minggu lalu, lalu tiga hal ini terjadi saat demo ke dosen pembimbing:

KEJADIAN 1

CRASH

Aplikasi crash saat tombol "Simpan" ditekan dua kali berturut-turut.

KEJADIAN 2

DATA HILANG

Data yang diinput lewat form tidak muncul lagi setelah aplikasi ditutup.

KEJADIAN 3

LAPORAN KOSONG

Laporan proyek hanya berisi tangkapan layar tanpa penjelasan alur kerja.

Ketiga masalah ini punya akar yang sama: tidak ada proses evaluasi terstruktur sebelum aplikasi dianggap "selesai". Debugging asal-asalan dan laporan tempelan adalah alasan paling umum nilai proyek akhir turun drastis di banyak kelas bootcamp maupun perkuliahan.

Skenario ini bukan cerita rekaan — hampir setiap angkatan mahasiswa Lab Pemrograman mengalami setidaknya satu dari tiga kejadian ini menjelang presentasi akhir. Aplikasi crash karena tombol ditekan dua kali biasanya berarti tidak ada validasi status pengiriman data, sesuatu yang mudah dicegah kalau sudah terbiasa menguji skenario "pengguna nakal". Data hilang setelah aplikasi ditutup biasanya berarti data hanya tersimpan di state sementara, bukan benar-benar tersimpan ke database lewat operasi CRUD yang sudah Anda pelajari di pertemuan sebelas. Laporan kosong terjadi karena tim menganggap dokumentasi sebagai pekerjaan di menit-menit terakhir, padahal laporan yang baik justru membantu tim sendiri menemukan bug yang terlewat. Hari ini kita membangun kebiasaan supaya ketiga hal ini tidak terjadi pada proyek Anda.

Tiga Jenis Bug yang Wajib Anda Kenali

Ketiga jenis ini butuh strategi pencarian berbeda — bug sintaks ditangkap editor, bug logika butuh penelusuran manual, bug runtime butuh simulasi kondisi nyata pengguna.

Perhatikan diagram ini karena sepanjang sisa slide hari ini kita akan terus merujuk ke tiga kategori ini. Bug sintaks adalah yang paling ramah bagi pemula — editor kode seperti VS Code langsung menggarisbawahi merah kalau ada tanda kurung atau titik koma yang hilang, jadi biasanya cepat ketahuan sebelum aplikasi dijalankan. Bug logika jauh lebih licik: kode Anda berjalan tanpa error sama sekali, tapi hasilnya salah, misalnya total belanja di aplikasi e-commerce Anda menghitung diskon dua kali karena kondisi if yang tertukar urutannya. Bug runtime adalah yang paling menakutkan saat demo di depan dosen, karena aplikasi tiba-tiba berhenti total ketika koneksi ke API atau database gagal di tengah jalan — persis seperti yang mungkin pernah Anda alami saat aplikasi e-commerce sungguhan seperti Shopee tiba-tiba menampilkan pesan error saat traffic tinggi.

Alur Debugging Sistematis: 4 Langkah

Aturan emas: jangan pernah mengubah kode sebelum langkah 1 dan 2 selesai. Mengubah kode sambil menebak-nebak sering menimbulkan bug baru di atas bug lama.

Alur empat langkah ini adalah standar yang dipakai hampir semua software engineer profesional, termasuk di tim engineering startup unicorn Indonesia. Langkah pertama, reproduksi, artinya Anda harus bisa memicu bug yang sama secara berulang dengan langkah yang persis sama — kalau Anda tidak bisa mengulang bug, Anda tidak akan pernah yakin sudah memperbaikinya. Langkah kedua, isolasi, adalah proses mempersempit dugaan penyebab, misalnya dengan menambahkan console.log di beberapa titik untuk melihat di mana data mulai salah. Langkah ketiga, perbaikan, baru dilakukan setelah Anda benar-benar tahu akar masalahnya, dan sebaiknya perbaikan itu sekecil dan setepat mungkin. Langkah keempat, verifikasi, sering dilupakan mahasiswa — padahal ini penting untuk memastikan perbaikan Anda tidak diam-diam merusak fitur lain yang tadinya berjalan baik.

Studi Kasus: Data Tidak Tersimpan ke Database

Tim Anda melaporkan: "Setelah isi form tambah produk dan tekan Simpan, data tidak muncul di daftar produk." Mari telusuri dengan alur empat langkah.

LANGKAH A — REPRODUKSI

Coba isi form yang sama tiga kali di perangkat berbeda → bug muncul konsisten, bukan kebetulan jaringan.

LANGKAH B — ISOLASI

Cek console: permintaan POST ke REST API terkirim, tapi respons status: 500. Masalah ada di back-end, bukan UI.

LANGKAH C — PERBAIKAN

Buka kode endpoint: kolom harga di database bertipe angka, tapi form mengirim teks berisi "Rp". Tambahkan pembersihan input sebelum simpan.

LANGKAH D — VERIFIKASI

Ulangi tiga kali skenario awal + coba input harga kosong dan harga negatif → semua tertangani, fitur lain (edit, hapus) masih normal.

Tool Debugging untuk Tiap Lapisan Aplikasi

FRONT-END (React Native)

console.log() untuk menelusuri nilai state dan props
React Native Debugger / Flipper untuk inspeksi komponen
Expo Go log viewer saat aplikasi dijalankan di HP

BACK-END & DATABASE (Python)

Postman / Thunder Client untuk menguji REST API langsung
print() dan traceback Python untuk lacak error
DB browser (mis. SQLite Browser) untuk cek isi tabel langsung

Prinsip: selalu cek dari sumber data, bukan dari tampilan. Kalau data salah di layar, cek dulu apakah API mengembalikan data yang benar sebelum menyalahkan komponen UI.

Hitung dari Nol: Densitas Bug Proyek Anda

Tim Anda menulis 2.500 baris kode untuk proyek akhir dan menemukan 8 bug saat sesi pengujian sebelum tenggat. Berapa densitas bug dan tingkat resolusinya?

Langkah	Perhitungan	Nilai
1. Total baris kode (LOC)	diberikan tim	2.500 baris
2. Konversi ke KLOC (ribuan baris)	2.500 ÷ 1.000	2,5 KLOC
3. Jumlah bug ditemukan	hasil sesi pengujian	8 bug
4. Densitas bug	8 bug ÷ 2,5 KLOC	3,2 bug/KLOC
5. Bug diperbaiki sebelum tenggat	hasil sesi debugging	7 bug
6. Tingkat resolusi bug	(7 ÷ 8) × 100	87,5%

Angka ~3–5 bug/KLOC saat pengujian pra-rilis dianggap wajar untuk proyek mahasiswa; yang penting tingkat resolusi mendekati 100% sebelum presentasi.

Bagian 2 dari 3

Evaluasi Kualitas & Checklist Testing

Dari "sudah jalan" ke "layak dinilai" — checklist testing menyeluruh dan rubrik skor berbobot.

Checklist Testing: Empat Lapisan Aplikasi

Lapisan	Yang Diuji	Contoh Pertanyaan
UI/UX	Tampilan & alur pengguna	Apakah tombol jelas, form mudah diisi di layar kecil?
Fungsionalitas	Fitur inti (CRUD, navigasi, login)	Apakah tambah/ubah/hapus data berjalan konsisten?
API & Integrasi	Komunikasi front-end ↔ back-end	Apakah semua endpoint merespons benar & cepat?
Keamanan Dasar	Validasi input, otentikasi	Apakah form login menolak input kosong/berbahaya?

Uji juga edge case (kasus batas): input kosong, angka negatif, koneksi internet terputus di tengah proses — bukan hanya skenario "jalan mulus" saat demo.

Banyak proyek mahasiswa hanya diuji dengan skenario "jalan mulus", padahal dosen penguji dan pengguna sungguhan hampir pasti akan mencoba hal-hal di luar skenario ideal itu. Lapisan UI/UX sering diabaikan padahal ini yang pertama kali dilihat penguji — form yang berantakan di layar HP kecil bisa langsung menurunkan kesan meski fungsinya benar. Lapisan fungsionalitas adalah inti operasi CRUD yang sudah Anda pelajari sejak pertemuan sebelas, jadi pastikan keempat operasi itu benar-benar konsisten, bukan hanya "create" yang berfungsi. Lapisan API dan integrasi penting karena di pertemuan dua belas Anda baru saja menyambungkan front-end dan back-end, titik sambung itu paling rawan bug tersembunyi. Terakhir, keamanan dasar sering terlewat mahasiswa pemula, padahal validasi input sederhana seperti menolak form kosong sudah cukup mencegah banyak masalah.

Empat Metrik Evaluasi Proyek Akhir

METRIK 1

FUNGSIONALITAS

Apakah semua fitur inti berjalan sesuai rencana di P1–P12?

METRIK 2

USABILITAS

Apakah aplikasi mudah dipakai oleh pengguna baru tanpa panduan?

METRIK 3

KEAMANAN

Apakah data pengguna & input tervalidasi dengan baik?

METRIK 4

DOKUMENTASI

Apakah laporan menjelaskan proses, bukan hanya hasil akhir?

Rubrik penilaian proyek akhir Anda kemungkinan besar mengombinasikan keempat metrik ini dengan bobot berbeda — mari kita hitung contohnya di slide berikutnya.

Empat metrik ini adalah kerangka evaluasi yang umum dipakai, baik di dunia akademik maupun saat startup mengevaluasi minimum viable product mereka sebelum peluncuran. Fungsionalitas biasanya mendapat bobot terbesar karena inilah inti dari sebuah aplikasi bisnis digital — tanpa fitur yang bekerja, sisanya tidak relevan. Usabilitas sering diremehkan mahasiswa, padahal aplikasi seperti Gojek sukses besar bukan karena teknologinya paling canggih, tapi karena mudah dipakai siapa saja. Keamanan menjadi makin penting sejak berlakunya Undang-Undang Perlindungan Data Pribadi, bahkan untuk proyek skala kuliah sekalipun, kebiasaan memvalidasi input harus dilatih sejak dini. Dokumentasi sering dianggap remeh, padahal dosen penguji dan calon investor menilai kualitas berpikir tim justru lewat laporan, bukan hanya lewat demo langsung.

Hitung dari Nol: Skor Evaluasi Berbobot Proyek

Tim penguji memberi skor 0–100 per metrik, lalu dikalikan bobotnya: Fungsionalitas 30%, UI/UX 20%, Keamanan 20%, Performa 15%, Dokumentasi 15%.

Langkah	Perhitungan	Nilai
1. Fungsionalitas (skor 80)	30% × 80	24,00
2. UI/UX (skor 90)	20% × 90	18,00
3. Keamanan (skor 70)	20% × 70	14,00
4. Performa (skor 85)	15% × 85	12,75
5. Dokumentasi (skor 75)	15% × 75	11,25
6. Skor akhir proyek	24,00+18,00+14,00+12,75+11,25	80,00

Skor 80,00 ini punya kelemahan tersembunyi: Keamanan (70) adalah metrik terlemah — itulah yang wajib diperbaiki sebelum tenggat, bukan metrik yang sudah tinggi.

Cara menghitung ini persis pola rubrik berbobot yang sangat umum dipakai dosen dan juga panel juri kompetisi startup mahasiswa. Perhatikan bahwa bobot fungsionalitas paling besar, 30 persen, mencerminkan filosofi bahwa aplikasi yang berfungsi baik adalah fondasi, sedangkan metrik lain menyempurnakan. Setelah menjumlahkan seluruh kontribusi berbobot di langkah enam, kita mendapat skor akhir 80,00 dari skala 100 — angka yang terlihat cukup baik. Tapi pelajaran penting slide ini ada di kalimat terakhir: skor total yang bagus bisa menyembunyikan kelemahan di satu metrik tertentu, dalam contoh ini keamanan hanya diberi skor 70. Tim yang cerdas akan memakai perhitungan seperti ini bukan untuk puas dengan skor total, tapi untuk mencari metrik terlemah dan memperbaikinya lebih dulu sebelum presentasi.

Coba Sendiri: Hitung Skor Rubrik Proyek Anda

Masukkan estimasi skor tiap metrik proyek akhir kelompok Anda, lalu amati skor akhir berbobot dan metrik terlemahnya.

Latihan Kelompok: Audit Bug Proyek Anda (20 Menit)

Kerjakan bersama tim proyek akhir Anda, gunakan alur debugging empat langkah dan checklist testing dari slide sebelumnya.

LANGKAH KERJA

Jalankan aplikasi Anda & coba semua operasi CRUD sekali lagi
Catat setiap bug yang muncul: jenis (sintaks/logika/runtime) & lapisan (UI/API/DB)
Terapkan reproduksi → isolasi → perbaikan → verifikasi pada 2 bug prioritas

YANG DIKUMPULKAN

Daftar bug (minimal 5) beserta klasifikasinya
Hitung densitas bug & tingkat resolusi tim Anda sendiri
Hitung skor evaluasi berbobot proyek versi tim (pakai bobot slide 13)

Hasil latihan ini langsung menjadi bahan mentah untuk bagian "Evaluasi Diri" di laporan proyek akhir Anda — jangan dibuang setelah kelas selesai.

Bagian 3 dari 3

Penyusunan Laporan Proyek Akhir

Mengubah temuan debugging dan evaluasi tadi menjadi laporan yang jujur, terstruktur, dan siap dipresentasikan.

Struktur Laporan Proyek Akhir yang Efektif

Bagian	Isi	Sumber
1. Ringkasan Proyek	Masalah bisnis & solusi aplikasi (1 paragraf)	Ide proyek P1
2. Fitur & Arsitektur	Daftar fitur, diagram alur data front-end↔back-end	P3–P12
3. Hasil Evaluasi	Checklist testing, densitas bug, skor berbobot	Slide 9, 11, 13
4. Bug & Perbaikan	Bug ditemukan, alur debugging, status akhir	Latihan kelompok
5. Keterbatasan & Rencana	Apa yang belum sempurna & langkah lanjut	Refleksi tim

Struktur lima bagian ini dirancang mengikuti alur logis: dari apa yang ingin dibangun, bagaimana ia dibangun, seberapa baik ia diuji, apa yang sempat rusak dan bagaimana diperbaiki, sampai apa yang jujur diakui belum sempurna. Bagian ringkasan proyek menghubungkan laporan ini kembali ke ide bisnis digital yang Anda rumuskan di pertemuan pertama, supaya penguji ingat konteks awal proyek Anda. Bagian fitur dan arsitektur adalah tempat Anda menunjukkan pemahaman teknis, termasuk bagaimana front-end React Native berkomunikasi dengan back-end Python lewat REST API. Bagian hasil evaluasi dan bug adalah bagian paling jarang ditulis dengan baik oleh mahasiswa, padahal inilah yang paling dihargai dosen karena menunjukkan proses berpikir, bukan hanya hasil akhir. Bagian terakhir, keterbatasan dan rencana, justru menaikkan kredibilitas laporan Anda karena menunjukkan kejujuran ilmiah, mirip bagian "limitations" pada paper penelitian.

Kebiasaan Menulis Laporan Teknis: Lakukan vs Hindari

LAKUKAN

Sertakan angka konkret (skor, densitas bug, jumlah fitur)
Jelaskan kenapa sebuah bug terjadi, bukan hanya apa yang diperbaiki
Akui bug/fitur yang belum tuntas secara jujur & terbuka

HINDARI

Tangkapan layar tanpa penjelasan alur kerjanya
Klaim "aplikasi sudah sempurna" tanpa bukti pengujian
Menyalin struktur laporan tim lain tanpa menyesuaikan konten

Dosen penguji dapat membedakan laporan yang ditulis dari proses nyata dengan laporan yang ditulis di menit terakhir — kejujuran soal keterbatasan justru lebih dihargai daripada klaim sempurna yang tidak terbukti.

Perbedaan antara laporan yang meyakinkan dan laporan yang terasa "asal jadi" biasanya bukan soal kerapian format, tapi soal kedalaman isi. Menyertakan angka konkret seperti skor evaluasi 80,00 atau densitas bug 3,2 per KLOC membuat klaim Anda bisa diverifikasi, berbeda dengan kalimat umum seperti "aplikasi berjalan lancar". Menjelaskan kenapa sebuah bug terjadi jauh lebih bernilai daripada sekadar menulis "bug sudah diperbaiki", karena itu menunjukkan Anda benar-benar memahami sistem yang Anda bangun, bukan hanya menyalin solusi dari internet. Di sisi yang harus dihindari, tangkapan layar tanpa konteks adalah kesalahan paling umum — sebuah screenshot form login tidak menjelaskan apa pun kalau tidak disertai penjelasan alur kerjanya. Terakhir, klaim "sudah sempurna" tanpa bukti pengujian justru mencurigakan bagi penguji berpengalaman, karena hampir tidak ada proyek mahasiswa yang benar-benar tanpa cela.

Latihan Individu/Tim: Kerangka Laporan Anda (15 Menit)

Gunakan struktur lima bagian dari slide 16 dan hasil audit bug dari latihan sebelumnya untuk mulai menulis kerangka laporan proyek akhir Anda.

TULIS SEKARANG

1 paragraf ringkasan proyek (bagian 1)
Daftar 3–5 fitur inti dengan status "selesai/sebagian/belum" (bagian 2)
Salin hasil skor & densitas bug dari latihan sebelumnya (bagian 3–4)

BAWA KE PERTEMUAN 14

Kerangka laporan lengkap lima bagian
Daftar keterbatasan & rencana perbaikan (bagian 5)
Draf 3 slide presentasi ringkas untuk demo

Laporan final & presentasi terstruktur akan disusun tuntas dan dipresentasikan pada Pertemuan 14 — pertemuan hari ini adalah fondasi datanya.

Ringkasan: Dari Bug ke Laporan Siap Presentasi

Empat langkah ini bukan tugas satu kali, melainkan siklus yang bisa Anda ulang setiap kali menemukan bug baru — bahkan setelah proyek akhir ini selesai, dalam pekerjaan nyata di industri bisnis digital.

Rangkuman ini menegaskan bahwa apa yang Anda pelajari hari ini bukan hanya untuk lulus mata kuliah Lab Pemrograman, tetapi kebiasaan kerja yang akan terus Anda pakai kalau kelak bekerja sebagai product manager, data analyst, atau bahkan mendirikan startup bisnis digital sendiri. Klasifikasi bug membantu Anda berpikir sebelum bertindak, alur debugging mencegah Anda menebak-nebak secara sembarangan, evaluasi berbasis angka membuat penilaian kualitas menjadi objektif bukan sekadar perasaan, dan laporan yang jujur membangun kepercayaan dengan siapa pun yang menilai kerja Anda, entah dosen, atasan, atau investor. Ingat juga bahwa siklus ini berulang — bahkan setelah proyek akhir selesai dan aplikasi Anda "sempurna" hari ini, bug baru akan selalu muncul seiring aplikasi dipakai lebih banyak orang, dan kerangka kerja yang sama tetap berlaku.

Menuju Pertemuan 14

Penyusunan Laporan Akhir & Presentasi Terstruktur

Bawa kerangka laporan, hasil audit bug, dan skor evaluasi Anda hari ini — minggu depan kita menuntaskan laporan final dan berlatih presentasi di depan kelas.

📖 Baca juga: Dcf Valuation — penjelasan mendalam dan contoh numerik.