Mengenal APIK, Aplikasi Ujian Kompetensi

Sebelum ada PurwaExam, ada APIK. Aplikasi Ujian Kompetensi — nama yang cukup jelas menyebut fungsinya sendiri, dibangun bertahun lalu, dan masih menyimpan jejak arsitektur PHP klasik yang khas zamannya.

Saya tidak membangun APIK dari awal. Tapi saya yang menangani perawatannya belakangan ini — termasuk migrasi kompatibilitas ke PHP 8.3 dan MySQL 8.4 — sebelum akhirnya jelas bahwa jalan ke depan bukan menambal terus, tapi membangun ulang. Tulisan ini soal APIK itu sendiri: apa isinya, bagaimana strukturnya, dan kenapa dia layak dikenang sebagai fondasi, bukan cuma “sistem lama yang diganti”.

Definisi Singkat

APIK (Aplikasi Ujian Kompetensi) adalah sistem berbasis web untuk menyelenggarakan ujian kompetensi — mengelola bank soal, peserta ujian, token akses, sampai rekap nilai. Fokusnya sejak awal memang ujian kompetensi lintas program studi, bukan ujian akhir per kelas mata kuliah.

Framework dan Arsitektur

APIK dibangun dengan CodeIgniter 3.1.13, salah satu framework PHP paling populer di era sebelum Laravel mendominasi, dipadukan pola HMVC (Hierarchical Model-View-Controller) lewat library Modular Extensions MX v5.5. Setiap fitur besar dipecah jadi modul mandiri — bukan satu folder controller raksasa yang menampung semua logika.

Databasenya MySQL, dengan nama skema apikdb. Waktu saya tangani kompatibilitasnya ke PHP 8.3 dan MySQL 8.4, satu hal yang jelas kelihatan: kode ini ditulis mengikuti kebiasaan MySQL versi lama yang lebih longgar soal tipe data. Ada satu error yang saya ingat betul — Unknown column 'telp' waktu update data mahasiswa, ternyata kolom aslinya bernama no_telp sementara seluruh kode PHP di modul itu mengacu ke telp. Bukan bug besar. Tapi butuh napak tilas satu-satu view dan model untuk pastikan tidak ada sisa referensi lama yang terlewat.

Modul yang Ada

Struktur modularnya cukup rapi untuk ukuran aplikasi seusianya:

• Admin — kelola akun admin dan pengelola
• Dashboard — ringkasan aktivitas
• Rumpun (dengan sub-modul Subrumpun dan LO) — struktur akademik berjenjang: rumpun ilmu → sub-rumpun → Learning Outcome, dasar pengelompokan soal
• Quation (bank soal) — CRUD soal, import lewat file, filter berdasarkan Learning Outcome
• Mahasiswa — data mahasiswa, termasuk import massal
• Participant — data peserta per sesi ujian
• Examination — peserta mengerjakan ujian dan mengganti password sendiri
• Token — generate kode akses ujian per sesi
• Score — penilaian, ekspor data, dan tiga jenis cetak berbeda: rekap admin, hasil peserta, dan lembar jawaban yang sudah dikerjakan
• Evaluasi — laporan evaluasi dikelompokkan per rumpun, sub-rumpun, dan Learning Outcome, lengkap fitur cetak
• Setting — pengaturan umum aplikasi dan pengaturan khusus ujian
• User — login, logout, ganti password

Cukup lengkap untuk kebutuhan ujian kompetensi murni. Yang tidak ada — dan ini jujur diakui, bukan aib — adalah konsep kepemilikan soal berbasis kelas, panel admin dengan peran granular, integrasi Safe Exam Browser, backup otomatis terjadwal, maupun audit log perubahan data. Semua itu masuk akal untuk aplikasi yang dirancang di masanya, untuk kebutuhan yang saat itu memang belum ada.

Kenapa Sejarah Ini Penting Diceritakan

Gampang menyepelekan sistem lama begitu ada yang baru. Tapi APIK bukan cuma “versi jelek dari PurwaExam” — struktur rumpun/sub-rumpun/Learning Outcome yang dipakai PurwaExam hari ini, konsep token akses ujian, sampai alur bank-soal-per-Learning-Outcome, semuanya diwariskan dari sini. PurwaExam bukan lahir dari kertas kosong; dia lahir dari bertahun pengalaman menjalankan APIK, plus satu kebutuhan baru yang tidak bisa lagi ditambal di arsitektur lama: ujian akhir per kelas yang soalnya harus rahasia.

Cerita lengkap soal kenapa dan bagaimana rekonstruksi itu dilakukan — termasuk sisi teknisnya — ada di PurwaExam: Studi Kasus Migrasi Sistem Ujian ke Laravel 13 & Filament.

Kalau Anda Masih Menjalankan Sistem “Zaman Dulu”

Banyak lembaga masih menjalankan aplikasi internal berumur 8-10 tahun yang sebenarnya masih berfungsi, cuma sudah tidak bisa mengikuti kebutuhan baru. Itu bukan berarti harus dibuang — kadang cukup dirawat dan disesuaikan versi PHP/database-nya. Kadang memang saatnya dibangun ulang dengan fondasi baru, sambil tetap menghormati apa yang sudah terbukti jalan bertahun-tahun. Kalau butuh yang menilai mana dari dua opsi itu yang tepat untuk sistem Anda, hubungi Sashindo.